Этот пост не о том, что JS лучший из всех языков программирования, нет. Речь будет идти только о сферах, которые он охватил, и о том, сколько возможностей он дал разработчикам, чтобы улучшить свой продукт.
Уже давно в мире программирования идет борьба. С самого момента появления компьютера программисты искали идеальный язык программирования. Один за другим создавались новые языки, чтобы приспособить их к определенным целям. И с этими новыми языками появилась новая эра технологий, появилось миллион библиотек и множество информации в свободном доступе, а с этим всем неизбежно появились новые ограничения. С давних времен программирования Java Applets (приложений) можно заметить, что различные языки неожиданно появлялись и так же неожиданно исчезали, кроме того, их полезность быстро сходила на нет.
Мир движется в новом направлении…
И вот, этот когда-то прекрасный новый язык теперь стал абсолютно бесполезным, как и его разработчики, а ему на смену уже маячит другой абсолютно новый прекрасный язык программирования.
Однако, JavaScript уже практически десятилетия находится рядом и никуда не уходит. Итак, уместно будет задать такой вопрос: «В каком же направлении он движется?» Однако, этот пост не совсем о «JavaScript». Также, он не касается того множества языков, которые были до него. И здесь не говорится о том, какой JavaScript замечательный.
Этот пост про программную платформу Node.
И эти вещи действительно необходимо различать. Потому что Node — это что-то другое. Это не просто язык. Это экосистема.
И это то, о чем будет идти речь.
Хотя… не совсем. Здесь не будет описываться миллион причин, по которым эта экосистема является самым инновационным посредником в области взаимодействия с открытым исходным кодом, которую когда-либо видел мир. На данный момент я просто проиллюстрирую то, как эта платформа уже победила вековую войну за совершенный язык, пройдя несколько ключевых территорий программирования современной эпохи:
Всемирная паутина
React, Angular и Vue
React, Angular и Vue это самые важные интерфейсные системы, существующие на сегодняшний день. Совместно, Facebook, Google и сообщество FOSS разработали интеллектуально эффективные инструменты для разработки интерактивных пользовательских интерфейсов.
В результате, практически всё, что вы делаете сегодня в Интернете, обслуживается очень интерактивным, эстетически приятным и простым в использовании интерфейсом. И все это стало возможным только благодаря экосистеме Node.
Нет никаких сомнений в том, что JavaScript главенствовал над веб-разработками в течение вечности, но React, Angular и Vue переносит все это на другой уровень.
Это период пользовательского интерфейса.
Период, когда разработчики интерфейсов больше не уклоняются от создания сложных одностраничных веб-приложений и полноценных наборов программного обеспечения.
Место, где Ты когда-то был веб-разработчиком, теперь Ты — разработчик программного обеспечения.
И вот так… Node превзошел Всемирную паутину.
Телефоны
React Native
(фреймворк для разработки кроссплатформенных приложений для iOS и Android)
Здесь речь пойдет не только об успехах платформы в сфере мобильных телефонов, но и о том, чтобы уяснить один важный момент:
Node является кросс-платформенным, то есть он может работать более чем на одной аппаратной платформе или операционной системе.И это подразумевает не только — «О, круто, это работает на моем телефоне!». И даже не это — «Вау, мой телефон, планшет, ноутбук и телевизор могут поддерживать YouTube!».
React Native — это всего лишь один из примеров структуры, разработанной в экосистеме Node, которая устраняет разрыв между разработкой интерфейсов и разработкой мобильных приложений в такой форме, которой ранее не существовало у других инфраструктур.
Наибольшим минусом при разработке приложений для телефона было в отсутствии их связи с интернетом. Однако с помощью React Native и экосистемы Node разработчик может создать единое приложение, поддерживаемое браузером, iOS и Android. Никакой другой язык не предлагает такую универсальность.
И вот так… Node превзошел мобильные телефоны.
Desktop
Electron
Конечно, не все, что мы делаем, происходит в Интернете. Настольные приложения также имеют огромное влияние на то, как мы будем взаимодействовать. Но почему мы должны работать на разных ПК по-разному, когда сеть теперь может обслуживать полнофункциональные приложения на всех ОС?
На самом деле это был вопрос времени, прежде чем JavaScript догнал производительность настольных компьютеров. Вот так и появился Electron.
Конечно, есть еще более эффективные языки для использования при программировании, но для большинства приложений, которые мы используем сегодня, JavaScript более чем достаточно.
Благодаря Cheng Zhao & Github была создана структура, которая меняет внешний вид настольных компьютеров. Корпорация Electron не только добавила разработку настольных приложений в уже растущий репертуар веб-разработчиков, но и сделала это таким образом, что она полностью совместима с другими ОС.
Хотя Windows по-прежнему является самой распространенной ОС сегодня, Mac находится в состоянии роста уже на протяжении 15 лет, и все большее и большее число разработчиков переключаются на Linux каждый день. И теперь даже небольшие игрушки, такие как Raspberry Pi, чаще станут появляться на Linux, а не только у тех, у кого Windows или Mac. Теперь можно представить, почему кросс-разработка ОС — такое огромное преимущество… и это только начало.
Теперь наш интернет, мобильный телефон и рабочий стол, полностью поддерживаются экосистемой Node. Единый набор инструментов, способный создавать один и тот же интерфейс во всех этих местах.
И вот так… Node превзошел Desktop.
Игры
Unity 3D
Я оставила это напоследок, потому что это не совсем «Node», это все таки больше относится к JavaScript, и об этом поговорим чуть более подробно:
Успех JavaScript состоит не в том, что он превосходит другие языки, Его успех — это прямой результат того, насколько он приспособлен для применения практически везде.
Разработчики JavaScript не пуристы.
Нам нравится наш язык таким, какой он есть (нет); версионно-фрагментированный, зависимый от транспилеров, кросс-платформенный, постоянно развивающийся и стремящийся туда, куда не добирался еще ни один из языков.
Как и развитие игр!
Когда Unity 3D впервые представила свой «UnityScript» на основе JavaScript в качестве средства для разработки игр, тогда стало понятно, что JavaScript теперь будет создавать действительно прикольные вещи. Это было одним из первых крупных набегов на не-веб-развитие, и это был явный признак того, что что-то будет происходить.
Теперь стало отчетливо видно, что JavaScript может делать намного большее, чем просто открывать меню, а также менять размер шрифтов на странице. Он может дать больше, чем просто позволит лайкнуть этот пост. Он может обрабатывать захватывающие, кросс-платформенные игровые события. И те же самые разработчики, которые когда-то были ограничены — Chrome, Firefox и Internet Exploder, внезапно стали разработчиками игр.
И хотя Unity недавно объявила о том, что они откажутся от поддержки UnityScript, я все равно буду говорить:
И вот так… JavaScript превзошел игры.
Хорошо, может быть, нет. Но это не последний раунд, правда?
Я не знаю, когда это закончится, но Node убирает одну преграду за другой и прокладывает путь к миру разработки программного обеспечения, где один язык управляет всеми остальными. Естественно, JavaScript не лучший язык для всего на свете. Но сила JavaScript в том, что он универсальный, и он является самой мощной развитой экосистемой, доступной на сегодняшний день.
Комментарии (205)
yurec_bond
16.01.2018 17:58Unity 3D можно программировать и на C#, так что это так себе аргумент.
yurec_bond
16.01.2018 18:08+2Да и на Unity свет клином не сошелся.
Большинство игр все еще пишут на c++Alexey2005
16.01.2018 22:39+1C++ начал резко сдуваться из-за своей совершенно кошмарной инфраструктуры.
Проект, перенесённый на другую машину при помощи git clone, почти наверняка не захочет собираться. А если вдобавок нужна кросс-компиляция? C++ обеспечит вам массу увлекательных квестов, когда проект, исходно собираемый в GCC, вдруг потребуется собрать под винду.
В XXI веке у такого языка просто нет шансов при наличии хоть какой-то альтернативы, ведь по нынешним временам любой проект просто обязан разворачиваться в два клика на любой платформе, и собираться под любой платформой для всех целевых платформ сразу.
Chaos_Optima
16.01.2018 23:50+2В XXI веке у такого языка просто нет шансов при наличии хоть какой-то альтернативы
Ды есть D, Rust, Nim и тд. И сколько уже было «убийц С++» а воз и нынче там.
ведь по нынешним временам любой проект просто обязан разворачиваться в два клика на любой платформе, и собираться под любой платформой для всех целевых платформ сразу.
В случае С++ это полностью зависит от программиста, буст разворачивается практически везде, Qt.
А уж про игры и графику я вообще молчу, там С++ царствовать будет ещё очень и очень долго.
FadeToBlack
19.01.2018 10:36А уж про игры и графику я вообще молчу
Не путайте игры, графику и 3d Engines. Движки еще долго будут писать на C++, но их будут делать пять огромных мировых компаний и может быть еще сотня мелких неизвестных узкоспециализированнных движков. Больше половины игр пишут на Unity, где c#.
Chaos_Optima
19.01.2018 13:40Не путайте игры, графику и 3d Engines
Я и не путаю, кроме игровых движков, есть 3D редакторы 2D редакторы рендеры и куча куча другого графического совта.
Больше половины игр пишут на Unity, где c#.
А можно ссылочку на статистику? А что насчёт Unreal?FadeToBlack
19.01.2018 14:083D редакторы 2D редакторы рендеры и куча куча другого графического совта.
И все это может быть написано хоть на питоне (при использовании ядра на с++)
А можно ссылочку на статистику? А что насчёт Unreal?
34% самых популярных игр разработаны на Unity
https://unity3d.com/ru/public-relations
Unreal не так популярен
Chaos_Optima
19.01.2018 14:26И все это может быть написано хоть на питоне (при использовании ядра на с++)
Отличное уточнение. Вы можете написать ось хоть на питоне (при использовании ядра на С++). Просто скриптовый язык нет смысла рассматривать, потому что скриптовым языком может быть любой язык, и заменить его так же не составит труда, важно именно ядро. Именно о нём и речь. (не видел ни одного рендера (типа Arnold, Prman) написанного с поддержкой скриптового языка)
34% самых популярных игр разработаны на Unity Unreal не так популярен
Ох уж эти маркетинговые ходы, хотя в области мобилок возможно и правда, но на PC и консолях можно пример нескольких громких игр написанных на Unity? Вот на Unreal я знаю и назвать могу довольно много, а вот на unity ни одно ААА тайтла не могу вспомнить.FadeToBlack
19.01.2018 14:51> а вот на unity ни одно ААА тайтла не могу вспомнить.
Я ничего вам сказать не могу, т.к. я всего лишь программист, и судя по рынку вакансий Unity просто доминирует. Реально, с какими играми бы я ни сталкивался — все на юнити. Касательно AAA сказать ничего не буду — Unity не совсем годен для AAA.
FadeToBlack
17.01.2018 18:06Ну вот почему на хабре минусуют здравые мысли?
Chaos_Optima
17.01.2018 18:12Может потому-что они не такие уж и здравые как вам кажется?
FadeToBlack
18.01.2018 06:58Я думаю, вам нужно лет 15 программировать на с++, чтобы понять
Chaos_Optima
18.01.2018 13:34+1Программирую на С++ уже 14 лет, сомневаюсь что через год что-то поменяется.
poxvuibr
18.01.2018 15:39Там в комментарии были следующие утверждения
Проект, перенесённый на другую машину при помощи git clone, почти наверняка не захочет собираться.
Это неправда?
C++ обеспечит вам массу увлекательных квестов, когда проект, исходно собираемый в GCC, вдруг потребуется собрать под винду.
Это неправда?
Chaos_Optima
18.01.2018 15:56+1Всё зависит от того как написан код. Если нормально, то всё будет спокойно собираться независимо от компилятора и машины. У меня очень редко когда были проблемы с компиляцией, больше всего проблем с зависимостями вот тут да, тут всё плохо.
VolCh
18.01.2018 16:39Скорее, не "если нормально", а "если хорошо, если разработчики уделяли внимание портируемости". "Нормально", увы, чаще всего обозначает "гарантированно работает в единственном целевом окружении".
Chaos_Optima
18.01.2018 16:47Ну тут многое ещё зависит от того какие библиотеки при этом используются. Я видел отвратный код который тем не менее успешно собирался под винду, линукс, андройд, мак, иос (разработка игры под мобилки с использованием marmalade). Так что если писать боле менее нормально с использованием правильных библиотек, то геморроя не будет.
FadeToBlack
19.01.2018 07:21Да будет геморрой. Будет. Каждый, блин, день будет. Каждую подключенную библиотеку нужно прикручивать с помощью говна и палочек, и писать обертки над маргинальными си-интерфейсами, если вдруг хочется ООП и классов.
Chaos_Optima
19.01.2018 13:46и писать обертки над маргинальными си-интерфейсами, если вдруг хочется ООП и классов.
Видимо вы что-то не то используете boost, Qt вполне себе оопшные (из тех что я ещё использую Alembic, Maya, Ilm, tbb и куча других практически все oop и все мультиплатформенные) и гемора как-то нет.FadeToBlack
19.01.2018 14:11Ну вот вы возьмите, например, IntelMKL. Если найдете обертку в виде Eigen — то флаг вам в руки, нет — будете писать через жопу. А кого интересуют GUI фреймворки, которых тысячи — выбирай любой. А вот что-то особенное всегда через жопу.
Chaos_Optima
19.01.2018 14:34IntelMKL
А в чём с ним проблема? Просто я от интела использую Tbb и Embree ispc(не библиотека но всёже) и никогда с ними проблем не было что под виндой что под линем.
А вот что-то особенное всегда через жопу.
У меня довольна узкая специализация, и практически всё особенное, но при этом практически все библиотеки ооп и собираются везде (Ну кроме USD, Pixar те ещё говнокодеры без слёз на их код не взглянешь).
0xd34df00d
19.01.2018 21:11И тут мне тоже стало интересно, в чём проблема с MKL? Отлично работает что с Eigen, что с dlib (который, кстати, быстрее, и псевдообратные матрицы там изобретать не надо!), что даже с hmatrix, хехе.
FadeToBlack
18.01.2018 20:10Меняется с каждым годом. С каждым годом C++ мог бы становиться лучше, а не вот это, что с ним делают. А если он не становится лучше, он движется назад. Не думаю, что через 20 лет его будут воспринимать всерьез. Его будут воспринимать примерно так, как мы сейчас воспринимаем Паскаль — что-то старое, программировать можно, но лучше не надо. C++ сложен, противоречив и жутко небезопасен. Вряд ли молодые люди будут выбирать его для изучения, когда сейчас так много других языков, которые проще, да и востребованнее. Для большинства применений не требуется суперпроизводительности, да и компьютеры все мощнее, а компиляторы все умнее оптимизируют.
0xd34df00d
18.01.2018 23:45С каждым годом C++ мог бы становиться лучше, а не вот это, что с ним делают.
А он, по-вашему, не становится лучше? В чём это заключается?
C++ сложен
При этом писать безопасный и выразительный код на нём становится всё проще с каждым новым стандартом.
противоречив
Спасибо потребности совместимости с С!
жутко небезопасен
Посмотрите при случае доклад Саттера с CppCon, кажется, 15-го года.
babylon
19.01.2018 03:07Меняется с каждым годом. С каждым годом C++ мог бы становиться лучше, а не вот это, что с ним делают. А если он не становится лучше, он движется назад. Не думаю, что через 20 лет его будут воспринимать всерьез.
Не могу не согласиться с тем, что С++ не становится лучше. Но уже есть гибрид Lua + msgpack в tnt и есть надежда, что языки вырулят на правильный природный путь и код будет помещаться в данные для юзанья и тестирования, а не как сейчас. Наконец-то уйдут в небытие классы и функции. Интересно это всё увидеть ранее 20-ти лет :)
0xd34df00d
19.01.2018 21:14Но уже есть гибрид Lua + msgpack в tnt и есть надежда, что языки вырулят на правильный природный путь и код будет помещаться в данные для юзанья и тестирования, а не как сейчас. Наконец-то уйдут в небытие классы и функции.
Я тут, если честно, ничего не понял.
FadeToBlack
19.01.2018 07:28А он, по-вашему, не становится лучше? В чём это заключается?
А сохраните-ка ваши данные в файл? Ну, не просто массив int, а что-нибудь посложнее, например, древовидную иерархию полиморфных классов.
При этом писать безопасный и выразительный код на нём становится всё проще с каждым новым стандартом.
Каждый новый стандарт превращает код с++ в месиво, которое уже никто не может понять. Единственное, что они сделали — это foreach. Посмотрите на монструозный синтаксис лямбд, неужели нельзя сделать вывод типов и стрелочные функции, которые компактны?
Free_ze
19.01.2018 09:21А сохраните-ка ваши данные в файл?
Библиотек сериализации море.
Единственное, что они сделали — это foreach.
Это далеко не единственное изменение, но как раз одно из бесполезных.
Посмотрите на монструозный синтаксис лямбд, неужели нельзя сделать вывод типов и стрелочные функции, которые компактны?
То есть неявный захват переменных? По сути-то там лишнее — обязательные фигурные скобки иreturn.FadeToBlack
19.01.2018 10:31Библиотек сериализации море.
В том то и дело, что мне еще нужно что-то подключать. Почему я не могу сделать это из коробки? Сериализация данных — это возможность, необходимое каждому приложению, если не всем. Но мы не можем взять и сделать это. Без бубна с синтаксическим разбором твоих исходников и генерации кода сериализации по ним… Разве это нормально вообще? Или вы знаете библиотеку, которая делает это хорошо и просто? Задайте себе вопрос, в чем проблема здесь: плохие библиотеки или язык без некоторых необходимых возможностей?
Это далеко не единственное изменение, но как раз одно из бесполезных.
одно из тех, которая реально упрощает кодирование. А не все остальные, которые только усложняют.
То есть неявный захват переменных? По сути-то там лишнее — обязательные фигурные скобки и return.
Да пофигу какой захват. Можно сделать несколько стрелок или какую-нибудь байду "&>" "=>".
Free_ze
19.01.2018 11:35+1В том то и дело, что мне еще нужно что-то подключать. Почему я не могу сделать это из коробки?
Вполне в духе современного тренда с модуляризацией библиотек) *здесь было бы выгоднее говорить о том, что подключать библиотеки — геморрой, иначе это не было бы ощутимой проблемой*
Без бубна с синтаксическим разбором твоих исходников и генерации кода сериализации по ним…
Но когда это окажется в языке, ведь компилятор будет работать точно так же.
Впрочем, возвращаясь к JS, у него те же самые проблемы (несъедобность без «бубна» с препроцессингом и целого особого тулчейна), только они не ограничиваются одной задачей, а вообще весь язык страдает. Но он тут «побеждает».
одно из тех, которая реально упрощает кодирование
Настолько же, насколько появление лямбд или все же просто прикольный современный синтаксис?FadeToBlack
19.01.2018 13:15-1Но когда это окажется в языке, ведь компилятор будет работать точно так же.
Вот! он будет точно так же работать, как работает КОМПИЛЯТОР, а не как написали свой moc разработчики либы! И сериализация будет через нормальный стандартизированный рефлекшн, а не через это говно с выкрутасами вокруг #define
Впрочем, возвращаясь к JS, у него те же самые проблемы
JSON.stringify() что ли? Да это просто шах и мат любому c++, только за это я готов признать победу JS (для контекста: JS не знаю, только QML немного. на С++ программирую больше 15 лет).
Настолько же, насколько появление лямбд или все же просто прикольный современный синтаксис?
Лямбды в таком виде ничего не упрощают, а создают условия для нагромождения кода. foreach позволяет нормально итерировать любую коллецию единым, читаемым способом, а не вот эти вот begin(), end(). Это упрощает ежедневное кодирование, экономит время. Язык должен экономить время, а не создавать дополнительные проблемы.
Free_ze
19.01.2018 13:32Вот! он будет точно так же работать, как работает КОМПИЛЯТОР, а не как написали свой moc разработчики либы!
В общем, вам важен авторитет писателя «говна». ОК.
JSON.stringify() что ли?
Нет, я про препроцессинг и старые стандарты.
Лямбды в таком виде ничего не упрощают, а создают условия для нагромождения кода.
Лямбды вам не нужны, а условие for вы настолько часто пишите каждый день, что это разительно экономит время. Яснопонятно… (=FadeToBlack
19.01.2018 14:04В общем, вам важен авторитет писателя «говна». ОК.
Вы вообще, понимаете, о чем речь? Не о том, что писатели компиляторов лучше напишут, а о том, что комплируемый код и метаинформация(рефлекшн) будут 100% достоверными, ибо получены в рамках одного и того же процесса компляции кода. А писателем этого может быть хоть кто, лишь бы в стандарте C++ это было прописано правильно, а компилятор этому следовал.
Нет, я про препроцессинг и старые стандарты.
Да кого интересует этот JS? Он, как и flash, сегодня на коне, а завтра никому не нужен. Завтра придумают сайты писать на питоне(через WebASM), и будем все офигевать от новой реальности.
Лямбды вам не нужны, а условие for вы настолько часто пишите каждый день, что это разительно экономит время. Яснопонятно… (=
Не нужны. Вот в таком виде — точно. Проще передать указатель на функцию. Вот серьезно. Это хоть не так громоздко будет выглядеть. Т.е. вы for не каждый день пишите? Пишите ли вообще код?
Chaos_Optima
19.01.2018 14:41Не о том, что писатели компиляторов лучше напишут, а о том, что комплируемый код и метаинформация(рефлекшн) будут 100% достоверными, ибо получены в рамках одного и того же процесса компляции кода
С чего вдруг? Или писатели компиляторов не бажут? Чем реализация в стандарте отличается от библиотечной реализации? (В плане переносимости) (Хотя я тоже безумно хочу поддержку рефлексии)
Не нужны. Вот в таком виде — точно. Проще передать указатель на функцию. Вот серьезно. Это хоть не так громоздко будет выглядеть.
Правда? Если конечно вам ненужны замыкания то возможно и правда, но я лично использую лямбды с замыканиями в 90% случаев, а писать многопоточный код с лямбдами стало вообще крайне приятно. Как и работать с сигнал слотами, и колбэками.FadeToBlack
19.01.2018 14:55С чего вдруг? Или писатели компиляторов не бажут? Чем реализация в стандарте отличается от библиотечной реализации? (В плане переносимости) (Хотя я тоже безумно хочу поддержку рефлексии)
И сколько багов вы нашли в компиляторах? Хотя не спорю, в новых фичах C++ я сталкивался. Но речь не об этом. А об языке и поддержки чего-то из коробки, а не за счет говна и палок (как в QT, например)
Правда? Если конечно вам ненужны замыкания то возможно и правда, но я лично использую лямбды с замыканиями в 90% случаев, а писать многопоточный код с лямбдами стало вообще крайне приятно. Как и работать с сигнал слотами, и колбэками.
Ну т.е. без лямбд и замыканий вы это можете реализовать?
Chaos_Optima
19.01.2018 15:21И сколько багов вы нашли в компиляторах?
Ну это можно сказать моё хобби, но немного.
А об языке и поддержки чего-то из коробки, а не за счет говна и палок
Тут я соглашусь, всё таки рефлексии и правда очень не хватает.
Ну т.е. без лямбд и замыканий вы это можете реализовать?
Естественно, но с лямбдами это стало во много раз проще. По моему мнению лямбды гораздо более полезная фича чем форычь, хоть и используется реже, просто потому что размер кода очень сильно сокращается и уменьшается разрыв контекста, код и читать и писать гораздо проще.
0xd34df00d
19.01.2018 21:30Проще передать указатель на функцию.
И как вы захватите в этот указатель состояние?
0xd34df00d
19.01.2018 21:29Лямбды в таком виде ничего не упрощают, а создают условия для нагромождения кода.
Любой язык создаёт условия для нагромождения кода, на любом языке можно писать паршиво.
0xd34df00d
19.01.2018 21:27Без бубна с синтаксическим разбором твоих исходников и генерации кода сериализации по ним…
Можно и без этого бубна, но с некоторыми пасами руками. Добавят, кстати, в какой-нибудь C++20 компилтайм-рефлексию, а в С++23 — метаклассы, можно будет и без этих пасов.
Но нет, это ж не то, что нужно, С++ же идёт не туда.
А не все остальные, которые только усложняют.
Какие остальные изменения усложняют кодирование? Ну, можно пример, что до них было просто, а с ними — сложно?FadeToBlack
20.01.2018 10:09Можно и без этого бубна, но с некоторыми пасами руками
Плавали, знаем, какие там пассы. Либо жуткая шаблонная магия, либо #define. В любом случае, чтобы подготовить класс для сериализации, придется некоторым образом все регистрировать.
Добавят, кстати, в какой-нибудь C++20 компилтайм-рефлексию, а в С++23 — метаклассы, можно будет и без этих пасов.
Несвоевременность — вечная драма. Будет поздно, все это нужно было сделать 10 лет назад. А к 30 году, когда все компиляторы будут это поддерживать, на с++ останутся сидеть старпёров (может быть даже я буду среди них) .
0xd34df00d
19.01.2018 21:23Каждый новый стандарт превращает код с++ в месиво, которое уже никто не может понять.
А что там непонятного-то? Даже, я не знаю, folding expressions вполне понятны.
Посмотрите на монструозный синтаксис лямбд, неужели нельзя сделать вывод типов и стрелочные функции, которые компактны?
Вывод типов в стиле Хиндли-Милнера я сам давно хочу. А что до синтаксиса — я где-то видел обоснование, почему это относительно минимальный неконфликтующий с имеющейся грамматикой (привет, наследие С, снова) вариант.FadeToBlack
20.01.2018 10:16А что там непонятного-то? Даже, я не знаю, folding expressions вполне понятны.
Это вы про писать или про читать?
неконфликтующий с имеющейся грамматикой
А есть ведь еще на клавиатуре символы, которые до сих пор не используются в С++? $ # @ что еще?
3axap4eHko
17.01.2018 19:03Потому что не все способны их понять, многие просто отстают в развитии. Когда-то Галилея вообще сжечь хотели за вполне здравую мысль.
sasha1024
16.01.2018 21:07Насколько я знаю, в Unity нет JavaScript, а представленный там UnityScript весьма далёк от JavaScript (не Unity-спец, видел мельком).
Suvitruf
17.01.2018 07:42В Unity возможность писать на JS уберут совсем в скором времени, о чём они не раз заявляли.
Vadem
17.01.2018 16:37Да. Например, вот тут можно почитать об этом — UnityScript’s long ride off into the sunset
rafis-tatar
16.01.2018 18:01.Net core и c# + Xamarin + AvaloniaUI
F0iL
16.01.2018 20:57Увы, даже по словам самих авторов, Avalonia еще активно пилится и до стабильного использования в продакшене пока далековато.
SirEdvin
16.01.2018 18:01+3Однако, JavaScript уже практически десятилетия находится рядом и никуда не уходит. Итак, уместно будет задать такой вопрос: «В каком же направлении он движется?» Однако, этот пост не совсем о «JavaScript». Также, он не касается того множества языков, которые были до него. И здесь не говорится о том, какой JavaScript замечательный.
Куда же ушли Java, C#, Python, Perl, Lua и еще куча языков? Тут вот все еще спорят, жив ли Delphi, а вас удивляет что JavaScript, который занял себе очень удобную нишу все еще с нами.
Алсо, сразу видно, что автор знает только javascript. Например, на Java, Python и C# можно делать все перечисленные вещи. Да, и фронтенд тоже. Есть TeaVM, Python.JS или Bridge.Net для этого. Вопрос только в полезности, применимости и так далее.
Реальная движущая сила JavaScript — это браузеры и фронт-енд разработчики, которым тесно в рамках браузеров. Завезут webASM и возможность использовать разные языки в браузерах и через год-второй очень много компаний и людей забудет про javascript. И давайте не будем без аргументов в духе "ну, если бы язык не был плохим, никто бы с ним не работал", у вас гигантское количество разработчиков на рынке умеет работать в основном только с этим языком, отрицать то, что этот фактор имеет сильное влияние на популярность javascript очень глупо.
Не говоря уже о том, что значительное число декстоп и мобильных приложений на javascript откровенно работают так себе. То есть их можно оптимизировать, но никто этим особо не парится, как я понимаю.
SirEdvin
16.01.2018 18:10Ну и да:
Хотя… не совсем. Здесь не будет описываться миллион причин, по которым эта экосистема является самым инновационным посредником в области взаимодействия с открытым исходным кодом, которую когда-либо видел мир.
Есть хотя бы одна? Что такого инновационного сделали?
Cim
16.01.2018 18:35+1Благодаря JS каждый может почувствовать себя успешным опенсорс контрибьютором, написав очень полезный npm пакет типа is-array или left-pad.
Чем не инновационный вклад в область взаимодействия с опенсорсом? А? Съели? Вот именно!
TheKnight
17.01.2018 09:12Проставьте пожалуйста теги эмоциональной разметки текста, вы кажется забыли про их существование.
Cim
17.01.2018 10:54Мне не до эмоций. Я разбираюсь в том, что инновационно наконтрибьютили с альтернативным понятием об архитектуре и качестве кода. В этом деле нужна выдержка, горячее сердце и холодный ум. А то за выкриками «whaaaaaaaaaaat» работать будет невозможно.
F0iL
16.01.2018 20:58+1Завезут webASM и возможность использовать разные языки в браузерах и через год-второй очень много компаний и людей забудет про javascript
Не забудет. WASM — не полная замена JS, и никогда ею не планировался, он придуман, мягко говоря, для немного других целей.neit_kas
17.01.2018 01:45Хотя на заре WASM ходили слухи, что мол по сети будут гоняться бинари WASM'а, а всё остальное в т.ч. и js компилироваться в него.
F0iL
19.01.2018 19:57Именно что слухи. На хабре есть интевью с создателем JavaScript и одним из создаетелей asm.js и WebAssembly, о том, как вообще все началось и для чего: habrahabr.ru/post/326276
FadeToBlack
19.01.2018 10:45-1WebASM уже завезли, и теперь можно делать сайты без JS. Наконец-то!
maxzh83
16.01.2018 18:20+1Я не знаю, когда это закончится, но Node убирает одну преграду за другой
Есть предположение, что закончится это когда браузеры в полном объеме научатся работать с чем-то кроме JavaScript (WebAssembly или что-то еще). Дальше начнется замедление развития или стагнация, но это только мое мнениеFadeToBlack
19.01.2018 10:47А потом реальные процессоры потихоньку переедут на WebASM (шутка, если что)
Yardanico
16.01.2018 18:40Так почему же тогда Electron приложения жрут по 500мб, в то время как нативные кушают раз в 10 меньше? Я понимаю, что это из-за постоянного повышения производительности компьютеров, но не нужно выходить за рамки
justboris
16.01.2018 20:38Не Electron-приложения, а Slack, не нужно обобщать.
Тот же VSCode жрет не больше других программ.
Alexsey
16.01.2018 21:14Тот же VSCode жрет не больше других программ.
VSCode при одинаковых условиях спамит процессами (как и весь софт на electron) и жрет больше, чем полноценная студия с решарпером и парой менее громоздких плагинов.
zapolnoch
16.01.2018 21:31Голый VS-Code действительно потребляет больше ОЗУ, чем например голый Sublime. Но если поставить одинаковый набор плагинов, которые например нужны лично мне в работе, то Sublime проигрывает по памяти. Даже с учетом спамных процессов.
evocatus
16.01.2018 23:47А по сравнению с IDE от JetBrains Atom или VSCode не выдерживают никакой конкуренции. Когда GoLand вышел и стал платным я пересел на VSCode и разница настолько ощутима, что я почти готов заплатить 90$ за право год пользоваться GoLand
justboris
17.01.2018 00:33Я отвечал на комментарий
Electron приложения жрут по 500мб, в то время как нативные кушают раз в 10 меньше
На вашем скриншоте в сумме получается около 400Мб, (меньше 500). Во-вторых это всего на четверть больше, но никак не в 10 раз.
Так что своим комментарием вы так же подтвердили, что все не так плохо, как некоторые любят говорить.
Alexsey
19.01.2018 21:17Так что своим комментарием вы так же подтвердили, что все не так плохо, как некоторые любят говорить.
Если бы VSCode имел все функции полноценной студии я бы с вами согласился, но тут получается такая ситуация что софтина, которая по встроенной функциональности не сильно далеко ушла от notepad++ жрет как полноценная IDE. Это при том что notepad++ ест 12 мегабайт памяти.
saggid
17.01.2018 08:49Discord на электроне, к примеру, имеет целую кучу фич — и потребляет на моей машине ~110мб озу. Telegram, к примеру, расходует 75мб. Dropbox (питон) — примерно 100мб.
Думаю, всё сильно зависит от того, какие проблемы решает приложение. Многие программы занимают много озу даже с учётом того, что они написаны на других языках. И весь этот гон в сторону node.js хоть отчасти и оправдан, но для десктопа использование большого кол-ва озу — дело в целом самое обыкновенное.
j_wayne
17.01.2018 10:00Telegram же на Qt был?!
saggid
17.01.2018 10:45О том и речь, что он занимает тоже нормально озу, хоть и не писался на джс.
aknew
17.01.2018 11:18На qt совсем не значит не на js, их модерновый qml вовсю использует js, хотя многие компоненты при этом реально написаны на С++ из-за чего там могут быть проблемы с утечками (плюсовые компоненты не подчиняются сборщику мусора)
farcaller
17.01.2018 12:08Как ни крути, а electron все же память жрет как не в себя — 3 из 5 топовых процессов у меня вот. А что касается дискорда, то там еще прошлой осенью были просто адовые утечки когда он мог по 4-5гб памяти съедать.
k12th
16.01.2018 19:06В Unity 3D никогда не было JS. UnityScript это в самом лучшем случае исковерканный диалект ECMAScript, как, скажем, ActionScript. Был во Flash JS? Нет, конечно.
Это была маркетинговая попытка привлечь внимание. Да и никто и не писал на UnityScript.
Перевод забавный, "превзошел десктопы". "Превзойти" в значении "овладеть" не употребляется уже, наверное, лет сто.
ice_shit
16.01.2018 19:46Сразу нет, я понимаю, что за мультиплатформенностью день сегодняшний и будущий, но javascript (electron как один из «выделяющихся» примеров) это точно не решение этой задачи на данный момент. На системах с достаточной производительностью (особенно мобильных) приложения на javascript не выдерживают никакой критики со стороны производительности функционала и использования системных ресурсов.
zapolnoch
16.01.2018 21:36+1Какую кроссплатформенную альтернативу для десктопов предлагаете использовать? Уродский JavaFX или Qt, нормальная лицензия которого начинается от 4к$.
ice_shit
16.01.2018 22:15К сожалению, я могу представить только Qt. Но это не значит что Qt — ультимативное решение
zapolnoch
16.01.2018 22:27Об этом и речь. Electron ужасен, но это едва ли не лучшее, что есть на кроссплатформенном рынке. По сумме параметров (цена, скорость разработки, качество UI, порог входа и т.д.) у Electron'а только один конкурент — Xamarin.
Sultansoy
16.01.2018 22:21А чего вдруг fx уродский? Очень даже удобный. Вы бы еще swing вспомнили, хотя и там парни из jetbrains доказали, что можно делать красиво как визуально, так и в коде.
asmrnv777
17.01.2018 01:44Ну, я хоть и не автор того коммента, но отвечу.
После большого опыта построения интерфейсов под Android и небольшого под iOS, в JavaFX без ста грамм разобраться не мог. Да и вообще до конца так и не смог разобраться, как там сделать более-менее сложный UI без костылей и велосипедов. Я не утверждаю, что его сделать нельзя, просто доки почти никакие, инфы в этих наших интернетах мизер, и работает оно (с точки зрения Android-разработчика) через зад. Почему нельзя было подсмотреть, «как надо» в других платформах, и перепилить fx — не ясно.SirEdvin
17.01.2018 10:32С точки зрения человека, у которого есть небольшой опыт в JavaFX, Android выглядит тоже странненько, правда.
poxvuibr
17.01.2018 10:48Qt, нормальная лицензия которого начинается от 4к$.
И зачем эта самая лицензия за 4k нужна?
firegurafiku
17.01.2018 16:38Qt, нормальная лицензия которого начинается от 4к$
А чем ненормальна бесплатная LGPL? До тех пор, пока ваше приложение просто использует Qt как библиотеку, вы не обязаны раскрывать никаких своих исходников.
VladimirPesterev
16.01.2018 20:11Сам по себе Node.js сложно сейчас назвать чем то инновационным. Тут дело в пакетном менеджере который поставляется вместе с ним — NPM. За react native могу сказать что никакой Node.js в вашем смартфона не запускается, а лишь js рантайм который преобразуется в нативные компоненты, разве что сам React Native поставляется NPM и тулзы всякие вроде пекеджер реакт натива действительно запускаются нодой на машине разработчика. В браузере также нельзя запустить чисто нодовые пакеты.
JC_IIB
16.01.2018 22:35Когда под рукой нет ничего, кроме молотка, все остальное кажется гвоздями.
Статья очень однобокая. Что, ничего кроме «божественной ноды», больше не позволяет лепить кросс-платформенные мобильные приложения? Ложь. Игры? Вообще смешно, вы настоящие ААА-класса игры видели? Да и то, что из Unity наконец-то выпиливают JavaScript, уже о многом говорит.
Да, и electron для меня — синоним неповоротливого, жрущего ресурсы как не в себя, приложения.
Naglec
16.01.2018 23:14Старый добрый баянчик:
Один пацан писал все на JavaScript, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно.
3axap4eHko
17.01.2018 00:01Я так понимаю троллинг удался ибо все у кого подгорают религиозным огнем ягодицы достали свои минусаторы (у кого они есть конечно), а у кого нет просто пишут гадкие комменты (опять же кто может). Что в том что JS лучше? У любого другого языка была возможность стать лучше, но не вышло. Что за мода такая хейтить успех? Я всегда думал, что IT сообщество выше этого, но видимо IT сообщество уже с гнильцой, как показывает практика. Надменные, самовлюбленные, брезжащие над своими технологиями люди, которые забыли куда мы должны двигаться.
Думаю пора покинуть это сообщество, после того как напишу прощальный пост.
OKyJIucT
17.01.2018 00:39+1Да каждый язык десять пунктов форы даст JS-у, все зависит от того, где и как их использовать. То прям панацея — JS есть и больше ничего не надо. Да, язык мощный, но кроме веба существует куча сфер и софта, где используются другие языки, и JS там ну вообще не взлетит.
3axap4eHko
17.01.2018 00:40Например?
Chaos_Optima
17.01.2018 00:48-1system, iot, big data, hight perf, machine learning, graphic.
3axap4eHko
17.01.2018 00:52-1ну бред, погуглите даже Photoshop использует nodejs
Chaos_Optima
17.01.2018 01:03-1А остальное? Может есть ОС или драйвер какой на js? А что с IOT? Может где big data на js ворочают? Может где торгуют с использованием js? А уж для нейросетей он прям идеально подходят (хоть там даже С++ является не достаточно быстрым и всё переводят на gpu). И что значит даже Photoshop? Maya использует python в роли скриптового языка, но это не значит что python подходит для разработки графического движка. Только в роли скриптового. Ну и да кто ещё использует JS в роли скриптового языка в графическом приложении? В Unity js like и тот дохлый.
quwy
17.01.2018 00:50+1У любого другого языка была возможность стать лучше, но не вышло.
Сабж даже после всех последних изменений выглядит убого. А единственная причина его распространенности — монополия. В такой ситуации даже кусок говна на палке будет использоваться всеми. Что, собственно, и произошло.
Я всегда думал, что IT сообщество выше этого
IT-сообщество видит, во что его пытаются превратить js-хипстеры, и ему это закономерно не нравится.
которые забыли куда мы должны двигаться
Напомните-ка, кто и когда делегировал право выбирать наравление нашего движения исключительно [бывшим] фронтэндщикам? Может лучше слушать тех, кто знает немного больше, чем один скриптовый язычек?
Думаю пора покинуть это сообщество, после того как напишу прощальный пост.
Не задерживайтесь.3axap4eHko
17.01.2018 01:11-1Сабж даже после всех последних изменений бла-бла-бла...
Какая к чертям монополия? Кто монополист здесь? Язык? Владелец языка кто? Это не C# microsoft и не swift Apple.
IT-сообщество видит бла-бла-бла…
бла-бла-бла… больше, чем один скриптовый язычек?Не считаю себя js хипстером и знаю достаточно языков, что бы видеть общую картину. Но даже не зная одного языка можно сказать, что хейтинг это не тру вэй
Не задерживайтесь.
Да, да я о таких как Вы писал. Надменные, самовлюбленные, брезжащие над своими технологиями люди. С одной стороны Вас жалко, а с другой так вам и надо. Я смотрю вас уже подтолкнули прям напихали можно сказать =)
quwy
17.01.2018 03:57Скажите честно, вы тролль, или тупо не догоняете в чем монополия жабаскрипта? Не понятно как разумное существо вообще может задать подобный вопрос.
знаю достаточно языков
Дайте угадаю. Помимо сабжа это: CofeeScript, Python, PHP, может быть еще TypeScript. Правильно?
Надменные, самовлюбленные, брезжащие над своими технологиями люди
O'rly? Да сама эта статья с вашими комментариями — просто классика самолюбования на тему «смотрите, какие мы крутые, всем стоять/бояться!».
F0iL
17.01.2018 10:57Скажите честно, вы тролль, или тупо не догоняете в чем монополия жабаскрипта?
А что, JS не используется нигде, кроме фронтенда? Кроме JS не существует языков разработки server-side для web? Кроме JS не существует языков разработки под мобильные платформы? Кроме JS не на чем писать под десктоп? Да, действительно монополия, а мужики-то не знали…
Дайте угадаю. Помимо сабжа это: CofeeScript, Python, PHP, может быть еще TypeScript. Правильно?
Ну вот он я, разработчик С и C++ (встраиваемые системы, десктопы, серверное ПО, от мелких утилиток до проектов с многомиллионной кодовой базой, под bare metal, Windows, Linux, VxWorks), C# (десктоп, бэкенд), в разные времена еще мучал Scala в связке с Hadoop, ассемблер для AVR и многое другое.
И мне безумно нравится JavaScript на сервере в воплощении NodeJS, поскольку он отлично подходит для ряда задач и прелестно их выполняет. Что со мной не так, доктор?
O'rly? Да сама эта статья с вашими комментариями — просто классика самолюбования на тему «смотрите, какие мы крутые, всем стоять/бояться!».
Эта статья скорее довольно жирный троллинг, на который как раз ведутся и бомбят надменные, самовлюбленные и брюзжащие люди, что мы и видим из комментов :)SirEdvin
17.01.2018 11:03А что, JS не используется нигде, кроме фронтенда? Кроме JS не существует языков разработки server-side для web? Кроме JS не существует языков разработки под мобильные платформы? Кроме JS не на чем писать под десктоп? Да, действительно монополия, а мужики-то не знали…
Это похоже уже на совсем толстый троллинг. Сколько у нас там фронтенд разработчиков? 30% или больше? Движение идет из фронтенда во всем сферы же. Не было бы монополии JS на браузерах, такое бы вряд ли произошло.
F0iL
17.01.2018 11:15Это да. И это произошло. Только по-вашему что, все, кто пилят бэкенд и микросервисы на ноде — это бывшие фротнендеры? Какая-то часть из них, да, возможно, но по моим наблюдениям, большинство пришло с других технологий (джависты, шарписты, питонисты, и т.д.). Это и отличает профессионала от религиозного фанатика — то что первый, в отличие от второго, выбирает инструмент в зависимости от его плюсов и минусов для конкретной задачи, а не основываясь на идеях «тру/не тру».
SirEdvin
17.01.2018 11:22Хорошо, если вы такой профессионал, подскажите, почему я должен писать свой веб-сервис, скажем на node.js, а не на python? Для более конкретного разговора, например, это прокси-сервис, который часть запросов заворачивает, а данные из них пишет себе в бд. Вот что такого есть в node.js от чего мне имеет смысл учить новый язык и чего я не могу найти на python? Проблемы с однопоточностью и асинхронность в python есть, причем изначально на async-похожем синтаксисе еще с python 2.6, если не раньше. Я думаю вы столкнетесь с тем, что каждый плюс node.js будет перекрываться другим плюсом из python и выбор нужно будет делать исключительно из того, что больше нравится, потому что это все-таки языки общего назначения.
Мне кажется, что большое количество людей, не смотря на то, какие они профессионалы делает выбор на хайпе и информации, которая с ним прилетела, потому что очень много людей не знают возможности своей платформы. Как пара очень странных адептом node.js, которые утверждали, что node.js прорывная, потому что там есть асинхронность.
VolCh
17.01.2018 11:52Как минимум, ещё выбор будет делаться по степени знания языка и всего стэка. Примитивное решение вашей задачи (допустим асинхронность в ней имеющееся требование, равно как и отсутствие требования в конкретном окружении типа windows) я на node.js напишу до вечера (это не мой основной стэк, но изучать надо будет конкретную часть экосистемы, а не язык и общепринятые практики разработки серверных приложений), на python практически наверняка дольше, скажем пускай три дня, включая восстановление в памяти базового синтаксиса языка, поиска стандартных или не очень библиотек/фреймворков с хорошей поддержкой асинхронного io (слово flask в голове крутится, но не уверен, что єто то, что надо), поиск и изучение лучших практик для них и python вообще и т. п. И оценка "три дня" базируется лишь, лишь на "хайпе" вокруг питон и информации, которая с ним прилетела — наверняка есть библиотеки/фреймворки, в которых большинство нужной функциональности красиво обёрнута и мне нужно будет лишь правильно её скомпоновать, и наверняка мне не придётся вспоминать C, чтобы написать биндинг к функциям ядра Linux и библиотеки СУБД. Просто по ощущениям, интуитивно. А в случае NodeJS я знаю, что production-ready библиотеки для создания веб-сервера, для отправки веб-запросов на другие сервера и для записи в популярные СУБД уже точно есть, как минимум в одном экземпляре. Знаю, а не надеюсь, как в случае python.
SirEdvin
17.01.2018 11:54Ну, поэтому я и написал:
Вот что такого есть в node.js от чего мне имеет смысл учить новый язык и чего я не могу найти на python?
Понятное дело, что можно склонятся к знакомому инструменту.
VolCh
17.01.2018 12:00На основе хайпа могу предположить, что nodejs сервер будет работать быстрее в общем случае, чем реализация на референсном python :)
SirEdvin
17.01.2018 12:17Если верит этим графикам, то нет.
VolCh
17.01.2018 12:41Насколько я понимаю, эти графики как раз показывают, что "из коробки" nodejs в общем быстрее python на подобных задачах. Чтобы обойти nodejs потребовалось подключать бинарные библиотеки как раз из экосистемы nodejs и писать для них биндинги.
Такие подходы на продакшене обычно говорят либо о хорошем знании экосистемы python "под капотом", либо о малой ответственности. Лично я бы рискнул использовать такой путь только для PHP, как наиболее известной мне платформе, причём с неделей минимум на нефункциональное тестирование.
SirEdvin
17.01.2018 13:07Там есть колоночка с asyncio, который нативный для python и можно увидеть, что отстает он не значительно и разрыв уменьшается с ростом размера запроса. Очень сомневаюсь, что эта разница стоит того, что бы начать внезапно учить JS, лучше уже попробовать uvloop)
А потом подключается libuv, и магическим образом скорость вырасает от 2 до 4 раз. Как по мне это дополнительно еще неплохо говорит о скорости работы самих языков.
SirEdvin
17.01.2018 13:22Так же стоит заметить, что первые графики относятся к tcp серверу. В случае http сервера, nodejs даже от нативного asycnio отстает.
Стоит заметить, что они использовали библиотеку, которая используется для парсинга http в nodejs. Они не предлагают ее использовать, так как их binding еще не production ready, но получается, если подключить хотя бы один элемент nodejs инфрастуктуры (а они написаны на C), то python оказывается далеко впереди.
Сомневаюсь, что в более сложных случаях nodejs будет выиграть даже у чисто python, так как можно предположить, что большая часть времени теряется где-то в js движке. Разумеется, если делать правильный выбор надо еще это все перепроверять самому, но так это просто интересное замечание.
VolCh
17.01.2018 13:35Если предстоит учить либо JS, либо Python, то разница может оказаться решающей даже в случае tcp-сервера :)
А насчёт http — как я понимаю колонка asyncio aiohttp и есть нативный (пускай и не "из коробки") способ написания асинхронных http-серверов. И даже если язык быстрее, то экосистема оказывается заметным узким местом.
Whuthering
17.01.2018 12:40+1Если вы уже пишете на Python или JS и этот язык по вашему мнению подходит для данной задачи (сам язык и привычный вам фреймворк подходит по быстродействию, наличию удобных и стабильных биндингов к используемой БД, различным сервисам/протоколам, и т.д.) — то пишите на нём, а если вы раньше не писали ни на том, ни на том, но имели опыт с любым C-подобным языком и не знаете ни JS, ни Python, то JS для вас окажется гораздо удобнее хотя бы по уже родному синтаксису.
SirEdvin
17.01.2018 13:14+1Как человек, который переходил от Java -> Python могу сказать, что это очень субъективно. Отсутствие скобочек не делает язык таким уж другим. Ладно бы не было привычных концептов, как в случае с Lua, там, например, нет массивов, только таблицы, как я понял, но так разницы почти нет.
0xd34df00d
17.01.2018 19:39И мне безумно нравится JavaScript на сервере в воплощении NodeJS, поскольку он отлично подходит для ряда задач и прелестно их выполняет. Что со мной не так, доктор?
Не пробовали там другие языкиА какие задачи вы на сервере джаваскриптом решаете?VolCh
18.01.2018 15:05Серверный JavaScript хорошо справляется с задачами маршрутизации, агрегирования, шлюзования и т. п. сообщений с частыми изменениями маршрутов и схем. Ну, например, трансляция сообщений amqp в сообщения websocket и обратно. Или шлюз, с серверной стороны предоставляющий graphql API, и являющийся клиентом нескольких HTTP RESTish сервисов. Наверное, для каждой конкретной задачи найдётся и более технически эффективный инструмент, но в целом если таких задач, с одной стороны, достаточно много, а, с другой, в целом они эпизодические и не очень критические, "написали и забыли", то выбирать каждый раз технологию и осваивать её или держать специалиста (а лучше двух для резервирования) по какой-то экзотической технологии, получается экономически менее эффективно, чем использовать в качестве основы язык, который и так в той или иной степени знает каждый разработчик в команде, и развертывание очередного сервиса на котором под силу администратору средней квалификации.
Технически хорошей альтернативой NodeJS для таких задач выглядят Python и Go, может Ruby, но если основной язык на проекте(ах) ни один из них, то с экономической точки зрения тратится на разработку придётся, скорее всего, больше, если будете искать бэкендеров со знанием, например, PHP и Python/Go/Ruby/… чем PHP и JavaScript.
0xd34df00d
18.01.2018 19:18Последний абзац, пожалуй, самое важное обоснование.
VolCh
18.01.2018 20:17Ну, собственно, главным критерием выбора инженерных решений всегда было (или должно было быть) технико-экономическое обоснование.
3axap4eHko
17.01.2018 17:29Почитайте мой первый комент, где я написал что троллинг удался, а дальше я просто продолжил этот троллинг поджигая задницы. Меня забавляют, что люди так остро реагируют на JS, что скорее всего это комплекс собственной неполноценности, потому что человек со здоровой самооценкой и критическим мышлением просто улыбнется.
0xd34df00d
17.01.2018 19:45Неа, это просто вопрос эстетики.
Есть, конечно, всякие профессионалы, которые решают задачи и получают за это деньги, и есть ещё всякие наркоманы вроде меня, которым почему-то важно немножко другое.3axap4eHko
17.01.2018 20:01Какой-такой эстетики? Это не исскуство где должно быть эстетично, здесь все измеримо в цифрах: качество кода, покрытие тестами, производительность, отказоустойчивость, масштабируемость, поддерживаемость, безопасность, скорость разработки. Все остальное — изотерический фен-шуй. Когда я вижу задачу которую я могу решить быстрее частично на ассемблере и частично на C# я ее решу именно так, а не буду пытаться сделать все на одном языке. Кто-то скажет что это суррогат — мне все равно, я качественно сделал задачу обеспечив выше перечисленные пункты. Если я вижу, что достаточно одного языка и решение будет универсальное, например веб приложение, с универсальным кодом как на сервере так и на клиенте, то я сделаю это так. И "немножечко другое" — это шелуха которую создают те кто ничего не может но хочет из себя что-то представлять.
0xd34df00d
17.01.2018 20:20Это не исскуство где должно быть эстетично
Это тоже зависит от задач-то, на самом деле.
здесь все измеримо в цифрах: качество кода, покрытие тестами, производительность, отказоустойчивость, масштабируемость, поддерживаемость, безопасность, скорость разработки.
Измерьте для начала в цифрах, пожалуйста, качество кода, поддерживаемость и безопасность. Ну вот прямо чтобы точно, алгоритмично, я вам на вход код, а вы мне алгоритм прогоняете и оценку на выход даёте.
И «немножечко другое» — это шелуха которую создают те кто ничего не может но хочет из себя что-то представлять.
Вы абсолютно правы. Я ничего не могу, но хочу из себя что-то представлять. И ещё, как вы ниже писали, очень опасаюсь за свой карьерный рост, куда мне, действительно, с плюсами, хаскелем и прочим идрисом, когда джаваскрипт шагает по планете.3axap4eHko
17.01.2018 20:37Это тоже зависит от задач-то, на самом деле.
Напишите мне эстетическую сортировку на любом известном вам языке
Измерьте для начала в цифрах...
Гугл в помощь. Даже на хабре можно найти ни одну статью об этом.
Вы абсолютно правы...
Я не сказал, что Вы создаете эту шелуху, но я вижу что Вы ее подбираете и распространяете, обожествляя и сакрализируя процесс в котором нет ни божественного ни сакрального.
И ещё, как вы ниже писали...
А еще я писал: "JavaScript такой же язык как и остальные, со своей областью применения" и это как-то вы проспустили. Если JS является частью Вашей профессиональной сферы, то да, Вы теряете, а если JS таковым не является, то что Вы делаете в этом посте?)
0xd34df00d
17.01.2018 21:19Напишите мне эстетическую сортировку на любом известном вам языке
Давайте я вам лучше power set напишу?
powerset = filterM $ const [True, False]
Во, написал. Ленивое, причём, и эстетичное, если шляпу алгебраиста примерять. И даже работает:
> powerset [0..3] [[0,1,2,3],[0,1,2],[0,1,3],[0,1],[0,2,3],[0,2],[0,3],[0],[1,2,3],[1,2],[1,3],[1],[2,3],[2],[3],[]]
Хотите всё-таки сортировку? Ну возьмите вот, почти как по учебнику (не совсем, ибо не in-place, но опустим это):
notqsort [] = [] notqsort (x:xs) = lessOrEq <> [x] <> greater where lessOrEq = notqsort [x' | x' <- xs, x' <= x] greater = notqsort [x' | x' <- xs, x' > x]
Эстетика, конечно, штука субъективная, и если вместо шляпы математика надеть шляпу хардкорного лоу-левел-программиста, то эстетичная сортировка будет уже немножко другой.
Но речь-то не только про код, но и про инструменты. Если у меня такой инструмент, что после рефакторинга и устранения ругани тайпчекера код просто работает, и все тесты (которые, надо сказать, проверяют скорее соответствие всей системы спеке, а не поведение отдельных функций) сразу зелёные — это хороший, приятный инструмент.
Если у меня такой инструмент, что я могу написать сигнатуру функции вроде
fmap : (a -> b) -> Vect n a -> Vect n b
и потом в четыре нажатия (generate definition, case split, дважды obvious proof search) написать её реализацию — это тоже хороший инструмент.
Если, в конце концов, мой инструмент позволяет мне наваять нетривиальные вычисления во время компиляции с оптимизацией, сравнимой с ручным кодированием (ну как тут), либо подобие ORM-фреймворка на шаблонах без всякой рантайм-рефлексии (не накатал до сих пор статьи, увы), то это тоже приятный инструмент. Хотя, признаю, я тут уже немножко извращенец.
Гугл в помощь. Даже на хабре можно найти ни одну статью об этом.
Нагуглил, говорят, неизмеряемое это совсем дело ;)
Я не сказал, что Вы создаете эту шелуху, но я вижу что Вы ее подбираете и распространяете, обожествляя и сакрализируя процесс в котором нет ни божественного ни сакрального.
Да не, просто я начинал программировать не потому, что о, бабки, или не потому, что о боже, как я обожаю удовлетворять потребности заказчиков, а потому, что мне нравится программировать. И вот до сих пор, через 15 лет нравится. Оно божественное и сакральное лично вот для меня, потому что меня до сих пор с этого прёт и штырит.
А еще я писал: «JavaScript такой же язык как и остальные, со своей областью применения» и это как-то вы проспустили.
Не только не пропустил, но и прочитал чуть дальше: и эта область уже стала достаточно широка, что бы быть конкурентно способным языком. Ну и потом совсем дальше: Он уже давно не просто скрипт для сайтика и тот кто понял это сейчас, уже обгоняет тех, кто как упрямый баран пытается привести примеры, что на нем не написать драйвер и сидит на обочине карьерного роста и продолжает ныть. Чем не про меня?
а если JS таковым не является, то что Вы делаете в этом посте?)
Ну он же всех то ли обошёл, то ли превзошёл.3axap4eHko
17.01.2018 21:33В том то и дело, что эстетика — субъективна. Вот что я имел ввиду https://www.youtube.com/watch?v=_UG4owIhk4I.
Нагуглил, говорят, неизмеряемое это совсем дело ;)
Значит плохо гуглили, ведь сами сказали что есть утилиты которые помогают Вам. Статик тайп чекеры различные линтеры они вполне способны обнаруживать грязный код, уязвимости, антипаттерны и прочее.
Оно божественное и сакральное лично вот для меня
Это называется интимное, это слово давно опошлили но значение его намного шире. А обожествление — признак фанатизма, тут все туго и с фанатиками диалога не бывает.
Чем не про меня?
Ну значит я был о Вас лучшего мнения ;)
0xd34df00d
17.01.2018 21:51В том то и дело, что эстетика — субъективна.
Так изначально речь шла о том ведь, из-за чего у людей чего-то там подгорает. Вот у кого эстетика такая, что JS или некоторые из целевых применений в неё не очень вписываются, у того и подгорает.
Значит плохо гуглили, ведь сами сказали что есть утилиты которые помогают Вам.
Это не утилиты, это свойства языка. Это не прикрученная сбоку непонятно какая типизация, это строгий и формально доказанный подход, с учётом которого язык был изначально построен.
Статик тайп чекеры различные линтеры они вполне способны обнаруживать грязный код, уязвимости, антипаттерны и прочее.
Считать качество кода по количеству срабатываний линтера — очень неблагодарное дело, как по мне.
Удивлён, что вы цикломатическую сложность, скажем, не привели.
А обожествление — признак фанатизма, тут все туго и с фанатиками диалога не бывает.
Да, согласен, это не очень хороший термин.
Хотя, в конце концов всё сводится к вашей аксиоматике. А откуда вы аксиоматику берёте?
Ну значит я был о Вас лучшего мнения ;)
Ну я по другим поводам ною, правда, но ною же. Что там типизация так себе, например, и так далее.3axap4eHko
17.01.2018 23:18Удивлён, что вы цикломатическую сложность, скажем, не привели.
ну как же?
и прочее.
просто я еще и ленивый
А откуда вы аксиоматику берёте?
Толковый словарь ожигова и несложные выводы
Что там типизация так себе, например, и так далее.
Ну это фитча языка. Обычно на это жалуются парни из мира строгой типизация и специально для них Майкрософт создала кастрированный TypeScript якобы вырезав слабую типизацию. Тут просто нужно постигнуть дзен JS да и вообще поменять свое отношение к окружающему миру и принять его таким какой он есть.
0xd34df00d
18.01.2018 19:22Толковый словарь ожигова и несложные выводы
То определения, а не аксиоматика. Аксиоматика — то, что вы считаете не требующим дальнейших обоснований. Мир во всём мире, личное благосостояние, удовлетворение любопытства, мало ли.
И вот после того, как вы убедились, что аксиоматика ваша непротиворечива, особой логической нужды её менять может и не быть. Со стороны это вполне может казаться как фанатичная вера.
Тут просто нужно постигнуть дзен JS да и вообще поменять свое отношение к окружающему миру и принять его таким какой он есть.
Не могу, увы. Под защитой строгих и выразительных систем типов я чувствую себя хорошо, комфортно, в сухости и безопасности.
wert_lex
17.01.2018 23:50Ну, хаскель, конечно, всему голова.
Но этого всего счастья нет в более мейнстримовых ЯП ровно настолько, насколько этого нет и в JS.
Более того, ниша для языков со слабой типизацией довольно широка.
По своему опыту перехода от строго типизированных языков к слаботипизированым и обратно, смело могу сказать, что писать на слаботипизированных языках что-то не слишком большое — прикольно.
Дальше, конечно, начинается жесть. Но во-первых до дальше еще дожить надо, а во-вторых JS в этом плане весьма на коне, ибо к нему за день гвоздями прибивается TS и можно ехать дальше.
Разумеется, я не призываю пихать везде JS.
0xd34df00d
18.01.2018 19:26Но этого всего счастья нет в более мейнстримовых ЯП ровно настолько, насколько этого нет и в JS.
А это и неважно. Я на хаскеле могу и микросервис написать, и обычный сервис, и в БД сходить, и глубокую нейросетку обучить (почти охренительно изящно, кстати).
Конечно, вы мне скажете, что знатоков JS куда больше, чем знатоков ML-стайл-функциональщины. Будете абсолютно правы, тут JS точновсехобошёл.
Кстати, я тут открыл, что в С++20 с корутинами можно добиться этакой do-нотации, по крайней мере, для single-result-монад. Надо будет написать про это.
По своему опыту перехода от строго типизированных языков к слаботипизированым и обратно, смело могу сказать, что писать на слаботипизированных языках что-то не слишком большое — прикольно. Дальше, конечно, начинается жесть.
Мой опыт скорее даже поддержки чужих шелл- и питоноскриптов (а в питоне типизация строгая, пусть и динамическая) говорит, что жесть начинается от этак 50 строк и от недели жизни скрипта.wert_lex
18.01.2018 19:40А это и неважно
А вот зависит. Если сам по себе или просто очень крутая команда, то ради бога, хоть хаскель, хоть агда, хоть идрис.
Но при работе в средней команде (окей, по крайней мере из тех, которые мне когда-либо встречались в дикой природе), я бы трижды подумал прежде чем что-то подобное использовать.
Просто даже кто это потом поддерживать будет? Сколько сейчас на рынке свободных и действительно квалифицированных хаскель-разработчиков, чтобы их можно было нанять в обычный среднебюджетный проект?
0xd34df00d
18.01.2018 20:03Ну, я про это и написал во втором абзаце.
Другое дело, что, на мой субъективный взгляд, хаскель как-то отходит от концепции avoid popularity at all costs. В фейсбуке его для всякого используют (и не только для спам-фильтров), в гугле какие-то библиотеки публикуют, знаю пару мест, о которых вы бы никогда такое не подумали, но где есть пишущие фуллтайм на нём люди. Опять же, субъективно пять лет назад всё было совсем по-другому. И, опять же, субъективно у какого-нибудь там Rust популярности вокруг меня меньше.
Посмотрим, что там дальше будет.
VolCh
18.01.2018 15:08поддерживаемость
частично на ассемблере и частично на C# я ее решу именно так, а не буду пытаться сделать все на одном языкеИ какова будет поддерживаемость подобного решения? Сколько C# разработчиков хорошо знают ассемблер, и сколько ассемблировщиков хорошо знает C#?
3axap4eHko
18.01.2018 15:11Поддерживаемость, это не о том кто знает язык
VolCh
18.01.2018 16:42+1Поддерживаемость — это о том, сколько ресурсов будет отнимать поддержка. В том числе и о том, сколько специалистов достаточного уровня есть на рынке и сколько они стоят.
0xd34df00d
17.01.2018 04:08Но даже не зная одного языка можно сказать, что хейтинг это не тру вэй
А какой тру-вей-то?
TOLK
17.01.2018 06:42Мдаа…
Фанатизм это всегда плохо. Есть вот религиозный, который так глаза затмевает, что страдают все, даже «единоверцы».
Terras
17.01.2018 01:20Этапы развития любого языка:
Язык — > Хайп — > Его суют во все щели -> Люди осознают минусы языка — > Язык занимает свою нишу или умирает.
Практически все, что перечислил автор — есть во всех языках. Я на Python могу написать сайт, прилагу на комп, прилагу под телефон, игру, асинхронный чатик и прочее. Но практика показала, что ниша питона Веб, Биг-дата и тестирование. Также было со всеми другими языками.
- Как веб-морда — вопросов нет, отличное решение (да и выбора нет).
- Как асинхронный бекенд для чатиков и прочее — вполне (но уже есть альтернативы)
- Как кросс-десктоп — ну только для чего-то легкого пока. (и то только по причине того, что Microsoft целенаправленно давил Java на windows)
- Реакт-натив — остой полный, сделаешь апу, а потом твой саппорт будет вешаться от числа пользователей, у которых что-то отваливается — проверенно на бою.
evocatus
17.01.2018 10:24Проблема с созданием дектопных приложений на web-стэке в том, что, несмотря на всю свою визуальную красоту, по функциональности эти приложения сейчас на уровне, который обычные десктопные приложения имели ещё в 90-х.
VolCh
17.01.2018 10:40А сильно функциональность десктопных приложений поднялась за 20+ лет? Чего не хватает в функциональности десктопных приложений на веб-стэке по сравнению с современными? Если под веб-стэком понимать не просто обертку для браузера, а полноценный стэк типа Электрона, у которого и доступ к диску есть, и к сети не только в рамках http.
evocatus
17.01.2018 21:51Я не про доступ к диску говорю, а про возможности GUI. Сколькими способами можно прокрутить scrollbar в Windows? А в типовом приложении на Electron? А вот из таких мелочей состоит эргономичность и удобство.
asmrnv777
17.01.2018 01:48React Native
Ага, а на выходе получаем скайп, переписанный непонятно зачем на реакте, который умудряется тормозить и на iPhone X, и на десктопе с i7-7700K при банальном наборе текста.
Или апп Facebook, который весит больше, чем многие игры (250! метров против 29 у нативного ВК на iOS, к примеру).
Хороший фреймворк, и проги интересные.
FasSsko
17.01.2018 09:03Скажу немного за RN. Мы юзаем нэйтив + RN на 10+ проектах, а это по 2 приложения на проект (iOS, android), так вот крашей связанных с RN на iOS практически нет (до 10 в сутки), на android чуть больше, но там проблема в том, что продюсеры умудряются загрузить картинку 4k, или парочку таких, вот оно и падает, это всё в рамках одного проекта. И да, у нас активных юзеров полтора — два миллиона на проект(на iOS раза в полтора больше чем на android). Ну и по поводу размера, фэйсбук столько весит не из за RN, у них под капотом куча всяких скрытых фич. У нас android весит около 30mb, iOS около 70, сюда входит грид (видосы с автоплеем, Инстаграм посты, твитер посты, кастомные ячейки), селфи фильтры, реклама, кучу скринов на RN, да и вообще много всего. На нэйтиве у нас грид, камера, пару простых вьюх (не успели перевести на RN), ну и нэйтив общается с бэкендом по WS(по историческим причинам, наши js либы не поддерживают RN, пока что), всё остальное на RN. И за больше чем год использование данной технологии в продакшене, почти нет никаких нареканий, всё работает весьма быстро и стабильно и с каждым релизом RN становится всё лучше и лучше. Поэтому смело могу сказать, если у кого-то что-то не получается с RN или он падает постоянно, то очень большая вероятность что проблема не в RN, а в недостатке знаний или в кривых руках.
Whuthering
17.01.2018 12:51Это проблема большинства хэйтеров, на самом деле, что люди хэйтят какую-либо технологию, сами совершенно не разбираясь в этой технологии :)
asmrnv777
17.01.2018 15:01Технология может быть дико крутой для технаря, только вот когда оно лагает на околотоповом железе у конечного пользователя — вся эта крутость сводится на нет.
asmrnv777
17.01.2018 15:00Ну тут одно дело, когда у ноунейма типа меня всё лагает в RN, и совсем другое, когда у гигантов типа Facebook и MS, которые его, тащемта, и развивают в основном. Это как бы намекает, что с технологией что-то не то.
Да и проблема-то не конкретно в RN, а в самом подходе — не может код, который работает в WebView или даже генерится кодогенератором в «типа нативный» работать сравнимо с нативным из-за оверхеда, увы.Whuthering
17.01.2018 15:09Это как бы намекает, что с технологией что-то не то.
или все-таки с руками ноунейма, раз у других все работает?
не может код, который работает в WebView или даже генерится кодогенератором в «типа нативный» работать сравнимо с нативным из-за оверхеда
Почитайте, как современные JIT-движки (типа Ignition и Turbofan в V8) оптимизируют код при выполнении, там реально фантастические вещи творятся, и в некоторых случаях на определенных этапах код становится по сути дела не «типа нативным», а прямо-таки «нативным», и оверхед сводится почти к нулю.asmrnv777
17.01.2018 15:13или все-таки с руками ноунейма, раз у других все работает?
Акцент не на ноунейме, а на том, что даже у создателей фреймворка не получается нормально сделать на нём сложный апп. Я не знаю, с чем это связано, но факт остаётся фактом — что новый скайп, что апп фейсбука — простите, полное говно с точки зрения как производительности, так и юзабилити.
Neikist
17.01.2018 17:38Брр, скайп полный трэш. По моим ощущениям он разве что на флагманах работать нормально будет, и то не факт. Впрочем скайп для десятки — тоже тот еще трэш.
asmrnv777
17.01.2018 23:18Говорю ж, он на iPhone X лагает, а это один из самых мощных девайсов на рынке, если не самый мощный на данный момент (по крайней мере в AnTuTu самый мощный нынче iPhone 8 Plus, а десятка вроде чутка пошустрее даже) :)
И самое печальное, что и на макоси заставили на новый б-гмерзкий скайп перейти. Старый (ветка 7.*) был просто великолепен, но на нём теперь пропадают сообщения. Единственный плюс нового скайпа — тёмная тема, но она даже близко не перекрывает минусы :(
VolCh
17.01.2018 15:34или даже генерится кодогенератором в «типа нативный» работать сравнимо с нативным из-за оверхеда, увы
Ну, JVM и .Net, как я понимаю, на настоящий момент активно используют такую кодогенерацию, а не интерпретируют байт-код, как можно подумать при знакомстве с ними.
Да и вообще бытует мнение, что современные компиляторы промышленного уровня генерируют в среднем лучший целевой код, чем средний разработчик.
asmrnv777
17.01.2018 15:40Под нативным я имел в виду не «машинный» код, а нативный для платформы. То есть тот, что написан на «нативном» для платформы языке — Java/Kotlin для Android, ObjC/Swift для iOS. То есть подразумевающие вызов апишек напрямую через дефолтное SDK, плюс построение интерфейсов с использованием SDK-шных тулз.
0xd34df00d
17.01.2018 19:47Тут скорее не в нативности дело, а в типизации. Трудно слаботипизированный код эффективно компилировать.
KirEv
17.01.2018 04:25В результате, практически всё, что вы делаете сегодня в Интернете, обслуживается очень интерактивным, эстетически приятным и простым в использовании интерфейсом. И все это стало возможным только благодаря экосистеме Node.
Извините, уважаемый автор, но после этих слов — статью читать перестал.
Не люблю субъективных высказываний <вставьтечтохотите>-дрочеров.
есть нативный яваскрипт на котором возможно творить чудеса, а дальше пошло поехало от jquery до nodejs, и сюда же можно прилепить typescript, angularjs, angular и остальное… все производно от javascript, и нет прямой связи между node(nodejs) и angular, typescript, etc. поправьте если я не прав.
PS: ради интереса, с недавних пор, интересуюсь typescript и angular5, чисто спортивный интерес, занимаюсь последнее время исключительно бекэндом (php, go, nodejs), и удивляюсь, насколько круто и гениально придумали с angular…
… на счет «javascript превзошел всех» — не скажу, но низкий поклон людям, которые совершенствуют ИТ-мир, пусть на основе javascript, создавая удивительные решения, низкий поклон, правда.
PS2: и не нужно создавать статей с такими громкими и провоцирующими оглавлениями.
PS3: и самое больное… куча инструментов, за основу которых взят javscript — это не чистый нативный язык с его свойствами и синтаксисом, это лишь диалект языка, в нем еще нужно разобраться, а что-бы в чем-то разобраться — нужна практика и опыт… потому меня жутко бесят (простите за личное) резюме, в которых при 5 лет опыта разработки указывается кишка-список из: javascript, nodejs, coffeescript,typescript, etc, etc, etc,… читать устанешь… потом на сайт из ссылки портфолио зайдешь — и все нахер виснет и тормозит…
Простите, бомбонуло…
Понимаешь, автор, не яваскриптом единым, закручивая шуруп молотком — можно выстрелить себе в ногу.Slowz
17.01.2018 09:02-1Зря вы обращаетесь к автору публикации как к автору статьи. Это же перевод.
А по теме: JS — действительно имеет большой «ариал обитания», но это не значит, что он лучше других. JS не сможет потеснить R, Python, C++, [language-name] в тех областях в которых они используются. Он просто составляет им конкуренцию и позволяет веб-разработчикам разрабатывать что-то большее чем веб-страничку. Разве это так плохо?Slowz
17.01.2018 10:31Что-то жестковато отреагировали, и минус в карму кинули… Можно прояснить за что?)
VolCh
17.01.2018 10:53Может за то, что JS уже потеснил как минимум Python и C++, а также PHP и Ruby в части областей, где они используются.
Slowz
17.01.2018 11:10Python в DataScience? C++ в системном программировании, игроделе? PHP, Ruby все исчезли с рынка и их больше не существует? Однако…
VolCh
17.01.2018 12:04"Потеснил" и "вытеснили — разные слова. Я не считаю, что создание NodeJs создало новые рынки, но отрицать, что с его созданием JS проник на многие существующие рынки, в том числе и на рынок системной разработки, и в игродел, сложно. А значит он потеснил на них более ранних игроков.
Slowz
17.01.2018 12:14Я согласен с вами. Когда писал, что «JS не сможет потеснить» имел ввиду как раз «вытеснить». Да и в целом, с посылом, что JS есть везде и играет не последнюю роль.
0xd34df00d
17.01.2018 19:49В data science, кстати, вполне мог бы потеснить. Клей для scipy/numpy/TF из него тоже вполне неплохой мог бы получиться. Может, даже получше, чем из питона, всякую декларативщину на нём выражать, на мой субъективный и дилетантский в обоих языках взгляд, проще.
SirEdvin
17.01.2018 11:08-1У меня нет прав кидать что-то в карму, но могу попытаться вам ответить.
Я думаю, те разработчики, которым приходится выбирать языки основываясь на мнении не разработчиков, которые используют в основном hipe-driven подход могут объяснить в чем проблема. Грубо говоря, JS настолько плох и насколько ужасно развивается, что вокруг него почти каждая компания пытается навернуть фреймворков, что бы спрятать сам js глубоко-глубоко внутри и почти никогда его не видеть. И это не делает платформу проще или понятнее.
Whuthering
17.01.2018 12:58Грубо говоря, JS настолько плох и насколько ужасно развивается, что вокруг него почти каждая компания пытается навернуть фреймворков
Ужас-то какой! Как страшно жить разработчику ПО, ведь все известные и используемые языки настолько плохи и ужасно развиваются!
Java ужасно развивается, поэтому джависты и шага без своего Spring сделать не могут.
C++ редкостная мерзость — то-то когда заходит речь о кроссплатформенных приложениях, все сразу же вспоминают про Qt.
Python вообще на редкость плох — посмотрите, люди придумали для него Django, Flask, Tornado и много других вещей, лишь бы спрятать всю подноготную глубоко-глубоко и никогда ее не видеть.
Слово hype научитесь хотя бы правильно писать, прежде чем поливать всех какахами, а то вообще смешно как-то ваша борьба с хайпом звучит.SirEdvin
17.01.2018 13:02Давайте на счет три назовем вместе разницу между, например, Django и Angular2? Я думаю, вы уже поняли, что Angular2 не использует JS, вместо него он использует другой язык, который собирается в JS.
Подобная ситуация так же есть в Java, которая так же развивается очень медленно, поэтому появляются такие языки как Kotlin, scala, которые работают на той же платформе и имеют совместимость в java, но позволяют ей не пользоваться.Whuthering
17.01.2018 13:28«Другой язык» — это все-таки слишком громко сказано.
Если сравнивать TypeScript и современный JavaScript, то по сути дела
TS = JS + compile-time type checking
Большую часть всего остального из действительно значимых либо вещей добавили в том или ином виде в ES6, либо это «вещи в себе» необходимые для более комфортной работы с типами.SirEdvin
17.01.2018 14:40Ну, я очень мало с ним знаком, но из того, что вспомнил, есть еще приватные свойства класса.
Это в целом достаточно, что бы язык был все-таки другим.
KirEv
17.01.2018 14:59да, погарячился обращаясь к переводчику как к автору,
више не писал что это плохо, это лишь еще один инструмент…
… просто бесит, когда человек пишет, грубо говоря на одном языке, и обожествляет его лишь потому, что ничего друго не знает…
именно такое впечатление образовалось о авторе оригинальной статьи, по ссылке можно немного узнать про автора, он по большому счету ничем кроме производных javscript не занимается.
для новичков подобные статьи считаю вредными
3axap4eHko
17.01.2018 19:19+1JavaScript такой же язык как и остальные, со своей областью применения и эта область уже стала достаточно широка, что бы быть конкурентно способным языком. Он уже давно не просто скрипт для сайтика и тот кто понял это сейчас, уже обгоняет тех, кто как упрямый баран пытается привести примеры, что на нем не написать драйвер и сидит на обочине карьерного роста и продолжает ныть. Да, на нем не напишешь драйвер или ОС или прошивку потому что он высокоуровневый с очень сильной абстракцией над структурами данных. Поэтому многие кто пишут на JS даже не представляют как реализуются такие базовые структуры данных как стек, очередь, списки, кучи и т.д. или виды сортировок или поиск по графу. Но зачем им это??? Зачем повару знать, как выплавить из металла ложку или сковороду? У него своя сфера ответственности где он должен хорошо справляться. Хорошо ли справляется JS в своей сфере — ДА! Отличный скриптовый язык для написания простого веб-сервиса, веб-сайта или игры. Вы не согласны? Тогда Вас уже обгоняют!
VolCh
18.01.2018 16:37Насчёт прошивки или ОС я бы не был так однозначен. Некоторые встраиваемые девайсы с прошивками как минимум UI реализуют на базе веб-браузеров типа Хромиума с активным использованием JS как в самом браузере, так и на встроенном сервере. Ну и как минимум часть ОС пишут на JS хотя бы для экспериментов.
3axap4eHko
18.01.2018 17:39Пошивка и ОС обеспечивают аппаратное взаимодействие, другим языком они предоставляют абстракцию над машинными командами? Какие машинные команды вы можете написать на JS?
VolCh
18.01.2018 18:09-2Практически любые из nodejs, например. Вариант "в лоб": создаём файл с нужными командами в нужном формате и запускаем его через
child_process.exec(). В какой-то мере пишем ассемблер (вполне может быть со своим оригинальным синтаксисом) и сборщик на JS. Невозможно?
Для языка высокого уровня взаимодействие с железом это прежде всего вопрос наличия биндингов к соответствующим библиотекам, а с этим у JS проблем нет.
3axap4eHko
18.01.2018 19:44Вы ставите телегу в переди лошади. child_process.exec() вызывает функцию ОС. Байндинги предоставляют API для вызыва функций ОС. Node js запускается ОС
unsafePtr
Это потому что у нас не было выбора.
VolCh
Был (есть?) VBScript
VolCh
Кто-то не застал IE 3.0? :)
Revertis
Я в таких случаях сравниваю технологии с форматом mp3. Он отнюдь не самый лучший, но он есть везде. Но можно ли сказать, что он превзошёл всех? Нет.
dom1n1k
Если слово превзошел употреблять в значении опередил — почему нет?
wert_lex
Как это нельзя? Можно!
mp3 сейчас разве что на кофеварке не воспроизводится и уж точно поддерживается абсолютно любым плеером. На высоких битрейтах даёт вполне хороший звук. Что, как не высокая распространенность и поддержка всеми платформами, являет собой триумф для формата передачи/обмена музыкой?
То же с JS. Можно долго и упорно поливать ES3,5, но с ES6 и вверх это вполне приятный язык программирования, со своими заморочками, достаточно обширным набором батареек (npm, ага), который, после некоторой настройки сборочного пайплайна, почти на всём, где есть браузер.
Это не значит, что JS — единственно-правильный вариант из всего. Но потешный полки нынче вполне себе боеспособная армия.
poxvuibr
В оригинале — has already won. Не превзошёл всех, а победил. Переводчик, как это часто бывает, порет отсебятину, отсюда и сложности.
zapolnoch
У JS нет конкурентов потому что все, кто боролся с JS — сдохли. Java.applet, Flash, Silverlight, Dart, CoffeeScript…
Microsoft поняли закономерность и вместо того, чтобы бороться с JS, стали с ним дружить и развивать через расширение, а не замену. Поэтому TypeScript живет и развивается.
Shtucer
Dart-то от чего сдох-то? Вполне себе живой, вроде, и здоровой. Возможно, причина в том, что он не очень-то и стремился бороться с JS.
vlreshet
И сколько платформ его нативно поддерживают?)
VolCh
Три основных десктопно-серверных и как рантайм для ВМ, и как окружение разработки, и две основных мобильных как целевые для нативного кода.
Shtucer
Побольше, чем TypeScript.
dpischalka
Надо сказать, что Typescript стал так популярен благодаря Angular. Многие изучают его потому что «надо». Мне он нравится, но многим — нет.
fillpackart
Все реактёры, которых я знаю, используют ts. Так себе конечно выборка, но angular — далеко не единственная причина популярности typeScript
hudson
Но все-таки хайп поднял скорее всего именно Angular) А так — да, замечательный язык.
Gennadii_M
Я автоматизировал на js, а потом перешёл на typescript. Обратно уже не хочу ) Может, Angular дал старт популярности, но сейчас typescript популярен, потому что он хорош.
yorick_kiev_ua
TS, это, извините, попытка решить проблемы волков и овец путём «а давайте заметём js под коврик и сделаем вид, что у нас не js вовсе, а как будто бы „нормальный“ язык со строгой типизацией, compile-time проверками и прочим сахаром».
В техническом плане это не замена, конечно, но для пишущего код — вполне.
VolCh
Ну, при достаточной популярности typescript вполне можно ожидать оптимизаций в JS-движках, особенно с JIT под капотом под предположения, что, например, тип переменных и параметров функций не меняется. Даже без ts такие оптимизации имеют смысл, так что я очень удивлюсь, если они уже не сделаны не только в движках от MS и Google, но и других.
Free_ze
Сдохли они по своим причинам, JS к этому не имеет отношения.
phponelove
Неверно. Никаких конкурентов у него не было.
Они никогда не были нативными для броузера. Со всеми вытекающими.
Ему жс никогда не был конкурентом, как и жаве. Он так же никогда не был нативным, был дырявой проприетарщиной от левого вендора. И смерть его лишь на малую часть связана с жс.
Это вообще нонейм нечто.
Он никогда не был нативным, да и ничего нового особо не предлагал. И проблемы были с тем, что никто не хочет и не будет менять шило на мыло.
Это вообще непонятно как тут оказалось.
В конечном итоге мы имеем то, что жс — это историческая случайность, которая живёт( в том виде, в котором есть сейчас) лишь потому, что есть легаси и готовая поддержка в броузерах, вместе с десятком лет эволюции.
Просто мс не осилили создать альтернативу и пошел по пути наименьшего сопротивления, ведь построить целый язык поверх жс не просто. Вернее тот язык, который будет выгодно отличаться от жс. Но опять же — тут есть проблема — куда девать жс и легаси.
Да и ТС не является языком( если только формально). Это позволяет его интегрировать в существующую экосистему. В дарте с этим проблемы, ведь он уже язык чуть более, нежели чисто формально. Интеграция его с жс и его в жс — сложна.
Именно поэтому говорить о каких-то конкурентах не имеет смысла — ведь их попросту не может быть. Даже когда доделают wasm, то это мало что поменяет для не llvm-based языков. Ведь жс получил поддержку всех платформ на халяву, а другие должны будут её пилить руками. А это далеко не так просто, как в случае с TS, где «компилятор» — это на 90% copy и на 10% replace.
Поэтому TS хорош тем, что добавляет такую нужную вещь как типизацию, но — это тупик. И причины банальны. Типизация это хорошо тогда, когда язык имеет её мощную поддержку, а когда она отдельно от языка — она вызывает много боли, которой могло и не быть.
Если раскрыть тему, то типизация даёт фишки те, которые не даёт жс. Простой пример — перегрузка функций, которой в ТС попросту нет( а то, что ей называется — ею не является). Классы не типы, енамы не типы. Типы не умеют в данные( хотя вроде генерики из жавы( с которых ТС и пастили) этого не умеют то же). И таких примеров масса, и как только они появляются в языке — одним copy/replace не обойтись.
Без всего этого типизация выглядит как дыра, а не как нужность. Хотя она и даёт фишки — комплишн/статические проверки, но это меньшее из того, что могло бы быть.