Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Electron. Как работает самый современный desktop framework

Усі статті, обговорення, новини про Front-end — в одному місці. Підписуйтеся на телеграм-канал!

Что почувствует разработчик, если ему\ей предложат написать desktop приложение? Он\Она наверняка расстроится. Ведь desktop видится нам в эру браузеров и интернета чем-то отсталым и ненужным. Но что делать если наш софт должен работать без интернета, на слабой машине и и при этом мог быть установлен одним кликом мыши? Учить морально и физически устаревшие фреймворки типа WPF явно не вариант, ведь их потом негде будет применить. Да и в поддержке они не всегда хороши, особенно с учетом того что желающих это делать точно не стоит очередь.

В таких случаях нам на помощь придет ̶M̶r̶.̶ ̶P̶r̶o̶p̶e̶r̶ Electron. Кроссплатформенный JavaScript фреймворк с которым справится при небольшой подготовке любой front developer. В своем портфолио Electron имеет много популярных программ, таких как MS Teams, VS Code, Skype, Spotify, WhatsApp и т.д. Electron разработан и поддерживается GitHub, а так же имеет больше комьюнити.

Меня зовут Алексей Голубев, я работаю с Electron порядка 2х лет. И сейчас мы немного поговорим о том, почему топовые компании выбирают этот инструмент для своих приложений.

А что под капотом?

В Electron можно выделить две основные части.

  • Main process. Main отвечает за создание браузерных окон и взаимодействие с операционной системой. Физически это NodeJS.
  • Renderer process. Каждое браузерное окно запускает веб страницу в своем renderer process. При этом несколько renderer могут между собой общаться, но никак не влияют друг на друга. Это по сути Chromium. Но мы его видим как окно обычного приложения.

Общается это все безобразие между собой по IPC.

Схема потоков Electron

При таком количестве взаимосвязанных частей все это выглядит довольно нестабильно, однако это лишь на первый взгляд. Например, краш одного из renderer никак не повлияет на соседние renderer и приложение продолжит работу. К тому же как правило используются последние стабильные версии NodeJS и Chromium. Из опыта — крашится эта штука крайне редко и работает стабильно, несмотря на солянку из слоев.

Стоит отметить что с виду это очень похоже на модель «клиент-сервер», но это только на первый взгляд. На самом деле NodeJS (main process) прослойка здесь нужна только для взаимодействия с ОС и вызывать мы ее можем из renderer процесса. Если упростить, то управлять файлами на диске можно прям в ангуляровской компоненте. Поэтому принято использовать main процесс исключительно для запуска окон, установки апдейтов и других вещей которые следует сделать при запуске.

А сколько ест?

Кроссплатформенность еще никому не давалась дешево и за все нужно платить. С Electron мы платим накладными расходами за висящую в памяти NodeJS и Chromium (70 мб). Дальше уже начинаются расходы приложения и если вы не сильно абузите API операционной системы то ваше приложение скушает по памяти и CPU сравнимые с обычным браузером цифры.

К этому стоит добавить довольно объемный установочный файл (70-80 мб) и его распакованную версию (300 мб), если сравнивать с чем-то более менее нативным конечно.

В целом для современных машин это не много, учитывая что после накладных расходов на запуск приложение кушает так же как и в стоковом браузере.

Скриншот Spotify на пике при переключении треков

А как насчет производительности?

Из коробки все работает силами Chromium со всеми его преимуществами и недостатками. Это и JS движок, и однопоточность, и песочница которая изолирует нас от операционной системы.

Если же вам этого не хватает вы можете запускать силами NodeJS child process. Так делают многие вендоры, наглядней всего это выглядит у VS Code.

Visual Studio Code умеет интегрироваться с консольными утилитами, подключать дебаггер, запускать линтер и все в отдельных процессах.

А такие бибилиотеки как Electron.NET позволяют запустит дочерним полноценный .NET Core и общаться с ним как с обычное клиент-серверное приложение. Таким образом в 1 клик по инсталлеру мы можем разместить на компьютере пользователя и клиент, и сервер, и портативную БД. Таким образом превратив, например, наше классическое веб приложение в десктоп.

Скрин процессов простаивающего Electron.NETприложения.

Есть еще одна особенность NodeJS которую мы можем использовать — импорт C/C++ библиотек (Native Addon), как это делает например Skype. Skype использует библиотеки по работе с медиа, кодеками и прочими вещами, которые довольно проблематично поддерживать вне C/C++.

А как с дебагом и автотестируемостью?

Как мы уже обсудили, есть 2 основных процесса — main и renderer. Их мы и можем дебажить, раздельно естественно.

Для дебага main достаточно запустить Electron с открытым портом под дебаг примерно так же как это делается в NodeJS и подключиться дебагером, например VS Code.

Дебаг renderer чуть сложнее и вариативней. Так как это по сути браузер то нам доступно 2 способа — подключиться к открытому порту для дебага либо открыть DevTools. Если вы используете WebPack, то учитывайте наличие source-map файлов в конечном бандле. К тому же у WebPack есть специальные target «electron-renderer» и «electron-main».

Скриншот открытого DevTools в Electron приложении

На этом этапе тесты можно разделить на 2 типа.

  1. Инфраструктурные. В случае с десктоп приложение мы отвечаем не только за работу приложения, но и за его установку, запуск, доставку, апдейд, удаление и т.д. Тут автотестеру придется освоить новые трюки, но особо проблем быть не должно, разве что с кроссплатформенностью. Либо же оставить эти тесты мануальными.
  2. Тесты приложения. И здесь все хорошо. Electron поддерживается многими фреймворками и документация изобилует примерами. Есть поддержка Selenium и WebDriver, Headless CI Systems (Travis, Jenkins). А если вам и этого мало, то можно использовать даже расширения для DevTools. Ваш тестировщик\тестировщица скорее всего довольно быстро разберется и не заметит особой разницы с веб приложением.

А есть ли подводные камни?

Подводные камни как и в любом проекте есть. Например версионирование. Вначале проект развивался довольно неспешно и мажорные версии выходили редко. Сейчас за ними не угнаться. Версия 11.0.0 вышла спустя 3 месяца после 10.0.0. При том что версия 3.0.0 вышла только спустя год после 2.0.0.

Многие версии включая версию 1(1.8.8) до сих пор получают обновления. Однако при обновлении на мажорную версию листайте ченжлог. К сожалению такой удобной миграции как в Angular не завезли и что-то может сломаться просто потому что какой-то из дефолтных флагов стал false вместо true.

Как писалось выше, мы делаем все операции бизнес логики делаем в renderer, т.е. на фронте мы можем вызывать fs и юзать диск, или ходить по ссылкам на другие ресурсы. Часто в таких случаях мы подключаем вспомогательные библиотеки которые могут быть рассчитаны на NodeJS, а не браузер. Поэтому вести они могут себя не так, как мы того ожидаем. При добавлении новых библиотек всегда есть шанс что нужно будет модифицировать конфиг webpack.

И что в итоге?

В итоге мы имеем:

  • кроссплатформенный JS фреймворк
  • мощный и расширяемый как нативными модулями, так и подпроцессами
  • не требователен к компетенции разработчиков, нам хватит front-end с хорошим знанием JS
  • совместим с TypeScript
  • имеет большое комьюнити и обширную библиотеку вспомогательных пакетов

Electron своей простотой и низким порогом входа постепенно вытесняет другие решения в десктопной разработке. Безусловно у фреймворка есть свои нюансы, которые нужно знать и работа с ним, как и с любым другим столь мощным современным инструментом, не будет легкой прогулкой. Однако, на данный моменту нас почти нет альтернатив, которые обеспечат то же качество и скорость разработки. Да и всем удобней, когда мы имеем на веб сайте и десктоп приложении теже UI/UX решения.

А что вы думаете по этому поводу? Как перенести красоту и функциональность наших веб сайтов в десктоп или этого не стоит вообще делать?

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному4
LinkedIn

Найкращі коментарі пропустити

Боже, какой треш.
Электрон это пожалуй самый хреновый выбор для десктопа. Я видел постман, занимающий 8гб после прогона тестов. Мне хватило.

Это с каких пор WPF — устаревший desktop framework?
Если бы прозвучао MFC — да, это уже легенда, но .NET framework называть устаревшим, это, пожалуй, через чур.
JS Electron — хм... это подойдет в случае, если вы хотите сделать очень простой интерфейс и вы владеете только JavaScript.
Это Microsoft может себе разрабатывать на Electron: Teams, Skype. Потому что у них ресурс, который мало с кем сравним в аутсорсе. Или Facebook для своего одноименного продукта, исопозуя React Native.
Или Linkedin — который на Flutter, что даже на нормально дивайсе (не самый последний) с отличным Wi-Fi соединением тормозит просто ужас.
Если же вы все-таки за качество, то все же как-то попытаетесь частями запустить на разных платформах продукт нативно. Просто потому что у вас не будет столько времени бороться с определеными потенциальными багами на разных платформах. Это касается всех платформ.
Все эти квази-кроссплатформенные фреймворки могут быть использованы с моей точки зрения только для прототипирования, MVP — чтобы привлечь инвестора или уж совсем что-то простое. Все остальное от Лукавого.
Насмотрелся на я на этих кроссплатформенных Френкенштейнов. Особенно на один продукт, который мне показали на React Native... Это было нечто.
Просто для кастомера, когда звучит сочетание одна кодовая база и мы покрываем все платформы — загораются глаза. Ибо зачем платить больше. По итогу все выходит — как всегда...

640 Гигабайт оперативной памяти хватит всем!

Не, я понимаю, что вэберу может срочно понадобиться написать какой то десктоп в 3 окошка, которые выжрут ХХХ гигабайт и у него времени нету учить тот же С#, Но плиз, не неужно никаких сравнений с нэйтив технологиями.

висящую в памяти NodeJS и Chromium (70 мб)

До какого же изумительного треша докатилась индустрия, если вот это порождение чудовищного ума стало мейнстримом. Веб-фронтенд был костыльным ужасом во все времена, так теперь этот кошмар перетащили и на десктоп, да ещё и обернув его в дичайшие абстракции с несколькики процессами, локальным http-сервером и движком для рендера html, виртуальной машиной для javascript, и всё это выжирает ресурсов в сотни раз больше, чем бортовой компьютер, на котором спейс-шаттл автоматически летал в космос.

Лично мне кажется, что кросс-платформенности можно было достичь гораздо меньшей ценой, чем изобретать этого уродливого монстра.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

So far the best part of the electron ecosystem is the pervasive use of JavaScript.

Whoops I meant worst. So easy to make that mistake when nothing is validating the types of words you write as you’re writing them.

nothing is validating the types of words you write as you’re writing them

TypeScript? Не, не слышал

По десктопу js занимает 2%, в топе С# 34%, потом кресты 31%, даже у паскаля/делфи 5%. Ну хде тут хваленный электрон вытесняет другие решения ? :-)))
dou.ua/...​language-rating-jan-2021

Ты же делай скидку на то, что этот рейтинг — про аутсорс. Конечно, на аутсорс будут охотно отдавать поддержку как корпоративных Windows-only десктоп приложений на C#, так и уже созданной ранее базы кода на C++/Qt.

И, это уже не говоря о том, что сравнивать напрямую десктопный С# с Электроном не вполне корректно, так как кросс-платформенной десктоп разработки на C# практически не существует (формально, есть GTKSharp и Avalonia, но никакой серьёзной ниши они не занимают).

А про те же кресты в том же опросе очень красноречиво говорит график личных предпочтений, где доля крестов даже в 2013м году была 7.5%, а сейчас и вовсе снизилась до 4%. И, посмотри для сравнения, как прёт в гору TypeScript.

А тайп скрипта в рейтинге десктопе вообще нет :-)

Странно, вот в вебе полно нового стэка в аутсорсе, те же реакты и ангуляры, дотнет кор на каждом углу. А вот с десктопом переход на электрон, не происходит.

Могу объяснить это только тем, что новой кросс-платформенной десктоп разработки, в принципе, мало. И там, где она есть — делается in-house продуктовыми компаниями.

Это же объясняет отсутствие TypeScript в рейтинге десктопа.

P.S. Кстати, в Facebook, наверное, идиоты работают, раз выбрали Electron для десктопной версии WhatsApp?

Кстати, в Facebook, наверное, идиоты работают

наверное

Так это... сделай им коммерческое предложение — перепишу ваш WhatsApp на Qt быстро и дёшево, летать будет так, что никакому Электрону и не снилось. Цукерберг позвонит (может быть).

А оно им нужно?
Я думаю они об этих всех недостатках знают, но оно им не нужно.
У них там свои KPI и приоритеты. Плюс вездесущий javascript дает возможность шарить инженеров на разнообразные задачи.
Они зарабатывают деньги, а не делают «идеальный» продукт.

А оно им нужно?

Ну, это шутка была, если что :) Конечно, не нужно — иначе сами FB давно бы уже наняли десктоп разработчиков на том же Qt.

А так, ты всё правильно написал:

вездесущий javascript дает возможность шарить инженеров на разнообразные задачи.
Они зарабатывают деньги, а не делают «идеальный» продукт.

— и именно этого не хотят понимать самые завзятые хейтеры js / Electron.

Так собственно за это и хейтят фб и его продукты — продукт говно, альтернатив нет, контора решает лишь свои проблемы и пох на качество.

Лично я фб использую лишь для авторизации на некоторых сервисах и связь с одним человеком, который там сидит по определенным причинам.
Вотсапа у меня нет и не будет.

Хваленый электрон используют лишь в небольшой нише чтобы накидать по быстрому корявое но абы как рабочее и скинуть проблемы с качеством на пользователя, аля «докинь планочку памяти» и прочее.

Так уже юзано-переюзано, это регаться по новой а у меня в тудуисте уже неск сотен заметок напоминалок, ссылок, много проектов там...
Собственно можно и гугел юзать а не фб, но регаться по новой это блин гемор.

уже бегу

Цукерберг позвонит

боже упаси

Я не знаю по каким критериям выбирали в фб. Сам их сайт конечно днище еще то, тормозное и уродское.

P.S. Кстати, в Facebook, наверное, идиоты работают, раз выбрали Electron для десктопной версии WhatsApp?

Откройте ссылку: apps.apple.com/app/facebook/id284882215
Посмотрите отзывы, посмотрите среднюю оценку: 2.7 из 5-ти.

Оценка WhatsApp для iOS:
apps.apple.com/...​app-messenger/id310633997
4.8 из 5-ти

Оценка WhatsApp для MacOS(На Электроне):
apps.apple.com/...​sapp-desktop/id1147396723
2.2 из 5-ти

Я так понимаю Facebook еще стал вводить «покращенння» для WhatsApp for iOS.

посмотрите среднюю оценку: 2.7 из 5-ти.

Да хоть 1 из 5ти. Неужели вы не понимаете, что всё равно будут пользоваться, потому, что если хочется общаться через WhatsApp с десктопа — то альтернатив попросту нет?

Ну и ещё один момент, более объективный. Не знаю точно про WhatsApp, но, в целом, в приложениях такого плана важен не только чат, но и видеозвонки.

С чатом и то не всё так просто — сейчас «под капотом» у многих XMPP, а для него под те же плюсы я не видел нормальных клиентских библиотек, кроме убогой libstrophe.

А уж если говорить про видеозвонки, то из нативных альтернатив встроенному в браузер WebRTC есть, разве что, GStreamer, в который недавно завезли поддержку WebRTC. Но, GStreamer, по отзывам коллег, кто имел с ним дело — это для тех месье, которые знают толк в извращениях.

Только эти решения принимают не «джаваскриптеры», и не технари вообще, а бизнес.

Ну, вот в рынке корпоративных чатиков лидеров рынка попытался потеснить Zulip. Угадай с одного раза, на чём написан их десктоп клиент?

Телеграм не конкурент корпоративным чатам. Он в топе в потребительском сегменте, куда, из всех обсуждаемых конкурентов «метит», разве что, Скайп.

И то, Скайп не совсем прямой конкурент Телеграму. Видеозвонки в «телегу» завезли только в 2020м, и то в альфа-версии. До этого же, телега была про чаты и только про чаты — да и сейчас остаётся преимущественно именно чатилкой.

А Скайп с момента своего появления использовался больше именно для видеозвонков. А чат был уже так, приятным приложением.

Если кого телега и вытеснила, так это Вайбер, да и то, с натяжкой. Среди тех, кому 35+, Вайбер ещё вполне уверенно держит позиции.

пора б молодим стартапам потрясти «лідерів ринку».

Zulip, действительно, не самый удачный продукт. Но — как-то не видать других желающих хотя бы попробовать потрясти лидеров рынка.

Ну хоч сервер не на жабоскрипті.

Какой-то странный, я бы даже сказал, религиозный хейт JavaScript.
На сервере-то он чем вам не угодил?

Якась релігійна любов до JavaScript. Інструмент підбираються під задачу. Ви, як СТО, мали б це знати. І є на багато ефективніші інструменти для серверних рішень

Это не у меня религозная любовь к JS. Я серверные решения писал преимущественно не на JS.

Вместе с тем, и религиозной ненависти к JS я тоже не понимаю. Для ряда задач на бэкенде он ничуть не хуже того же Python или .NET Core.

К тому же, неприятно, что Александр подтасовывает факты.

Типизация и «нормальный ООП» решается TypeScript (и, если что, в том же Python «нормальной» типизации тоже нет, как и приватных членов класса, например)

Worker threads в NodeJS давно уже завезли; другое дело, что не так и много задач, для которых нужен именно отдельный поток, а не штатные средства асинхронного ввода-вывода.

Где NodeJS будет действительно неэффективен — так это в CPU-intensive нагрузке (да и то, с появлением worker threads этот недостаток довольно сильно нивелируется). Так для таких задач его и не применяют.

смешно, если у вебртц под капотом гстример работает

Судя по содержимому модуля video_coding, вряд ли:
webrtc.googlesource.com/...​ter/modules/video_coding

Да хоть 1 из 5ти. Неужели вы не понимаете, что всё равно будут пользоваться, потому, что если хочется общаться через WhatsApp с десктопа — то альтернатив попросту нет?

Как показывает история с месенджерами, люди долго не пользуются таким, и при первой же возможности переходят на другой месенджер, уже было их огого, но истоия продолжается как день сурка.

общаться через WhatsApp с десктопа — то альтернатив попросту нет?

веб версия

в Facebook, наверное, идиоты работают, раз выбрали Electron для десктопной версии WhatsApp?

Судя, по последним изменениям в самом Фейсбуке (веб) — таки идиоты...

Читаю комменты и не могу понять почему у некоторых так пылают джёппы?
Их заставляют писать на «трешовом» электроне? вроде нет
Их заставляют пользоваться приложениями, написанными на электроне? да, но только минимально, по работе.
Им насильно суют электрон в глотку? Заставляют писать ему хвалебные статьи? Бьют палкой?

Из всего сонма комментариев вынес только одну причину, которую с натяжкой можно принять — у некоторых рабочие чатики расположены в электрон-приложухах. Всё.

Не нравится вам электрон? Ну так не пишите на нем, оставьте мс тимс, скайп, слак только для работы. Судя по тем же комментам работы на альтернативах типа qt и прочих жаваэфыкс валом, она хорошо оплачивается и качество поделий выходит в разы лучше. Зачем же лишний раз подогревать планету сгоревшими пуканами?

Обычные пользователи должны быть санитарами леса, обычные пользователи могут и должны проголосовать долларом — уйти к конкурентам, у которых не тормозит. Например: «тормозит у меня вебшторм, перейду-ка я на ВСкод».

Так а нет прямых конкурентов Teams и Slack. В этом же и дело.

«Просто чатов» — хватает. «Комбайнов», поддерживающих кучу интеграций с различными инструментами — хотя бы даже такого уровня нет.

Звучит как свободная ниша на рынке.

дай угадаю с одного раза, чем бы ты ее заполнил

Угадывай. Мне аж самому интересно.

А вот не факт. У того же Slack недавно были проблемы с прибыльностью, так как Teams очень сильно поджимают их в нише корпоративных мессенджеров

Почему тут так много людей дрочат на всякое легаси? К чему этот срач?
Я еще года 4 назад знал что Electron это новый стандарт для десктоп приложений, как только Visual Studio Code вышла. А все так пишут как будто его только вчера анонсировали как Blazor.

Блейзор говно, начал писать апп для себя и забил хер, п**ц какая тормознаая первая загрузка, хотя там логики почти ноль было, ток начал писать апп, дебаг через такую лутую срак...Короче удолил и начал писать на старом добром asp .net mvc + jQuery на фронте.
Юзал клиентский блейзор, не серверный.

