Comments 224
Однако, JavaScript уже практически десятилетия находится рядом и никуда не уходит.
Это потому что у нас не было выбора.
Был (есть?) VBScript
Как это нельзя? Можно!
mp3 сейчас разве что на кофеварке не воспроизводится и уж точно поддерживается абсолютно любым плеером. На высоких битрейтах даёт вполне хороший звук. Что, как не высокая распространенность и поддержка всеми платформами, являет собой триумф для формата передачи/обмена музыкой?
То же с JS. Можно долго и упорно поливать ES3,5, но с ES6 и вверх это вполне приятный язык программирования, со своими заморочками, достаточно обширным набором батареек (npm, ага), который, после некоторой настройки сборочного пайплайна, почти на всём, где есть браузер.
Это не значит, что JS — единственно-правильный вариант из всего. Но потешный полки нынче вполне себе боеспособная армия.
Но можно ли сказать, что он превзошёл всех?
В оригинале — has already won. Не превзошёл всех, а победил. Переводчик, как это часто бывает, порет отсебятину, отсюда и сложности.
Microsoft поняли закономерность и вместо того, чтобы бороться с JS, стали с ним дружить и развивать через расширение, а не замену. Поэтому TypeScript живет и развивается.
Dart-то от чего сдох-то? Вполне себе живой, вроде, и здоровой. Возможно, причина в том, что он не очень-то и стремился бороться с JS.
В техническом плане это не замена, конечно, но для пишущего код — вполне.
Ну, при достаточной популярности typescript вполне можно ожидать оптимизаций в JS-движках, особенно с JIT под капотом под предположения, что, например, тип переменных и параметров функций не меняется. Даже без ts такие оптимизации имеют смысл, так что я очень удивлюсь, если они уже не сделаны не только в движках от MS и Google, но и других.
У JS нет конкурентов потому что все, кто боролся с JS — сдохли. Java.applet, Flash, Silverlight
Сдохли они по своим причинам, JS к этому не имеет отношения.
У JS нет конкурентов потому что все, кто боролся с JS — сдохли.
Неверно. Никаких конкурентов у него не было.
Java.applet
Они никогда не были нативными для броузера. Со всеми вытекающими.
Flash
Ему жс никогда не был конкурентом, как и жаве. Он так же никогда не был нативным, был дырявой проприетарщиной от левого вендора. И смерть его лишь на малую часть связана с жс.
Silverlight
Это вообще нонейм нечто.
Dart
Он никогда не был нативным, да и ничего нового особо не предлагал. И проблемы были с тем, что никто не хочет и не будет менять шило на мыло.
CoffeeScript
Это вообще непонятно как тут оказалось.
В конечном итоге мы имеем то, что жс — это историческая случайность, которая живёт( в том виде, в котором есть сейчас) лишь потому, что есть легаси и готовая поддержка в броузерах, вместе с десятком лет эволюции.
Microsoft поняли закономерность и вместо того, чтобы бороться с JS, стали с ним дружить и развивать через расширение, а не замену. Поэтому TypeScript живет и развивается.
Просто мс не осилили создать альтернативу и пошел по пути наименьшего сопротивления, ведь построить целый язык поверх жс не просто. Вернее тот язык, который будет выгодно отличаться от жс. Но опять же — тут есть проблема — куда девать жс и легаси.
Да и ТС не является языком( если только формально). Это позволяет его интегрировать в существующую экосистему. В дарте с этим проблемы, ведь он уже язык чуть более, нежели чисто формально. Интеграция его с жс и его в жс — сложна.
Именно поэтому говорить о каких-то конкурентах не имеет смысла — ведь их попросту не может быть. Даже когда доделают wasm, то это мало что поменяет для не llvm-based языков. Ведь жс получил поддержку всех платформ на халяву, а другие должны будут её пилить руками. А это далеко не так просто, как в случае с TS, где «компилятор» — это на 90% copy и на 10% replace.
Поэтому TS хорош тем, что добавляет такую нужную вещь как типизацию, но — это тупик. И причины банальны. Типизация это хорошо тогда, когда язык имеет её мощную поддержку, а когда она отдельно от языка — она вызывает много боли, которой могло и не быть.
Если раскрыть тему, то типизация даёт фишки те, которые не даёт жс. Простой пример — перегрузка функций, которой в ТС попросту нет( а то, что ей называется — ею не является). Классы не типы, енамы не типы. Типы не умеют в данные( хотя вроде генерики из жавы( с которых ТС и пастили) этого не умеют то же). И таких примеров масса, и как только они появляются в языке — одним copy/replace не обойтись.
Без всего этого типизация выглядит как дыра, а не как нужность. Хотя она и даёт фишки — комплишн/статические проверки, но это меньшее из того, что могло бы быть.
Никаких конкурентов у него не было.
Таки был минимум один. Когда IE победил в войне браузеров, в нём было два языка: JScript (диалект JavaScript) и VBScript (диалект VisualBasic), но MS как-то умудрилась не сделать последний стандартом де-факто. Скорее всего, благодаря большей приверженности к закрытости чем сейчас, благодаря самонадеянности.
Большинство игр все еще пишут на c++
Проект, перенесённый на другую машину при помощи git clone, почти наверняка не захочет собираться. А если вдобавок нужна кросс-компиляция? C++ обеспечит вам массу увлекательных квестов, когда проект, исходно собираемый в GCC, вдруг потребуется собрать под винду.
В XXI веке у такого языка просто нет шансов при наличии хоть какой-то альтернативы, ведь по нынешним временам любой проект просто обязан разворачиваться в два клика на любой платформе, и собираться под любой платформой для всех целевых платформ сразу.
В XXI веке у такого языка просто нет шансов при наличии хоть какой-то альтернативы
Ды есть D, Rust, Nim и тд. И сколько уже было «убийц С++» а воз и нынче там.
ведь по нынешним временам любой проект просто обязан разворачиваться в два клика на любой платформе, и собираться под любой платформой для всех целевых платформ сразу.
В случае С++ это полностью зависит от программиста, буст разворачивается практически везде, Qt.
А уж про игры и графику я вообще молчу, там С++ царствовать будет ещё очень и очень долго.
А уж про игры и графику я вообще молчу
Не путайте игры, графику и 3d Engines. Движки еще долго будут писать на C++, но их будут делать пять огромных мировых компаний и может быть еще сотня мелких неизвестных узкоспециализированнных движков. Больше половины игр пишут на Unity, где c#.
Не путайте игры, графику и 3d Engines
Я и не путаю, кроме игровых движков, есть 3D редакторы 2D редакторы рендеры и куча куча другого графического совта.
Больше половины игр пишут на Unity, где c#.
А можно ссылочку на статистику? А что насчёт Unreal?
3D редакторы 2D редакторы рендеры и куча куча другого графического совта.
И все это может быть написано хоть на питоне (при использовании ядра на с++)
А можно ссылочку на статистику? А что насчёт Unreal?
34% самых популярных игр разработаны на Unity
https://unity3d.com/ru/public-relations
Unreal не так популярен
И все это может быть написано хоть на питоне (при использовании ядра на с++)Отличное уточнение. Вы можете написать ось хоть на питоне (при использовании ядра на С++). Просто скриптовый язык нет смысла рассматривать, потому что скриптовым языком может быть любой язык, и заменить его так же не составит труда, важно именно ядро. Именно о нём и речь. (не видел ни одного рендера (типа Arnold, Prman) написанного с поддержкой скриптового языка)
34% самых популярных игр разработаны на Unity Unreal не так популярен
Ох уж эти маркетинговые ходы, хотя в области мобилок возможно и правда, но на PC и консолях можно пример нескольких громких игр написанных на Unity? Вот на Unreal я знаю и назвать могу довольно много, а вот на unity ни одно ААА тайтла не могу вспомнить.
Там в комментарии были следующие утверждения
Проект, перенесённый на другую машину при помощи git clone, почти наверняка не захочет собираться.
Это неправда?
C++ обеспечит вам массу увлекательных квестов, когда проект, исходно собираемый в GCC, вдруг потребуется собрать под винду.
Это неправда?
Скорее, не "если нормально", а "если хорошо, если разработчики уделяли внимание портируемости". "Нормально", увы, чаще всего обозначает "гарантированно работает в единственном целевом окружении".
и писать обертки над маргинальными си-интерфейсами, если вдруг хочется ООП и классов.
Видимо вы что-то не то используете boost, Qt вполне себе оопшные (из тех что я ещё использую Alembic, Maya, Ilm, tbb и куча других практически все oop и все мультиплатформенные) и гемора как-то нет.
IntelMKLА в чём с ним проблема? Просто я от интела использую Tbb и Embree ispc(не библиотека но всёже) и никогда с ними проблем не было что под виндой что под линем.
А вот что-то особенное всегда через жопу.У меня довольна узкая специализация, и практически всё особенное, но при этом практически все библиотеки ооп и собираются везде (Ну кроме USD, Pixar те ещё говнокодеры без слёз на их код не взглянешь).
А он, по-вашему, не становится лучше? В чём это заключается?
А сохраните-ка ваши данные в файл? Ну, не просто массив int, а что-нибудь посложнее, например, древовидную иерархию полиморфных классов.
При этом писать безопасный и выразительный код на нём становится всё проще с каждым новым стандартом.
Каждый новый стандарт превращает код с++ в месиво, которое уже никто не может понять. Единственное, что они сделали — это foreach. Посмотрите на монструозный синтаксис лямбд, неужели нельзя сделать вывод типов и стрелочные функции, которые компактны?
А сохраните-ка ваши данные в файл?Библиотек сериализации море.
Единственное, что они сделали — это foreach.Это далеко не единственное изменение, но как раз одно из бесполезных.
Посмотрите на монструозный синтаксис лямбд, неужели нельзя сделать вывод типов и стрелочные функции, которые компактны?То есть неявный захват переменных? По сути-то там лишнее — обязательные фигурные скобки и
return.Библиотек сериализации море.
В том то и дело, что мне еще нужно что-то подключать. Почему я не могу сделать это из коробки? Сериализация данных — это возможность, необходимое каждому приложению, если не всем. Но мы не можем взять и сделать это. Без бубна с синтаксическим разбором твоих исходников и генерации кода сериализации по ним… Разве это нормально вообще? Или вы знаете библиотеку, которая делает это хорошо и просто? Задайте себе вопрос, в чем проблема здесь: плохие библиотеки или язык без некоторых необходимых возможностей?
Это далеко не единственное изменение, но как раз одно из бесполезных.
одно из тех, которая реально упрощает кодирование. А не все остальные, которые только усложняют.
То есть неявный захват переменных? По сути-то там лишнее — обязательные фигурные скобки и return.
Да пофигу какой захват. Можно сделать несколько стрелок или какую-нибудь байду "&>" "=>".
В том то и дело, что мне еще нужно что-то подключать. Почему я не могу сделать это из коробки?Вполне в духе современного тренда с модуляризацией библиотек) *здесь было бы выгоднее говорить о том, что подключать библиотеки — геморрой, иначе это не было бы ощутимой проблемой*
Без бубна с синтаксическим разбором твоих исходников и генерации кода сериализации по ним…Но когда это окажется в языке, ведь компилятор будет работать точно так же.
Впрочем, возвращаясь к JS, у него те же самые проблемы (несъедобность без «бубна» с препроцессингом и целого особого тулчейна), только они не ограничиваются одной задачей, а вообще весь язык страдает. Но он тут «побеждает».
одно из тех, которая реально упрощает кодированиеНастолько же, насколько появление лямбд или все же просто прикольный современный синтаксис?
Но когда это окажется в языке, ведь компилятор будет работать точно так же.
Вот! он будет точно так же работать, как работает КОМПИЛЯТОР, а не как написали свой moc разработчики либы! И сериализация будет через нормальный стандартизированный рефлекшн, а не через это говно с выкрутасами вокруг #define
Впрочем, возвращаясь к JS, у него те же самые проблемы
JSON.stringify() что ли? Да это просто шах и мат любому c++, только за это я готов признать победу JS (для контекста: JS не знаю, только QML немного. на С++ программирую больше 15 лет).
Настолько же, насколько появление лямбд или все же просто прикольный современный синтаксис?
Лямбды в таком виде ничего не упрощают, а создают условия для нагромождения кода. foreach позволяет нормально итерировать любую коллецию единым, читаемым способом, а не вот эти вот begin(), end(). Это упрощает ежедневное кодирование, экономит время. Язык должен экономить время, а не создавать дополнительные проблемы.
Вот! он будет точно так же работать, как работает КОМПИЛЯТОР, а не как написали свой moc разработчики либы!В общем, вам важен авторитет писателя «говна». ОК.
JSON.stringify() что ли?Нет, я про препроцессинг и старые стандарты.
Лямбды в таком виде ничего не упрощают, а создают условия для нагромождения кода.Лямбды вам не нужны, а условие for вы настолько часто пишите каждый день, что это разительно экономит время. Яснопонятно… (=
В общем, вам важен авторитет писателя «говна». ОК.
Вы вообще, понимаете, о чем речь? Не о том, что писатели компиляторов лучше напишут, а о том, что комплируемый код и метаинформация(рефлекшн) будут 100% достоверными, ибо получены в рамках одного и того же процесса компляции кода. А писателем этого может быть хоть кто, лишь бы в стандарте C++ это было прописано правильно, а компилятор этому следовал.
Нет, я про препроцессинг и старые стандарты.
Да кого интересует этот JS? Он, как и flash, сегодня на коне, а завтра никому не нужен. Завтра придумают сайты писать на питоне(через WebASM), и будем все офигевать от новой реальности.
Лямбды вам не нужны, а условие for вы настолько часто пишите каждый день, что это разительно экономит время. Яснопонятно… (=
Не нужны. Вот в таком виде — точно. Проще передать указатель на функцию. Вот серьезно. Это хоть не так громоздко будет выглядеть. Т.е. вы for не каждый день пишите? Пишите ли вообще код?
Не о том, что писатели компиляторов лучше напишут, а о том, что комплируемый код и метаинформация(рефлекшн) будут 100% достоверными, ибо получены в рамках одного и того же процесса компляции кодаС чего вдруг? Или писатели компиляторов не бажут? Чем реализация в стандарте отличается от библиотечной реализации? (В плане переносимости) (Хотя я тоже безумно хочу поддержку рефлексии)
Не нужны. Вот в таком виде — точно. Проще передать указатель на функцию. Вот серьезно. Это хоть не так громоздко будет выглядеть.
Правда? Если конечно вам ненужны замыкания то возможно и правда, но я лично использую лямбды с замыканиями в 90% случаев, а писать многопоточный код с лямбдами стало вообще крайне приятно. Как и работать с сигнал слотами, и колбэками.
С чего вдруг? Или писатели компиляторов не бажут? Чем реализация в стандарте отличается от библиотечной реализации? (В плане переносимости) (Хотя я тоже безумно хочу поддержку рефлексии)
И сколько багов вы нашли в компиляторах? Хотя не спорю, в новых фичах C++ я сталкивался. Но речь не об этом. А об языке и поддержки чего-то из коробки, а не за счет говна и палок (как в QT, например)
Правда? Если конечно вам ненужны замыкания то возможно и правда, но я лично использую лямбды с замыканиями в 90% случаев, а писать многопоточный код с лямбдами стало вообще крайне приятно. Как и работать с сигнал слотами, и колбэками.
Ну т.е. без лямбд и замыканий вы это можете реализовать?
И сколько багов вы нашли в компиляторах?Ну это можно сказать моё хобби, но немного.
А об языке и поддержки чего-то из коробки, а не за счет говна и палок
Тут я соглашусь, всё таки рефлексии и правда очень не хватает.
Ну т.е. без лямбд и замыканий вы это можете реализовать?Естественно, но с лямбдами это стало во много раз проще. По моему мнению лямбды гораздо более полезная фича чем форычь, хоть и используется реже, просто потому что размер кода очень сильно сокращается и уменьшается разрыв контекста, код и читать и писать гораздо проще.
Можно и без этого бубна, но с некоторыми пасами руками
Плавали, знаем, какие там пассы. Либо жуткая шаблонная магия, либо #define. В любом случае, чтобы подготовить класс для сериализации, придется некоторым образом все регистрировать.
Добавят, кстати, в какой-нибудь C++20 компилтайм-рефлексию, а в С++23 — метаклассы, можно будет и без этих пасов.
Несвоевременность — вечная драма. Будет поздно, все это нужно было сделать 10 лет назад. А к 30 году, когда все компиляторы будут это поддерживать, на с++ останутся сидеть старпёров (может быть даже я буду среди них) .
Потому что не все способны их понять, многие просто отстают в развитии. Когда-то Галилея вообще сжечь хотели за вполне здравую мысль.
Насколько я знаю, в Юнити большинство разработчиков используют C#.
.Net core и c# + Xamarin + AvaloniaUI
Однако, JavaScript уже практически десятилетия находится рядом и никуда не уходит. Итак, уместно будет задать такой вопрос: «В каком же направлении он движется?» Однако, этот пост не совсем о «JavaScript». Также, он не касается того множества языков, которые были до него. И здесь не говорится о том, какой JavaScript замечательный.
Куда же ушли Java, C#, Python, Perl, Lua и еще куча языков? Тут вот все еще спорят, жив ли Delphi, а вас удивляет что JavaScript, который занял себе очень удобную нишу все еще с нами.
Алсо, сразу видно, что автор знает только javascript. Например, на Java, Python и C# можно делать все перечисленные вещи. Да, и фронтенд тоже. Есть TeaVM, Python.JS или Bridge.Net для этого. Вопрос только в полезности, применимости и так далее.
Реальная движущая сила JavaScript — это браузеры и фронт-енд разработчики, которым тесно в рамках браузеров. Завезут webASM и возможность использовать разные языки в браузерах и через год-второй очень много компаний и людей забудет про javascript. И давайте не будем без аргументов в духе "ну, если бы язык не был плохим, никто бы с ним не работал", у вас гигантское количество разработчиков на рынке умеет работать в основном только с этим языком, отрицать то, что этот фактор имеет сильное влияние на популярность javascript очень глупо.
Не говоря уже о том, что значительное число декстоп и мобильных приложений на javascript откровенно работают так себе. То есть их можно оптимизировать, но никто этим особо не парится, как я понимаю.
Ну и да:
Хотя… не совсем. Здесь не будет описываться миллион причин, по которым эта экосистема является самым инновационным посредником в области взаимодействия с открытым исходным кодом, которую когда-либо видел мир.
Есть хотя бы одна? Что такого инновационного сделали?
WebASM уже завезли, и теперь можно делать сайты без JS. Наконец-то!
Я не знаю, когда это закончится, но Node убирает одну преграду за другой
Есть предположение, что закончится это когда браузеры в полном объеме научатся работать с чем-то кроме JavaScript (WebAssembly или что-то еще). Дальше начнется замедление развития или стагнация, но это только мое мнение
Не Electron-приложения, а Slack, не нужно обобщать.
Тот же VSCode жрет не больше других программ.
Тот же VSCode жрет не больше других программ.
VSCode при одинаковых условиях спамит процессами (как и весь софт на electron) и жрет больше, чем полноценная студия с решарпером и парой менее громоздких плагинов.
Я отвечал на комментарий
Electron приложения жрут по 500мб, в то время как нативные кушают раз в 10 меньше
На вашем скриншоте в сумме получается около 400Мб, (меньше 500). Во-вторых это всего на четверть больше, но никак не в 10 раз.
Так что своим комментарием вы так же подтвердили, что все не так плохо, как некоторые любят говорить.
Так что своим комментарием вы так же подтвердили, что все не так плохо, как некоторые любят говорить.
Если бы VSCode имел все функции полноценной студии я бы с вами согласился, но тут получается такая ситуация что софтина, которая по встроенной функциональности не сильно далеко ушла от notepad++ жрет как полноценная IDE. Это при том что notepad++ ест 12 мегабайт памяти.
Discord на электроне, к примеру, имеет целую кучу фич — и потребляет на моей машине ~110мб озу. Telegram, к примеру, расходует 75мб. Dropbox (питон) — примерно 100мб.
Думаю, всё сильно зависит от того, какие проблемы решает приложение. Многие программы занимают много озу даже с учётом того, что они написаны на других языках. И весь этот гон в сторону node.js хоть отчасти и оправдан, но для десктопа использование большого кол-ва озу — дело в целом самое обыкновенное.
Как ни крути, а electron все же память жрет как не в себя — 3 из 5 топовых процессов у меня вот. А что касается дискорда, то там еще прошлой осенью были просто адовые утечки когда он мог по 4-5гб памяти съедать.
Далее нужно хранить другие данные для быстрого перерендерига части, которой нет в кэше. Сколько это займёт — не знаю. Зависит от размера и сложности страницы.
Далее, элементы HTML. Не знаю, сколько памяти занимает элемент, но меньше 200 байт на 64-битке мне представить сложно. Теперь представьте простую табличку или что-то на неё похожее строк на 500. Столбцов штук 5. Но элементов в строке будет не менее 15. Уже 7500 элементов, которые в самом простом случае займут 1.5+ МБ (сколько в реальности — не знаю). И это была самая простая страница, без картинок, без кэширования приложения или ещё чего-то интересного.
А с javascript в целом всё не так сложно. Рассчитывайте размер struct как количество элементов * 8 байт (или 4 байта на 32-битке). Аналогично и с переменными. В итоге сколько памяти поюзаете, столько и будет затрачено. Исключение составляют только:
1. Хэши. Их поля занимают очень много (до 100 байт на 64-битке). Но раз мы их юзаем, значит они нам нужны?
2. Созданные объекты: объекты, массивы, строки. Добавят оверхэд 30-70 байт (на 32-битке в 2 раза меньше).
Но конечно всё-таки нюансы есть: 8 байт, когда переменная могла занимать 2 — не очень круто. Если вам это важно, юзайте 32-битные версии — там все переменные и поля классов занимают 4 байта, но и это больше, чем могло бы быть.
Другой нюанс — размер бинарника. Ведь запуская javascript мы одновременно тянем библиотеку из много всего, а также движок javascript. Это как когда вы пишете программу из пары строчек, но из-за подключений библиотек файл раздувается до огромных размеров. И всё это должно быть в памяти. Точно не знаю, сколько, но, возможно, 30 МБ на процесс, из которых порядка половины шарится, если запустить несколько процессов.
Ну и третий нюанс — сборка мусора. Предполагает, что в каждый момент времени часть данных будет не собрана, а значит приложение всегда будет занимать больше памяти, чем использует.
В общем если уж и предъявлять претензии к javascript, то лучше к скорости, а не к памяти. Да, всё оптимизируется, но работает всё-равно дольше.
В Unity 3D никогда не было JS. UnityScript это в самом лучшем случае исковерканный диалект ECMAScript, как, скажем, ActionScript. Был во Flash JS? Нет, конечно.
Это была маркетинговая попытка привлечь внимание. Да и никто и не писал на UnityScript.
Перевод забавный, "превзошел десктопы". "Превзойти" в значении "овладеть" не употребляется уже, наверное, лет сто.
После большого опыта построения интерфейсов под Android и небольшого под iOS, в JavaFX без ста грамм разобраться не мог. Да и вообще до конца так и не смог разобраться, как там сделать более-менее сложный UI без костылей и велосипедов. Я не утверждаю, что его сделать нельзя, просто доки почти никакие, инфы в этих наших интернетах мизер, и работает оно (с точки зрения Android-разработчика) через зад. Почему нельзя было подсмотреть, «как надо» в других платформах, и перепилить fx — не ясно.
Qt, нормальная лицензия которого начинается от 4к$.
И зачем эта самая лицензия за 4k нужна?
Qt, нормальная лицензия которого начинается от 4к$
А чем ненормальна бесплатная LGPL? До тех пор, пока ваше приложение просто использует Qt как библиотеку, вы не обязаны раскрывать никаких своих исходников.
Статья очень однобокая. Что, ничего кроме «божественной ноды», больше не позволяет лепить кросс-платформенные мобильные приложения? Ложь. Игры? Вообще смешно, вы настоящие ААА-класса игры видели? Да и то, что из Unity наконец-то выпиливают JavaScript, уже о многом говорит.
Да, и electron для меня — синоним неповоротливого, жрущего ресурсы как не в себя, приложения.
Так и тянет сказать: So what?
Один пацан писал все на JavaScript, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно.
Я так понимаю троллинг удался ибо все у кого подгорают религиозным огнем ягодицы достали свои минусаторы (у кого они есть конечно), а у кого нет просто пишут гадкие комменты (опять же кто может). Что в том что JS лучше? У любого другого языка была возможность стать лучше, но не вышло. Что за мода такая хейтить успех? Я всегда думал, что IT сообщество выше этого, но видимо IT сообщество уже с гнильцой, как показывает практика. Надменные, самовлюбленные, брезжащие над своими технологиями люди, которые забыли куда мы должны двигаться.
Думаю пора покинуть это сообщество, после того как напишу прощальный пост.
Да каждый язык десять пунктов форы даст JS-у, все зависит от того, где и как их использовать. То прям панацея — JS есть и больше ничего не надо. Да, язык мощный, но кроме веба существует куча сфер и софта, где используются другие языки, и JS там ну вообще не взлетит.
Например?
ну бред, погуглите даже Photoshop использует nodejs
Сабж даже после всех последних изменений бла-бла-бла...
Какая к чертям монополия? Кто монополист здесь? Язык? Владелец языка кто? Это не C# microsoft и не swift Apple.
IT-сообщество видит бла-бла-бла…
бла-бла-бла… больше, чем один скриптовый язычек?
Не считаю себя js хипстером и знаю достаточно языков, что бы видеть общую картину. Но даже не зная одного языка можно сказать, что хейтинг это не тру вэй
Не задерживайтесь.
Да, да я о таких как Вы писал. Надменные, самовлюбленные, брезжащие над своими технологиями люди. С одной стороны Вас жалко, а с другой так вам и надо. Я смотрю вас уже подтолкнули прям напихали можно сказать =)
А что, JS не используется нигде, кроме фронтенда? Кроме JS не существует языков разработки server-side для web? Кроме JS не существует языков разработки под мобильные платформы? Кроме JS не на чем писать под десктоп? Да, действительно монополия, а мужики-то не знали…
Это похоже уже на совсем толстый троллинг. Сколько у нас там фронтенд разработчиков? 30% или больше? Движение идет из фронтенда во всем сферы же. Не было бы монополии JS на браузерах, такое бы вряд ли произошло.
Хорошо, если вы такой профессионал, подскажите, почему я должен писать свой веб-сервис, скажем на node.js, а не на python? Для более конкретного разговора, например, это прокси-сервис, который часть запросов заворачивает, а данные из них пишет себе в бд. Вот что такого есть в node.js от чего мне имеет смысл учить новый язык и чего я не могу найти на python? Проблемы с однопоточностью и асинхронность в python есть, причем изначально на async-похожем синтаксисе еще с python 2.6, если не раньше. Я думаю вы столкнетесь с тем, что каждый плюс node.js будет перекрываться другим плюсом из python и выбор нужно будет делать исключительно из того, что больше нравится, потому что это все-таки языки общего назначения.
Мне кажется, что большое количество людей, не смотря на то, какие они профессионалы делает выбор на хайпе и информации, которая с ним прилетела, потому что очень много людей не знают возможности своей платформы. Как пара очень странных адептом node.js, которые утверждали, что node.js прорывная, потому что там есть асинхронность.
Как минимум, ещё выбор будет делаться по степени знания языка и всего стэка. Примитивное решение вашей задачи (допустим асинхронность в ней имеющееся требование, равно как и отсутствие требования в конкретном окружении типа windows) я на node.js напишу до вечера (это не мой основной стэк, но изучать надо будет конкретную часть экосистемы, а не язык и общепринятые практики разработки серверных приложений), на python практически наверняка дольше, скажем пускай три дня, включая восстановление в памяти базового синтаксиса языка, поиска стандартных или не очень библиотек/фреймворков с хорошей поддержкой асинхронного io (слово flask в голове крутится, но не уверен, что єто то, что надо), поиск и изучение лучших практик для них и python вообще и т. п. И оценка "три дня" базируется лишь, лишь на "хайпе" вокруг питон и информации, которая с ним прилетела — наверняка есть библиотеки/фреймворки, в которых большинство нужной функциональности красиво обёрнута и мне нужно будет лишь правильно её скомпоновать, и наверняка мне не придётся вспоминать C, чтобы написать биндинг к функциям ядра Linux и библиотеки СУБД. Просто по ощущениям, интуитивно. А в случае NodeJS я знаю, что production-ready библиотеки для создания веб-сервера, для отправки веб-запросов на другие сервера и для записи в популярные СУБД уже точно есть, как минимум в одном экземпляре. Знаю, а не надеюсь, как в случае python.
Ну, поэтому я и написал:
Вот что такого есть в node.js от чего мне имеет смысл учить новый язык и чего я не могу найти на python?
Понятное дело, что можно склонятся к знакомому инструменту.
На основе хайпа могу предположить, что nodejs сервер будет работать быстрее в общем случае, чем реализация на референсном python :)
Насколько я понимаю, эти графики как раз показывают, что "из коробки" nodejs в общем быстрее python на подобных задачах. Чтобы обойти nodejs потребовалось подключать бинарные библиотеки как раз из экосистемы nodejs и писать для них биндинги.
Такие подходы на продакшене обычно говорят либо о хорошем знании экосистемы python "под капотом", либо о малой ответственности. Лично я бы рискнул использовать такой путь только для PHP, как наиболее известной мне платформе, причём с неделей минимум на нефункциональное тестирование.
Там есть колоночка с asyncio, который нативный для python и можно увидеть, что отстает он не значительно и разрыв уменьшается с ростом размера запроса. Очень сомневаюсь, что эта разница стоит того, что бы начать внезапно учить JS, лучше уже попробовать uvloop)
А потом подключается libuv, и магическим образом скорость вырасает от 2 до 4 раз. Как по мне это дополнительно еще неплохо говорит о скорости работы самих языков.
Так же стоит заметить, что первые графики относятся к tcp серверу. В случае http сервера, nodejs даже от нативного asycnio отстает.
Стоит заметить, что они использовали библиотеку, которая используется для парсинга http в nodejs. Они не предлагают ее использовать, так как их binding еще не production ready, но получается, если подключить хотя бы один элемент nodejs инфрастуктуры (а они написаны на C), то python оказывается далеко впереди.
Сомневаюсь, что в более сложных случаях nodejs будет выиграть даже у чисто python, так как можно предположить, что большая часть времени теряется где-то в js движке. Разумеется, если делать правильный выбор надо еще это все перепроверять самому, но так это просто интересное замечание.
Если предстоит учить либо JS, либо Python, то разница может оказаться решающей даже в случае tcp-сервера :)
А насчёт http — как я понимаю колонка asyncio aiohttp и есть нативный (пускай и не "из коробки") способ написания асинхронных http-серверов. И даже если язык быстрее, то экосистема оказывается заметным узким местом.
Серверный JavaScript хорошо справляется с задачами маршрутизации, агрегирования, шлюзования и т. п. сообщений с частыми изменениями маршрутов и схем. Ну, например, трансляция сообщений amqp в сообщения websocket и обратно. Или шлюз, с серверной стороны предоставляющий graphql API, и являющийся клиентом нескольких HTTP RESTish сервисов. Наверное, для каждой конкретной задачи найдётся и более технически эффективный инструмент, но в целом если таких задач, с одной стороны, достаточно много, а, с другой, в целом они эпизодические и не очень критические, "написали и забыли", то выбирать каждый раз технологию и осваивать её или держать специалиста (а лучше двух для резервирования) по какой-то экзотической технологии, получается экономически менее эффективно, чем использовать в качестве основы язык, который и так в той или иной степени знает каждый разработчик в команде, и развертывание очередного сервиса на котором под силу администратору средней квалификации.
Технически хорошей альтернативой NodeJS для таких задач выглядят Python и Go, может Ruby, но если основной язык на проекте(ах) ни один из них, то с экономической точки зрения тратится на разработку придётся, скорее всего, больше, если будете искать бэкендеров со знанием, например, PHP и Python/Go/Ruby/… чем PHP и JavaScript.
Почитайте мой первый комент, где я написал что троллинг удался, а дальше я просто продолжил этот троллинг поджигая задницы. Меня забавляют, что люди так остро реагируют на JS, что скорее всего это комплекс собственной неполноценности, потому что человек со здоровой самооценкой и критическим мышлением просто улыбнется.
Какой-такой эстетики? Это не исскуство где должно быть эстетично, здесь все измеримо в цифрах: качество кода, покрытие тестами, производительность, отказоустойчивость, масштабируемость, поддерживаемость, безопасность, скорость разработки. Все остальное — изотерический фен-шуй. Когда я вижу задачу которую я могу решить быстрее частично на ассемблере и частично на C# я ее решу именно так, а не буду пытаться сделать все на одном языке. Кто-то скажет что это суррогат — мне все равно, я качественно сделал задачу обеспечив выше перечисленные пункты. Если я вижу, что достаточно одного языка и решение будет универсальное, например веб приложение, с универсальным кодом как на сервере так и на клиенте, то я сделаю это так. И "немножечко другое" — это шелуха которую создают те кто ничего не может но хочет из себя что-то представлять.
Это тоже зависит от задач-то, на самом деле.
Напишите мне эстетическую сортировку на любом известном вам языке
Измерьте для начала в цифрах...
Гугл в помощь. Даже на хабре можно найти ни одну статью об этом.
Вы абсолютно правы...
Я не сказал, что Вы создаете эту шелуху, но я вижу что Вы ее подбираете и распространяете, обожествляя и сакрализируя процесс в котором нет ни божественного ни сакрального.
И ещё, как вы ниже писали...
А еще я писал: "JavaScript такой же язык как и остальные, со своей областью применения" и это как-то вы проспустили. Если JS является частью Вашей профессиональной сферы, то да, Вы теряете, а если JS таковым не является, то что Вы делаете в этом посте?)
В том то и дело, что эстетика — субъективна. Вот что я имел ввиду https://www.youtube.com/watch?v=_UG4owIhk4I.
Нагуглил, говорят, неизмеряемое это совсем дело ;)
Значит плохо гуглили, ведь сами сказали что есть утилиты которые помогают Вам. Статик тайп чекеры различные линтеры они вполне способны обнаруживать грязный код, уязвимости, антипаттерны и прочее.
Оно божественное и сакральное лично вот для меня
Это называется интимное, это слово давно опошлили но значение его намного шире. А обожествление — признак фанатизма, тут все туго и с фанатиками диалога не бывает.
Чем не про меня?
Ну значит я был о Вас лучшего мнения ;)
Удивлён, что вы цикломатическую сложность, скажем, не привели.
ну как же?
и прочее.
просто я еще и ленивый
А откуда вы аксиоматику берёте?
Толковый словарь ожигова и несложные выводы
Что там типизация так себе, например, и так далее.
Ну это фитча языка. Обычно на это жалуются парни из мира строгой типизация и специально для них Майкрософт создала кастрированный TypeScript якобы вырезав слабую типизацию. Тут просто нужно постигнуть дзен JS да и вообще поменять свое отношение к окружающему миру и принять его таким какой он есть.
Ну, хаскель, конечно, всему голова.
Но этого всего счастья нет в более мейнстримовых ЯП ровно настолько, насколько этого нет и в JS.
Более того, ниша для языков со слабой типизацией довольно широка.
По своему опыту перехода от строго типизированных языков к слаботипизированым и обратно, смело могу сказать, что писать на слаботипизированных языках что-то не слишком большое — прикольно.
Дальше, конечно, начинается жесть. Но во-первых до дальше еще дожить надо, а во-вторых JS в этом плане весьма на коне, ибо к нему за день гвоздями прибивается TS и можно ехать дальше.
Разумеется, я не призываю пихать везде JS.
А это и неважно
А вот зависит. Если сам по себе или просто очень крутая команда, то ради бога, хоть хаскель, хоть агда, хоть идрис.
Но при работе в средней команде (окей, по крайней мере из тех, которые мне когда-либо встречались в дикой природе), я бы трижды подумал прежде чем что-то подобное использовать.
Просто даже кто это потом поддерживать будет? Сколько сейчас на рынке свободных и действительно квалифицированных хаскель-разработчиков, чтобы их можно было нанять в обычный среднебюджетный проект?
поддерживаемость
частично на ассемблере и частично на C# я ее решу именно так, а не буду пытаться сделать все на одном языке
И какова будет поддерживаемость подобного решения? Сколько C# разработчиков хорошо знают ассемблер, и сколько ассемблировщиков хорошо знает C#?
Фанатизм это всегда плохо. Есть вот религиозный, который так глаза затмевает, что страдают все, даже «единоверцы».
Язык — > Хайп — > Его суют во все щели -> Люди осознают минусы языка — > Язык занимает свою нишу или умирает.
Практически все, что перечислил автор — есть во всех языках. Я на Python могу написать сайт, прилагу на комп, прилагу под телефон, игру, асинхронный чатик и прочее. Но практика показала, что ниша питона Веб, Биг-дата и тестирование. Также было со всеми другими языками.
- Как веб-морда — вопросов нет, отличное решение (да и выбора нет).
- Как асинхронный бекенд для чатиков и прочее — вполне (но уже есть альтернативы)
- Как кросс-десктоп — ну только для чего-то легкого пока. (и то только по причине того, что Microsoft целенаправленно давил Java на windows)
- Реакт-натив — остой полный, сделаешь апу, а потом твой саппорт будет вешаться от числа пользователей, у которых что-то отваливается — проверенно на бою.
А сильно функциональность десктопных приложений поднялась за 20+ лет? Чего не хватает в функциональности десктопных приложений на веб-стэке по сравнению с современными? Если под веб-стэком понимать не просто обертку для браузера, а полноценный стэк типа Электрона, у которого и доступ к диску есть, и к сети не только в рамках http.
React Native
Ага, а на выходе получаем скайп, переписанный непонятно зачем на реакте, который умудряется тормозить и на iPhone X, и на десктопе с i7-7700K при банальном наборе текста.
Или апп Facebook, который весит больше, чем многие игры (250! метров против 29 у нативного ВК на iOS, к примеру).
Хороший фреймворк, и проги интересные.
Да и проблема-то не конкретно в RN, а в самом подходе — не может код, который работает в WebView или даже генерится кодогенератором в «типа нативный» работать сравнимо с нативным из-за оверхеда, увы.
или все-таки с руками ноунейма, раз у других все работает?
Акцент не на ноунейме, а на том, что даже у создателей фреймворка не получается нормально сделать на нём сложный апп. Я не знаю, с чем это связано, но факт остаётся фактом — что новый скайп, что апп фейсбука — простите, полное говно с точки зрения как производительности, так и юзабилити.
И самое печальное, что и на макоси заставили на новый б-гмерзкий скайп перейти. Старый (ветка 7.*) был просто великолепен, но на нём теперь пропадают сообщения. Единственный плюс нового скайпа — тёмная тема, но она даже близко не перекрывает минусы :(
или даже генерится кодогенератором в «типа нативный» работать сравнимо с нативным из-за оверхеда, увы
Ну, JVM и .Net, как я понимаю, на настоящий момент активно используют такую кодогенерацию, а не интерпретируют байт-код, как можно подумать при знакомстве с ними.
Да и вообще бытует мнение, что современные компиляторы промышленного уровня генерируют в среднем лучший целевой код, чем средний разработчик.
В результате, практически всё, что вы делаете сегодня в Интернете, обслуживается очень интерактивным, эстетически приятным и простым в использовании интерфейсом. И все это стало возможным только благодаря экосистеме 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,… читать устанешь… потом на сайт из ссылки портфолио зайдешь — и все нахер виснет и тормозит…
Простите, бомбонуло…
Понимаешь, автор, не яваскриптом единым, закручивая шуруп молотком — можно выстрелить себе в ногу.
А по теме: JS — действительно имеет большой «ариал обитания», но это не значит, что он лучше других. JS не сможет потеснить R, Python, C++, [language-name] в тех областях в которых они используются. Он просто составляет им конкуренцию и позволяет веб-разработчикам разрабатывать что-то большее чем веб-страничку. Разве это так плохо?
Может за то, что JS уже потеснил как минимум Python и C++, а также PHP и Ruby в части областей, где они используются.
"Потеснил" и "вытеснили — разные слова. Я не считаю, что создание NodeJs создало новые рынки, но отрицать, что с его созданием JS проник на многие существующие рынки, в том числе и на рынок системной разработки, и в игродел, сложно. А значит он потеснил на них более ранних игроков.
У меня нет прав кидать что-то в карму, но могу попытаться вам ответить.
Я думаю, те разработчики, которым приходится выбирать языки основываясь на мнении не разработчиков, которые используют в основном hipe-driven подход могут объяснить в чем проблема. Грубо говоря, JS настолько плох и насколько ужасно развивается, что вокруг него почти каждая компания пытается навернуть фреймворков, что бы спрятать сам js глубоко-глубоко внутри и почти никогда его не видеть. И это не делает платформу проще или понятнее.
Подобная ситуация так же есть в Java, которая так же развивается очень медленно, поэтому появляются такие языки как Kotlin, scala, которые работают на той же платформе и имеют совместимость в java, но позволяют ей не пользоваться.
више не писал что это плохо, это лишь еще один инструмент…
… просто бесит, когда человек пишет, грубо говоря на одном языке, и обожествляет его лишь потому, что ничего друго не знает…
именно такое впечатление образовалось о авторе оригинальной статьи, по ссылке можно немного узнать про автора, он по большому счету ничем кроме производных javscript не занимается.
для новичков подобные статьи считаю вредными
JavaScript такой же язык как и остальные, со своей областью применения и эта область уже стала достаточно широка, что бы быть конкурентно способным языком. Он уже давно не просто скрипт для сайтика и тот кто понял это сейчас, уже обгоняет тех, кто как упрямый баран пытается привести примеры, что на нем не написать драйвер и сидит на обочине карьерного роста и продолжает ныть. Да, на нем не напишешь драйвер или ОС или прошивку потому что он высокоуровневый с очень сильной абстракцией над структурами данных. Поэтому многие кто пишут на JS даже не представляют как реализуются такие базовые структуры данных как стек, очередь, списки, кучи и т.д. или виды сортировок или поиск по графу. Но зачем им это??? Зачем повару знать, как выплавить из металла ложку или сковороду? У него своя сфера ответственности где он должен хорошо справляться. Хорошо ли справляется JS в своей сфере — ДА! Отличный скриптовый язык для написания простого веб-сервиса, веб-сайта или игры. Вы не согласны? Тогда Вас уже обгоняют!
Насчёт прошивки или ОС я бы не был так однозначен. Некоторые встраиваемые девайсы с прошивками как минимум UI реализуют на базе веб-браузеров типа Хромиума с активным использованием JS как в самом браузере, так и на встроенном сервере. Ну и как минимум часть ОС пишут на JS хотя бы для экспериментов.
Пошивка и ОС обеспечивают аппаратное взаимодействие, другим языком они предоставляют абстракцию над машинными командами? Какие машинные команды вы можете написать на JS?
Практически любые из nodejs, например. Вариант "в лоб": создаём файл с нужными командами в нужном формате и запускаем его через child_process.exec(). В какой-то мере пишем ассемблер (вполне может быть со своим оригинальным синтаксисом) и сборщик на JS. Невозможно?
Для языка высокого уровня взаимодействие с железом это прежде всего вопрос наличия биндингов к соответствующим библиотекам, а с этим у JS проблем нет.
Вы ставите телегу в переди лошади. child_process.exec() вызывает функцию ОС. Байндинги предоставляют API для вызыва функций ОС. Node js запускается ОС
Проблема яйца и курицы, а не телеги и лошади. И вообще я писал не об ОС, а о вызове произвольных машинных команд.
о вызове произвольных машинных команд.
Прям произвольных?
Вызвать можно произвольные. Реакция зависит от окружения.
Что значит "прямого следствия нет"?
Не поверите, но она ограничивается окружением всегда. Хотя бы архитектурой процессора. А так нам никто не мешает записать сгенерированный машинный код в, например, бут-сектор диска и отправить машину на ребут, если уж очень хочется минимума ограничений.
Без лирики: с момента получения трансляторами JS простых способов биндинга произвольных объектных библиотек, на JS вполне можно писать и низкоуровневые вещи типа работы с памятью и i/o. Насколько это целесообразно — отдельный разговор, но лично писал (точнее правил) JS-код для embeded приложений, взаимодействующих с USB-девайсами на низком уровне, по сути драйвера этих устройств на JS, работающих с ними через биндинги к ohci функции ядра Linux, предоставляющих высокуровневый доступ к ним из обычного кода веб-сервера.
-
JavaScript превзошел всех