А на машине разработчика нельзя скомпилировать 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-овые зависимости сам и шарить их между приложениями и не только.
Webpack в свое время стал популярен потому что был проще в конфигурации чем его более возрастные конкуренты на тот момент. Vite сейчас молодой и пока не обросший сложностью инструмент, будем надеяться что его не постигнет судьба webpack-а через время.
Информацию вы вольны искать любым доступным способом, можете сами найти, может вам что-то передаст заказчик или предаставит специалистов, которые поделятся сакральными знаниями.
Вопрос был как лично Вы и Ваша команда это делаете.
Бухгалтерские отчеты - это типовая задача, для этого даже полуфабрикаты в виде 1С есть, а то и готовые конфигурации
Расскажите как происходит "полное погружение" в предметную область, мне серьезно интересно. Вот допустим сегодня Вы начинаете новый проект знания о предметной области которого у Вас равны нулю. Какие нужны действия команды для погружения? Допустим Ваш новый проект связан с бухгалтерией, Ваши знания ограничиваются что бухгалтерия это что-то связанное с расчетом денег (ну допустим). Допустим заказчик присылает Вам 200 отчетов которые должны генериться Вашим проектом с минимальными объяснениями на бухгалтерском языке, все отчеты разные и нужны для разного. Какие Ваши и команды действия по погружению в предметную область и сколько времени это может занять? Как будет распределение погружения между командой, и если да то как потом погруженные сведения будут передаваться между командой? И в целом как выглядит процесс?
Можно но как это относиться к тому что все должны немедленно начать писать на 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-овые зависимости сам и шарить их между приложениями и не только.
Webpack в свое время стал популярен потому что был проще в конфигурации чем его более возрастные конкуренты на тот момент. Vite сейчас молодой и пока не обросший сложностью инструмент, будем надеяться что его не постигнет судьба webpack-а через время.
Вопрос был как лично Вы и Ваша команда это делаете.
А что тогда не типовая задача?
Расскажите как происходит "полное погружение" в предметную область, мне серьезно интересно. Вот допустим сегодня Вы начинаете новый проект знания о предметной области которого у Вас равны нулю. Какие нужны действия команды для погружения? Допустим Ваш новый проект связан с бухгалтерией, Ваши знания ограничиваются что бухгалтерия это что-то связанное с расчетом денег (ну допустим). Допустим заказчик присылает Вам 200 отчетов которые должны генериться Вашим проектом с минимальными объяснениями на бухгалтерском языке, все отчеты разные и нужны для разного. Какие Ваши и команды действия по погружению в предметную область и сколько времени это может занять? Как будет распределение погружения между командой, и если да то как потом погруженные сведения будут передаваться между командой? И в целом как выглядит процесс?
Тоже неплохой вариант