Потому что вжикквери и есть норм фреемверк, минимальный и простой, SPA мне не нужен, там простой дизайн/UI с гридами, формами и загрузкой/отображением картинок, модные реакты/ангуляры и прочее говно будет оверхедом шо ппц.

SPA мне не нужен

А будто если бы стал нужен, то это мол все бы изменило и ты бы выбрал фреймворк? Достаточно же скачать какой-нибудь jquery-router на 150 строчек и продолжай писать свое спа дальше.

Блейзор то говно, не спюрю, но нахуя ты на JQuery перешел?
Надо было на Angular писать, но очень похож на .NET и работает нормально.

asp .net mvc + jQuery на фронте.

Это уже некромания, я бы за 2х текушей ЗП бы к тебе не пошел бы.

Я проект для жены пишу, никакой команды нет, он должен решать четко поставленные проблемы, и желательно поскорее, а не создавать/монетизировать жопочасы в джире.

+ jQuery на фронте.

А еще говорят, что jQuery якобы надо хоронить) Вангую, что он переживет все эти ваши ангуляры с реактами и вебассемблями))

Короче удолил и начал писать на старом добром asp .net mvc + jQuery на фронте.

+1, вот буквально недавно сдал проект на том же самом. Со всякими реактами ебанины было бы в два раза дольше, и стоимость соответственно. Можно было бы и не получить проект с 2x эстимейтами.

Это называется «На чём быстрее всего сделать проект? На том, во что ты уже умеешь» :)

А тут не про то что занешь, а про оверхэд и овер-инжиниринг. Многим сайтам не нужен спа от слова совсем.

Многим сайтам не нужен спа от слова совсем

Сайтам — вполне возможно. А иногда, так и вообще вреден, так как потом для целей SEO начинаются танцы с бубном в виде server-side rendering.

Но это — сайтам, где у тебя большинство статического / отдаваемого с сервера контента, куда в паре-тройке мест нужно добавить браузерного интерактива.

Но я, к сожалению, видел обратные примеры, когда подход «SPA не нужен» из-за неумения в React / Angular применяли к Веб-приложениям с предсказуемыми последствиями в виде полной перезагрузки страницы при переходе с одного экрана на другой.

А я видел как «перерндерить лишний раз вьюшечку» не впадо и «юзер не заметит», в итоге спа куда более ормознутее и корявее с кучей оверинжиниринга, говнокода (реактивное программирование — умри) чем простые постраничные сайты.
Все это делалось потому что «спа с реакт и ангуляр везде пишут», «все так пишут ну и значит мы будем писать», «фейсбук так пишеь», «а вообще мы другого в жизни и не видели»....

«перерндерить лишний раз вьюшечку» не впадо и «юзер не заметит», в итоге спа куда более ормознутее и корявее с кучей оверинжиниринга, говнокода (реактивное программирование — умри)

Ну вот ты сам разве не замечаешь, как неявно — а, может быть, и умышленно — в своих комментариях ставишь знак равенства между самой технологией и неумением её использовать / отсутствием инженерной культуры в принципе?

Реактивное программирование — если под этим понимается RxJS и аналоги — в SPA никто использовать не заставляет. В ReactJS так точно.

«Перерендерить лишний раз вьюшечку» — опять же, могу говорить только про React — если горе-разработчик не разобрался даже с shouldComponentUpdate / React.memo, то это к чему вопрос — к уровню знаний и навыков конкретного разработчика, или к самой технологии?

Весь джаваскрипт а особеноо новомодные фреемверки, это полное отсутсвие инженерной культуры, там только «создать самому проблему, а потом героически ее решать»
То что на выходе массово получается тормознутое говно лишний раз доказывает что js и уеб-девелопмент это «гамно баба, гамно дед, гамно пасика и мэд». Поэтому если есть возможность сильно упростить я выберу это.

Да, это 1.
2. — там был фиксед прайс, при этом нужно было конкурировать за цену. И понятно нужно было минимальный объем неопрелленгости.
3. Интерфейс предполагался довольно несложный, то что на Мвс — джквири вполне доступно сделать
4. До этого был еще один похожий проект на том же, из которого можно было переиспользовать определённые компоненты.

Почитав коменти, поржав.

В бізнесі рішає time to market. Поки фанати qt і інших мертвих технологій будуть завершувати свою альфу, електронщікі вже отримають свою першу тисячу користувачів, матимуть відгуки і покращать продукт, і це все поки qt-шники пилять альфу.

Память? Пф... Якщо продукт вирішує вашу проблему — докупите ще пару Гб.

і що, хоч хтось відмовився від слака чи тімза, бо там багато жреться памяті? просто всі мучаються да і все.

Скайп десь так помирав

Скайп помирав зовсім по іншим причинам

Те що у хом’ячків

Хомяки це основа ринку. А думка парочкі гіків нікого не цікавить, вони не приносять кеш.

В бізнесі рішає time to market.

На самом деле нет. Сырой продукт потом хейтят так, что не отмоешься (потому что конкуренты не дадут)

Поки фанати qt і інших мертвих технологій будуть завершувати свою альфу, електронщікі вже отримають свою першу тисячу користувачів, матимуть відгуки і покращать продукт, і це все поки qt-шники пилять альфу.

Высокая скорость разработки на языках с динамической типизацией — опасный миф. По факту скорость падает раза в три по сравнению с плюсами.

факту скорость падает раза в три по сравнению с плюсами.

Факт который мы можем наблюдать «в природе»
До определённого размера кодовой базы скорость разработки на ruby, php, python, js — выше чем на java, c#

Вопрос только в определении этого уровня, на который влияет компетенция команды.

Но скорость разработки -это топ3 параметр влияющий на популярность применения ЯП или технологии

Скриптові мови добре підходили для написання скриптів.

То вони й зараз підходять для скриптів та прототипів. Але хто що під скриптом розуміє — то вже таке.

Я не знаю за шарп, але нещодавно знайомий казав, що написав математику для еліптичних кривих на пітоні за вечір, а на плюсах застряг би на місяць, задепресував би та й кинув цю справу.

Мне тут кажется, что это вопрос не сколько самого языка, сколько доступности готовых либо стандартных, либо сторонних библиотек под него.

Python, да, силён тем, что под него куча готовых библиотек под всяческую математику, благодаря популярности языка в data science.

Еще на нем очень легко писать. Даже говорили про синдром привыкания, когда любой другой язык потом кажется уродством. Я начинал с Питона и почувствовал.

Еще там штука, как и в С, что пишешь как думаешь. А вот в С++ на каждом шагу 8 или 11 разных методов отстрелить ногу, и все время надо думать, какой из них выбрать. Поэтому кодится очень медленно, пока не набросал себе всю нужную инфраструктуру.

На самом деле нет

Гугл, амазон і фейсбук сміються тобі в обличчя.

Высокая скорость разработки на языках с динамической типизацией — опасный миф.

Динамічна типізація тут ні до чого.

приятно слушать человека, который одновременно не понимает ни кьют ни аппаратные ограничения платформ

Потому что проект тудушка, такое пойдет для электрона, для чего то посложнее через годик/другой утонет в собственном овне из багов и костылей.
Про вижуал студио код не надо плес, там ресурсы мама не горюй и инжнеры таки куда лучше чем в местных DumayGopoySoft тимлиды пихающие тупо модныее фреемверки в проект без мыслей надо оно или нет.
И опять таки скайп и тимс отвратные и лично я ими пользую по одной причине — принятый канал связи на проекте, лично для меня они и нах не нужны и считаю их паршивыми программами как с точки зрения по тебляемых ими ресурсов так и юзабилити.
А планку памяти мне на дом компе уже подкидывать нет куда, да и проще в телегу написать или в фейстайм позвонить чем апргрейдить комп для очередной софтины у которой куча аналогов.

я ими пользую по одной причине — принятый канал связи

І це тут ключове. Продукт зробили, зайняли нішу. Тепер ви змушені цим користуватися. І бізнес Ваша точку зору про «ресурси» не цікавить, бо ці ресурси (РАМ) дешеві.

Електрон може в веб. Більше WPF/Qt в веб толком не можуть. Тому вони не є йому конкурентами.

Qt может в WebAssembler

Думаю сексу буде забагато, це дуже не mainstream шлях, тому там граблей дофіга може бути. Хтось реально його використовує?

Думаю сексу буде забагато, це дуже не mainstream шлях

какой секс? берещ приложение, написанное на кьют, пересобираешь, запускаешь

Удивило количество хейтеров электрона и js в целом. Любой инструмент это про то, как ускорить/упростить/удешевить достижение цели. И в мире, где больше половины разработчиков так или иначе вынуждены знать js, и есть много специалистов которые действительно хороши, не удивительно что есть инструменты заточенные под эти знания.
И речь даже не о кроссплатформенности. Когда есть команда, которая умеет делать веб приложения, её легко пересадить на электрон, сильно легче чем на Win Forms, WPF, Qt и подобное. И качество будет выше, чем если бы эта же команда с нуля учила С#/С++/Java на один-два проекта, и дешевле чем собирать новую команду, и не разбегутся фронтендщики от предложения выучить джаву.

Поддерживаемость кода может быть частью цели команды, я не говорил про написать один раз. И код на знакомом языке программист поддерживает лучше чем на незнакомом.

яка різниця писати на тайпскрипті чи на шарпі

Разница в знании библиотек и особенностей рантайма. Сам язык это капля в море.

Есть софтинка десктопная Clockify. Там 3 кнопки и пара надписей. Оно глючит, что при запуске, что при ресайзе окна. Мерзость.

Удивило количество хейтеров электрона и js в целом.

Электрон решает проблемы бизнеса (time-to-market, development-cost)
Но не решает проблемы конечных пользователей (ux)

И в мире, где больше половины разработчиков так или иначе вынуждены знать j

Это, пожалуй, и есть основная (хоть и другая) проблема — js очень часто применяется сильно не к месту, и там, где лучше было бы без него.

js очень часто применяется сильно не к месту, и там, где лучше было бы без него.

«Все, что может быть написано на JavaScript, — будет написано на JavaScript»
— (ц) Джефф Этвуд (Jeff Atwood) — один из создателей Stack Overflow

Сам вот последние полгода подумываю, а не перейти ли на TS/JS
на беке то делать — тоже самое, а платят — просто больше и все.

от всех кого виртуально, но знаю, и поэтому прислушивась, пишут примерно вот такое,
...
Поговорил с парой рекрутеров в #Канада
— Величайший спрос на React Native. JS-ники долго раскачиваются по мобильным технологиям, мобильщики нифига не понимают в React. В среднем, конечно. Вообще, войтивайтишникам я бы советовал смотреть сюда. Конечно, все хотят синьоров, но когда так сильно не хватает — то новичков тоже берут.
— Огромный спрос на React / Redux / Typescript.
— Большой спрос на node / Go.
— Микросервисы на любом языке тоже могут дать билет в жизнь.
— На QA спрос падает, много аутсорса в Индию. Хотя автоматизаторы вполне имеют шанс.
— PHP спрос околонулевой в стартаперской тусовке.
— Про менеджеров я даже не спрашиваю уже.
— «Крепкий джун просит 70, синьор с семилетним опытом — 140. Ну и какой смысл брать джуна?»

--- другой:
С появлением SPA, многое изменилось. Backend уже не отдает HTML, он упростился настолько, что он теперь stateless. Он теперь отдает простой RESTful API.
Фронтенд сейчас доминирует по сложности и объему. Я регулярно снимаю метрики со своих проектов. В Volicon и Verizon объем кода фронтенда, который написан на JS/HTML/CSS, превосходил объем бэкэнда, который дает API, в четыре раза. Примерно так же соотносилось количество людей, занятых во фронтенде и бэкэнде.

Благодаря тому, что сложность и затраты переехали во фронтенд, как-то сама появилась новая профессия — фронтенд-инженер. Они не дизайнеры, но хорошо понимают что красиво, а что уродливо. Они не юзабилисты, но отлично умеют предсказывать, когда и за что придут юзабилити-баги. Они не продакт-менеджеры, но прекрасно разбираются в требованиях. И они обязаны быть очень хорошими программистами
...
Фронтенд-инженер — это инженер, который встречает требования первым, и никогда не трактует их буквально. Он не должен психовать что они меняются, потому, что он понимает, что никто на самом деле ничего не требует — это мы вместе с продакт-менеджерами пытаемся догадаться, как решить проблему пользователя, которую он нихера не осознает.

Прекрасная это работа — фронтенд-инженер. И если вы прям кровь из носу хотите, чтобы он был fullstack и оставался при этом хорошим frontend — дайте ему *ядь писать бэкенд на том же языке что и frontend. Это TypeScript. Не переживайте — это очень хороший язык.
(конец цитаты)

так я этим — встречает требования первым, и никогда не трактует их буквально. Он не должен психовать что они меняются, потому, что он понимает, что никто на самом деле ничего не требует — это мы вместе с продакт-менеджерами пытаемся догадаться, как решить проблему пользователя, которую он нихера не осознает. — и занимаюсь почти всю свою программерскую карьеру

а платят — ой по разному.
за TS/JS — больше...

веб — и фронт и бекенд на джс. мобилки — на джс, с разными вариантами. десктоп — на джс. робототехника/умные дома — на джс. игры — и те на джс пишутся (правда казуальные)

единственное — лоу левел не на джс по очевидным причинам

кто выпилюет кто запиливает. по большому счету, джс — крайне удобен и универсален, кто уж без типов никак не может — юзает ТС

мобилки — на джс

Распятие и святую воду куда нести?

Попробуй свою голову ею окропить может мрак выйдет

А что еще делать с кривыми ReactNative, Cordova?

Это вредительство для области.

Обратись к экзорцисту — он поможет

А тебе бы к наркологу

Я не пью и наркоту не жру, так что не по адрессу

А те же:
* Не перехожу на личности
* Не применяю js везде там где это нужно и не нужно.

И способ приема не важен.

Это с каких пор WPF — устаревший desktop framework?
Если бы прозвучао MFC — да, это уже легенда, но .NET framework называть устаревшим, это, пожалуй, через чур.
JS Electron — хм... это подойдет в случае, если вы хотите сделать очень простой интерфейс и вы владеете только JavaScript.
Это Microsoft может себе разрабатывать на Electron: Teams, Skype. Потому что у них ресурс, который мало с кем сравним в аутсорсе. Или Facebook для своего одноименного продукта, исопозуя React Native.
Или Linkedin — который на Flutter, что даже на нормально дивайсе (не самый последний) с отличным Wi-Fi соединением тормозит просто ужас.
Если же вы все-таки за качество, то все же как-то попытаетесь частями запустить на разных платформах продукт нативно. Просто потому что у вас не будет столько времени бороться с определеными потенциальными багами на разных платформах. Это касается всех платформ.
Все эти квази-кроссплатформенные фреймворки могут быть использованы с моей точки зрения только для прототипирования, MVP — чтобы привлечь инвестора или уж совсем что-то простое. Все остальное от Лукавого.
Насмотрелся на я на этих кроссплатформенных Френкенштейнов. Особенно на один продукт, который мне показали на React Native... Это было нечто.
Просто для кастомера, когда звучит сочетание одна кодовая база и мы покрываем все платформы — загораются глаза. Ибо зачем платить больше. По итогу все выходит — как всегда...

Linkedin — который на Flutter, что даже на нормально дивайсе (не самый последний) с отличным Wi-Fi соединением тормозит просто ужас.

Samsung s10e, никаких особых тормозов в LinkedIn не замечал. Баги — есть, да. Но, в плане скорости работы, я даже не подозревал, что это не нативное приложение.

В файрфоксе на ноуте при 10К контактов тормозит по-черному и глючит.

пока не тормозит.
щас пишут такое говно на флаттере и реакте, что даже на девайсе с 6ГБ ОЗУ и 8 ядрами тормозит нещадно

А откуда инфа, что LinkedIn на флаттере? Ведь оно не на флаттере

Если честно, то, если не изменяет память, где-то видел список приложений. Но вот не помню — где. Если есть линк, что освежит память, будет ок. Но, по-моему, точно не нативно написано приложение.

Я думал там RN какой нибудь, но внезапно (!), там натив:
i.imgur.com/ErKnVLP.png

Можно линк на github? Это точно апп, а не SDK? Потому как под их акком на github ничего такого не нашел.
Или я таки что-то с Linkedin напутал? :)

Это я декомпильнул apk :) Исходников на гитхабе, конечно, нету.

, но .NET framework называть устаревшим, это, пожалуй, через чур.

так и есть. И С# и нет хреньмворк вещи очень древние, парадигмы с их выпуска не менялись, а приехало очень много качественно много нового. Вон как например с типами в TS, с HKT и метой в скале.

сли бы прозвучао MFC — да, это уже легенда

уже история

Все остальное от Лукавого.

аргументы? точно ли в 100% вещей нужно именно настолько все быстро что на кроссплатформенную прослойку нету места, и маленькие платформозависимые кусочки не срабатывают?

который мне показали на React Native... Это было нечто.

это же ужасный жавоскрипт и столь же прелестные жавоскрипторы, не идея кроссплатформы в частности. Ведь есть сишные либы которые таки кроссплатформенные, и запускаются на многих архитектурах процей и осях?

Просто для кастомера, когда звучит сочетание одна кодовая база и мы покрываем все платформы — загораются глаза. Ибо зачем платить больше. По итогу все выходит — как всегда...

Нам нужны пруфы, билли. Где пруфы билли? Можно на нативке наговнокодить так что работать будет хуже кроссплатформы.

И С# и нет хреньмворк вещи очень древние, парадигмы с их выпуска не менялись, а приехало очень много качественно много нового.

Чего?

Сравните типы в С# и таковые в Scala, TS, хошкеле и прочих языках посвежее. Сравните ваш притрушенный захардкоденный linq и коллекции в котле или в скале. Сравните прибитые гвоздями к язку async/await и IO монады и прочие таски, да хотя бы те же фьючи. Алсо посмотрите на явные реактивные штуки по типу akka-streams и fs2. Абсолютно всё что там есть не годится в сравнение со свежими вещами.

захардкоденный linq

Чем тебе LINQ не угодил? Это же главная фича .NET, на нем в 10 раз быстрее все написать можно чем на твоей Java.
А ты в курсе кстати, что Scala даже в США подыхает уже? И тут на Доу недавно писали что на нее работу уже найти не реально в США.
А .NET на твердом третем месте по США, с мизерным отрывом от 2-го места.

Чем тебе LINQ не угодил? Это же главная фича .NET, на нем в 10 раз быстрее все написать можно чем на твоей Java.

 во первых не на java, a на scala, и можно вполне себе свой линк написать.. На С# ты линк не напишешь и тот что есть для тех целей что нужно не перевелосипедишь, и это все потому что нету ХКТ который нужен для создания подобных вещей.

А ты в курсе кстати, что Scala даже в США подыхает уже? И тут на Доу недавно писали что на нее работу уже найти не реально в США.

смищно, количество вакух у меня в линкедыне говорит совершено об обратном

А .NET на твердом третем месте по США, с мизерным отрывом от 2-го места.

 и? миллионы мух не могут ошибатся?

Скала крутая я не спорю, на мой взгляд самый крутой язык после .NET)
Но уже пошла тенденция, что люди не могут работу на ней найти, и идут на другой язык, это я ради объективности, а не чтобы потролить, если бы .NET загнулся, я бы Скалу учил бы наврено.

потому что нету ХКТ который нужен

Что такое это XKT? скинь ссылки на статьи какие-то, а то не гуглитсья.
Мне если что LINQ всегда хватало, вот недавно читал на Хабре статью, про то что программирование это изобретение велосипедов, там типа менеджер просил разработчика делать новые фичи, и он кучу методов писал, и менял потом их, а я сразу понимаю, как читаю, что на LINQ это можно все было в 10 раз быстрее сделать.

Что такое это XKT? скинь ссылки на статьи какие-то, а то не гуглитсья.

www.baeldung.com/...​scala/higher-kinded-types очень упрощенно — лямбды для типов.

вот недавно читал на Хабре статью, про то что программирование это изобретение велосипедов, там типа менеджер просил разработчика делать новые фичи, и он кучу методов писал, и менял потом их, а я сразу понимаю, как читаю, что на LINQ это можно все было в 10 раз быстрее сделать.

linq — не больше чем синтаксический сахар.

Это типа монада какая-то? На LINQ вроде же можно такое написать.

люди не могут работу на ней найти,

