Комментарии 60
Если вы не писали на Go, советую попробовать, вы удивитесь как часто надо if err != nil
в своем языке я как раз эту проблему решил, взяв из раста ? оператор :)
го не идеален, но это (имхо, конечно же) лучшее, что есть (для веб-бэкенда, в большинстве случаев)
иронично, но я вижу в го часть проблем js, которые делают его плохом языком - нет планов на будущее. "у нас же язык для глупых стажёров гугл, которые должны уметь делать простые вещи быстро. нам дженерики не нужны, давайте копипастить функции. ой, дженерики всё-таки нужны, давайте думать как их нормально вкорячить"
Имхо, хоть го и простой, но в нем достаточно подводных камней и вряд ли можно назвать его языком для стажеров. И нормальных альтернатив ему нет.
Питон, пхп медленные и без нормальной статической типизации, нужно придумывать костыли, хотя экосистемы хороши, но для бэкенда в том же python вы берете либо негибкий django, либо голый fastapi;
жс сам по себе кривой и тс его не особо спасает, хоть и делает жизнь чуть лучше, экосистема хороша, но в зависимостях часто начинается мракобесие, а node_modules раздувается страшно;
джава тяжелая переусложненная жаба;
шарп потихоньку отмирает, над его экосистемой вообще плакать хочется, тот же automapper недавно решил стать коммерческим, и многое держится чисто на поддержке самих Microsoft, плюс раздувается легко, стартует медленно;
Rust хорош, но нужно прикладывать усилия, чтоб писать хороший читаемый поддерживаемый код.
И в каждом из этих языков можно легко повыкапывать еще проблем, из-за которых смотришь больше в сторону го.
(Какие еще языки можно сюда вставить? Интересна еще ситуция с Kotlin, но это все тот же jvm)
Ну а то, что разработчики го так криво что-то реализуют на примере дженериков, это уже другой вопрос, но лично я не вижу ему альтернатив на данный момент для веб-бэкенда, хотя проблем в нем безусловно достаточно и тащить его в какие-то другие сферы, кроме разве что cli, devops и тулинга, не стоит
"потихоньку отмирающий шарп" вызвал улыбку =)
Ниже количество новых репозиториев, создаваемых каждый год для указанного языка.
Стоит только учитывать, как у шарпа с приростом аудитории и крупных проектов, где он используется. Рынок десктопа возглавили электрон и qt, тулинг те же go, раст, python, веб go, node, ml у нас python, мобилки js, flutter, native. А как еще с приростом вакансий у шарпа? Естественно уже написанные крупные проекты перегонять с шарпа не будет и в свое время он отхватил свой кусок, но что в остальном сейчас с ситуацией по миру? Да те же базовые индексы популярности откроем, где видно падение процентов. Я не говорю, что все плохо и он мертв, но видна тенденция даже для самих шарп разработчиков, что я встречал, тот же Андрей Парамонов из Dodo
в tiobe c# на 2 позиции выше go стоит.
Электрон возглавил рынок десктопа? Очень смелое утверждение. В энтерпрайзе C# даже на линукс десктопах уже.
Про тулинг неверно - вы видимо не владеете вообще актуальной информацией. C# даже в linux в systemd сервисах применяется. Cli утилит тоже полно и довольно серьезных утилит.
Из своего опыта: на .net 8 написан мощный etl инструмент, который на go не напишешь без костылей. Имеет ui/cli интерфейсы для windows/linux.
В организации, в которой я работаю, новые проекты пишутся и на .net. И вполне успешно работают.
-2.37%, не очень уверенно стоит
Утверждаю из того, что вижу, и того как активно он применяется в том числе для крупных open source решений даже у microsoft. Понятно, что не убил всех остальных, но смело выбился в топ.
Подозреваю, что ситуация характерна для компаний уже активно использующих .net в своем инструментарии.
right tool for the job
Также весьма подозреваю, что он не вклинился, а уже был частью компании, что весьма характерно для .net
Неправильно подозреваете. В компании практически все современные технологии присутствуют в разной мере.
Лидеры в энтерпрайз java и c#. И в ближайшее время это не изменится.
Я про то, что он явно вошел в компанию во время бурного роста платформы .net, когда и альтернатив -то особо не было, и так просто его, конечно же, никто не выкинет, есть специалисты, есть задачи, есть опыт
Как я и говорил, отхватили свой кусок и никто не будет тратить миллиарды, чтобы их выкидывать, будет глупо, если уже есть специалисты и сами языки никто не забрасывал.
Стековерфлоу - на .net
Игровой движок Unity - использует c# почти везде, где не надо работать с железом и не знаю, как сейчас, но раньше они говорили о планах вообще всю кодовую базу на c# перевести.
Unreal Engine - опять же много где использует c# (включая скрипты сборки, всякую там кодогенерацию и так далее)
Больше того, и в десктопе он активно теснит тот же Qt. Если вы возьмёте какой нибудь новый профессиональный инструмент, то скорее всего сейчас там будет не Qt, а Avalonia UI. Просто хотя бы потому, что порог входа ниже, а производительность местами даже лучше (см. тесты производительности c# Dictionary и его c++ из std).
Когда то давно, c# может и умирал (ибо был прибит толстыми гвоздями к Windows, Azure и так далее), но сейчас это средство кросплатформенной разработки, которое просто решает задачу, причем простые задачи решаются прямо из коробки, а тот же Hello World пишется именно что в одну строчку. Сейчас на нем можно писать под десктоп (Avalonia UI), веб (blazor, asp net core), мобилки (тут вообще куча технологий на любой вкус и цвет) и даже под ML есть (правда похоже, что оно нафиг не кому не нужно)
За основу чисто статику отдает, не сказать, что самый яркий пример, есть еще из интереса?
Тут сложно не согласиться, по сути одно из основных применений c#.
По сути в местах, где собирается под виндовс? Потому что за основу это чистый c++. И если вы хотите реально нормально делать что-то на unreal, нужно брать opensouce код и многое выкорчевывать, чтобы нормально его оптимизировать.
В целом логичное утверждение, потому что проф софт делается с приоритетом под винду и может дойти до Линукса. На маке за основу либо проф софта нет, либо он урезан. Если делают приоритетно кросс-платформенное что-то, вряд ли берут c#, а если и берут, подозреваю, что это компании, в инструментарии которых давно теплится .net.
Его основные инструменты asp net, avalonia, unity. В части мобильных приложений у него вообще кладбище фреймворков заброшенных и редко пишется что-то на них, а ml звучит очень сомнительно.
Я не утверждаю, что он мертв, мне самому понравилось состояние .net и как над ним стараются, огорчило только состояние экосистемы(той части, которой не занимается Microsoft). Но я посматривал на тот же tiobe, на то, какие бигтехи внедряют его вообще(кроме тех, у кого он давно и у кого есть опыт использования) для бэкенда, слушал мнение ребят из Додо, у которых вся инфра на .net актуальном. И виден очень медленный, но спад.
Могу ошибаться, я не всезнающ, но такая сложилась для меня картина
Rust хорош, но нужно прикладывать усилия, чтоб писать хороший читаемый поддерживаемый код.
Это в любом языке. Да, раст посложнее в освоении, но для написания компиляторов или фреймворков. Для перекладывания жсонов он простой. Плюс, уже придумали LLM для подсказок и фикса простых ошибок
Так что да, раст - вполне себе альтернатива. Жаль, что многие считают его только заменой С
Просто для меня брать раст для перекладывания жсонов как брать пушку для стрельбы по воробьям, можно, но зачем
right tool for the job
его явно в бэкенд не для этого завозят(исключим orjson в python)
Странное заявление. Брать более эргономичный и безопасный язык для простых задач неправильно, потому что он тоже хорош и в других задачах?
его явно в бэкенд не для этого завозят
Ну можно других слушать и делать как кто-то говорит. Я вот пишу для себя маленькие боты и сервисы и кайфую. Очень быстро, куча ошибок отлавливается на этапе компиляции, приятный тулинг. Минусов не нашел пока
Для себя пишите, на чем нравится, но за основу речь идет про бизнес, никто не будет задорого нанимать и обучать редких раст разработчиков крудописателями и перекладывателями жсонов, будут брать го, python, php, node, каким бы раст эргономичным ни был, потому что на них и делается это быстрее, и найти и перевести разработчиков на них проще, и концепций надо понимать меньше.
Rust очень хорош, я не спорю, но right tool for the job
Я так понял Rust единственный адекватный язык из все вами перечилсенных)
Для сложного бекенда go - это боль.
Все что потом будет развиваться и обрастать фичами будет тяжело масштабировать на go.
По производительности он выигрывает разве что по балансу холодный старт-производительность.
А по rps go даже asp net проигрывает.
Я golang языка не сторонник, но откуда у вас информация?
Источник какой именно информации интересует?
какие именно встретили проблемы при масштабировании, ибо микросервисы на го и даже модульный монолит легко масштабируются при правильной архитектуре
про производительность не интересно, явно взяли hello world примеры и даже не посмотрели на нормальные приложения, состояние экосистемы, тулинг для профилирования и то, сколько выжирают сервисы того же asp.net и как они раздуваются
Начну отвечать с конца.
Asp .net core больше требует ресурсов, но она и большее количество запросов может обрабатывать. Go меньше требует ресурсов, но по rps проигрывает. Даже накрученный fast http проигрывает asp .net core aot с их накрученными фишками для стендового тестирования.
Что значит правильная архитектура? Естественно, что речь идёт не о говнокоде. Говнокод можно на любом языке написать и будут проблемы с масштабированием. Речь о том, что на go всё вручную приходится писать. Даже стандартные и очевидные вещи иногда. А отсутствие дженериков для методов (не функций) портит чистоту кода, приходится всякие неочевидные вещи применять типа композиций функций.
Если брать cli утилиты, то жирные cli утилиты тоже уже плохо масштабируются т.к. нет нормальной кодогенерации, кроме go generate, дженерики портят ситуацию, приходится в некоторые случаях просто копировать много одинакового кода потому что либо дженерики в методах и все зависимости передавать в них в качестве аргументов, либо хитрые композиции, которые уже не выглядят так просто, как идиоматичный go way.
На примере того же .net: отличные дженерики, удобный di, roslyn инкрементальные генераторы, всякие linq и деревья выражений, что например позволяет не указывать все столбцы явно в .Scan на go.
Это вкратце.
По производительности он выигрывает разве что по балансу холодный старт-производительность.
А по rps go даже asp net проигрывает.
https://aws.amazon.com/blogs/compute/introducing-the-net-8-runtime-for-aws-lambda/
https://devblogs.microsoft.com/dotnet/announcing-dotnet-8/
Ощущение, что статью писал бэкенд разработчик после того как стал фулстеком))
На JS не все так плохо как пишет автор, а джунов которые могут писать код на React и куче зависимостей сильно больше чем на том же Go)
это хороший язык в том смысле, что он, определенно, решает свою задачу (иначе он не был бы столь популярен), и это очень плохой язык в смысле того, насколько много усилий нужно приложить, чтобы решить тривиальную задачу.
npm create vite@latest
Готово. Можно начинать решать тривиальную задачу.
Если проблема в том, что нельзя это сделать без сторонних инструментов — тогда по этой логике и C/C++ плохие языки, потому что без QT (или аналогов) сложно нарисовать даже простое окно с двумя кнопками. И таких примеров масса.
К тому же, злая ирония такова, что на бэкенде, где JS еще можно как-то стерпеть, есть из чего выбрать (например, Go), а вот на фронтенде выбора нет.
Есть. Dart (Flutter), Elm, ClojureScript, C# (Blazor).
Ситуация с фронтендом настолько ужасна, что самый популярный и стабильный фреймворк React заставляет вас писать на языке jsx (tsx), который является абстракцией над JS и HTML. Альтернативы еще хуже, например, Svelte также добавляет свой html-js-подобный язык с различными магическими директивами.
В чём же ужас? JSX выглядит чище, чем композиция компонентов в Flutter, Swift UI, Jetpack Compose. Мне правда сложно сказать, что XML-like синтаксис и его использование ужаснее, чем функции (или конструкторы классов), в которые в качестве аргументов передаются результаты функций (или экземпляры классов), приправленное большим количеством обратных круглых скобочек.
В Svelte, кстати, признали ошибку, с 5 версии, ЕМНИП, синтаксис не отличается от ванильного JavaScript.
В итоге этот “динамический” язык не работает без кучки компиляторов, каждый из которых имеет свои конфиги, свою экосистему плагинов (каждый из коротых в любой момент может может сломать обратную совместимость, не обновиться вовремя, стать depracated и прочее).
В простом случае JavaScript позволяет написать приложение без использования внешних зависимостей, транспиляторов и сборщиков. Браузеры уже поддерживают ESM, веб-компоненты.
В итоге в него все добавляют и добавляют, как следствие, на нем можно писать в десяти разных стилях и одна проблема решается дюжиной разных способов. Как думаете, как это влияет на качество и удобство разработки? Правильно, влияет очень плохо. Два проекта даже на React могут выглядеть совершенно по разному, не говоря уже о проектах с разными фреймворками.
А в других экосистемах иначе? iOS (Swift), Android (Java/Kotlin), Flutter (Dart). Внутри даже одной компании встречаются проекты, использующие разные архитектурные подходы, файловую структуру, да ещё к тому же разные подходы: Vanilla vs Storyboard vs Swift UI, Vanilla vs Jetpack Compose.
Они даже синтаксически (из-за бесконечного юзания различных настроек и сахаров) легко могут отличаться.
С тех пор как stage-0, stage-1 фичи перестали тащить в проекты, прошло много лет. В большинстве современных JS/TS-кодовых баз синтаксис вполне стандартный, без неожиданных сюрпризов.
Далее, TypeScript не дает никаких гарантий. Вообще. Как же так? Компонент в систему добавили, +1 язык выучили, а undefined все еще is not a function? Причина в том, что TS был разработан для gradual adoption, то есть плавной интеграции с JS. Разработчики предположили (и правильно предположили), что просто взять и переписать весь джаваскрипт в мире на TS не получится, и любой TS-код будет взаимодействовать с небезопасным JSом. Как следствие, очень и очень часто в своем TypeScript проекте вы будете видеть тип any который как бы говорит “хз что это, делай с этим что хочешь но на свой страх и риск”.
Предположим. Как это применимо к написанным с 0 проектам на TypeScript? У нас даже джуны знают, что почему нельзя использовать any (или когда можно).
Классная типизация, да?
Да, у TypeScript действительно классная типизация, которая обеспечивает null-safety в отличие от упоминаемого Golang. Не говоря уже о том, что TypeScript легко позволяет перечислить все инварианты и на этапе проверки типов узнать, что где-то контракты не сошлись. Сопоставимые гарантии может дать только Rust, разве что.
JS это плохой язык и тулинг эту проблему не решает, видимо, потому что это просто невозможно в принципе
Как мы видим на практике, как раз решает — и довольно эффективно.
Если вы не писали на Go, советую попробовать, вы удивитесь, насколько жизнь может быть приятнее (как бонус еще и конская производительность)
Отсутствие null-safety, отсутствие потокобезопасности на этапе компиляции, кастрированные дженерики мы опустим. Golang замечательный язык, однако тоже с компромиссами и неверными архитектурными решениями, с которыми приходится мириться.
Наверное, один из самых грамотных и аргументированных комментариев, что я вообще видел, а не простое поливание грязью или пустое отрицание.
Думаю что всё таки сравнение с Rust слишком сильное (хотя про инварианты это чаще всего правда). Да, TypeScript улучшается каждый год, но всё же корректность типов у них не является Design Goal: https://github.com/microsoft/TypeScript/wiki/TypeScript-Design-Goals (Non-Goal #3) и на этой основе они иногда не хотят делать его слишком стогим и к этому пока что всё ещё нужно быть готовым.
Сравнение с Rust было исключительно в контексте гарантий инвариантов на уровне типов. Если указано, что тип должен иметь определённое поле с конкретным значением или состоять из подобных типов, TypeScript это позволяет выразить и строго гарантирует. На моей памяти не так много не-функциональных языков поддерживают такую выразительность — первым в голову приходит именно Rust.
Но да, вы абсолютно правы: поскольку в TypeScript система типов основана на структурной типизации (structural typing), возможно передать значение, которое является структурным подмножеством ожидаемого. Поэтому два инварианта, одинаковые структурно, с точки зрения TypeScript считаются одним и тем же типом. Аналогично, если, например, ожидается конкретный тип с фиксированными полями, а на вход приходит объект с теми же полями и “довеском” — с точки зрения TypeScript это допустимо.
К счастью, в последние годы всё чаще используются Branded Types, которые позволяют жёстко зафиксировать конкретный тип, делая систему ближе к номинативной типизации (nominal typing).
Примеры
type AccountID = UUID
type ProfileID = UUID
// true
type _ = AccountID extends ProfileID ? true : ProfileID extends AccountID ? true : false
type AccountID = Branded<UUID, 'AccountID'>
type ProfileID = Branded<UUID, 'ProfileID>'>
// false
type _ = AccountID extends ProfileID ? true : ProfileID extends AccountID ? true : false
class Rectangle {}
class Circle {}
function calculateArea(circle: Circle): number {
return 42
}
// ok, the function accepts
calculateArea(new Circle())
// Oops, the function accepts Rectangle instances as well, because Rectangle structurally equals Circle.
calculateArea(new Rectangle())
class Rectangle {}
const CircleBrand = Symbol('type')
class Circle {
private [CircleBrand] = 'circle'
}
function calculateArea(circle: Circle): number {
return 42
}
// ok, the function accepts
calculateArea(new Circle())
// ok, the function doesn't accept non-circle instances
calculateArea(new Rectangle())
Строгая типизация приводит к раздуванию объема кода, соответственно последствия это ухудшение читаемости. Какие либо нетривиальные проекты, используюшие TS, содержат просто монстровые объемы многовложенных деклараций типов.
Типизация также усложняет monkey patching, а иногда и вообще делает его невозможным. В Java monkey patching огромная проблема. В Python monkey patching чаще всего тривиален.
Не просто так создавали duck typing, были на то серьезные причины, лаконичность, скорость разработки. Хотя в то время уже давно были языки с очень строгой типизацией. Более того, самый первый язык ассемблер таковым является.
На моей памяти не так много не-функциональных языков поддерживают такую выразительность — первым в голову приходит именно Rust.
C++20 ещё.
Всё так.
JS не масштабируется
Самое ужасное, как по мне, это то, что отцы-основатели говорили: «Всё есть файл», а эти их наследнички говорят: «Всё есть сервер». Полный финиш, это когда модули запретили делать файлами (тот, кто скажет, что это повышает безопасность, пусть сначала хорошо подумает). Так получилось, что люди, которые развивают ECMAScript — это сотрудники компаний, зарабатывающих на облаках. Совпадение, наверно /s.
Недавно читал книжку, типа «Препроцессоры для профессионалов», там был раздел про то, как писать свои плагины на JS, например. Чтобы потом за пять минут долетать. В итоге я запилил свой фреймворк и даже подумывал написать статью: «Как не писать CSS руками, а высокоэффективно генерировать». Так вот, автор, тонкий тролль, пишет: «…но есть и ограничения на то, что вы можете делать в плагинах при помощи JS [напоминаю — речь идёт о коде, выполняемом во время компиляции]. Вы не можете поднять свой веб-сервер!». Когда я прочитал, то смеялся и плакал одновременно.
А потом к чуваку, написавшему тут статью про симуляцию неймспейсов, в комментарии приходят зумеры в коротких штанишках и пишут: «вылезай из подполья, немцы уже ушли, а в JS придумали модули!» (реальный случай).
Как вы могли понять из предыдущего абзаца, проблема “JS не предоставляет из коробких нужных инструментов” удесетеряется в случае, если вы пишете не для сервера, а под браузер.
Это вообще какая-то злая ирония. Язык изначально спроектирован как функциональный, но в нём до сих пор нет паттерн-матчинга из коробки! А-а-а-а-а!!! А для работы с DOM из коробки нет чейнинга! А для коллекций (это, правда, не только для браузера — скорее, для сервера, как раз) нет суб-языка запросов (как LINQ для C#).
Опять же, после этого приходят зумеры в коротких штанишках и спрашивают: «Дяденька, зачем тебе jQuery? Мы читали, он устарел!» К изначально функциональному, декларативному языку приделали какой-то невероятно уродливый императивный DOM API, и считают, что так и надо.
В общем, спасибо за статью. Я писал на этом языке много лет, и хочу писать и дальше. И у меня уже, как в том анекдоте про психа, едущего по встречке («Он не один! Их сотни!!!»), стали появляться робкие сомнения. Но, похоже, раз кто-то ещё помимо меня это понимает и пишет такие статьи, это, всё-таки, они всей шайкой едут по встречке, а не мы.
"Это не трасса, это река"- Телевизор.
Я понимаю, праздник, выходной (с праздником, кстати!), хочется потрепаться о реках, телевизорах и смысле жизни, но, честное слово, я самый неподходящий для этого собеседник. У меня, как у инженера, знатно полыхает от темы, а это на философский лад совсем не настраивает.
Хотите поговорить? Хорошо, давайте поговорим: почему crypto.randomUUID() требует HTTPS? Они правда считают, что в небезопасных контекстах не нужен безопасный гуид? Да хрен там. Они просто хотят, что я всю разработку вёл не локально, а в каком-нибудь дурацком облаке. И платил за это, конечно.
Как и в случае с модулями, меня не устроит общий ответ «для безопасности». Все самые худшие преступления в истории человечества оправдывали безопасностью. (И заботой о детях). Как и в случае с модулями, я хочу увидеть конкретный сценарий взлома, который был предотвращён. А потом спросить: как же мы до этого всю жизнь жили с локальной (не по HTTPS!) имплементацией ::CoCreateGuid() из WinAPI, и у нас жопа не отпадывала, и злые хакеры через неё не проникали.
Это форменный пи-ц (вместо "-" подставляйте что хотите в меру своей испорченности). И ладно, если бы написано было с юмором, но нет. Все написано на серьезных щщщах.
Где-то на "вэб нельзя ломать" я поржал в голос. Нет, серьезно. Одна сплошная вода и постоянное вымученная мантра: "js плохой, потому что плохой".
Тема статьи действительно дискуссионная. Да, можно привести кучу различных моментов и хорошенько их обсудить. Но вот за одну статью по десять раз переливать из пустого в порожнее такая себе история.
А вообще, если есть свой замечательный язык, то вместо липовых статей лучше организовали набор статей-руководств. И в выразительной форме показали как выглядит решения на вашем языке и на js. А статьи паразиты в принципе не нужны.
Очередная вызывающая рукалицо бомбежка от вчерашнего джуна (а может, и сегодняшнего) "я-очень-крутой-потому-что-я-написал-свой-язык-который-никому-не-нужен" с аргументацией уровня "ты дулак" и очень плоским пониманием предмета обсуждения. Искренне надеюсь, что эта статья - байт на комменты, иначе прямо печально за автора.
Всех вот этих проблем с зависямостями и компиляциями js можно избежать, если рендерить HTML на сервере с помощью языков, предназначенных для этого. А js использовать для минимальных манипуляций с DOM, например, повесить коасс open на менюшку по клику на иконку. Но нет же, надо притащить фреймворк, компилятор и ещё несколько библиотек для того, чтобы эта несчастная менюшка красиво выезжала. Вместо одной строчки CSS сейчас принято тащить 1кБ js, в итоге имеем то, что имеем.
Чтобы такие вещи заявлять, нужно вернуться в эпоху "До JS" и сравнить, а затем сравнить текущее состояние. Но, как минимум, хочется отметить, что сам принцип работы с интерфейсами поменялся в корне благодаря JS, а также появилось множество инструментов, чтобы не работать с интерфейсами по старому. В статье это выставляется как проблема, но не видно кардинально-иного решения.
Тема интересная, но скатилась в обычную рекламу.
Любому говнокодеру всегда что-то мешает.
А этот тупо запулил тут вымышленный хейт, чтобы свою телегу пропиарить. Статья ни о чём.
Скажу кратко, ваш язык, тг канал и статья никому не нужны, учите уроки и вырастайте из джуна
Спасибо, открыли глаза, теперь я понял, что js плохой язык. Теперь буду писать веб только на хороших языках(видимо на Go)
На чем только не писал за 20 лет. И каждый из этих языков хоронили и обливали грязью регулярно.
JS искренне люблю за его невероятную пластичность. Ну а кто не в состоянии удержать в руках эту летучую субстанцию - есть огромное количество альтернатив построже.
Соглашусь что как язык JS да и TS не очень хороши. Однако Deno отчасти преодолевает ряд проблем, указанных в публикации. Импорты там очень гибко настраиваются и TS работает изначально без дополнительных настроек.
Удивительно что статью заминусили, я думал уж точно все согласны с тем, что JS и фронтенд-экосистемы отвратительны.
Кажется стоит напомнить людям о том, как должны выглядеть нормальные технологии.
Более того, выбор может пасть на 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 уже решен то и инструмент не нужен. Но нет, у нас же миллион причин чтобы точно что-то делать на билде увеличивая его время до минут, иногда и десятков минут.
Подскажите, что используете для профилирования node приложений? В Go pprof очень мощный, а что в node по аналогам?
Не работал с node уже много лет, я использовал плагин для Chrome позволяющий отображать информацию из node в DevConsole. Вроде бы еще был вариант для прода позволяющий запустить node с какими-то ключами и она начинала выдавать лог который также впоследствии можно было прочесть плагином. Как все это работало и назвалось так сходу не подскажу.
Pyroscope, node-pprof
Когда мы говорим “джаваскрипт”, мы подразумеваем много разных вещей:
Когда мы говорим “джаваскрипт”, мы подразумеваем TypeScript. Никакой разработки на чистом JS, в современном мире вестись не должно. (Если вы, конечно, не извращенец).
Короче, из коробки JS годится лишь для написания очень маленьких вещей
Никакой разработки на чистом JS, в современном мире вестись не должно. (Если вы, конечно, не извращенец).
Фронтенд это боль
Я так и не увидел технологии на которой фронтенд делать проще и дешевле. Qt и GTK непредлагать.
из джаваскрипта ничего нельзя удалить
А из Go что-то удаляли?
TypeScript не помог
Еще как помог, а Bun помог еще больше.
Далее, TypeScript не дает никаких гарантий. Вообще.
https://github.com/GoogleFeud/ts-runtime-checks
Если вы не писали на Go, советую попробовать, вы удивитесь, насколько жизнь может быть приятнее (как бонус еще и конская производительность)
Если вы не писали на Nemerle, советую попробовать, вы удивитесь, насколько жизнь может быть приятнее.
Почему JS (и TS) это плохой язык