Как так вышло, что еще 10 лет назад можно было один раз встретиться с представителем компании и на следующий день уже выходить в команду, а сегодня найм растягивается на недели и включает много этапов.
Еще 15 лет назад в одной из статей крупные западные компании публично признались, что не умеют нанимать: людей выбирают очень медленно и не всегда эффективно.
И это в идущих друг за другом абзацах. Тут наверно надо определиться с временным периодом.
Есть процесс называемый трансляцией (я его назвал сборкой, сути это не меняет). Это преобразование кода на одном языке в другой (Go в машкод, C# в MSIL, TS в JS), принципиальной разницы в этом нет. Если в MSIL, есть типы, то в машкоде их нет, как и в JS. Разработка в JS, это конечно не тоже самое, что в машкоде, но принцип тот же.
Если на Go, DLL вызывается неправильно происходить SEGFAUL, что более страшно, чем плохо написанные .d.ts. Вы так же можете нарваться на такие же проблемы.
Зачем Вы мне это пишите уже сколько раз? Я Вам уже написал что сравнивать это бессмысленно. По Вашей логике корректное сравнение будет сборка спичек в коробок и сборка камешков на песке в пирамидку это же тоже сборка и сути не меняет, значит ее можно сравнить с сборкой Go в машинные коды и Ts в JS и чего угодно правильно? Я уже написал Вам что в браузере (а я пишу только о нем) иной метод распространения кода. Было бы корректное сравнение если бы Вы писали на Go++ с каким-то там новым крутым синтаксисом который бы транспилировался в Go а потом компилировался в машинные коды на каждом клиенте. Мой аргумент что TypeScript не поддерживается браузером, Ваш аргумент ну есть же трансляция это же ведь сборка а раз это сборка то значит это также как и везде, вот только зачем Вы сравниваете с чем-то другим? Если вспомнить о том что TS не первый кто пытался (до него были CoffeScript и Dart и где они сейчас?) а также то что TS разрабатывается компанией которая очень любить уничтожать свои же технологии в один день.
Один прекрасно настроенный Vite все решает, или Bun для консольных приложений.
Для того чтобы его запустить надо поставить node, затем затащить зависимости через npm. Или просто писать код сразу в блокноте и он сразу заработает после сохранения файла и это работает везде. Вот допустим Вы "собрали" свой TS файлик который содержит 5 строк кода и задеплоили на сайт, пользователь открывает сайт а у него падает в этом файле на 12 строке кода, Ваши действия? Vite решит эту проблему?
Вот эта причина:
Не везде и не для всего это проблема актуальна, до появления TypeScript-а писался код и все было нормально.
А что касается полифилов:
Я у Вас что-то спрашивал про полифилы? Нет не спрашивал
TS в плане поддержки "старья" ничем не отличается от других технологий.
Это потому что этим ребятам пришлось создавать все с нуля силами волонтеров. Если бы был открыт компилятор Delphi то они справились намного быстрее и была бы 100% совместимость с Delphi в компилируемых единицах.
В Go есть процесс сборки, в C# есть процесс сборки
Вот только в случае TS нет никакой "сборки", они просто генерит такой же код с некоторыми изменениями чтобы работало в JS потому что браузер не понимает TS. Вы сравниваете разные вещи. Цель создания TS это просто попытка решения проблемы слабой типизации языка JavaScript вызывающей падения в рантайме чтобы можно было отловить их на компайл тайм. Именно эту проблему решает TS засчёт обязательного требования по указанию всех типов параметров и созданию интерфейсов, все остальное это некоторое количество сахарка. Но JS все еще остается динамическим языком со слабой типизацией и в отличии от Go/C# и прочих языков которые компилируют в бинарный код, код на JS так и остается кодом на JS в котором можно вытворять все что угодно в рантайме. Преимущества типизации ts имеют смысл когда Вы пишите код для backend-а. На фронте я хз что Вы делаете что Вам так сильно нужна типизация.
Проблемы в том, что бы использовать TS из-за того, что его не поддерживает браузер нет.
Проблема заключается в обмазыванием тонной тулинга просто для того чтобы сделать такой же код который просто можно написать и он просто будет сразу работать. Если транспилировать TS с последним стандартом то различий в результирующем файле будет не так и много помимо сахарка самого ts. А давайте еще тонну транспиляторов напишем которые кучу сахарка и приемов добавят? Вот только смысл во всем этом если на выходе все равно будет старый добрый JavaScript и возможности всех эти языков будут ограничены возможностями JavaScript. Как по мне жду когда в WASM-е добавиться доступ к WebAPI и DOM вот тогда фронтовый код вполне можно будет писать на языках не требующих что-то исправлять транспиляторами, неисключено что js может сильно подвинуться каким-нибудь rust-ом или go.
Нет ни единой причины не использовать TypeScript в браузере, да посредством сборки, но сути дела это не меняет. Если не согласны приведите контрпример.
Нет это Вы предъявите мне причины почему я должен использовать TypeScript, потому что это Вы утверждаете что я должен на нем писать. Я не утверждал что надо на чем-то писать и если я пишу на чем-то еще то "являюсь извращенцем".
Внезапно оказывается, что даже если собирать нативный бинарник, он может не запуститься на голой ОС из-за отсутствия библиотек. И надо либо ставить библиотеки, либо раздувать бинарник. То же самое в JS-мире -- хочешь поддержку старых браузеров, раздувай бандл полифилами.
Вероятно потому что TypeScript это не целый новый язык а просто надстройка добавляющая статическую типизацию (ну по крайней мере делающая вид) и еще пару фишек а также продвинутый тайчекер основанный на этой информации.
А на машине разработчика нельзя скомпилировать TS в es5 со всеми полифилами? Или это другое?
Можно но как это относиться к тому что все должны немедленно начать писать на TypeScript? Ну я могу сказать что на C# можно в том числе и фронт писать для веба (через Blazor) также с шагом компиляции, к слову таких инструментов для разных языков куча которые транспилируют в JavaScript, но является ли это аргументом для того чтобы утверждать что надо писать только на TypeScript?
А то что в Стиме половина игр ставят на комп vc++ redistributable?
Приложения написанные на Go компилируются в бинарный код на машине разработчика и распространяются дальше в нем не требуя компиляции и линковки на клиентских машинах. JavaScript распространяется в исходных текстов и требует компиляции/интерпретации на каждой клиентской машине браузером. И если браузер не понимает TypeScript (и не факт что станет в будущем) то Ваша аналогия выстрелила мимо. До тех пор пока TypeScript не появиться в браузере говорить о том что только в нем надо писать весь код а все кто не согласен извращенцы крайне спорно. Особенно учитывая что 95% кода написанных на TypeScript это JavaScript.
Не работал с node уже много лет, я использовал плагин для Chrome позволяющий отображать информацию из node в DevConsole. Вроде бы еще был вариант для прода позволяющий запустить node с какими-то ключами и она начинала выдавать лог который также впоследствии можно было прочесть плагином. Как все это работало и назвалось так сходу не подскажу.
Более того, выбор может пасть на JS (и вполне адекватно, к сожалению) даже когда вы пишете мобильное и/или десктопное приложение, например, на React Native или Electron. Как сложилась такая ситуация, отдельная история, но это факт, и с ним надо мириться.
Выбор может пасть если в команде есть только Web разработчики и руководство пытается сэкономить в остальных случаях вполне нормально начать делать на других языках/технологиях. А мириться или нет это уже Вам решать.
Ситуация с фронтендом настолько ужасна, что самый популярный и стабильный фреймворк React заставляет вас писать на языке jsx (tsx), который является абстракцией над JS и HTML.
В случае React-а популярный не значит хороший и правильно сделанный поэтому ну такой себе показатель.
Логика разработчиков JS проста — миллионы сайтов и приложений работают на джаваскрипте, следовательно, из джаваскрипта ничего нельзя удалить. В итоге в него все добавляют и добавляют, как следствие, на нем можно писать в десяти разных стилях и одна проблема решается дюжиной разных способов. Как думаете, как это влияет на качество и удобство разработки? Правильно, влияет очень плохо. Два проекта даже на React могут выглядеть совершенно по разному, не говоря уже о проектах с разными фреймворками. Они даже синтаксически (из-за бесконечного юзания различных настроек и сахаров) легко могут отличаться.
Ну тогда любой язык существующий больше 5 лет тоже автоматически плохой, потому что любой уважающий себя язык развивается, какие-то вещи в нем признаются устаревшими но не удаляются из-за обратной совместимости чтобы дать людям время на адоптацию. Веб также удаляет технологии, Flash с Silverlight-ом не дадут соврать.
Короче, из коробки JS годится лишь для написания очень маленьких вещей, а как только ситуация меняется, начинаются маневры, и поверх основной технологии (собственно, языка), начинают наслаиваться дополнительные, и все это (из-за основной причины, отсутствия нужных инструментов в самом языке), ходит ходуном и шатается от ветра как карточный домик.
Итого, JS “из коробки” не масштабируется — факт. Для масштабирования требуется сильное усложнение системы путем добавления в нее компонентов неочевидного качества. И дело даже не в комьюнити - разработчики сторонних инструментов большие молодцы, что решают насущные проблемы, но они просто не могут решить их по настоящему качественно, потому они сами вынуждены писать на джаваскрипте. Это рекурсия и порочный круг.
То чувство когда участвовал в проекте в 2004 году во времена когда для JS не было ни одной IDE и даже тулинга не существовало, когда IE еще был на коне а отладка посредством alert-ов не считалась зашкваром (FireBug прототип всех Dev Console-ей появится только в 2006) на JS делался большой проект (1млн+ строк кода) для серьезных дядей в органах власти. JS был и на фронте и на бэке (JS скрипты можно было писать через специальный плагин для apache они имели доступ к БД и файловой системе). Цена ошибки в этом проекте была высока особенно в расчетах и отчетах. К слову проект этот работает до сих пор. Читая то что пишите Вы сейчас в 2025 когда чего только нет для JS и его экосистемы я чуть не подавился попкорном.
TypeScript не помог
Typescript помог с проблемой для решения которой он был создан, вероятно Вы просто не в курсе что это за проблема.
Если вы не писали на Go, советую попробовать, вы удивитесь, насколько жизнь может быть приятнее (как бонус еще и конская производительность)
Если не писали на Assembler-е советую попробовать, вы удивитесь насколько жизнь может быть приятнее (как бонус еще и конская производительность) а еще и полная свобода доступа к железу.
JS это плохой язык и тулинг эту проблему не решает, видимо, потому что это просто невозможно в принципе
JS до сих пор один из самых популярных и простых в освоении языков, а насчет тулинга то как по мне то это пузырь который искуственно раздут, многие вещи для которых надо вкатывать целые комбайны с кучей шагов для выполнения затаскиваются в проекты просто потому что так модно и все везде что-то там используют. Например буквально в каждый проект надо затащить webpack (в новые vite тащат), почему? Найдутся миллион причин чтобы это сделать хотя уже давно ESM во всех браузерах поддерживаются, и да webpack это инструмент в первую очередь для бандлинга ресурсов а не швейцарский нож для всего на свете, и если вопрос с бандлингом сейчас в 2025 уже решен то и инструмент не нужен. Но нет, у нас же миллион причин чтобы точно что-то делать на билде увеличивая его время до минут, иногда и десятков минут.
Если нет реализации чего-то на каком то языке что мешает подключить dll/so/dylib и пользоваться. Это касается и MQTT и OpenCV, вот Вам хороший кроссплатформенный HTML Render https://sciter.com бесплатный для использования с подключением библиотеки, в проект можно легко затащить через OpenGL контекст.
JetBrains делает эксперименты и по сути все их IDE являются прощупыванием почвы, сейчас сделать IDE на Delphi невозможно просто потому что компилятор закрыт и сильно пришит к Delphi, но если бы он был открыт и свободно доступен то эксперименты бы были стопроцентов.
Для потерявшего былую популярность Delphi он этого делать не станет.
У них до сих пор существует IDE для рельсов которые уже давно не популярны.
Открытие компилятора позволила бы другим компания создать инструменты совместимые с Delphi. Free Pascal собирается под огроменный зоопарк всего включая JVM и даже JS с оговорками. Тот же Free Pascal смог бы сделать на 100% совместимый с Delphi режим совместимости. Условный JetBrains мог бы сделать IDE для этого компилятора и т.п.
Delphi и его диалект в FPC - прекрасные языки, причем достаточно современные. Все эти годы он не топтался на месте: добавили языковые фишки вроде неймспейсинга, дженериков, анонимных функций, допилили компилятор и сделали бэкэнд на LLVM для кроссплатформенности, сделали поддержку самых разных платформ. Даже пробовали интегрировать с .NET!
С этим никто не спорит, но лично я считаю правильным ходом было бы отдать компилятор Delphi в Open Source и тогда очень быстро и IDE для всех осей появятся и много чего еще. Но что-то мне подсказывает что такое не произойдет.
Но современным новичкам изо всех щелей пихают убогий петухон и жабоскрипт (он норм) и из за огромного числа либ для выполнения почти любых задач, люди иногда перестают думать сами и собирают программы из всего готового
Ну про Delphi в свое время говорили также, что в нем не надо сильно знать программирование а просто подключать контролы и писать биндинги. Стандартный курс обучения включал только основы языка а все остальное время обучающиеся учились как пользоваться IDE.
Заголовок не соответствует содержимому статьи потому что причем тут зумеры? А по сабжу описание выглядит каким-то слишком уж оторванным от жизни. Только на одной моей работе был человек комиты которого были как днем так и в 3 часа ночи но это был его личный выбор. Сам же я на первой же работе обжегся когда перерабатывал чтобы "не подводить кого-то там" и ездил в командировки за свой счет и много еще каких шишек набил. Остаться на час максимум можно если прям очень сильно горит прод и то обычно просто надо подставить костылек или откатить прошлую версию а уже на следующий день со свежей головой разобраться что там была за шляпа.
C# может и сделан по лекалам Java, только вот WinForms, на половину, до сих пор состоит из тех же классов с теми же именами, что и VCL в Delphi.
WinForms это древняя технология существующая до сих пор только потому что есть легаси написанное на ней. И вообще ничего удивительного в копировании хороших вещей от конкурента нет, этим все занимаются.
Ну и если посмотреть на современные возможности Delphi и экосистемы, то мы имеем штатный кроссплатформенный фреймворк FMX (под все платформы), сторонний (от нашего разработчика) нативный фреймворк для Android/iOS - FGX, кучу веб-фреймворков, включая бэкенд фреймворки и фронтенд фреймворки (MARS, Horse, DMVC, UniGUI, TMS Web Core, mORMot, RAD Server и т.д.).
Всё это позволяет покрыть почти все что нужно
Еще раз я не говорю инструмент что-то не умеет и он плох в том что он делает. Проблема лежит не в технической плоскости, а в том что у него маленькое сообщество (по сравнению с мейнстримными языками) а также маленькая известность. Одно это дает очень много недостатков инструменту (банально попробуйте настроить github actions для проекта delphi) уменьшает фонд новичков (потому что на курсах учат модно-молодежные технологии). Все эти процессы не происходят одномоментно, все это растягивается на годы, но факт в том что Delphi как инструмент сейчас не особо популярен и то что он может или нет этого не изменит.
Как по мне в свое время надо было отдавать в Open Source компилятор языка и IDE это дало бы сильнейший буст популярности а также дало "лишние руки" на поддержку все этого добра, но это надо было делать до того как появился Free Pascal и Lazarus, сейчас уже поезд ушел.
А МС, купивший акции Борланда тут не при чем. И совсем не участвовал в установке курса инструмента.
C#, руками главного архитектора, взяли что можно из Delphi и вели его напрямую в провал имея право голоса купленными акциями.
А Borland только простите Delphi имел в портфолио? Вообще то у него в портфолио была целая россыпь языков. И эта история о которой Вы говорите очень туманна и голословно утверждать что вот прям чтобы Delphi убить это было сделано.
.NET конкурировал с Java и был сделан по лекалам Java и Delphi тут совсем ни при чем. Конкурентом Delphi был Visual Basic потому что эти два продукта были очень сильно похожи по функционалу (и существовали в одно время) и возможностям и нацелены на один и тот же сегмент рынка. Выводы в статье крайне спорные. Delphi как продукт как существовал в своей нише так и существует, уменьшение популярности связано с тем что в начале нулевых произошел сильный сдвиг на Web платформу всего что только можно и Delphi как инструмент нацеленный на desktop разработку стал мало кому нужен, потому что и desktop разработка стала мало кому нужна. Попытка в мобилки была обречена на провал потому что там властвуют не сдвигаемые технологии, на андроиде Java которая вряд ли куда-то денется а там и Kotlin-ы подтянулись а на iOS даже не стоит пытаться тамошняя публика умеет только в инструменты самого эпла и боготворит их. Кроссплатформа для мобил тоже обречена на провал, потому что там высочайшая конкуренция. Что с серверами и веб? Там тоже уже давно много мастодонтов которых тяжко сдвинуть. Также тут есть доля злой шутки, язык Pascal и его производные в сообществе считались (и до сих пор много кем считаются) "игрушечным" не серьезным языком, это примерно как с PHP до сих пор много людей считают что он плох просто потому что кто-то где-то его поливал гомном. Delphi программисты считались теми кто "программирует мышкой", т.е. сам по себе инструмент не воспринимался серьезно. И я это не выдумал я сам начинал как Delphi программист и первые деньги заработал именно разрабатывая на Delphi. Итого проблема не в инструменте как таковом (а он хорош) а в том что компания инструмент делавшая (все компании) не подстроились под рынок во время и упустили огромные сегменты куда могли зайти первыми и стать мейнстримом.
Отнюдь, для хорошего GUI на Qt придется приложить гораздо больше сил, чем в Delphi (RAD Studio)
И конечно же бенчмарки Вы сможете сходу приложить?
При этом всё так же на выходе один исполнительный файл без лишних зависимостей.
Вы можете убрать лишние зависимости и в Qt не поверите, и даже можно слинковать статически в один файл. Вот только теперь внимание вопрос, а что это дает? Клиенту абсолютно фиолетово один у Вас файл или нет. А linux-ах дак вообще это даже хорошо потому что клиент легко может затащить qt-овые зависимости сам и шарить их между приложениями и не только.
И это в идущих друг за другом абзацах. Тут наверно надо определиться с временным периодом.
Зачем Вы мне это пишите уже сколько раз? Я Вам уже написал что сравнивать это бессмысленно. По Вашей логике корректное сравнение будет сборка спичек в коробок и сборка камешков на песке в пирамидку это же тоже сборка и сути не меняет, значит ее можно сравнить с сборкой Go в машинные коды и Ts в JS и чего угодно правильно? Я уже написал Вам что в браузере (а я пишу только о нем) иной метод распространения кода. Было бы корректное сравнение если бы Вы писали на Go++ с каким-то там новым крутым синтаксисом который бы транспилировался в Go а потом компилировался в машинные коды на каждом клиенте. Мой аргумент что TypeScript не поддерживается браузером, Ваш аргумент ну есть же трансляция это же ведь сборка а раз это сборка то значит это также как и везде, вот только зачем Вы сравниваете с чем-то другим? Если вспомнить о том что TS не первый кто пытался (до него были CoffeScript и Dart и где они сейчас?) а также то что TS разрабатывается компанией которая очень любить уничтожать свои же технологии в один день.
Для того чтобы его запустить надо поставить node, затем затащить зависимости через npm. Или просто писать код сразу в блокноте и он сразу заработает после сохранения файла и это работает везде. Вот допустим Вы "собрали" свой TS файлик который содержит 5 строк кода и задеплоили на сайт, пользователь открывает сайт а у него падает в этом файле на 12 строке кода, Ваши действия? Vite решит эту проблему?
Не везде и не для всего это проблема актуальна, до появления TypeScript-а писался код и все было нормально.
Я у Вас что-то спрашивал про полифилы? Нет не спрашивал
"JS в плане поддержки" вот так надо написать.
Это потому что этим ребятам пришлось создавать все с нуля силами волонтеров. Если бы был открыт компилятор Delphi то они справились намного быстрее и была бы 100% совместимость с Delphi в компилируемых единицах.
Вот только в случае TS нет никакой "сборки", они просто генерит такой же код с некоторыми изменениями чтобы работало в JS потому что браузер не понимает TS. Вы сравниваете разные вещи. Цель создания TS это просто попытка решения проблемы слабой типизации языка JavaScript вызывающей падения в рантайме чтобы можно было отловить их на компайл тайм. Именно эту проблему решает TS засчёт обязательного требования по указанию всех типов параметров и созданию интерфейсов, все остальное это некоторое количество сахарка. Но JS все еще остается динамическим языком со слабой типизацией и в отличии от Go/C# и прочих языков которые компилируют в бинарный код, код на JS так и остается кодом на JS в котором можно вытворять все что угодно в рантайме. Преимущества типизации ts имеют смысл когда Вы пишите код для backend-а. На фронте я хз что Вы делаете что Вам так сильно нужна типизация.
Проблема заключается в обмазыванием тонной тулинга просто для того чтобы сделать такой же код который просто можно написать и он просто будет сразу работать. Если транспилировать TS с последним стандартом то различий в результирующем файле будет не так и много помимо сахарка самого ts. А давайте еще тонну транспиляторов напишем которые кучу сахарка и приемов добавят? Вот только смысл во всем этом если на выходе все равно будет старый добрый JavaScript и возможности всех эти языков будут ограничены возможностями JavaScript. Как по мне жду когда в WASM-е добавиться доступ к WebAPI и DOM вот тогда фронтовый код вполне можно будет писать на языках не требующих что-то исправлять транспиляторами, неисключено что js может сильно подвинуться каким-нибудь rust-ом или go.
Нет это Вы предъявите мне причины почему я должен использовать TypeScript, потому что это Вы утверждаете что я должен на нем писать. Я не утверждал что надо на чем-то писать и если я пишу на чем-то еще то "являюсь извращенцем".
Как это относиться к сабжу про TS?
Вероятно потому что TypeScript это не целый новый язык а просто надстройка добавляющая статическую типизацию (ну по крайней мере делающая вид) и еще пару фишек а также продвинутый тайчекер основанный на этой информации.
Можно но как это относиться к тому что все должны немедленно начать писать на TypeScript? Ну я могу сказать что на C# можно в том числе и фронт писать для веба (через Blazor) также с шагом компиляции, к слову таких инструментов для разных языков куча которые транспилируют в JavaScript, но является ли это аргументом для того чтобы утверждать что надо писать только на TypeScript?
Это тут вообще причем?
Приложения написанные на Go компилируются в бинарный код на машине разработчика и распространяются дальше в нем не требуя компиляции и линковки на клиентских машинах. JavaScript распространяется в исходных текстов и требует компиляции/интерпретации на каждой клиентской машине браузером. И если браузер не понимает TypeScript (и не факт что станет в будущем) то Ваша аналогия выстрелила мимо. До тех пор пока TypeScript не появиться в браузере говорить о том что только в нем надо писать весь код а все кто не согласен извращенцы крайне спорно. Особенно учитывая что 95% кода написанных на TypeScript это JavaScript.
TypeScript уже доступен нативно в браузере? Когда станет тогда имеет смысл высказывать подобное мнение.
Не работал с node уже много лет, я использовал плагин для Chrome позволяющий отображать информацию из node в DevConsole. Вроде бы еще был вариант для прода позволяющий запустить node с какими-то ключами и она начинала выдавать лог который также впоследствии можно было прочесть плагином. Как все это работало и назвалось так сходу не подскажу.
Выбор может пасть если в команде есть только Web разработчики и руководство пытается сэкономить в остальных случаях вполне нормально начать делать на других языках/технологиях. А мириться или нет это уже Вам решать.
В случае React-а популярный не значит хороший и правильно сделанный поэтому ну такой себе показатель.
Ну тогда любой язык существующий больше 5 лет тоже автоматически плохой, потому что любой уважающий себя язык развивается, какие-то вещи в нем признаются устаревшими но не удаляются из-за обратной совместимости чтобы дать людям время на адоптацию. Веб также удаляет технологии, Flash с Silverlight-ом не дадут соврать.
То чувство когда участвовал в проекте в 2004 году во времена когда для JS не было ни одной IDE и даже тулинга не существовало, когда IE еще был на коне а отладка посредством alert-ов не считалась зашкваром (FireBug прототип всех Dev Console-ей появится только в 2006) на JS делался большой проект (1млн+ строк кода) для серьезных дядей в органах власти. JS был и на фронте и на бэке (JS скрипты можно было писать через специальный плагин для apache они имели доступ к БД и файловой системе). Цена ошибки в этом проекте была высока особенно в расчетах и отчетах. К слову проект этот работает до сих пор. Читая то что пишите Вы сейчас в 2025 когда чего только нет для JS и его экосистемы я чуть не подавился попкорном.
Typescript помог с проблемой для решения которой он был создан, вероятно Вы просто не в курсе что это за проблема.
Если не писали на Assembler-е советую попробовать, вы удивитесь насколько жизнь может быть приятнее (как бонус еще и конская производительность) а еще и полная свобода доступа к железу.
JS до сих пор один из самых популярных и простых в освоении языков, а насчет тулинга то как по мне то это пузырь который искуственно раздут, многие вещи для которых надо вкатывать целые комбайны с кучей шагов для выполнения затаскиваются в проекты просто потому что так модно и все везде что-то там используют. Например буквально в каждый проект надо затащить webpack (в новые vite тащат), почему? Найдутся миллион причин чтобы это сделать хотя уже давно ESM во всех браузерах поддерживаются, и да webpack это инструмент в первую очередь для бандлинга ресурсов а не швейцарский нож для всего на свете, и если вопрос с бандлингом сейчас в 2025 уже решен то и инструмент не нужен. Но нет, у нас же миллион причин чтобы точно что-то делать на билде увеличивая его время до минут, иногда и десятков минут.
Если нет реализации чего-то на каком то языке что мешает подключить dll/so/dylib и пользоваться. Это касается и MQTT и OpenCV, вот Вам хороший кроссплатформенный HTML Render https://sciter.com бесплатный для использования с подключением библиотеки, в проект можно легко затащить через OpenGL контекст.
JetBrains делает эксперименты и по сути все их IDE являются прощупыванием почвы, сейчас сделать IDE на Delphi невозможно просто потому что компилятор закрыт и сильно пришит к Delphi, но если бы он был открыт и свободно доступен то эксперименты бы были стопроцентов.
У них до сих пор существует IDE для рельсов которые уже давно не популярны.
Открытие компилятора позволила бы другим компания создать инструменты совместимые с Delphi. Free Pascal собирается под огроменный зоопарк всего включая JVM и даже JS с оговорками. Тот же Free Pascal смог бы сделать на 100% совместимый с Delphi режим совместимости. Условный JetBrains мог бы сделать IDE для этого компилятора и т.п.
С этим никто не спорит, но лично я считаю правильным ходом было бы отдать компилятор Delphi в Open Source и тогда очень быстро и IDE для всех осей появятся и много чего еще. Но что-то мне подсказывает что такое не произойдет.
Ну про Delphi в свое время говорили также, что в нем не надо сильно знать программирование а просто подключать контролы и писать биндинги. Стандартный курс обучения включал только основы языка а все остальное время обучающиеся учились как пользоваться IDE.
Заголовок не соответствует содержимому статьи потому что причем тут зумеры? А по сабжу описание выглядит каким-то слишком уж оторванным от жизни. Только на одной моей работе был человек комиты которого были как днем так и в 3 часа ночи но это был его личный выбор. Сам же я на первой же работе обжегся когда перерабатывал чтобы "не подводить кого-то там" и ездил в командировки за свой счет и много еще каких шишек набил. Остаться на час максимум можно если прям очень сильно горит прод и то обычно просто надо подставить костылек или откатить прошлую версию а уже на следующий день со свежей головой разобраться что там была за шляпа.
"Джентльменам принято верить на слово" (с)
Пример будет?
Если Вам и сравнивать нечем то зачем Вы утверждаете о то что к чему-то надо прилагать больше сил чем другому?
WinForms это древняя технология существующая до сих пор только потому что есть легаси написанное на ней. И вообще ничего удивительного в копировании хороших вещей от конкурента нет, этим все занимаются.
Еще раз я не говорю инструмент что-то не умеет и он плох в том что он делает. Проблема лежит не в технической плоскости, а в том что у него маленькое сообщество (по сравнению с мейнстримными языками) а также маленькая известность. Одно это дает очень много недостатков инструменту (банально попробуйте настроить github actions для проекта delphi) уменьшает фонд новичков (потому что на курсах учат модно-молодежные технологии). Все эти процессы не происходят одномоментно, все это растягивается на годы, но факт в том что Delphi как инструмент сейчас не особо популярен и то что он может или нет этого не изменит.
Как по мне в свое время надо было отдавать в Open Source компилятор языка и IDE это дало бы сильнейший буст популярности а также дало "лишние руки" на поддержку все этого добра, но это надо было делать до того как появился Free Pascal и Lazarus, сейчас уже поезд ушел.
А Borland только простите Delphi имел в портфолио? Вообще то у него в портфолио была целая россыпь языков. И эта история о которой Вы говорите очень туманна и голословно утверждать что вот прям чтобы Delphi убить это было сделано.
.NET конкурировал с Java и был сделан по лекалам Java и Delphi тут совсем ни при чем. Конкурентом Delphi был Visual Basic потому что эти два продукта были очень сильно похожи по функционалу (и существовали в одно время) и возможностям и нацелены на один и тот же сегмент рынка. Выводы в статье крайне спорные. Delphi как продукт как существовал в своей нише так и существует, уменьшение популярности связано с тем что в начале нулевых произошел сильный сдвиг на Web платформу всего что только можно и Delphi как инструмент нацеленный на desktop разработку стал мало кому нужен, потому что и desktop разработка стала мало кому нужна. Попытка в мобилки была обречена на провал потому что там властвуют не сдвигаемые технологии, на андроиде Java которая вряд ли куда-то денется а там и Kotlin-ы подтянулись а на iOS даже не стоит пытаться тамошняя публика умеет только в инструменты самого эпла и боготворит их. Кроссплатформа для мобил тоже обречена на провал, потому что там высочайшая конкуренция. Что с серверами и веб? Там тоже уже давно много мастодонтов которых тяжко сдвинуть. Также тут есть доля злой шутки, язык Pascal и его производные в сообществе считались (и до сих пор много кем считаются) "игрушечным" не серьезным языком, это примерно как с PHP до сих пор много людей считают что он плох просто потому что кто-то где-то его поливал гомном. Delphi программисты считались теми кто "программирует мышкой", т.е. сам по себе инструмент не воспринимался серьезно. И я это не выдумал я сам начинал как Delphi программист и первые деньги заработал именно разрабатывая на Delphi. Итого проблема не в инструменте как таковом (а он хорош) а в том что компания инструмент делавшая (все компании) не подстроились под рынок во время и упустили огромные сегменты куда могли зайти первыми и стать мейнстримом.
И конечно же бенчмарки Вы сможете сходу приложить?
Вы можете убрать лишние зависимости и в Qt не поверите, и даже можно слинковать статически в один файл. Вот только теперь внимание вопрос, а что это дает? Клиенту абсолютно фиолетово один у Вас файл или нет. А linux-ах дак вообще это даже хорошо потому что клиент легко может затащить qt-овые зависимости сам и шарить их между приложениями и не только.