Потому что приходят на собес, не могут ответить ни на один скаласпецифичный вопрос и уходят.

Так может, Вы не умеете людей готовить?

он просто человек науки, который смекнул что в науке мало платят, у него ж голова на плечах! а безголовым разрабам в ИНДУСстрии платят

вот и страдает теперь от дилемы, как бы это разрабов обнаучить :)
а они ж безголовые, никак не поймут предлагаемого счастья.

Я оттуда же. Может, старше, или не математик.

Ааа, так вот как называется категория вопросов «автор задротил сто лет и спрашивает редчайший нюанс, который не встретится на практике» — скаласпецифичность :)

Да прям уж таки. Натайпить тайпкласс show или же как работает for comprehension прямо экзотические вопросы? или же простенькая задачка на implicit precedence это экзотика? Знание таких вещей как асимптотика операций основных коллекций и вот этовещи повседневные, надо знать уметь чтобы кодить каждый день, но далеко не все отвечают на эти вопросы. Перевожу на язык плюсистов — вещи равнозначные тому чем отличается конструктор копирования от конструктора перемещения и чем отличается & от &&.

Ты сейчас пытаешься дьявола призвать или как все это понимать?

1) typelevel.org/...​ats/typeclasses/show.html
2) docs.scala-lang.org/...​r/for-comprehensions.html
3) docs.scala-lang.org/...​AQ/finding-implicits.html
4) docs.scala-lang.org/...​ance-characteristics.html
Вот так это понимать. На ваш язык:
1) как затайпить визитер с кастомным тустрингом
2) как рассахарить linq
3) как оверрайднуть в вашем di фрейме порядок подбора компонентов
4) думаю понятно
Вещи вообще несложные но редко кто с ходу на эти вопросы дает ответ.

Святые угодники, мне даже на наем не понятно.

не в R&D топових компаній Світу? З такими глибокими знаннями CS.

в аутсорсе задачи простые и понятные, никто не пушит и не требует делать хз что. Я занимался «олимпиадными задачками» класса с 6 и в течении всего универа, и мне как-то сильно надоело этим заниматься. По опыту общения со всеми моими знакомыми из фаанга, каждый из них выглядит хуже выжатого лимона, мне крайне не хочется постигнуть эту участь. Один мой одноклассник после недолгой работы там был выжат настолько, что даже не смог закончить универ. Зачем мне это надо? Ну и более того, R&D это говнякать ужасный говнокод ради получения едва рабочего результата, и это ну уж никак мне не нравится.

смищно, количество вакух у меня в линкедыне говорит совершено об обратном

В Украине и PHP на первом месте пока. Это не показатель, надо смотреть на то, что популярно в США. И тенденции там.

Это не показатель, надо смотреть на то, что популярно в США. И тенденции там.

пруфы будут? или аутсорс проекты исключительно из США?

Был в долине такой же любитель скалы, он долго ныл на Доу пол года назад, что в долине на скалу нет работы вообще, всего 5 позиций было из тех что ответили, и его везде не везли, и он пошёл обратно на Java. И писал всем типа не учите Скалу.
Монстер пишет что есть 4к вакансий конечно, реальный человек из Калифорнии писал что у них там Скала умирает.

писал что у них там Скала умирает.

потому что ей так положено. Когда-то я копнул ее, и понял что — она — отличная научная лаборатория. Одерски и Ко — респект и уважуха.

И что практичное в ней родится — появится в обычных ЯП и подходах.
Поэтому чтобы на ней писать — либо надо фанатень от нее, либо заниматься «прикладной наукой».

Она навсегда будет уделом редких проектов, и команд члены которых не захотели/не смогли уйти совсем чистую в науку. потому что зарабатывать презренные деньги хотят :)

Когда первые стабильные ее версии появились — в нее по той же причине ломанулись хаскелисты. Потому что Haskell конечно крут, но джавистам платят ощутимее больше. А перейти на богомерзкую джаву хаскелист не мог по религиозным убеждениям.
Причем они так снобствовать начали, что встречал призывы в англоязычном комьюнити как-то попустится, и не ржать над пришедшими в Скалу из Джавы.

Так что «Иван Камышан Scala» — последователен. Им, «научным ребятам из хаскелей» положено со скалы смотреть на копошащихся в полях разработчиков.

смищно, количество вакух у меня в линкедыне говорит совершено об обратном

Примерно так же когда-то говорили те кто вбухался в биток.
До того, как он улетел вниз на пару лет.
Пересчитай вакансии. Заскринь. Лет через 5 повесишь в рамку как теплую память о золотых деньках )

Так нет, их было значительно меньше года 3-4 назад. Хайпопик давно прошел у скалы и это радует. Кста, биток недавно вскакивал до невообразимо большой величины.

Через 5 лет придумают что-то более новое и более хорошее, есть догадки что конкретно, но гоп говорить пока рано.

Уважаемый сэр, я даже не знаю, что вам ответить на все эти «комментарии.»
Вы C# и WPF видели, на чем-то помимо Scala что-то нативное разрабатывали?
Вы имеете представление, как работает JS (Node), C#(.NET), Java (JVM)?
Как работают истинно компилируемые языки, как то: C/C++, Objective-C?
Хотя последний, как и Swift — работают через llvm, но не суть.
В общем, есть представление, как стартуют приложения под Android?
Когда вы найдете ответы на все эти комментарии, у вас отпадут ваши вопросы.
Я писал еще начиная с С++ около 20 лет тому назад (со всеми известными и не особо библиотеками). И перешел потом в мобайл (iOS/Android).
Потом back на Java так же имею опыт работы на Scala.
В общем, на всем, кромеа Ruby, Go, Python и Haskel.

Вы C# и WPF видели, на чем-то помимо Scala что-то нативное разрабатывали?

Да, видел. Лучше комбинации языка + экосистемы на котором есть работа пока не придумали

что-то нативное разрабатывали?

Щас бы С# интерпретируемый в IL называть нативочкой. У него толстый рантайм(превед дотнет фреймворк редистрибутабле), а у нативочки рантайма по хорошему быть не должно.

Как работают истинно компилируемые языки

 Да, давайте разведем дискуссии про истинность коньпеляции, даже плюсики используют промежуточное представление сейчас и «истинно» конпелируемое, как вы выражаетесь, именно оно. А нужно это в том числе и затем, что портировать такую жирную байду как стандарт С++ под всё что угодно это очень сложно и переделывать каждый раз нет смысла.

В общем, есть представление, как стартуют приложения под Android?

какая разница как они там стартуют, если кроссплаформа заматывает эти все «а вы знаете» так что нужно использовать эти знания по минимуму в исключительных случаях?

Когда вы найдете ответы на все эти комментарии, у вас отпадут ваши вопросы.

 у меня вопросов нет, у меня есть претензии к травителям за «трушность» ,"нативность" и «жава апплеты/ асп/ впф это хорошая технология».

Я писал еще начиная с С++ около 20 лет тому назад

И?

Потом back на Java так же имею опыт работы на Scala.

И?

В общем, на всем, кроме Ruby, Go, Python

И?

Haskel

а вот это зря, меньше бы за всякие «прогрессивные технологии» топили.

Вообще к чему это все? Я должен испугаться ваших регалий и плашки принципал тимлид архитект? К чему эти все побития кулаками в грудь? Ну я тоже могу понтанутся, у меня есть аж целых 2 красных диплома мехмата и медалька лучшего студента выпуска от факультета, и?

Кстати, если вы такой синьор и знаете все от и до, может ответите на такую элементарную задачку: «может ли статся, что выражение val v = new Foo произведет null» на этой самой скале?

Ответ я знаю, но если вы прям настолько большой специалист мирового класса, вопрос элементарен и должен приходить в голову в течении 5 минут.

Ну я тоже могу понтанутся, у меня есть аж целых 2 красных диплома мехмата и медалька лучшего студента выпуска от факультета, и?

в науку вам надо, в науку. А не в разработчики.

может ли статся, что выражение val v = new Foo произведет null

а классный вопрос, именно вне привязки к конкретному ЯП

конечно его на собеседовании вряд ли можно задавать, собеседуемый наверняка обидится в каком либо виде

но вопрос я ввернул так
Как бы ответили на вопрос о ЯП мейнстрим ООП семейства, спецификацию которого вы не знаете:
может ли статся, что выражение val v = new Foo произведет null

Эх, жаль на собеседовании не задают таких вопросов...

в науку вам надо, в науку. А не в разработчики.

вас забыл спросить. Вы вообще кто такой чтобы определять куда мне надо? Очередной дядька с интернета?

а классный вопрос, именно вне привязки к конкретному ЯП

с привязкой к конкрентому яп — scala.

Эх, жаль на собеседовании не задают таких вопросов...

задают, кек, если приходить неподготовленным на собес.

Данный человек заявлял что он иксперд всего и писал на всем. Ну раз он такой иксперд, то должен на это ответить, да и ответ легко гуглится, и если идея под рукой получается ещё быстрее чем гуглится.

Ну раз он такой иксперд, то должен на это ответить, да и ответ легко гуглится,

никто ничего никому не должен.
и никто из разработчиков не должен соответсвовать вашему мнению «чела от науки»

вас забыл спросить

мне одобряма не надо. что считаю нужным — то и пишу.

а вам в науку надо. иначе так и будете, как на доу — непризнанным гением среди в разработчиков :)
когда поймете это — будет уже поздно, года юные пройдут, когда можно было попасть в какую-то программу поддержки талантов от фаанга — уже не возьмут
да и жена, дети, «ипотека».

Очередной дядька с интернета?

совершенно верно — дядька которому видно что пацан попал в не то окружение.
в «дурную компанию», если хотите :)

а то что пацан этого не понимает, ну так — он же пацан еще, чтобы понимать
глядишь, один дядька, другой дадька, третий скажут ему — может и начнет соображать в правильном направлении.

не начнет — ну, значит не воспользовался. мало ли что все мы упускаем шансов не учиться на собственных — неисправимых ошибках

и никто из разработчиков не должен соответсвовать вашему мнению «чела от науки»

вы похоже не знаете кто такой чел от науки, а я знаю. Но у разрабов говорить о тех вещах о которых они не имеют понятия это принято.

а вам в науку надо.

там не платят, а вот в ИНДУСтрии платят и платят хорошо.

непризнанным гением среди в разработчиков

почему непризнаным, материальный эквивалент признания меня вполне устраивает.

дядька которому видно

ну у меня есть голова на плечах чтобы анализировать действительность. Организационная структура науки такова, что там нет никакой возможности что-то заработать, что у нас, что за картоном.

ну, значит не воспользовался

поверь, людей которым писать говнокод и ничего за это не получать и так, уже хватает и отбою там нет. А рокетсаянс, ну я не из тех кого бы взяли им заниматся, немного не хватает.

Но у разрабов говорить о тех вещах о которых они не имеют понятия это принято

Ну ты вот яркий пример. О джаве понятия не имеешь, но пытаешься задвигать тут на икспердных щщах какуюто дичь.

меня есть голова на плечах чтобы анализировать действительность.

Громкое заявление :) особенно на фоне чсв :)

Ну ты вот яркий пример. О джаве понятия не имеешь, но пытаешься задвигать тут на икспердных щщах какуюто дичь.

Я имею. Все возможности языка продиктованы его спекой, системой типов и экосистемой. При этом сама экосистема не может сильно пушнуть язык дальше первого и особенно второго. Система типов у жабки довольно скромная, а спека запутанная и уж очень сильно энфорсит бойлерплейт. По этому вы его либо пишете, либо используете аннотации. Аннотации они же вайтбокс макросы штука немного непрозрачная и не особо безопасная. Как не крути — если сравнить с более современными альтернативами, жабка как язык по возможностям отстает.

Я имею

Нет, не имеешь. Ты надуваешь щеки о том, чего не знаешь, неся какую-то псевдотехническую чушь с видом эксперта, таковым не являясь.

Нет, не имеешь. Ты надуваешь щеки о том, чего не знаешь, неся какую-то псевдотехническую чушь с видом эксперта, таковым не являясь.

А ты компетентен оценить? И вообще знаешь кто я такой? Ты же кроме моих мессаг на форуме ничего не видел, а кроме как по рофлу я на доу сообщений я не пишу, иначе как ещё вас разводить на лулзы? На серьёзных щах никаких лулзов не получается.

там не платят

платят, но не лохам всяким

платят, но не лохам всяким

докажите что соотношение запросы/зп выше в науке, тогда ваше утверждение будет иметь силу. Пока что все наблюдения по этому критерю сильно не в пользу науки.

да как-то не вперлось кому-то что-то доказывать
если так интересно, то просто гуглишь зп сотрудников айви лиг и тиер 1 универов и смотришь

Смотришь запросы на эти должности, делишь ЗП и получаешь что соотношение получается очень такое себе.

Ок, это валидный критерий. Очевидно, что наука — она не для слабеньких. Там нужен ум и характер, без чего на галерах можно вполне себе существовать.

WPF уже устарел лет 5 как миниум. я 5 лет назад писал на WPF и WCF. Сейчас их заменил Anuglar с Web API на .NET 5. Сам .NET не устарел а наоборот это язык и фреймворк будущего где больше фич чем во всех языках программирования вместе взятых. А с 5-й версией и скорость выше чем в C++

А с 5-й версией и скорость выше чем в C++

Бенчмарки в MS проводили?

На C/C++/Rust пишут, чтоб получить большой перформанс + предсказуемый постоянный перформанс (без постоянных сборок мусора в самый неподходящий момент), чем языки как C#/Java/Go похвастаться не могут, сколько бы не выжимали из их компилятора.

Да, в презентации Майкрософт видел что .NET 5 обогнал все кроме Rust по их тестам)
Так для обычного WEB API сборка мусора это не большая проблема, она занимает не больше секунды обычно, и если в какой-то момент все запросы займут на секунду дольше никто это не заметит. А вот утечка памяти которую легко допустить на

C/C++/Rust

Для веба была бы гораздо большой проблемной, я сам раньше очень C++ любил, но на него не было не одного веб фреймврока, видимо из-за утечек памяти, которые бы были в вебе с большей вероятностью.

Да, в презентации Майкрософт видел что .NET 5 обогнал все кроме Rust по их тестам)

Удивительно, что бенчмарки зафейкали так, чтоб C# обогнал Rust. А, подожди, в MS есть еще и комнада разработки Rust, friendly fire начальство недопустило.

А вот утечка памяти которую легко допустить на ... Rust ... Для веба была бы гораздо большой проблемной

Лол, расскажи как допустить утечку памяти в Rust.

Я на Rust не писал, может там и нельзя, а вот на C++ я сам их много раз делал.
А кстати почему там нет утечек, если язык не управляемы без сборки мусора? Значит утечку можно сделать.

А кстати почему там нет утечек, если язык не управляемы без сборки мусора?

Может быть потому, что это была основная selling feature и design constraint Rust: запилить язык без сборщика мусора, в котором максимально сложно допустить утечку памяти.

Значит утечку можно сделать.

Покажи как: play.rust-lang.org

Значит утечку можно сделать.

Компилер не дает. Говорят, поэтому на нем сплощная камасутра вместо кодинга.

Компилер не дает. Говорят, поэтому на нем сплощная камасутра вместо кодинга.

Не считая вариантов с unsafe code:

1) Box::leak
2) mem::forget()
3) Взять два Rc (reference counter), и связать их в цикл (это уже как минимум Rust 303, но возможно)

Профтикати ресурс, що старе не видаляється і пам’ять буде жертись — можна і на JS, якщо шо і є підозра, що багато де це є, лол.

Я имел в виду утечку в стиле C++

Держи обзор
ithare.com/...​t-punishment-for-failure
По сути — одно и то же, только симптомы разные

Когда по медиане запрос выполняется за 5 мс, а в худшем случае за 1000мс из-за сборки мусора, это доставляет кучу проблем, особенно если рейт запросов очень большой. Латентность запроса — это то, что нельзя решить, вбухав еще один миллион долларов в авто-скейлер.

А чем конкретно мешает задержка

1000мс

Время от времени?
Если это не система наведения ракеты, а API которое обслуживает другие микросервисы или SPA?

Когда по медиане запрос выполняется за 5 мс, а в худшем случае за 1000мс

А что мешает не писать так, чтобы было «1000мс из-за сборки мусора»?
Более того, паузу в 100500мс вполне можно получить и в c++/rust/whatever.

Более того, паузу в 100500мс вполне можно получить и в c++/rust/whatever.

сборкой мусора?

это шутка такая? в с++ программист и только он контролирует, когда деаллокейтить память

а деаллокейтит память тоже программисит, за O(-1)?

ты вообще понимаешь, о чем я говорю?

в с++ программист и только он контролирует, когда деаллокейтить память

поэтому там, где gc тратит 1000ms на деаллокацию памяти, в с++ программист тратит 0 (т.к. он контролирует ситуацию)
ничего не упустил?

вы бы хоть описание проблемы почитали по ссылке прежде чем отвечать.

ничего не упустил?

Упустив що не завжди добре зразу ж звільняти пам’ять. Коли у тебе пам’ять фрагментована як швейцарський сир (а це запросто буває в програмах, які крутяться тижнями — різного роду сервери, бази даних, ...), то новий allocate вже працює далеко не за O(1) :(.

edit: managed же пам’ять запросто може бути дефрагментована.

в с++ программист тратит 0 (т.к. он контролирует ситуацию)

Если используются сбрасываемые пулы памяти (например, когда обрабатываются запросы на stateless сервере) — то да.
Когда аллокатор на чанках — то один переход по указателю en.wikipedia.org/wiki/Free_list

Бред. Просто выходишь через exit(). OS сама все вычистит. Если там какие-то расшаренные мютексы — так поудаляй руцями на выходе.

А еще есть пулы памяти. Это когда аллоцируется подряд из массива, а потом говоришь reset(), и про всю эту память забыли, и выделаем на том же месте память заново.

Хотя, может, у чувака отладка менеджера памяти в ОС включена. В любом случае — кошечек надо уметь готовить.

Просто выходишь через exit()

можно, еще, шнур из резетки вытащить

Лучший вариант, если утечка ресурсов)

А что мешает не писать так, чтобы было «1000мс из-за сборки мусора»?

т.е. не писать на C# вообще? Okay.

Более того, паузу в 100500мс вполне можно получить и в c++/rust/whatever.

Какая-то херня может приключиться, поэтому умные люди отключают файлы подкачки и всю память выделают заранее в кастомные алокаторы в начале программы.

т.е. не писать на C# вообще? Okay.

конечно, писать нужно только на java :)

поэтому умные люди отключают файлы подкачки ...

мне всегда казалось, что «умные люди» понимают, что gc != sleep(random()).

И если, например, вы делаете 100500 аллокаций, то деаллокаций будет тоже 100500. В случае с gc (в отличие от ручного управления, или arc) есть больший шанс, что эти 100500 деаллокаций будут сделаны единым блоком, что может создать неудобсва (но швгс весьма не большой, т.к. почти все gc сейчас concurrent и low-pause).
Чтобы уменьшить шансы возможных неудобств, «умным людям» полезно понимать, как работает gc, и следить чтобы он справлялся. Это не сложнее «возни с кастомными аллокаторами».

Выглядит слишком хорошо чтоб быть правдой. Есть ссылки о том как работает GC и как правильно его использовать?

Там пяток разных алгоритмов разной степени протухлости

Выглядит слишком хорошо чтоб быть правдой.

Если бы gc был таким злом, как его обычно рисуют, то его давно бы заменили на ARC.

Есть ссылки о том как работает GC и как правильно его использовать?

Правильно, просто следить, что мусор собирается быстрее, чем создается, и не создавать сверх нормы. Тут получается компромис между идиоматичеостью(читабельностью) и здравым смыслом.
Для jvm есть последний ultra-low-pause shenandoah gc и pauseless" gc от azul

afaik в .net gc не такой замечательный, но там больше low-level api, что позволяет создавать меньше мусора.

Если бы gc был таким злом, как его обычно рисуют, то его давно бы заменили на ARC.

GC это добро для людей, которые не умеют и не хотят в оптимизацию перформанса.

Правильно, просто следить, что мусор собирается быстрее, чем создается, и не создавать сверх нормы.

Есть конкрктеные примеры? Без этого звучит так «Чтоб не было проблем с безопасностью памяти в C, следи, чтоб память правильон выделялась и освобождалась в коде, и чтоб обращения к памяти были только в рамках выделенной памяти». 100% корретно, 0% полезно.

не умеют и не хотят в оптимизацию перформанса.

Вы утверждаете, что там, без gc будет O(n) c gc будет O(n^2) ?
Или для вас «оптимизация перформанса», это указать «-O4» вместо «-O1» ?

Есть конкрктеные примеры?

Куда уже конкретнее
Немного выше вы утверждаете,

Когда по медиане запрос выполняется за 5 мс, а в худшем случае за 1000мс из-за сборки мусора

и перподносите это как фундаментальный недостаток gc.
Конкретным действием здесь будет:
— собрать метрики, чтобы посмотреть, что реально происходит в эти 1000ms (например в java есть jfr, который это умеет)
— исправить и забыть.

Хотя, как заметили выше, если эти 1000ms были вызваны фрагментацией памяти, и последующим full-gc, то альтернативой было бы просто скрешиться (что в реальности и просходит), из-за невозможности выделить очередной блок памяти.

Народ, який дуже переживає за паузи в GC, як правило забуває що дуже багато структур даних, якими вони користуються (vector, hashmap, ...) працюють за O(1) тільки «в середньому», тобто O(1) це амортизований час роботи, а не найгірший. Наприклад vector.push_back працює швидко-швидко, але деколи треба все це барахло переносити в нове місце, а це вже займає багато часу. Власне тому і є поняття hard real-time систем, де гарантії на найгірший випадок.

До речі, класичною задачею в темі аморт. аналізу є задача про те, як зробити щоб vector.push_back() завжди працював за O(1). Рекомендую — дуже хороша головоломка, яка сильно просвітляє на цю тему.

Смищно, можно использовать реквест хеджинг, к одному придет гц, к другому — нет девяточки увеличатся.

Во-первых, такой херней некто на серьезном скейле не занимается.

Во-вторых, влияние tail latency намного большее, чем вы пердставляете на высоконагруженных системах.

Во-первых, такой херней некто на серьезном скейле не занимается.

ручаешься за весь интернет? У вас есть полномочия?

влияние tail latency намного большее, чем вы пердставляете на высоконагруженных системах.

Есть такое понятие как количество 9-к в SLA, и «значимость» tail latency определяется им, а не вашим субъективным мнением.

ручаешься за весь интернет? У вас есть полномочия?

Лицензия

Есть такое понятие как количество 9-к в SLA, и «значимость» tail latency определяется им, а не вашим субъективным мнением.

Долго расписывать, и пока что нет уверенности в адекватности собеседника понять написанное, поэтому в этот раз скипну чтоб сэкономить время.

Лицензия

сертификаты «от конторы синьор помидор халоад архитект» это немного другое, и не дает вам возможности говорить за весь интернет.

Долго расписывать, и пока что нет уверенности в адекватности собеседника понять написанное, поэтому в этот раз скипну чтоб сэкономить время.

В таких случаях люди обычно дают линку

Погодите, это как у вас получается сравнивать дерево с бетоном?
WCF — это вообще для коммуникации, здесь оно никак не коррелирует.
WPF — это desktop framework.
Anuglar — это браузерный framework. Думаю, что сами понимаете, что где и как процессится.
Про сравнение с С++.
Есть в мире только два языка, которые работают быстрее.
Asm и С.
Все остальное в принципе не сможет из-за, как тут было уже написано, хотя бы из-за GC.
И еще про сравнение, еще лет 20 назад был спор, что быстрее С или С++.
Так вот, если писать на С++ в стиле С — не используя ни exception handling, ни позднее связывание (inheritance). Тогда они будут на уровне. Что, собственно, и делают в подсистемах, критичных по пифоманс. Как то — gamedev.
А если вообще говорить про kernel level, то там в здравом уме никто не пишет на С++, все на С

kernel level

Говорят, в Виндовс дрова на С++. Горчака надо засаммонить.

Есть в мире только два языка, которые работают быстрее.
Asm и С.

*cough*rust*cough*

где больше фич чем во всех языках программирования вместе взятых.

чего-чего? в шарпах нет и половины из этого списка dotty.epfl.ch/...​aprogramming/staging.html.
И из этого списка: www.typescriptlang.org/...​notes/typescript-4-1.html
и ещё из многих списков.

Чувак, ну вот серъезно, зачем сравнивать «корову с ананасом».

С# объектный ЯП, куда, за уши, притягивают всю эту функциональщину.
Ну понятно дело что в изначально функциональных языках все эти фишки будут намного лучше развиты.

P.S. Со Scala я никогда не сталкивался.

як виглядає в них crud з апі до бази

Примерно как ООП в сишке — везде тянем объект «мир», модификации к которому возвращаем и постоянно дрчм на «чистоту функций» и «отсутствие сайд-эффектов»

Scala — говно. Подробности вот тут — dou.ua/forums/topic/16012

Ты бы ещё статью 10-ти летней давности привел. Кста, ты её читал? Смысл понял? если нет объясняю: дяденька захотел писать на скале как на джаве и вдруг столкнулся с тем моментом что внезапно существует альтернатива. Но разбиратся — это для лохов, по этому с глаз долой и из сердца вон, давайте лучше продуктивно писать тонны бойлерплейта или страдать с самопальным метапрограммированием.

Зачем страдать с метапрограммированием и прочим матаном? Может, проще его не использовать и радоваться жизни?

Зачем страдать с метапрограммированием и прочим матаном? Может, проще говнокодить и радоваться жизни?

Fixed

Жрать тонны багов и писать тонны бойлерлейта это радоватся жизни?

Это с каких пор WPF — устаревший desktop framework?

Programming model под WPF мягко говоря немножко дибильная, неудобная и трудозатратная.

Часто во время разработки сталкиваешься с каким-то дибильным поведением фреймворка, которое можно раскурить только если начать серьезно ковыряться в исходниках, а исходников, увы, не было (да, сейчас появились, но сейчас уже всем пох).

Если спросить совета на форуме, то единственный полезный ответ, который можно получить — «вы неправильно готовите MVVM, у нас готовят по-другому», который позволяет прийти к выводу, что никто не знает как правильно готовить MVVM и заставляет сомневаться в решениях, принятых в начале карьеры.

Если запилить более менее вменяемый API/фреймворк для разработки UI, которым бы могли пользоваться тупые люди типа меня, за которым стоит WPF для рендеринга — было бы ***енно.

Я лично не думаю, что у меня хоты бы одно приложение, написанное на WPF есть. Вру, есть Visual Studio Community, но я ею не пользуюсь.

Programming model под WPF мягко говоря немножко дибильная, неудобная и трудозатратная.

«я ниосилил»

Если всё это по итогу тупо работает через браузер — вообще зачем городить приложение? Тупо работать через браузер и дело в шляпе. Просто ради лишнего ярлычка в мобильнике? Тогда это уже скорее претензия к браузерам, почему нельзя тупо создавать приложения на их основе, по сути дающие ярлычок, виджетик, и локальное хранение каких-нить настроек. И такое приложение и места жрать не будет, и от проблем с безопасностью страдать, и вообще нуждаться в его серьёзной разработке. И работать может на нескольких браузерах, отличаясь по сути только скриптом инсталляции. А уже приложением по UX будет делать его сервер.

Ладно бы что-то новое, так нет же, игры онлайновые именно так работают. Но.... как же тогда продать заказчику приложение, жутко необходимое, потому что как это так, у всех есть, у меня нет. Вот эту задачу по сути Электрон и выполняет: красивый фантик для из говна конфетки.

Когда-то такую задачу на винде достаточно успешно выполнял Internet Explorer. Как браузер говно, а вот для показа контента в приложениях, общения с серверами, простеньких игрушек — просто цацка. Но... ослик сдох.

Тогда это уже скорее претензия к браузерам, почему нельзя тупо создавать приложения на их основе, по сути дающие ярлычок, виджетик, и локальное хранение каких-нить настроек.

Ну здесь большой привет Apple, которая регулярно подсерает ограничениями в Safari не только Progressive Web Applications (которые ты, по сути, и описал), но даже и «обычным» Single Page Applications.

Отдельные лучи добра яблочникам за их упорное нежелание добавлять SharedWorkers в Safari и драконовскую политику для audio autoplay.

И как с дизайном, получается опять богомерзкий css+html!? Опять бутсрап и прочее?

батони і текстбокси там готові є

там є все те що ви бачите на сайтах
тобто берете собі якийсь coreui.io який у вас і в адмінці на проекті викростивується — і майже все й зробили.

це ж головна причина такого рішення:
під капотом Нода та Хроміум
щоб зробити portable&offline версію сайту.

640 Гигабайт оперативной памяти хватит всем!

После прочтения первых двух фраз "

Что почувствует разработчик, если ему\ей предложат написать desktop приложение? Он\Она наверняка расстроится.

" я понял, что читать эту чушь дальше просто вредно. Автор явно не в курсе, что кроме телефонов есть еще масса другой техники.

правильно было бы «web разработчик», так статья обретает некий смысл)

а заодно и название статьи сменить на «„Electron. Как работает самый современный JS framework“»

Не, я понимаю, что вэберу может срочно понадобиться написать какой то десктоп в 3 окошка, которые выжрут ХХХ гигабайт и у него времени нету учить тот же С#, Но плиз, не неужно никаких сравнений с нэйтив технологиями.

Скоро будете писать, что АнреалЭнжайн — это ф*гня для ААА игр и нужно все переписать на ЖаваСкрипте... пофик,что 2 кадра в секунду...

Начиная с Quake (idTech 2) внутри движков есть скриптовый интерпретатор, как и в браузре JavaScript. Чаще всего этот скриптовый язык это — Lua ru.wikipedia.org/wiki/Lua, в ID движках это Quake C ru.wikipedia.org/wiki/QuakeC. В Unreal это ru.wikipedia.org/wiki/Blueprint. Движок сам по себе это платформа для создания продукта — компьютерной игры или симулятора-тренажора, так же как и браузер это универсальная платформа для WWW.

Я знаю, что есть возможность писать скрипты в том же UE, это никак не отменяет актуальности моего поста.

Так и есть же, для всякой индюшатины зачем что-то кроме жиэса и юнити?

ЖапаСкрип это круто, а C#/WPF и С++/Qt — єто х*ерня для десктопа ????
WHATTTT ?
Чуваки, я прошу прожения, вы со своим жавойСкрипт и WEB-frontend совсем обнаглели ?

Чуваки, я прошу прожения, вы со своим жавойСкрипт и WEB-frontend совсем обнаглели ?

не, они просто заполняют нишу.
пока могущие писать на

C#/WPF и С++/Qt

заняты более важными делами чем писать кросплатформенные GUI — веберы их пишут.
как адепты правильных технологий освободятся — так все и перепишут.

а бизнесу ждать некогда этого момента. ему на вчера надо.

Интересно будет сравнить по скорости разработки C++ допустим с wxWidgets, Java с Swing и Electron. Сколько времени займет создать минимально полезное приложение и что получится по потребляемой памяти. Возможно все не так уже и плохо. Как раз идея для статьи — спасибо.

Отложилось как-то в памяти, как когда-то запускал экзешник с одной пустой оконной формой на vb 6.0 и то же самое на WinApi. Уже даже в таком примитивном сценарии, на 3 пентиуме, ощущалось что пустая форма на винапи запускалась раз в 5 быстрее)

я когда-то на винапи написал игруху, так она просто летала — там нельзя было заметить хоть какую-то нагрузку на проц от нее.

Неокрепшая js макака выгорит за 3 дня и пойдет работать в глово, после всех этих LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam);

Я тогда был неокрепшим С++ войтивайтишником, который делал memset(this, 0, sizeof(*this)); но руки очень чесались. Добавляет самоуверенности, когда видишь, что работает.

И правильно сделает :) десятки алиасов на каждый базовый тип могут подорвать психику. Полагаю что создавался он теми же людьми что делали телепузиков.

Ммм... вкус молодости. Ностальгия просто.

VB6 — наверное, до сих пор, самая лучшая вещь для Desktop разработки.

— Простейший язык
— Моментальная компиляция
— Никаких зависимостей
— Манюсенький exe
(Если всё правильно помню)

Delphi — вторым

Моментальная компиляция

Ни разу не моментальной она была для крупных приложений, если речь именно о сборке в .exe файл, а не о просто запуске в IDE.

И были свои весьма неприятные нюансы с версионированием и совместимостью COM интерфейсов.

Возможно, не писал ничего серьозного на нём.

Опять же, VB6 наверное самый простой способ написать COM обьект до сих пор.

а не о просто запуске в IDE

Не знал об особом режиме.

VB6 наверное самый простой способ написать COM обьект до сих пор.

На самом деле, на .NET ненамного сложнее

Опять же, VB6 наверное самый простой способ написать COM обьект до сих пор.

Самый простой — ATL. Причём, с поддержкой «дуал-интерфейс» (а не только «дисп-интерфейс», как в ВБ).

Я бы посмотрел один COM обьект: примеры на VB6 и на ATL.

а не только «дисп-интерфейс», как в ВБ

VB6 поддерживал early binding — главное, чтобы никто кривыми руками не менял уже опубликованные интерфейсы.

Самый простой — ATL

Ну да, ну да. Толстенный талмуд по разработке под ATL до сих пор где-то на работе лежит.

ATL с его подходом «шаблон на шаблоне и шаблоном погоняет» был отнюдь не самым простым и очевидным инструментом для создания COM объектов.

ATL сам по себе аццкий но генераторы проектов из MSVS автоматически создают нужную обвязку. Я когда-то на WTL писал встраиваемые ui компоненты которые впихивались в VB программу

Самая худшая, и самая большая ошибка использовать VB в ентерпрайз разработке (но использовали ведь! Когда бывший вайтишник-водитель грузовика пишет систему на коленке в качестве развлечения а потом становится менеджером и поделка превращается в копроративный стандарт, обрасиая свистелками и перделками)

TIOBE rating
...
5 C# 3.95% -1.40%
6 Visual Basic 3.84% -1.44%
7 JavaScript 2.20% -0.25%
8 PHP 1.99% -0.41%
...

TIOBE — индекс цитирования. На пхп намного больше софта написано, но о нем говорить неинтересно видимо 😏

This. Язык, на котором я, 5-классник, мог писать реально работающие программы. Сейчас чтоб написать программу на простейшем языке, нужно знать как пользоваться консолью, собирать компилятор из сорцов и стопицот каких-то фреймворков, которые меняются каждые месяцев. Надо запилить язык как VB6.

.NET — это серьезное осложнение для тех, кто не ходил в универ и занимается программированием просто для лулзов. Я хз, ты хоть раз писал на BASIC, имеешь ли представление о том, насколько простым может быть язык программирования. То, во что сейчас превратился .NET не позволяет в него войти кому-то, кто не имеет желание и времени становиться профессиональным программистом.

Я все свое детсов провел, ковыряясь в VB6 для своего удовольствия. Когда вышел .NET, это был преломный момент, я целый год ничего не мог писать, из-за нереального кол-ва инфы и способностей, которые нужны, чтоб хоть что-то писать на .NET и читать чужой код. Эта «поездка» завезла меня в итоге в профессиональное программирование.

Я не вижу сейчас языка, который бы мог занять нишу BASIC/Visual Basic. Людям нужно или как минимум приготовиться к tough ride с Python или Javascript, или вообще забить на программирование и оставить его взрослым дядям.

Согласен насчет простоты бейсика, сам педалил на нем в школе для фана на ZX Spectrum, но не согласен насчет дотнета и жабоскрипта, как помесивший дот нет, жабоскрипт на фронте на джейквери, на первом анугляре и на втором анугляре(6 или 8 точно не помню), и на фронте с графикой и на бэкнэнде...скажу что чтобы педалить на нем реально на порядок сложнее чем на дотнете, в первую очередь из-за еблей с консолями, фреемверками, конфигами и прочим дерьмом которое вот вообще с программированием не связано.

В итоге чтобы добраться до программирования фичи уходит уйма времени. На дотнете это заметно проще и в первую очредь из-за крутой среды разработки и атоматизации очень много чего, но соглашусь что это все еще довольно нагруженный язык и фреемверк, хотя до тех же плюсов еще очень далеко.

Так же я писал много мелких проектов и вот ща для себя пишу еще один, маленькое приложение с крудами, гридами, базой с помощь .Net+ EF + Visual Studio пишется ну оооочень быстро, в пару кликов у меня был проект с ГОТОВОЙ авторизацией\регистрацией и сопуствующими сменой пароля, аппрув имейла, была уже простенька верстка, накатывается полностью база, легко добавляются тестовые данные в эту базу, там же из под коробки EF+ мигратор и коде ферст, который легко сменить на дата бейз ферст просто добавив коннекшен к базе и в пару кликов стянуть всю схему из существующей базы к себе в проект и педалить SQL руками если тебе так проще, очень легко дебажится, в одну кнопку запускается сервер в режиме дебаг и все что нужно для отладки, при наличии решарпера достаточно нажать Ф12 чтобы увидеть исходный код который легко читать и отформатирован, и это без особой ебли...

Если бы взял этот богомерзкий JS на фулл стэк я б все еще долбился с конфигами и авторизацией, большей степени гуглил бы очередной фикс с гитхаба и охеревал бы от количества пакетов которое тянет фронт.

Проблема донета в том, что часто там требуется фулл стэк, а это само по себе включает три разных направления — браузер, сервер и база данных.

Хотя вот также взять и на винформах набросить мелкую утилиту для себя, это нефиг делать и очень просто, за тебя всю студия сделает, даже не нужно богомерзкий HTML или XML пободный фронт пилить, в дизайнере накидал кнопок, форм и обработчики событий и вот уже будет работать приложуха.

Универ у меня инженерый но абсолютно не связан с компами, после бейсика в школе, C# .Net мой первый язык и фреемверк, осваивал полностью все сам в далеком 2010\2011 годах без крутых галерных курсов с менторам и домашками.

Если бы взял этот богомерзкий JS на фулл стэк я б все еще долбился с конфигами и авторизацией

Под тот же NestJS есть готовые генераторы всего этого счастья :) Но, да, в .NET несколько удобнее, потому что у тебя есть визарды прямо в IDE, и не нужно курить мануалы по CLI выбранного фреймворка.

в первую очередь из-за еблей с консолями, фреемверками, конфигами и прочим дерьмом которое вот вообще с программированием не связано.

Люто, бешено плюсую.

охеревал бы от количества пакетов которое тянет фронт.

Месье знает о чем говорит. Имел несчасть работать (к счастью недолго) с Электроном, в который запихивали Ангуляр приложение, правда, достаточно сложное. Но node_modules в ПЯТЬДЕСЯТ ТЫСЯЧ файлов — это просто за гранью добра и зла.

Но node_modules в ПЯТЬДЕСЯТ ТЫСЯЧ файлов — это просто за гранью добра и зла.

Ну если бы ты видел количество исходников, которые стоят за всеми подключенными к твоему .NET проекту NuGet пакетами — то количество файлов ИМХО было бы ненамного меньше.

Я не вижу сейчас языка, который бы мог занять нишу BASIC/Visual Basic.

Есть FreeBasic www.freebasic.net (последний релиз вышел в декабре, т.е. язык вполне живой вроде как). Правда, насколько я понимаю про него не очень-то и знают (а посему и коммюнити у него вроде небольшое)...
Для юниксов и линуксов есть еще GAMBAS ru.wikipedia.org/wiki/Gambas , но насколько он прост — хз (не смотрел его).

NET — это серьезное осложнение для тех, кто не ходил в универ и занимается программированием просто для лулзов.

Помню в 9-м классе на олимпиаду по программированию пошел(на паскальчике писал), на компах стояли IDEшки для паскаля, basic, vb.
Пришел чел и заявил что ему нужна среда для плюсов, я аж поднапрягся т.к. сидел парень с очень важным чсв лицом.
Дали доп время, он установил, посидел еще минут 10 втыкая в задание на мониторе и полупустой «main» и ушел грустный.
Ба-дум-тсс:)

как на моей первой работе, еще студентом, после очередного спора в группе что кручее Си или Паскаль, подошел я к одному из наших ведущих разработчиков (мы на Си писали) с этим вопросом
— А правда что Си кручее Паскаля?
Ожидая чсв себе погреть, что правильный язык выбрал первым

и получил ошарашивающий ответ
— хороший программист и на бейсике напишет круто. плохому никакой язык не поможет.

В языке не только должны быть простые вещи (которые есть в пайтоне), но еще не должно быть сложных вещей (которые, увы, тоже есть в пайтоне).

сложные вещи могут пригодиться для сложных задач (пример: корутины)
но, думаю, они не должны засорять ядро языка (синтаксис и операторы)

Нужен язык, который не предназначен для решения сложных задач, в котором не будет места для этих богомерзких вещей, в т.ч. корутинов.

В идеале — язык, который ПОЛНОСТЬЮ можно понять, прочитав книжку на 50 страниц.

Серьезно, понять весь C в скоупе 50 странц? Там страниц 10 нужно только чтоб объяснить зачем нужен мейкфайл там, где другие языки сами понимают что и как собирать.

Ну ти в 5-ому класі теж не всі 100% фіч ВБ юзав, правда?

Берёшь идеешечку, и в окошечке пишешь имя файлика. И никаких мейкфайлов.

Какую идеешечку? VS Code нифига не понимает.

Какую идеешечку?

Eclipse, QtCreater, Code::Block.... тысячи их ))

VS Code нифига не понимает.

Так VSCode это про продвинутый редактор с возможностью слепить из него IDE (пр наличии прямых рук), а не про IDE «из коробки». Странно требовать от блокнота умение компилировать файлы .

Найдёшь сам, не маленький

какое отношение мейкфайл имеет к си?

Я хз, у меня на работе с С все было на мейкфайлах. Хотел дома расслабиться полабать немного. Все было хорошо до тех пор пока был один .c файл. Когда появился второй, оказалось, что ничего не работает. Поиск в гугле ничего хорошего не дал кроме рекоммендаций запилить мейкфайлы.

Ставишь Эклипс, или если надо кросс-платформенно и разные конфигурации — тогда читаешь пособие по камасутре с CMake. Мейкфайлы руками — это прошлое тысячелетие.

Как это не работает? Ты как маленький. Пишешь сотню файлов в командную строчку компилятору и все. Не надо никаких мейкфайлов.

Там страниц 10 нужно только чтоб объяснить зачем нужен мейкфайл

Не путай язык с системой сборки ))
$ gcc -Wall hello.c -o hello

Консоль — это то, что не хотелось бы добавлять в нагрузку неокрепшим умам.

Консоль — как пример что make для сборки не всегда нужен. Это разные сущности.

Если говорим про консоль, то проект с одним файлом даже проще собирается:

make hello

С несколькими файлами там становится все грустнее и грустнее.

Ну с несколькими файлами нужно юзать систему автосборки. Или юзать IDE, которая сделает это за тебя.

Это же консоль. А ты ее не хотел. Какой-то ты противоречивый

Я сделаю это попроще — богомерзкие языки с фигурными скобочками не канают.

И это правильно. Возьми ассемблер, там скобочек нет, пишешь все в столбик. Почти как Питон

Мейкфайл вообще к языку не относится. Поставь студию и не мучься.

В идеале — язык, который ПОЛНОСТЬЮ можно понять, прочитав книжку на 50 страниц.

Brainfuck?

все не так уже и плохо.

Все плохо, поверь

Интересно будет сравнить по скорости разработки C++ допустим с wxWidgets, Java с Swing и Electron

жизнь и сравнила.
потому что именно скорость разработки от момента
надо сделать GUI клиент
до
пользователь запускает клиент
решает.

Программирование — не всегда даже весомая часть — разработки

что получится по потребляемой памяти.

тоже что и при переходе с С++ на Java
за увеличение скорости разработки обычно платится более высоким потреблением ресурсов в рантайме

В «эмбедеде», просто нет возможности в увеличении потребления ресурсов.
Поэтому... панели в недорогих авто тормозят, и надо покупать андроидную на алиэкспресс :)
(пробегала недавно новость-аналитика — автопроизводители жалуются что их заказы на чипы задвигают все. и вторая, о том что спрос на разработку ПО для авто будет расти и расти, то есть — и на эмбедед программистов тоже)

Ну а игры — игроман купит себе видяху или приставку последнего поколения.
Или игровой смартфон, есть и такие, с теплотрубочкой на SoC.

В энтерпрайзе — серверов докупим, инстансов наразвернем, если проблема не в O(n!) конечно :)

Да конечно докупят вам серверов в энтерпрайзе, а потом догонят и ещё раз докупят. В энтерпрайзе вообще каждую копейку считают, а потом ещё пересчитывают и недай потратить лишнюю. А сервера вообще могут обходится так что вся контора на них работать будет без прибыли (сумы с шестью нулями). Так что профайлинг и оптимизация один из основных видов деятельности. Вопрос об абгрейде железа (или аренды вычеслительных мощностей) всегда ставится последним когда уже некуда оптимизировать.

Да конечно докупят вам серверов в энтерпрайзе, а потом догонят и ещё раз докупят

если будет аргументировано — то докупят :)
а если не будет, то как вот недавно у нас, от 3ех отказались :)

А сервера вообще могут обходится так что вся контора на них работать будет без прибыли

могут. на другом проекте сейчас у нас так.
там WebRTC, количество пользователей растет, докупаются регулярно и дедики. в итоге — на уровне окупаемости пока там :)

Так что профайлинг и оптимизация один из основных видов деятельности

да. потому и на моем проекте 3 впски оказались в итоге лишними.
а будут нужны — аргументирую, купят.

Масштабы конечно смешные, в сравнении с проектами где меряют сервера в сотнях.
но суть та же, как в истории с одним сервсисом у танкистов
был на ноде, 4 сервера, в пике загрузка под 100%
переписали на спор на джаве — стал 1, загрузка в пике под 60%

суть та же — то ура докупаем сервера, то, считаем расходы, млин, ребят, надо бы как-то убрать парочку (десятков, сотен, у кого как), ок, убираем, если ресурсы на оптимизацию есть

Вопрос об абгрейде железа (или аренды вычеслительных мощностей) всегда ставится последним когда уже некуда оптимизировать.

по разному. бывает и первым, когда — некогда оптимизировать.
людей же всегда не хватает :) как и времени. как и денег. :)

там WebRTC, количество пользователей растет, докупаются регулярно и дедики

О, любопытно. У них много звонков идёт через TURN? Или звонки на много участников, и нужно железо под SFU?

не вникал. совсем разные команды, они с нашей только фронтендеров брали на время.
на старте только немного был в курсе, когда подкинул им заготовку для сайта и логику.
но не потянул два совсем разных проекта
подробности в личке, а то еще ломанутся и будет хабр эффект :)

сравнивай сравнимое
берем html vs qml и сравниваем
потом там и там упираемся в боттлнек и сравниваем усилия по оптимизации
потом берем qt6, где qml напрямую транслируется в с++ код и снова сравниваем

берем html vs qml и сравниваем

неа. берем «js и css либы для фронтенда» vs qml

потом там и там упираемся в боттлнек и сравниваем усилия по оптимизации

сначала надо упереться.
то есть когда пользователи начнут жаловаться.

а пока клиент к ним в руки не попал — жаловаться им приходится только на его отсутствие.

оптимизации же фронтендщикам известы. до уровня прекращения жалоб, ессно, а не до уровня потребления ресурсов как при

qml напрямую транслируется в с++ код
неа. берем js либы для фронтенда vs qml

и?

и выходит что GUI клиент делать даже проще чем мордочку сайта с аналогичной функциональностью

а также к тому что UI сейчас фактически не верстают.
Он сейчас делается накидыванием компонент на js

Даже на заплеванном jQuery — который выбирают ради тьмы плагинов под него.
А «верстка» — берется CSS либа, фреймворк — и усё

а также к тому что UI сейчас фактически не верстают.
Он сейчас делается накидыванием компонент на js

так мокап делается

А «верстка» — берется CSS либа

и начинаются извращения
а вы qml видели? работали?

а вы qml видели? работали?

не видел, не работал.
и не планирую. на кой он мне, бекендеру :)
GUI клиент нам же не нужен
(и не помню и по другим проектам, и джавовским, тоже не был нужен. Тогда еще не было Реакта, и ExtJS рулил)

Мобильные клиенты — планируется заказать у сторонних команд.

а если придется, как уже писал, вдруг GUI писать, то вначале пощупаю Electron
Хотя думаю наши фронтендеры на нем и останутся.
Им тоже qml не нужен

Другими словами — qml то может и лучший, технологически.
а кто писать то на нем хочет/будет?

не видел, не работал.
и не планирую. на кой он мне, бекендеру :)

тогда какой смысл влезать в

берем html vs qml и сравниваем

?

тогда какой смысл влезать в

смысл в том что в первой части — ошибка.
не html, а
«js и css либы для фронтенда»

вы фронтед разрабатывали, что влезаейте в тему об удобствах разработки для Electron?
я фулестчил.
и так как писал GUI на
plain C
на голой видеокарте (в геймдеве, мимо DirectXов)
Java Swing
немножко на C# WinForms

поэтому догадываюсь о плюшках Electron немножко.

а Qt существует столько времени, и — Неуловимый Джо какой-то

Qt существует столько времени, и — Неуловимый Джо какой-то

Ну, он не неуловимый Джо, на нём вполне себе пишут. Из недавнего, с чем сталкивался — менеджер установки плагинов к Adobe Illustrator от Astute Graphics (но и там, есть подозрение, что Qt используется как обёртка для браузера).

Просто пишут на Qt в основном те, у кого уже есть экспертиза с C++ на борту.

уже есть экспертиза с C++ на борту.

ну то есть чтобы написать GUI — требуется программист на С++
с нюансами разработки на С++

А как у меня есть старая шутка
Собеседование выпускника
— Что изучали, какие ЯП знаете?
— Все 4ре года изучали С++!
— Ясно, понятно, никаких ЯП не знаете, и не программировали...

на нём вполне себе пишут

и на Haskell вполне пишут.
и думаю даже на ЯП в позиции за 100ую, в рейтинге Tiobe — тоже вполне пишут!

с чем сталкивался

Клиент к Postgerss тоже кажется на Qt
IDE Eric6 — на PyQt
напрягусь — еще вспомню :)

и что это меняет?

Десктопный Viber тоже на Qt

берем «js и css либы для фронтенда»

leftpad штоле? Жабаскриптовая экосистема — это отдельный пц.

я люблю тролить идеалистов, есть такая вредная привычка :)

кого парит что там пипец?
добавьте к этому — что бек то часто густо на php

и посмотрите в интернет — львиная масса того что увидите сделана на двух 314цах
js и php

и чё, не работает?

а то что там пипец, это да
недавно почти два дня искали проблему, чего млин редиректит то SSR
оказалось, там какая-то 4ая либа в зависимостях — ну очень умная. принимала сама решение — а вот этот урл буду редиректить!

добавьте к этому — что бек то часто густо на php

Что такое php? Какой-то древний язык, существовавший в до-джанговско-нодовские времена?

Framework Usage Distribution in the Top 1 Million Sites
trends.builtwith.com/framework

Web and Internet Technology Usage Statistics
Popular Technologies
trends.builtwith.com

Это за гранью добра и зла. Только если нужно срочно что-то написать зная только JavaScript и без особых требований к ресурсам. Автор, можете привести примеры, где вы использовали этот инструмент? Писать на этом калькулятор, который будет весить 300 Мб? Или что-то высоконагружаемое, что сразу просядет по ресурсам?! Непонятно

ПС. Жаль, Teams пока не плох вроде, но если они останутся на электроне, будет то же, что было со скайпом — неповоротливый прожорливый монстр.

Ну пока никто ничего не измерял, поэтому мы не знаем по идее. В прошлом движке Firefox Gecko (до создания нового движка на Rust) весь UI браузера был написан на JavaScript через XUL фреймверк. Работало нормально для разных диалогов печатей, меню и т.д. Критичные к скорости работы браузера вещи — например парсеры HTML и CSS конечно были написаны на С++. Delphi тоже в свое время ругали за «расточительность», однако небезызвестные Skype (до покупки Microsoft) и Totlal Comander и много чего еще на нем были написаны. Часто скорость разработки более важна нежели производительность.

Кстати, есть какие-то бенчмарки Файрфокса до и после, и Хрома за те же даты?
Можно было бы сравнить хоть как-то скорость.
ЗЫ там на Расте вроде далеко не все
ЗЗЫ пытался найти — девелоперы писали что ушли в Раст для затыкания безопасности, а не за скоростью

Бенчмарков полно сами Mozila делают вот этот developer.mozilla.org/...​docs/Mozilla/Benchmarking. Но мне вот этот нравится www.youtube.com/watch?v=op7ge8EoQmo Еще есть бенчмарк SunSpider webkit.org/...​/sunspider/sunspider.html который гоняет JavaScript (V8 уже давно как не чемпион, хотя был) ИМХО В том состоянии котором был Gecko с кодовой базой еще от Netscape Navigator (даже не C++ 98) утечками памяти и т.д. нужен был сам рефакторинг. Rust по идее потому что это как и JavaScript — их разработка.

И это я их должен сам запускать, вместо того, чтобы кто-то умный нарисовал готовые графики?

Delphi тоже в свое время ругали за «расточительность», однако небезызвестные Skype (до покупки Microsoft)

скайп на Qt был написан afaik

Pascal з використанням Delphi. Де ви взяли qt?

Де ви взяли qt?

в тумбочке

кстати, очень показательна судьба редактора Атом, в котором кору пришлось переписать на с++, иначе там с перформансом совсем все плохо было

почему тогда у VSCode с перфомансом всё хорошо?

отзывы и личный опыт, особенно на фоне тормозной идеи. атом тоже когда-то давно пробовал и проблемы с перфомансом хорошо помню, ничего подобного в vscode нет

I promised at the beginning that I would get back to this question.

TL;DR: We tried. It didn’t work out for us.

We built a text buffer implementation in C++ and used native node module bindings to integrate it in VS Code. The text buffer is a popular component in VS Code and thus many calls were being made to the text buffer. When both the caller and the implementation were written in JavaScript, V8 was able to inline many of these calls. With a native text buffer, there are JavaScript <=> C++ round trips and given the number to round-trips, they slowed everything down.

For example, the VS Code Toggle Line Comment command is implemented by looping through all the selected lines, and analyzing them one-by-one. This logic is written in JavaScript, and will invoke TextBuffer.getLineContent for each line. For each call, we end up crossing the C++/JavaScript boundary and we have to return a JavaScript string in order to respect the API that all of our code is built on top of.

Our options are simple. In C++, we either allocate a new JavaScript string on each call to getLineContent which implies copying the actual string bytes around, or we leverage V8’s SlicedString or ConstString types. However, we can use V8’s string types only if our underlying storage is also using V8’s strings. Unfortunately, V8’s strings are not multi-thread safe.

We could have tried to overcome this by changing the TextBuffer API, or by moving more and more code to C++ to avoid the JavaScript/C++ boundary cost. However, we realized we were doing two things at the same time: we were writing a text buffer using a different data structure than a line array, and we were writing it in C++ rather than JavaScript. So, rather than spending half a year on something we didn’t know would pay off, we decided to keep the text buffer’s runtime in JavaScript, and only change the data structure and associated algorithms. In our opinion, this was the right decision.

короче, еще одни с++ неосиляторы

висящую в памяти NodeJS и Chromium (70 мб)

До какого же изумительного треша докатилась индустрия, если вот это порождение чудовищного ума стало мейнстримом. Веб-фронтенд был костыльным ужасом во все времена, так теперь этот кошмар перетащили и на десктоп, да ещё и обернув его в дичайшие абстракции с несколькики процессами, локальным http-сервером и движком для рендера html, виртуальной машиной для javascript, и всё это выжирает ресурсов в сотни раз больше, чем бортовой компьютер, на котором спейс-шаттл автоматически летал в космос.

Лично мне кажется, что кросс-платформенности можно было достичь гораздо меньшей ценой, чем изобретать этого уродливого монстра.

Все очень просто — у жабаскрипта никогда не было (VBScript не в счет) конкурентов в браузере = его учат = толпа вайтишников-жабаскриптеров = пассаж про молоток в руках. Електрон будут юзать просто потому что есть толпа обученных людей. В отличие от хРуста.

бортовой компьютер, на котором спейс-шаттл автоматически летал в космос.

Для ногодрыгалки сейчас хватает 8битного контроллера, шаттл не намного сложнее. Это вам не видео кодировать-декодировать или нейронки гонять

Память дешевая, увеличь ее стоимость в 10 раз, все сразу научатся писать кросс-платформ красивый легкий на Qt

Лично мне кажется, что кросс-платформенности можно было достичь гораздо меньшей ценой, чем изобретать этого уродливого монстра.

Например?

C++ Qt
JavaFX
Чтото там для питона.
Все это уже от рождения кроссплатформенное.

Чтото там для питона.

PyQt
WxPython

C++ Qt

привет плюсы и война с ними вместо решения задач. Большая часть разработки на С++ — война с ним.

JavaFX

вы же в курсе насколько древняя эта гадость и насколько неудобные абстракции там юзают?

Чтото там для питона.

 а чем лучше жс? обе безтиповые гадости

Большая часть разработки на С++ — война с ним.

странно, никакой войны. все работает из коробки. что я делаю не так?

Да это же камышан, все кроме него все делают не так )

Большая часть разработки на С++ — война с ним

Это вроде про Раст писали.

Нет, раст. Раст пытаестя, и в большом числе случаев у него это получается, показать что если что-то сделать вот так то будет проблема. В С++ такой роскоши нет и надо воевать со своим кодом и компилятором чтобы он выдал нормальное сообщение об ошибке линкера/темплейтов или же до посинения искать UB/утечку. В расте такая возня только в качестве исключения, а не рутины.

надо воевать со своим кодом и компилятором чтобы он выдал нормальное сообщение об ошибке линкера/темплейтов или же до посинения искать UB/утечку

У меня проект 5 лет в проде без автотестов, утечек и крешей. ЧЯДНТ?

Ну значит очень простой проект, или этого всего просто не видно.

вы же в курсе

Я в курсе.
А вот ты — нет.
Потому что я на JavaFX пишу. И смотрю на разработку и обновления. В отличии от тебя.
Поэтому каждый твой тезис — глупость.

Потому что я на JavaFX пишу. И смотрю на разработку и обновления. В отличии от тебя.

 и как оно, на каждый чих обмазываться мотком макроаннотаций, писать тонну форлупов на пустом месте, ваять коллбеки или же всратое стрим апи которому отчаянно не хватает ХКТ?

Лол, шо за смешную ерунду ты несешь? ))

Хто знає якісь навчальні матеріали по електрону? Якогось адекватного короткого курсу не знайшов. (Робота з файлами та архівами локально). Навіть на ютубі тільки базові якісь штуки.
І ще якийсь фреймворк для швидкої побудови інтерфейсу. Щоб там буди вкладинки, колор пікери, датасеттери, бари, «спойлери» — панелі, які можна згортати на інші елементи інтерфейсу на десктопах, типу docs.microsoft.com/...​eswindow.png?view=vs-2019 (зовнішній вигляд елементів не важливий)
Треба написати невелику програму для редагування файлу і графічного відображення даних з самого файлу під він та мак. Вчити окрему мову довго, жабаскрипт більш менш знаю.

так. але ці плагіни ще треба знати а писати самому всі стилі і писати код для реалізації функціонування тих же пікерів, барів — додатковий час. може кто знає вже готовий фрейворк, який підходить під електрон в т.ч. — може поділяться назвою)
УПД. матеріали по ноду ждс в більшості розказують як робити збірку проектів з автокомпилціями стилів та скриптів. Про роботу з локальними файлами дуже мало.

бюджету нема — просто спрощення деяких робочих процесів )).

може кто знає вже готовий фрейворк, який підходить під електрон в т.ч. — може поділяться назвою)

Так все те же, что и под обычный front-end.
React-Bootstrap, Ant Design, UIKit — тысячи их.

матеріали по ноду ждс в більшості розказують як робити збірку проектів з автокомпилціями стилів та скриптів.

Не может быть такого. Скорее всего, ты читал материалы про какой-нибудь Webpack или другие бандлеры для фронт-енд разработки.

Всё хорошо у ноды с работой с файлами:
nodejs.org/api/fs.html

Не может быть такого.

я казав не про можливості а про навчальні матеріали чи уроки.

React-Bootstrap, Ant Design, UIKit

дякую, подивлюсь

про навчальні матеріали чи уроки.

Ну вот первое же, что находится в Google:
metanit.com/web/nodejs/2.8.php

Я по офф доке учил)

Якщо ще використання самого електрону можна пояснити обмеженністю бюджету та бажанням покрити декілька платформ, то крутити .net машину у браузері вже просто за межею добра і зла.

Electron своей простотой и низким порогом входа постепенно вытесняет другие решения в десктопной разработке.

В десктопній розробці програм в стилі «так, нам треба на всі платформи, на вчора, показати юзеру оці три картинки і відюшку з котиком». Крок в сторону якоїсь швидкодії чи вузької спеціалізації — і електрон пролітає зі свистом. Та що там казати — юзери телеграм вибирають в якості основного месенджера по причині «він не на електроні».

Особливо я обрав Телеграм, як єдиний адекватний популярний месенджер. Але його прожорливість змушує його перезававантажувати періодично.

И сейчас мы немного поговорим о том, почему топовые компании выбирают этот инструмент для своих приложений.

Потому что десктопная разработка не в тренде, и людей, умеющих в какой-нибудь адекватный юай-фреймворк тупо мало.

А JS-ников и верстальщиков которые будут двигать кнопки и красить их в нужный цвет можно чуть ли не на улице набрать прямо перед офисом.

А електрон — это просто инструмент, который позволяет кое-как запустить любое свистяще-пердящее фронтенд-говно на десктопе-не-внутри-хрома.

А то что вы написали в статье это все маркетинговый булшит.

умеющих в какой-нибудь адекватный юай-фреймворк

«Имя, сестра, имя!» ©

Лично я к таковым относил бы только Qt, но не так страшен Qt, как C++. А если писать на каком-нибудь Python, то по скорости работы результат будет не сильно отличаться от Electron.

Есть проект github.com/nodegui/nodegui, который позволяет использовать Qt как UI framework и писать, при этом, на JavaScript. Но уж очень в зачаточном состоянии, пока что :(

Кстати да, любой язык с динамической типизацией — это x3 к цене проекта

Ну это уже слишком толсто, коллега

но не так страшен Qt, как C++.

пиши на QML

QML — это разметка. Основную логику приложения же на ней не напишешь.

Да, там можно подключать JavaScript, и, наверное, даже получится слой View сделать полностью на QML + JS. Но это не спасёт от необходимости писать на C++ model и controller / presenter / viewmodel.

это все можно написать на жабоскрипте
а потом, по мере надобности легко переносить в плюсы
с электроном такой гибкости нет

с электроном такой гибкости нет

Есть. Нативные модули называется. Самый известный пример — Скайп, у которого на Электроне только UI, а ядро подключается именно как нативный модуль.

разница в легкости подключения с++ кода к qml vs. html/js огромна

В Electron подключение нативных модулей нужно крайне редко, и скорость и простота разработки остального приложения с лихвой компенсирует неудобства.

Но, смысл объяснять это собеседнику, который хэйтит всё, кроме C++ и называет JS разработчиков «неосиляторами»...

Ви взагалі бачили колись вершину Rapid Application Interface Development — Delphi

Не только видел, но и педалил в своё время. Как и на VB6.

яка ж там швидкість розробки, коли там батона нема ?

О Боги... месье никогда не слышал про react-bootstrap, ant design, UIKit, PrimeNG?

Полно библиотек готовых UI компонентов на любой вкус.

WYSIWIG дизайнера нет, это да. Но эту идею и в Веб разработке похоронили ещё где-то во времена Frontpage.

Ну так вы сами ответили на свой вопрос )

Знаешь JavaScript front-end — получаешь условные 4К, и тебя любят везде, как того дембеля из ДМБ.

Знаешь даже относительно современный WPF — уже не факт, что найдёшь работу на такую зарплату. Знаешь что-то более нишевое — может и повезти найти работу на хорошие деньги, но будет постоянно мулять job security.

В Electron подключение нативных модулей нужно крайне редко, и скорость и простота разработки остального приложения с лихвой компенсирует неудобства.

мы ходим по кругу

Но, смысл объяснять это собеседнику, который хэйтит всё, кроме C++ и называет JS разработчиков «неосиляторами»...

это называется «слить»
я ничего не хейчу, кроме забавной идеи совать жабоскрипт везде, где ни попадя, аргументируя это якобы легкостью разработки и низким порогом входа

я ничего не хейчу, кроме забавной идеи совать жабоскрипт везде, где ни попадя, аргументируя это якобы легкостью разработки и низким порогом входа

Потому что — возможно, подсознательно — вы переживаете за свою job security.

Ну вот сами подумайте: если у вас есть стабильный спрос на C++/Qt и вам нравится работать с этим тех. стеком — то вряд ли вас хоть как-то будет волновать то, где, кто и куда суёт JavaScript? :)

Но нет — вы-то понимаете, что многое из того, что раньше бы вам заказали разработать на Qt, теперь отдадут JS разработчикам на Electron. И вот это уже муляет.

Вот это пожалуй коментарий, который точнее всего описывает причины хейта к електрону.

Знаешь, что интересно. Что мир свернёт в эту сторону, мне говорил один очень умный дядька ещё году эдак в 2012м, когда Электрон и ему подобные фреймворки были совсем ещё не в тренде. XUL — и то очень мало кто использовал помимо самого файрфокса в те годы.

И вот я тогда тоже, при всём уважении к его опыту, воспринимал это предсказание как ересь, и не верил, что мир десктоп разработки реально может свернуть в эту сторону. Но дядька оказался прав.

Знаешь, что интересно. Что мир свернёт в эту сторону, мне говорил один очень умный дядька ещё году эдак в 2012м, когда Электрон и ему подобные фреймворки были совсем ещё не в тренде

Вот еще цитата из 2007-го:
any application that can be written in JavaScript, will eventually be written in JavaScript.
blog.codinghorror.com/...​principle-of-least-power

я уже объяснил, что конкретно муляет: технология, которую суют туда, где она работает, мягко говоря, херово под соусом «мы ваших поинтеров не понимаем и учиться не собираемся, нас и так неплохо кормят. а если шото не устраивает — купите себе комп пожирнее и морочьте голову»

Ну вот сами подумайте: если у вас есть стабильный спрос на C++/Qt и вам нравится работать с этим тех. стеком — то вряд ли вас хоть как-то будет волновать то, где, кто и куда суёт JavaScript? :)

Меня бесит что скайп и тимс, которые я обязан использовать, написаны на этом дерьме. Потому жрет оперативу не только скайп, а еще всякие студии с виртуалками.

Но нет — вы-то понимаете, что многое из того, что раньше бы вам заказали разработать на Qt, теперь отдадут JS разработчикам на Electron.

Я же говорю — если я вижу в лиде електрон, то я элементарнейше перетягиваю кастомера на Qt, тупо ценой, с этим проблем нет вообще.

Это работает с кастомерами, которые смотрят в первую очередь на цену.

С более опытными, которые зададут себе правильный вопрос — «А не останусь ли я у разбитого корыта, если завтра уставший архитектор окончательно устанет и свалит со своей командой в закат?» — такие фокусы провернуть намного сложнее.

Это можно спросить про любую команду, и?

Спросить, конечно, можно, вот только ответ будет разным.

В случае Electron, на него можно быстро переучить любого фронт-ендера. Фронт-енд — в мейнстриме, а, значит, специалисты такого профиля найдутся.

В случае C++/Qt, это сейчас довольно нишевая технология, специалистов найти будет непросто, что сильно повышает риски при уходе текущей проектной команды и даёт ей дополнительные рычаги для выкручивания рук по условиям сотрудничества.

P.S. Возможно, ты не сталкивался, а я хорошо помню, как в середине и даже конце нулевых многие заказчики, когда им предлагали уже вполне мэйнстримный на тот момент C#, говорили «не-не-не, мы потом не найдём никого на поддержку, пишите на VB .NET»

Ниже уже написал, что как минимум на джава фх вы плохо смотрели.

А если писать на каком-нибудь Python, то по скорости работы результат будет не сильно отличаться от Electron.

Может быть. А может быть, и нет.

А ещё результат с Qt+Python:
— будет обладать более-менее нативным look&feel операционной системы (не хуже, чем у Электрона точно);
— будет написан на строго типизированном ЯП, и даже ваши самые неопытные товарищи не смогут сложить яблоки с помидорами или засунуть одну хэш-табличку туда, где ожидалась другая хэш-табличка (Typescript? а у Электрона точно все интерфейсы протайпскриптированны?);
— не будет заложником абсолютно мрачной security model Электрона, где любая XSS-уязвимость даёт возможность полного code execution от имени пользователя.

Другое дело, что людей со знанием и Qt и Питона мало.

Другое дело, что людей со знанием и Qt и Питона мало.

Спрос рождает предложение. Английский явно сложнее выучить, чем освоить Qt, но как видишь, людей хватает.

А предложение определяет спрос. И в эту сторону рынок рабочей силы кодеров работает намного чаще, иначе Электрон никогда бы и свет не увидел.

будет написан на строго типизированном ЯП

Это на Python-то? )))
Не, я в курсе, что там есть type annotations, но это совсем не то же самое, что «строго типизированный ЯП»

Typescript? а у Электрона точно все интерфейсы протайпскриптированны?

Насколько я помню, да, для всего есть описания типов в виде .d.ts файлов

будет обладать более-менее нативным look&feel операционной системы

Это, сейчас, зачастую минус, а не плюс.

«Имя, сестра, имя!» ©

WPF был относительно годным, не знаю, убили его уже или еще живой.

Есть мнение, что WPF стагнирует. Сейчас WinUI развивают и, возможно, что-то даже из этого получится. Но это не точно :)

Ещё дергается, но тенденция налицо

Он не кроссплатформенный, как и WinUI

WPF с его графическими возможностями вплоть до рендера самописных шейдеров на элементах интерфейса очень даже. Проблема в том, что только Windows.

Правда жизни технологий, побеждает не лучшая с «инженерной точки зрения»

Даже я, думаю себе, если бы пришлось сейчас GUI клиента писать, для обычного компа, взял бы я Swing/SWT, WPF, Qt или wxWidgets ?

Врядли. При том что на Electron’е еще ничего не писал, взял бы думаю его.

Память будет выедать? так пользователи все равно не оценят труд по экономии памяти на их компах.

А потім буде як із віндовим клієнтом дропбокса, який жиріє з кожним роком, втрачаючи функціональність. І замість синхронізації файлів просто пердолить CPU.

Якщо це критично, можна йому пріорітет прищучити. Але ж та сама проблема із вижиранням оперативи. Деякі версії ще й течуть оперативою як дівка місячними

Але ж та сама проблема із вижиранням оперативи.

Как будто бы до появления Electron проблемы утечки памяти не существовало, ага.

Я уже достаточно бородатый дядька, чтобы помнить поиски memory leaks в C++ коде с помощью BoundsChecker.

Как будто електрон решает все проблемы утечки памяти

там просто течет так, что на мелкие утечки уже никто не обращает внимания

Якщо писати на нових плюсах, а не на гівні мамонта, і користуватися сучасними компіляторами з усякими санітайзерами й іншими статік чекерами, то не так і страшно, як колись.

Якщо писати на нових плюсах, а не на гівні мамонта, і користуватися сучасними компіляторами з усякими санітайзерами й іншими статік чекерами

А здесь мы снова приходим к тому, что таких людей — дефицит на рынке.

просто у вас рынок такой — дурнуватый.
когда с++ девелоперу платят в полтора раза меньше формошлепа, на рынке начинаются чудеса
и вопли — ох-ах, ну где же все с++ девелоперы, когда они так нужны

Slack и Microsoft программистов не на украинском рынке нанимали. И уж у кого-кого, а у MS разработчики на C++ точно есть. Но — и те, и другие, тем не менее, выбрали Electron.

Slack и Microsoft программистов не на украинском рынке нанимали

охх, не факт

Но — и те, и другие, тем не менее, выбрали Electron.

по одной простой причине — уже был запилен сайтик
тем не менее это не отменяет факта, что и слак и скайп и тимз работают крайне отвратно

Да ну прям «крайне отвратно».

У Teams ещё да, иногда бывают проблемы с отрисовкой UI. Но, ключевое слово — «иногда». И то там ещё вопрос, в Teams дело, или в истощении ресурсов системы.

У Skype была проблема, что, опять же, иногда «замирал» UI — но это вроде как полечили ещё пару апдейтов назад.

Slack сейчас активно не пользуюсь, но, когда пользовался примерно с год назад — вот вообще не помню каких-то серьёзных проблем с ним.

из последнего: скайп у упор не видел камеру, все остальные приложения видели
тимз периодически забывает откуда и куда должен проистекать звук
слак самый внятный из всей троицы
но все три нехило жрут цпу во время разговора

Да ну прям "крайне отвратно".

Прямо сейчас у меня на машине тимс, обычный, с*ка говорильник+чат, жрет 9 процессами суммарно 1,2 гигабайта.
Да, это крайне отвратно.

Понимаете, подавляющему большинству наплевать, сколько оперативной памяти занимает Teams.

А усилия по удовлетворению меньшинства эстетствующих гиков (это не оскорбление лично вас с моей стороны, если что) — не оправданы с точки зрения бизнеса.

Я все это понимаю.
Но это не отменяет того, что тимс действительно работает отвратно. Как и скайп. В отличии например от телеграма. Просто те, кого вы назвали большинством, уже привыкли считать отвратность нормой.

Так вот я же, как человек, пользующийся Teams и Skype ежедневно, и пытаюсь понять, что же там такого отвратного, кроме потребления памяти?

Нет, ну согласен — в Teams цитирование сделано через жопу, но Electron тут, как бы, не при делах.

Telegram — да, он шустрый, но он же и умеет намного меньше, чем Slack / Teams.

что же там такого отвратного, кроме потребления памяти?

Общее глючево. Он в целом тормозит.
Даже тупой скроллинг чата вверх на несколько экранов вызывает замену текста прямоугольниками-плейсхолдерами. Да и в целом юай имеет ощутимую задержку ответа.

тупой скроллинг чата вверх на несколько экранов вызывает замену текста прямоугольниками-плейсхолдерами

Вот честно — не замечал, пока ты на это не обратил внимания.

Не знаю, зачем разработчики Teams показывают плейсхолдеры для всех сообщений, а не только там, где нужно подгрузить картинку или другой внешний контент — но это, скорее, вопрос к пряморукости этих конкретных разработчиков, а не к технологии.

Сами современные браузерные движки при правильной HTML/CSS разметке отлично справляются с отрисовкой, включая плавную анимацию и offscreen compositing.

скорее, вопрос к пряморукости этих конкретных разработчиков, а не к технологии

А вот я не уверен. Я скорее прихожу к мысли что это воркераунд для сокрытия глючащих отрисовки / подгрузки / разметки текста при быстром скроле наверх.

Кстати, проверил в скайпе, который тоже на Электроне написан. Всё отлично скроллится вертикально, никаких плейсхолдеров.

Да, если очень резко проскроллить вверх, заметна небольшая пауза при подгрузке старых сообщений. Но это не прям пипец-пипец какая проблема, как по мне.

...а теперь сравни сделав тоже самое с телегой

Сравнивал, конечно. Понятно, что у телеги шустрее работает, кто же спорит. Вопрос же только в том, что мало кого на самом деле так уж сильно волнует скорость работы этой самой пресловутой вертикальной прокрутки

А вот глянь сюда ради интереса:
react-window.now.sh/...​mples/list/scroll-to-item

Отлично же всё прокручивается во всех направлениях.

Ыэээм...
И что? Внутри браузера != електрон, да?

Внутри браузера != електрон, да?

Как раз, наоборот. Электрон — это не более, чем обёртка над движком браузера. Поэтому, если внутри браузера прокрутка может работать быстро, то и в Электрон приложении будет работать точно так же быстро.

Вцелом Teams работает неотзывчиво. Описать нельзя, нужно, наверное, высокоскоростной камерой замерять. Нажимаешь на кнопочку или таб, а результат видишь с задержкой, которая заметна. Общее чувство эргономики страдает. Даже переключение между табами хрома работает быстрее.
VS Code страдает подобным, поэтому подозреваю, что может быть какая-то общая проблема электрона.

Но дело не в этом. В Teams просто уебищный и неудобный UI для людей родом из 90-х, которым не нужна куча свистоперделок, а нужен просто работающий чат.

У меня небольшая группа людей с хобби, я запилил нам Office 365 подписку и Teams. Никто не хочет ею пользоваться, все продолжают чатиться в ватсапе, сколько я их не уговаривал. Да и сам я не хочу в teams лезть.

Amazon Chime был отличным в этом смысле, простой чатик без свистоперделок (вру, добавили автозагрузку превьюшек для ссылок и он скатился в говно), в тормозах замечен не был.

Может у вас компы слабые? У меня на разогнаом 10700к десктопе не глючит вообще.

i5-3470. 12 Gb DDR3. Тимс глючит, постман глючит, клокифай глючит. Только не говори, что для тимс нужен проц для разгона.

Бери десктоп на топовом i7 последнего поколения, он же стоит как треть ЗП синьора по статистике Доу. Зачем мучатся?

Это рабочий комп. Дома я принципиально не ставлю ничего для работы (даже вижуал студии нет).

Так работай на домашнем как я. Что за мазохизм? Смысл в 2 раза дольше такски делать?
У меня в комадне есть синьор один, купил себе топовый игровой ноут за 6k$ но работает с галерного огрызка, я просто прозрел когда это узнал.

У меня тоже есть домашний хороший ноут, но работаю я сидя дома с галерного огрызка. Просто потому что я ибал заносить весь галерный софто-мусор на свой огороженный уйутненький ноут.

топовом i7 последнего поколения

лучше 7 ризен

Лол, мне теперь надо собрать игровой десктоп с топовой разогнанной комплектухой и системой охлаждения за $500, чтоб долбаный чатик не тормозил? :)

ICQ в свое время не тормозила на моем древнем Duron 800, а тут в 2020 не могут заставить работать чатик с аналогичным функционалом в компании, которая непосредственно разрабатывает OS Windows и по идее должна иметь людей, которые понимают как под нее программировать UI.

Хватит обычного десктопа за 1.5k$ это же недельная зарплата нормального синьора.
Тебе же все равно мощный комп нужен что-бы солюшен билдился за 1 секунду а не за 30.
Видимо в MS думали что у всех разработчиков по умолчанию нормальные компы.

Тебе же все равно мощный комп нужен что-бы солюшен билдился за 1 секунду а не за 30.

а тимз умеет отключаться пока солюшн билдится?

Он просто не занимет все 8 ядер ЦП, просто не трогай его пока билдиш, у меня в комадне на тимс никто не жаловался, и все поржали, когда я рассказал что на Доу у людей Тимс тормозит.

у меня в комадне на тимс никто не жаловался, и все поржали, когда я рассказал что на Доу у людей Тимс тормозит.

у меня в команде все поржали, когда рассказал, что у когото тимз не тормозит
время окуительных историй

а мы поржали что на доу John Kelly покупает комп серверного уровня чтобы тимс не тормозил

Я не ради Тимса покупал, я и незнал что он тормозит, пока вы не сказали, я покупал что бы 25 проектов билдились за 2 секунды.

Прикинь, есть люди, котоыре ведут разработку в облаке, а на ноуте запускают ssh, почтовый клиент, браузер и чатик.

т.е. нетбуками, да и ноутбуками по мнению MSFT уже никто не пользуется, все вернулись обратно на десктопы?

На нормальном ноуте с i7 тоже не тормозит.

На нормальном ноуте с i7 тоже не тормозит.

Можно ТТХ озвучить, а то я выкину еще 2 штуки баксов, а мне опять скажут — не нормальный ноут?

За ноуты не ручаюсь, у но у меня на десктопе i7 не тормозил не разу, десктоп i7 это как i9 ноут.

Ты не стесняйся, озвуч, десктоп это не зашквар.

Отличный аргумент.
Давай еще возьмем какойнибудь серверный тредриппер или ксеон и будем проверять не глючит ли на нем сраный десктопный чатик.

Это прога для разработчиков, в МС думают что у любого нормального разработчика будет минимум последний i7.

Твои комментарии все смешнее и смешнее ))

Это прога для разработчиков, в МС думают что у любого нормального разработчика будет минимум последний i7.

Это что MS своих разработчиков не считает адекватными? До недавнего времени там i7 приходилось выпрашивать и его давали только после апрува менеджера и скип менеджера. Сейчас вроде дефицит процессоров прошел, но вместо этого надо выпрашивать память.

Плюс в MSFT больше половины — не разрабочтики, им-то что делать с тимсом?

Так за свои деньги комп купи, десктоп с топовым i7 за 1k$ собрать можно без монитора. Ты же столько за 1 день зарабатываешь.

1. А как насчет того, что я не буду покупать компьютер со своих личных денег для корпорации с капитализацией 1.8 триллиона долларов? :)

2. А потом выяснить, что компьютеры и ноуты, купленные в Best Buy внезапно нельзя подключить к корпоративной сети и их прийдется относить обратно.

1. А как насчет того, что я не буду покупать компьютер со своих личных денег для корпорации с капитализацией 1.8 триллиона долларов? :)

Тебе же на нем приятнее работать будет. Из за того что он летает а не глючиь будешь таски делать быстрее и работать на час меньше.

2. А потом выяснить, что компьютеры и ноуты, купленные в Best Buy внезапно нельзя подключить к корпоративной сети и их прийдется относить обратно.

А вот это уже хреново, ни свой не принести, ни нормальный от компании не получить.

Тебе же на нем приятнее работать будет.

По моему опыту, гораздо лучше, когда приятнее дома, а не на работе :)

Из за того что он летает а не глючиь будешь таски делать быстрее и работать на час меньше.

Т.е. заплатить своих личных денег, чтоб таски в MSFT быстрее закрывались? What about no?

Т.е. заплатить своих личных денег, чтоб таски в MSFT быстрее закрывались? What about no?

Ты в другом контексте). По-хорошему в Украине все — сабконтракторы (и очень многие — сапожники без сапог одновременно).

В Teams просто уебищный и неудобный UI для людей родом из 90-х, которым не нужна куча свистоперделок, а нужен просто работающий чат.

Так а нет же смысла использовать Teams там, где нужен «просто работающий чат».

Teams — это, действительно, комбайн, интегрированный с MS Office, календарём, и Бог знает чем ещё. И все эти интеграции полезны в крупных компаниях, но не для небольшой группы друзей, увлечённых одним хобби.

Может, беда не в том, что Teams «плохой», а в том, что его используют не по назначению? :)

Teams — это, действительно, комбайн, интегрированный с MS Office

То, что тимс подсасывает, скажем, из какого-то ендпойнта в системе, скажем, джсончики из аутлука должно как-то оправдывать то, что у него весь юай тормозит?

Можно пример неуебищного корпоративного чатика вместо тимс?

Я и Teams не называл таковым, если что.

Вашим бы коллегам сделать там нормальное цитирование и оптимизировать отзывчивость — и уже вполне норм будет, как по мне. Для нас с Сигме ещё интеграция с Planner и SharePoint является очень приятной плюшкой.

А так, мы как-то смотрели на альтернативы; лучше Teams и Slack ничего не нашлось. Zulip на третье место бы поставил, но у них с видеозвонками полный швах.

Вашим бы коллегам

На всякий случай, я не имею никакого отношения к MSFT.

А-а, простите, по вашим комментариям показалось обратное. Ошибался.

Описать нельзя

Да можно. Работая с тимсом мне вечно кажется что на нажатие каждой кнопки разработчики вставили что-то типа
Thread.sleep(random(100, 500));

По крайней мере, если бы у меня стояла задача симитировать отзывчивость тимса, я бы поступил именно так :-З

какая-то общая проблема электрона

Как бы о чем и речь )

Работая с тимсом мне вечно кажется что на нажатие каждой кнопки разработчики вставили что-то типа
Thread.sleep(random(100, 500));

А у слака, кстати, тоже так?
На Тимс я слышал нарекания, но, в основном, от маководов. На Windows если и есть проседания по отзывчивости, то совсем незначительные (кроме вертикального скролла, да).

Как-то я на слак пока не попадал, ничего не могу сказать.

Windows если и есть проседания по отзывчивости, то совсем незначительные

— Очень долго реконнектится если отваливается сеть, при этом некоторые чаты надо обновлять принудительно. То есть, статусы уже у всех обновились в окне контактов, светятся зеленым\красным, но в окне непосредственно чата висит баннер сверху ( ’’ ... refresh ... ", не помню на память точное сообщение). Обновляешь — бах — 5 новых сообщений, самое старое 10минутной давности.
Очень неприятная особенность.

— Интегрированный Yammer открывется очень долго (но то, так по мелочи)

Лично не сталкивался с таким, но, допускаю, что такое возможно. Тут бы Артёму К. внимание обратить — может, скинет ссылочку своим коллегам, которые Тимс занимаются

не оправданы с точки зрения бизнеса.

с точки зрения бизнеса ни качество ни юзабилити не оправдано — давайте бабло и не отсвечивайте

Говнокода было меньше. А сборка мусора задача не самая простая, решалась десятилетиями, и все мои «детские» ошибки с утечкой памяти в современных платформах вообще прошли бы незамеченными.

Но на любой сборщик мусора найдётся армия борзописцев, уложившихся в дедлайн

Но на любой сборщик мусора найдётся армия борзописцев, уложившихся в дедлайн

Как говорится: зовите рвачей — нужно больше фичей.

Такі речі за один день не зникають, але eventually вони або схаменуться, або зʼявиться щось інше. Дружині я просто поставив RaiDrive.

А я користуюсь ним і далі. І що він потребує не дивився. Правда я його не тримаю весь час активним.
Я до того що таких як я — повно, і вони замінять дропбокс з інших причин.

История с виндавс виста & asus eee pc, как и история о 2008м людей ничему не учит

История учит что ничему не учит

а я, в далеком 200* году когда имея опыт разработки на Java Swing столкнулся что — ой, а работы то фактически и нет. «Все в веб!»
так что тут еще и чисто меркантильное — если вдруг придется писать GUI, ну напишу его я на правильной технологии. и — юноша с опытом разработки на TS под Electron работу найдет легко. Наверняка еще и выше по оплате.

а ты, с глубоким знанием Qt?

бывает конечно всякая работа. на доу ж как-то даже программиста на Cincom Smalltalk искали...

но в целом, освоившись в вебщине — видится мне что делать GUI на Electron’е и правда полегче будет. попробую может когда-нибудь. пока на беке плюс лидство — работы хватает.

а ты, с глубоким знанием Qt?

А я пока отжимаю клиентов с електрона на Qt, причем весьма успешно. Тупо ценой.

Тупо ценой.

ценой да, можно.
ценой клиентов и с джавы/.нет на ts/js а то и php отжимают :)
а если гошечки немножко добавить — то и обмана клиента никакого не будет — все будет работать не хуже.

А что не так с EEE? Семёрка кстати на них толково так поднималась. Другое дело что апгрейд там не самый простой, но тем не менее возможный.

Иные и по сей день живут как приставка к телевизору.

Тому кто это придумал — нужно в голову гвоздь забить (ДМБ)

Так хоть гвоздь в голове будет, а то там ваще пусто.

Викиньте каку.

Единственный нормальный продукт на электроне это Visual Studio Code. Без понятия как им это удалось. Все остальное тормознутый ад: скайп, тимс, постман уже написали ниже (5 вкладок в постмане умудряются фризить i5 c 12 Гб оперативы).

Visual Studio Code

Перегоняют в шарповский байткод?

Боже, какой треш.
Электрон это пожалуй самый хреновый выбор для десктопа. Я видел постман, занимающий 8гб после прогона тестов. Мне хватило.

Дякую за коментар. Бо я не зміг сформулювати без мата

Ну якщо тільки для десктопа — то так. Але якщо стоїть питання «є веб-версія, давайте портуємо її на десктоп», то відповідь очевидна...

Звісно, я як користувач надаю перевагу більш оптимізованому за ресурсами ПЗ. Але нажаль, 99.9% користувачів навіть не знає що це таке і як вимірювати.

Вже розробляються заміну на Rust: Tauri (Build smaller, faster, and more secure desktop applications with a web frontend)

Хтось ще вірить, що Rust замінить... ну майже все? Вбивця С, вбивця С++, тепер от — вбивця JS. Що далі? Портуєте на FPGA?

Почекай коли на Rust буде така ж швидка компіляція як і на Go, тоді і замінить

этого не будет, ибо компильго ничего не делает по сравнению с компилем раста

Сейчас все топовые Big Tech компании активно хантят членов Rust Core Team и меряются письками кто схантит самого большого члена. Казалось бы, зачем им все эти люди, если Rust все?

Казалось бы, зачем им все эти люди

Отправить колонизировать Марс. Вот тебе и

Rust все

:-)

Топові Big Tech, які ще нічого на ньому не написали — хантять. Мозілла, яка писала на ньому кілька років, звільняє.

Ответил бы по делу, но посмотрел на ваш тайтл и решил, что в этот раз лучше скипнуть.

Мені дуже подобається Rust і його принципи, я б з радістю на нього перейшов, якби індустрія була готова платити за цю додаткову безпеку. Але вона не готова. Можливо, поки що, а можливо і ніколи не буде.

Вы говорите про какую-то абстрактную индустрию, а я про Big Tech. Подробностей не будет ввиду NDA, но если вы знаете Rust, то для вас есть вакансий в Amazon, Google, Microsoft, Oracle на реальные проекты с большим импактом.

Mozilla к Big Tech никакого отношения не имеет. Это компания не может себе позволить держать специалистов такого уровня, когда с ней начали серьезно конкурировать на рынке труда за этих специалистов, и вцелом не имеет ресурсов продолжать разработку языка, который подбирается к статусу industry standard, ничего на этом не зарабатывая.

то для вас есть вакансий в Amazon, Google, Microsoft, Oracle

A порівняйте кількість плюсових і растових вакансій в цьому вашому Big Tech? Ну, ось.
І, окрім того, якщо щось потрібно в чотирьох компаніях світу, а вцілому в галузі ні — то це говорить про його стан ще красномовніше навіть за історію з Мозіллою.

A порівняйте кількість плюсових і растових вакансій в цьому вашому Big Tech?

Могу прикинуть, что в Амазоне растовых вакансий сейчас сравнимо или даже больше, чем вакансий на С++, потому что оттуда С++ выпилили еще в 2000-х.

окрім того, якщо щось потрібно в чотирьох компаніях світу, а вцілому в галузі ні — то це говорить про його стан ще красномовніше навіть за історію з Мозіллою.

Top down approach. Большие компании могут себе позволить рискнуть проектом, написав его на Rust. Они двигают Rust adoption. Через годик-полтора людям надоест сидеть в Амазоне, кто-то уйдет, кого-то уволят, начнут просачиваться в компании левелом поменьше (где можно только арбайтен на проверенных временем вещах) и продвигать Rust там, имея серьезный опыт его использования. Глядишь и вакансии на галерах появятся рано или поздно.

Да уже в линк и джинн стучатся с растом

Могу прикинуть, что в Амазоне растовых вакансий сейчас сравнимо или даже больше, чем вакансий на С++, потому что оттуда С++ выпилили еще в 2000-х.

Пошук вакансій С++ в amazon.jobs (www.amazon.jobs/...​ry=&city=&region=&county=) - 11837 штук. Давайте навіть фільтранемо лише девелоперів та архітекторів — все одно більше 9000.

Пошук там же по Rust: (www.amazon.jobs/...​ry=&city=&region=&county=) - 149 штук (121 якщо так само фільтранути лише девів та архітектів)

Навіть у вказаному Вами, як приклад, Big Tech, різниця майже в 100 разів.

Пошук вакансій С++ в amazon.jobs (www.amazon.jobs/...​ry=&city=&region=&county=) - 11837 штук. Давайте навіть фільтранемо лише девелоперів та архітекторів — все одно більше 9000.

По вашей ссылке на первых 10 страницах есть только 3 конкретно С++ вакансии.

Все остальные — обычные SDE, которых подтянуло, потому что в описании вакансии есть стандартное «Programming experience with at least one modern language such as Java, C++, or C# including object-oriented design», что значит, «Нужно чтоб ты знал хотя бы один язык программирования. Если знаешь С++ — годится, но писать ты на нем не будешь, в 99% будет Java»

Давай еще предположим на секунду, что я не по наслышке знаю на чем пишут в Амазоне :)

Если знаешь С++ — годится, но писать ты на нем не будешь, в 99% будет Java"

И что, в итоге плюсовиков на Java пересаживают?

А чому ж в списку «треба, щоб ти знав хоч одну мову програмування» немає «ну, наприклад, Rust»? Він би тоді теж знаходився загальним пошуком.

1. Потому что все используют стандартное описание вакансии, написанное в каком-то далеком 2010 году и никто его не обновляет.
2. Потому что Rust программисты не пойдут колбасить на джаве.

Main process. Физически это NodeJS.

Вау, какая вкусная оператива! Хрум.

Каждое браузерное окно запускает веб страницу в своем renderer process. Это по сути Chromium.

Хрум — хрум — хрум — хрум — хрум — хрум — хрум — хрум — хрум....

А ведь когда-то браузер считался «тонким клиентом». Сейчас он выжирает больше всей раздутой операционки со всеми её службами. И всё ради отображения кучки текстбоксиков и рекламных банеров. Даже без полнотекстового поиска по ним, ибо отобразить всё сразу уже и 100 гиг не хватит.

смотри, что там в браузере:
1) защита вкладок друг от друга. каждая вкладка в своем процессе с отрезанными правами доступа наружу
2) треш-расшифровка дерева DOM со всеми кошерными и некошерными хаками совместимости
3) JS-машина, неверное
4) возможно — кеш последнего отображения страницы
5) рендерер, который отрисовывает в квадратики памяти текст и картинки со страницы + куча пикселей вокруг, чтобы при скролле показывать уже отрисованную картинку из памяти, а не начинать шрифты и ДОМ прорабатывать
6) плагины в каком-то количестве
вот это вот все + 10М строк кода и жрут память

А ещё все-все-все ресурсы, включая видеорекламу, которые при первой же возможности кешируются. Разумеется не особо спрашивая операционку, а сколько вообще можно отожрать. Сразу в максималочку и до исчерпания.

Тот же скайп вообще вышвырнул и забыл, потому что гиг оперативы выжирает просто так, даже без какого-либо активного действия. Вацап не ставил по той же причине — прожорлив как хряк, толку ноль.

ну браузер же не для скайпа придумывали, а чтобы сайты крутить при связи через модем

А ЖабаСкрипт придумали чтобы делать им маленькие кошерные програмульки в одну строчку. А не вот это вот всё!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

И не внутри скайпа.

реально память выедает только 3.
можете взять, например, netsuft и посмотреть)

Так он же не на Хромиуме?

Кроссплатформенность еще никому не давалась дешево и за все нужно платить.

Были всякие поделки типа Qt или wxWidgets, дающие кроссплатформенность и позволяющие писать на любом из стопки языков.

То, что теперь электрон

Вот у Flutter, да, есть хорошие шансы подвинуть Электрон. Но там, по-моему, пока с полноценной кросс-платформенной поддержкой десктопа туговато.

Flutter огонь. Но десктопные приложения не фреймворком единым делаются. На JS дофигища готовых решений и готовых пакетов в npm. В случае же с флаттером, для сторонних библиотек нужно будет писать биндинги к C, что повышает порог вхождения и вот это вот все. Готовых решений на дарте пока еще маловато.
Но посмотрим )

Що значить «подєлкі»?

ну по сравнению с электроном жеж Ж)

Назвать Qt «поделкой, которая была» может только полный дилетант в этом вопросе) И кстати, Qt рулит именно в embedded, на нем делают дашборды для авто, систем «умный дом» и т.д. Потому что в Qt последних лет 5 оптимизировали Qml, и теперь ему нет равных на слабом железе. Да и на десктопе, разница ощутима.

ты удивишься. давай конкретное авто

Современный дeсктоп — это, как правило 1) игрушки/прочий графико-интенсивный софт 2) софт, завязанный на железяки. При этом, софт достаточно объёмный, сложный, рассчитанный на написание командами приличного размера.

Тот же .NET/WPF для такого подходит и используется. А что из этого умеет жабоскриптовый «электрон»?

visual studio code — буде достатнім прикладом?

Это не десктопное приложение — а онлайновый «Visual Studio Codespaces» перенесенный в оффлайн.

И не очень ясно, зачем оно на десктопе нужно — когда есть куда более продвинутый и бесплатный ВижуалСтудио?

Ок, кросплатформенность разве что. Для юниксов/линуксов — там с оффлайновыми графическими иде/отладчиками eсть определённый дефицит.

Ы?
Эклипс?
PyCharm?
Что еще мсье хочется?

Эклипс?
PyCharm?

Эклипс — адское тормознутое г. (написанное на жабе?)
PyCharm, вроде, только для пайтона? Впрочем, он убог тоже.

Эклипс на ура хавает сорцы Хромиума. Там под 10 миллионов строк.
github.com/...​docs/linux/eclipse_dev.md
Вы просто не умеете их готовить.

в линуксах есть же vi, зачем еще что-то нужно? :0

Потому что для той же современной фронтенд-разработки или для разработки под NodeJS классическая Visual Studio неудобна от слова «совсем». Всё-таки она изначально создавалась под C++ и .NET, и «уши» этого наследия торчат отовсюду, даже если использовать расширения для разработки на других языках и платформах.

VS Code же — это Swiss army knife. Можно писать хоть на JavaScript, хоть на Python, хоть на Golang.

Современный дeсктоп — это, как правило 1) игрушки/прочий графико-интенсивный софт 2) софт, завязанный на железяки

А также клиенты разнообразных мессенджеров (Skype, Slack, Teams, Discord), специализированные редакторы (Typora, Left) — и это первое, что приходит в голову.

А что из этого умеет жабоскриптовый «электрон»?

Кроссплатформенность и порог входа существенно ниже Qt / WxWidgets.

Только под Windows, действительно, можно было бы писать на .NET / WPF. И, собственно, корпоративные приложения чисто для внутреннего употребления иногда даже сейчас так и пишутся.

Но, как только речь заходит о чём-то более массовом, то аудитория пользователей MacOS становится слишком значимой, чтобы её игнорировать.

Кроссплатформенность и порог входа существенно ниже Qt

Когда в руках молоток, все вокруг кажется гвоздями. «Порог входа ниже» означает что качество софта будет таким же низким, а потому мы все ловим тормоза и краши скайпа, слака и прочего мусора.

При всём при этом, скайп и особенно слак не могут пожаловаться на нехватку популярности.

И, более того, для борьбы с тормозами и крашами достаточно одного толкового майора senior’а, остальное же может писаться мидлами и, местами, даже джунами — тупо потому, что в тех стеке Electron на порядки сложнее выстрелить себе в ногу, чем в C++.

При всём при этом, скайп и особенно слак не могут пожаловаться на нехватку популярности.

Да потому что даже если фейсбук-скайп-слак будет адово тормозить и требовать продать душу в пользовательском соглашении — им все равно будут пользоваться. Потому что сетевые эффекты.

И вообще, после того как МС купила скайп, она полностью выпилила оттуда весь оригинальный протокол и перевела на свой. Это можно было заметить по требованию включить его в оригинальных линуксовых клиентах. Это говорит о том, что основная ценность скайпа сейчас — не технологии, а юзербаза.

И, более того, для борьбы с тормозами и крашами достаточно одного толкового майора senior’а

Почему тогда я ловлю краши майкрософт скайпа на майкрософт виндоус 10? Толковых майоров не нашлось?

после того как МС купила скайп, она полностью выпилила оттуда весь оригинальный протокол и перевела на свой

Потому что предыдущий peer-to-peer протокол на основе супер-нод имел свои особенности, которые МС никак не устраивали. Да и стабильным этот старый протокол назвать было нельзя, особенно под конец его существования

Почему тогда я ловлю краши майкрософт скайпа на майкрософт виндоус 10?

Потому, что, видимо, эти краши случаются у пренебрежимо малого количества пользователей?

Потому что винда просто обожает прятать ошибки под ковёр.

А скажи, специалист по винде, почему в ней трудно удалить но легко over-write ? Я делал файл флажок работающего процесса и с удалением не смог, а с перезаписью смог. Это баг? Может пора Линдоус писать?

Java разработчику простительно не знать особенностей Windows, но нет — функции «прятать ошибки» в Windows нет от слова совсем. Вся их обработка на совести разработчика самого приложения.

Другое дело, что если мы говорим про Electron, то ошибки в JavaScript коде с вероятностью 99,99% не приведут к аварийному завершению хост-процесса, а что там происходит внутри виртуальной машины v8 — это операционную систему не волнует, и не должно.

Другое дело, что если мы говорим про Electron, то ошибки в JavaScript коде с вероятностью 99,99% не приведут к аварийному завершению хост-процесса

А вот в реальности получается как: какой-то индус рисует очередной модуль для связки ЖС с нативщиной, в нем баги-краши, и жабаскриптеры сразу опускают ручки: «ой, а как же я буду дебажить нативщину». В итоге на проект дергается за три-дорого специалист нативщик, который собственно и разруливает это все непотребство.

Короче говоря, бога нет.

Это справедливо для Скайпа, который исторически использует собственные нативные библиотеки для звонков и видео.

Но в большинстве других Electron приложений никаких нативных модулей нет, потому что попросту не нужны.

А даже если и нужны, то их кто-то писал — и, значит, доступный специалист-нативщик, вероятно, в наличии есть. К тому же, есть существенная разница между одним специалистом, который уже есть на борту и привлекается точечно, и наймом целой команды, умеющей в нативную разработку.

Вы внутри уже подготовили армию прикладных программистов знающих ваш фреймворк от корки до корки? Ведь только в этом случае можно за три простых шага в несколько часов собрать на основе использования вашего фреймворка любое чудо? А сколько стоят курсы Электрон для непосвященных? За сколько можно научиться собирать за три простых шага чудеса какие заблагорассудятся?
А иначе нет шансов, не взлетит.

Так я за мировое господство. Таковы цели фреймворко-творчества. Запилил фреймворк — запили академию по нему.

Ну и куда же по-твоему электрон сложит логи? Как уведомит об ошибке? В общем, есть ещё много такого, о чём винда по-дефолту не расскажет. А коль скоро скайп перекроен мелкомягкими (разговор был о нём), то про совесть их разработчиков впору легенды слагать и кино снимать — индийское, с танцами и бубном

у них есть еще замечательная поделка — тимз
жуткое глюкалово

Жаль конечно что ICQ и Скайп похоронили. Их вполне можно было обновить в соответствии с новыми веяниями в плане безопасности и проходимости протоколов — и пользовать ещё хрен знает сколькодесят лет.

Суть-то не поменялась, в основном это просто чатик с большим контакт-листом. Иногда звоночки. Иногда массовый звоночек, разумеется для платящих клиентов. Но это всё. И это «всё» могло просто сожрать телефонию с потрохами, превратив опсосов в жалких извозчиков трафика.

Ну и куда же по-твоему электрон сложит логи? Как уведомит об ошибке?

Как запрограммируешь — туда и сложит, и так и сообщит. Все механизмы для логгирования и уведомления об ошибках операционная система предоставляет, а больше от неё ничего и не требуется.

Ну да, механизмы. Направленные ровно на то, чтобы те кто не знает, где искать — в жизни не нашли, куда же софт втихаря срёт ошибками.

Даже Андроид переплюнули.

Потому что предыдущий peer-to-peer протокол на основе супер-нод имел свои особенности, которые МС никак не устраивали. Да и стабильным этот старый протокол назвать было нельзя, особенно под конец его существования

Они знали обо всех особенностях еще до покупки скайпа (due diligence), и все равно решили его купить, а не делать свой клиент с нуля.

Потому, что, видимо, эти краши случаются у пренебрежимо малого количества пользователей?

letmegooglethatforyou skype crashes

Они знали обо всех особенностях еще до покупки скайпа (due diligence), и все равно решили его купить, а не делать свой клиент с нуля.

И что это доказывает? :) Да, знали. И, раз купили — то посчитали это целесообразным с точки зрения бизнеса, разве нет?

letmegooglethatforyou skype crashes

Ну, такое практически по любому популярному приложению можно нагуглить. Но говорит это только о том, что идеально оттестированного и отлаженного софта в потребительском сегменте практически не бывает.

И что это доказывает? :) Да, знали. И, раз купили — то посчитали это целесообразным с точки зрения бизнеса, разве нет?

Это доказывает, что МСу нужна была пользовательская база, а не технология.

Это вполне распространённый сценарий в бизнесе. МС точно не единственные, кто покупали другие компании ради их пользовательской базы.

Я хотя и не фанат Скайпа, но справедливости ради, скажу что за последние лет 5 вообще не помню случая, чтобы он куда-то «вылетал». Все работает как часы. И даже на телефоне через 3G.

про ваш слак как апликуху могу сказать одно — ацкое чудище, и приводить его в пример — не очень здорово

особенно слак

Десктопный клиент слака неюзабелен. Ток браузерная версия.

Только что открыл в браузере — никаких отличий от десктопного клиента не заметил. Разве что, экономия памяти может играть роль, потому что в браузере не нужно запускать ещё один полновесный экземпляр webkit

Именно так. Нах не нужен еще один браузер — и так памяти не хватает

1 — частный случай десктопного софта (но тут WebGL в помощь)
2 — еще более специализированый кейс (как и в случае с .NET/WPF нужно писать низкоуровневые библиотеки на C\C++ специфичные для железа и вызывать его из electron’a)

Для электрона есть своя немаленькая ниша на десктопе, и она активно заполняется. Список приложений на этом фреймворке достаточно большой www.electronjs.org/apps
Электрон не претендует на то, чтобы делать на нем софт для монтажа видео или риалтайм процессинг данных с 1кк датчиков. Но для быстрой разработки бизнес-приложения под 3 платформы — очень даже толковый инструмент.

Но для быстрой разработки бизнес-приложения под 3 платформы

Есть и другие решения, например тот же JavaFX. И он всяко будет гораздо оптимальнее говнотрона. Вот только усредненный джавист про JavaFX хорошо если слышал.
А JS-тушек можно за час армию набрать.
Вот и все причины.

На JavaFX смотрели несколько лет назад. К нему были существенные вопросы как касательно зрелости самого инструмента, так и его дальнейшего развития после перехода «под крыло» сторонней компании.

Плохо смотрели :)
У OpenJFX все прекрасно. И со зрелостью и с поддержкой, и с апдейтами. А Пение там ниже какуюто чепуху постит.

Насколько «всёпрекрасно»?
1) Покажи работу на этой цацке в Украине?
2) Покажи достойные продукты на этой цацке, не сильно специализированные — я б не против пощупать их на предмет вменяемости для конкретного юзера.

PS. Если б я был всегда прав, мне бы незачем было общаться с остальными. И вот уж где всегда большинство ошибается — так это в отслеживании технологий. Всегда рулят те, кто держит продукт руками, а не читает новости и развешивает ухи на ивентах.

PPS. JFX удалось пробить брешь к мобильным платформам, это уже имеет хоть какие-то признаки автономности софта, без перекладывания проблем на конечного пользователя?

Насколько "всёпрекрасно"?

openjfx.io
Да и вообще погугли, полезно )

1) Покажи работу на этой цацке в Украине?

При чем тут Украина? Нам спихивают через бодишопы саппорт разной чуши. Десктоп же это узкоспециализированные и нестандартные вещи, выходящие за пределы стандартного макакинга бекенда на куче хайповых технологий и фронта на хроме.
И кстати, даже у нас я видел вакансии с JavaFX.

Покажи достойные продукты на этой цацке

Я что тебе гугл?
Кроме того, из-под нда (не своего) я знаю, что как минимум на нем пишут софт для космоса, для авиации, для медицинского оборудования. И твои умозаключения о том что он не нужен и не взлетел никому особенно не упали :)

Одним из критериев используемости инструмента является в том числе то, что на стековерфлоу всегда есть куча актуальных и свежих запросов и ответов на проблемы. Что означает что куча людей на нем пишет и разбирается.

ПС. насчет мобильных платформ и JFX вообще ничего не знаю и не слышал. Возможно, это направление мертво. Судя по мейлинг листам ежедневной рассылки по openjfx разработчика, 100% деятельности про десктопы.

Десктоп же это узкоспециализированные и нестандартные вещи

Материалайз?

даже просто запрос javafx materialize уже даст представление что в гугле полно всего про javafx
www.jfoenix.com

Там, вроде, на С++ было. Вероятно, MFC. Может, уже перепилили.

Но с развитием у этой самой ЖабаФХ совсем уж по-жабьи. Жаба своё на андроиде отыграла по полной.

А десктопы... скоро мы вообще забудем, что это. Эра телевизоров во всю стену уже наступила. И да, это Андроид.

А десктопы... скоро мы вообще забудем, что это.

Ага-ага, их хоронят всего лишь чуть меньше лет, чем Винду и PHP :)

Ну, винду могут похоронить вместе с десктопом на раз. А ключевой драйвер десктопа — рабочее место, и оно вполне даже может перейти на андроид.

Другой вопрос администрирование этого зоопарка, разворачивание доменной инфраструктуры на ведре это мягко скажем придётся заново выпить всё выпитое за долгие десятилетия админами.

Линуха бы могла это всё пожрать без шума и пыли. Если бы не откровенная бюрократия в процессе разработки и согласования, которая утопила всё что только можно утопить. Конечно, это тоже когда-нить пройдёт, но вот когда это случится... пока даже начинаний не видел. Вообще всё плохо на Линухе с десктопом именно для рабочего места.

В то же время — выпускать приставку уже не будет модным, надо будет покупать её вместе с новым телевизором, в который разумеется будут предустановлены игры (чтобы продать из комплектом). Десктопы могут просто повторить судьбу телефонов теми же последовательными изменениями, которые по сути уничтожили телефон, сделав из него тамагочи.

Вообще всё плохо на Линухе с десктопом именно для рабочего места.

А что плохо? Сижу уже лет 7 на убунте. Не надо виртуалки запускать — софт на компе компилится и багает так же, как на железе или сервере.

Программисты — это чуть ли не единственная профессия, у которой нет проблем с доступностью профессионального софта на Linux. Но мир не заканчивается на программистах.

Обработка видео и звука, проектирование зданий и интерьеров, ПО для вёрстки печатной продукции, работа с графикой и фотографиями — да, для большинства из этого можно найти какие-то программы под Linux, от любительского до почти профессионального уровня. Но, беда в том, что все эти программы — совсем не тот индустриальный стандарт, к которому привыкли иллюстраторы, полиграфисты, видеомонтажёры и т.п.

Никто в здравом уме не пересядет с Adobe Illustrator на Inkscape, или с Adobe InDesign на Scribus.

ну был же когда то SG на мипсе, и сидели десигнеры как миленькие на злом юниксе и не рыпались

SiliconGraphics жеж
эхх, маладьожжжжж ©

И где теперь тот SG со своим MIPS? :)

Сидели-то на злом юниксе не от хорошей жизни, а потому, что только у SG было достаточно мощное графическое железо. Да и альтернатив-то тогда в плане ОС особо не было для железа такого класса.

И где теперь тот SG со своим MIPS?

СГ мигрировал софт в винду, мипсы мигрировали в роутеры
а загнулись они изза дороговизны и проприетарщины

а где их OpenGL?
SGI пережил 2 купившие его компании и теперь в составе HPE

Нічого різним дизігнерам сюди лізти!

Так они отнюдь и не стремятся :) Это же среди программистов есть горячие головы, мечтающие пересадить всех десктоп-пользователей на Линукс.

Не путай, это манера манагеров «пересадить» куда-нить с первого числа. А программисты хотят ДОПИЛИТЬ, чтобы этим действительно можно было пользоваться.

Да, чёрт возьми, мы хотим CentOs в мире десктопа.

PS. А виндой пользуются, потому что большинство остались на Windows 7, несмотря на всю её древность. И медленно-медленно мигрируют на десятку, с тем же примерно темпом как апгрейдят железо.

PPS. Лучшим дизайном винды считаю Windows 98. И спасибо разработчикам Classic Shell, которые более 10 лет удерживают его живым и работящим поверх всех форточек. Да, мелкомягкие, всех ваших «революционных» нововведений я не увидел, как и ослик-браузера во всех его инкарнациях. Разрабам Classic Shell тоже задонатил. А мелокомягкие — лососнут тунца.

«для програмістів» це синонім «нічого не працює, після зборки ретельно обробити напилком».

Щоб їм їздити на авто, створеному для автомайстрів aka Moskvich

Чтобы «все работало» нужно как и прежде, 95% времени не машиной пользоваться, а пялиться в терминал и гугл чтобы это наконец заработало.

Потому что надо вылизать много чего. Если быть точным, вообще всё. Это как в ресторане, где заказав яишницу надо самому найти петуха, который трахнет курицу редкого вида самку глухаря [как это будет на новоправопысном?], чтобы потом убедить её снести именно яйцо (и не дедушке), и чтобы последнее не самоуничтожилось в конфликте с новыми веяниями буддизма.

Вот буквально только что: тривиальнейшая задача — отправить почту с командной строки. Херак-херак скрипт, mail то-то и то-то — с горем пополам работает. Хорошо, теперь иди в демона... матьмояженщина, пути ему не абсолютные, линки мы не понимаем, командную строку разбирать тоже не хотим — а зачем когда можно послать подальше. Ладно, хрен с вами, пишу отдельным файлом скрипт (это напомню, чтобы послать письмецо в 1 строчку). Отладил, вроде пашет. Запускаю службу — а болт. Проверяю другими командами, всё поднимается. Тот же грёбаный мэйл проверяю — никаких ошибок не сыплет, логи чисты как биография Януковича перед выборами. Но из прямого запуска скрипта всё работает, из службы — зюськи.

Решение в лоб — беру sendmail. Твою ж дивизию, какой кретин писал ему синтаксис? Почему я должен всё делать руками, включая перевод в base64 темы письма? Откуда я должен узнать, что сабж от тела отделяется не одним переводом строки, а двумя, а один просто проглатывается?

А теперь вишенка на тортике: если в скрипте после вызывается sendmail, то строчка с командой mail внезапно начинает отрабатывать и тоже слать, прилетают оба письма. Если её там нет, то не шлёт.

И так — вообще всё. И всё что работает, работает не потому что документация, а потому что копипаста готовых решений. И как только хакеры догадаются отравить тот же stackoverflow каким-нить сильно дырявым советом, нацеленным на раскрытие заднего прохода всему миру, и накрутить голоса, используя сетку ботов — произойдёт то же, что и с драйверами для Windows, под видом которых Гугл активно льёт вирусню — благо последние-то активно приплачивают за рекламу.

Зато как багу какую подправить — обнаруживаешь готовые патчи, появившиеся в одно время с багом, и которые по 2-3 года не могут заимплементить в релиз.

Вот буквально только что: тривиальнейшая задача — отправить почту с командной строки. Херак-херак скрипт, mail то-то и то-то — с горем пополам работает. Хорошо, теперь иди в демона... матьмояженщина, пути ему не абсолютные, линки мы не понимаем, командную строку разбирать тоже не хотим — а зачем когда можно послать подальше. Ладно, хрен с вами, пишу отдельным файлом скрипт (это напомню, чтобы послать письмецо в 1 строчку). Отладил, вроде пашет. Запускаю службу — а болт. Проверяю другими командами, всё поднимается. Тот же грёбаный мэйл проверяю — никаких ошибок не сыплет, логи чисты как биография Януковича перед выборами. Но из прямого запуска скрипта всё работает, из службы — зюськи.

Решение в лоб — беру sendmail. Твою ж дивизию, какой кретин писал ему синтаксис? Почему я должен всё делать руками, включая перевод в base64 темы письма? Откуда я должен узнать, что сабж от тела отделяется не одним переводом строки, а двумя, а один просто проглатывается?

А теперь вишенка на тортике: если в скрипте после вызывается sendmail, то строчка с командой mail внезапно начинает отрабатывать и тоже слать, прилетают оба письма. Если её там нет, то не шлёт.

А чем тебя gmail не устраивает в браузере?

Тем что это скрипт, он должен сам работать.
________________
А гмыло в браузере меня не устраивает вообще всем, это исключительно аварийный/удалённый доступ к почте. Для всего остального есть честные почтовые клиенты. Я люблю когда много, и быстро, и 14 ящиков в одном окне, даже то мыло что от государства на gov.ua, прикинь, оно всё ещё существует.

UPD: оно-то существует, но у этих зебилов тупо сертификат закончился. И всем похер. Даже на то, что эти ящики являются юридическими адресами ФОПов.

Ну признай же что Пение описал обычный эпизод из обычного дня жизни обычного убунтовода или прочего другого вида линуксятника

> Вот буквально только что: тривиальнейшая задача — отправить почту с командной строки

Вже смішно... вот прямо заплющюю очі й бачу, як домохозяйки за пару хвилин автоматизують відправку пошти на Win або Mac =)

От як раз для домохозяйок вінда саме те що треба, а ще краще якийсь андроєд. А от для Лінукса не мати «із коробки» засобів швидкої автоматизації настільки примітивних задач — то ганьба.

Питання не в тому, чи там все є. А в тому, що для примітивної задачі є необхідність лізти в RTFM замість рішення «із коробки». Або ж шукати який софт ставити (і це той ще гемор).

Я лише навів конкретний свіжий випадок із чим зіткнувся просто під час дискусії — як приклад, чому Linux є складним.

По суті не в лінуксі справа як такому. А у відсутності достойних дистрибутивів, точніше кажучи одного, який можна тупо поставити і працювати, а не «вот ето вот всьо».

Вот буквально только что: тривиальнейшая задача — отправить почту с командной строки.

А покажи пжл как ты в форточках отправляешь почту из командной строки?

тривиальнейшая задача — отправить почту с командной строки

Ви пішли шляхом, яким треба було йти в якомусь 1999-му році. Зараз ця задача вирішилась би методом «смикнути апішку сервіса, відповідального за оповіщення». Код для цього скопіпастився б з сайту сервіса, зайняло б це секунд 30. Інша справа, що, можливо, за це довелося б заплатити. Але так-то у всіх вже є контракти з якимось клаудом, і це був би просто ще один рядок в стандартому інвойсі.

І залежність ще й від клауда. Там, де нічого взагалі не треба, де задача одноразова.

Ви коли сексом займаєтесь теж використовуєте древній інтерфейс замість того щоб заключити контракт з якимось клаудом :)

Я кодер. И для меня не супер. Потому что неудобно.

Я кодер. И для меня не супер.

здравствуй кодер

А ключевой драйвер десктопа — рабочее место, и оно вполне даже может перейти на андроид.

Не может. Никто кучу специализированного софта переписывать под Андроид не будет.

Полноценный (!) MS Office там тоже не появится по понятным причинам, а лёгкая замена MS Office на Libre / OpenOffice — это, скорее, из разряда сказок, если речь о корпоративной среде с совместной работой над документами.

выпускать приставку уже не будет модным, надо будет покупать её вместе с новым телевизором, в который разумеется будут предустановлены игры

Приставки покупают не для того, чтобы играть в казуалки. А запихнуть в телевизор ту же мощную видеокарту и обеспечить ей необходимое охлаждение — боюсь, необходимые инженерные решения поднимут цену на такой телевизор до стоимости печени единорога. Ну, или придётся менять форм-фактор такого телевизора с плоского на «ящик» а-ля старые кинескопные телевизоры эпохи наших родителей.

Не может. Никто кучу специализированного софта переписывать под Андроид не будет.

Если начнётся тренд (а Гугл умеет в тренды), побегут переписывать как в своё время верстальщики переписывали всё под хром, а до того — под Internet Explorer.

Вот только нет пока приличного ведроида для больших экранов и маленького поля зрения. Тупо нет. Ну и делать соответственно никто кроме Гугла не станет, разве что китайцы, чтобы не оказаться под прессом патентных тролей последнего (для этого совсем не обязательно что-то нарушить). А та же Сяоми может взять да и поднять интерфейс человеческий. Шутка, не смогут, потому что китайцы они... ну не могут просто взять и допилить, обязательно бросят недоделанным всё за что берутся. Потому хард у них получается, а софт... увы.

вспомнилась статья

... задача трансформации Android в «настольную ОС» (что сейчас ассоциируется и с рабочими станциями) не является ни нерешаемой, ни бессмысленной.
Android — путь к десктопу — ko.com.ua/...​oid_put_k_desktopu_113948

В общем-то они правы, просто чуть опередили своё время. Как знать, может проект и реанимируют.

Но камень преткновения — именно интерфейс. Слишком уж просто всё испортить, если пытаться сделать его «универсальным», вместо понимания что нельзя переделать природу человека, равно как и устройств ввода. Интерфейс под пальцы всегда будет отличаться от интерфейса под мышь, под голос, под пульт управления, под лазерную указку.

Кстати, последняя не так сложна как кажется. УФ датчик плёночный можно сделать достаточно чувствительным и долговечным, а от диодов добиться приличной фокусировки паршивой пластиковой линзой. На крайний случай синий, хотя датчик под него сильно дороже, как по мне, дешевле вложиться в излучатель помощнее, нежели удорожать массив датчиков.

Интереса ради всё-таки глянул. Внезапно, проект прекрасно форкнулся в PhenixOS и живее всех живых. Но нам его поюзать не судьба, ибо китайский чуть менее чем полностью. Гугл, естественно, послан оттуда широкими шагами с великим китайским «спасибо» за Андроид.

Да ладно, вот например откуда хром растет:
Blink is a fork of the WebCore component of WebKit, which was originally a fork of the KHTML and KJS libraries from KDE. It is used in Chrome starting at version 28.

Ты какуюто малосознанную чушь постишь.

Підписатись на коментарі