Pull to refresh

Comments 423

Ещё есть претензия к функции .sort(), мол она сортирует лексикографически

Претензия прежде всего в том, что она сортирует используя не оператор сравнения, а что-то иное, не важно даже что. Это полнейшая глупость.


Если вам часто приходится прибегать к ней, то скорее всего вы делаете что-то не так.

Чем веб разработка такая особенная? Это просто платформа для исполнения кода вашего приложения. И потребности зависят от того, что это за приложение. Представьте себе, не все занимаются формошлёпством.

NodeJs там нету формошлепства. По скорости работы на сколько мне известно сопоставим с php. Все чаще его выбирают как основу для backend в своих приложениях

А зачем тащить js на backend? Дешевле разрабы чем на java, .net? Или есть какие-то другие веские причины?

Интересно, а какие веские причины тянуть на бэк микросервисную архитектуру, которая основана на общении микросервисов по http-протоколу, который в свою очередь был разработан для общения браузера с веб-сервром. Почему бы не использовать для общения микросервисов на стороне бэка rmi или CORBA?

Потому-что во многом удобно использовать rest api и http, а не corba. А насколько удобно лепить «многопоточного» слона из js и тащить его на бэк? Ну правда, чем это оправданно?

Мне кажется что rest api там используются не только поэтому. Вернее было бы уточнить а почему это стало удобно. Ответ мне на эти оба вопроса кажется связанным.
1) Сначала развитие веб привело к потребности в разработки различных инструментов для своей работы — от стандартов, средств сетевой инфраструктуры — до веб-серверов и веб-браузеров.
2) Потом интернет массово распространился что привело к обкатке всех этих средств миллиардами пользователей. И вот в этот именно момент эти средства начинают становиться удобными.
3) Теперь оказывается что в нашем распоряжении есть надежный протокол https, инфраструктура для работы по этому протоколу и такие же надежные библиотеки, веб-браузер на движке v8 и наконец сам движок v8 на котором построен nodejs.


И нет ничего удивительного в том, что


  • мы начали использовать протокол не для общения веб-браузера с веб-сервером а для вообще для любого обмена данными
  • мы начали использовать веб-браузер не для чтения научных статей а для разработки приложения, в том числе и для enterprise
  • этот же по сути движок веб-браузера мы начали использовать и на бэке
    Причина все та же — удобно, требует минимальных ресурсов на сервере, и минимальных затрат на разработку.
и вся эта белиберда привела к отстою в индустрии на долгие годы

Предположительно сейчас всех сделает mobile. Точно так как раньше всех сделал браузер. Правда монстры ERP этого еще не поняли. Но рано или поздно появятся mobile-first ERP и картинка станет другой.

mobile-first ERP

Не появится — этому мешает обычная реальность, данная нам в ощущениях: разглядывать информацию с экрана телефончика, даже большого — совершенно ужасно.
Но вот рабочие места для людей, которые данные в основном вбивают, тем или иным путем — они уже начинают быть mobile-first, да. Потому что если можно данные не вбивать, а фоткать и уверенно распознавать — это огромный прорыв в скорости работы. Ну и мобильным работникам это очень удобно (естественно).

А вот всякая отчётность и прочая аналитика из браузеров никуда не денется — работать с такими вещами на большом экране просто значительно удобнее.
Не появится — этому мешает обычная реальность, данная нам в ощущениях: разглядывать информацию с экрана телефончика, даже большого — совершенно ужасно.

Извините, но это всё субъективно. Вам это может быть и ужасно, кому-то нормально, а кому-то вообще нравится. Особенно если рассматривать не на «экране телефончика», а скажем на планшете с нормальным экраном.
Извините, но это всё субъективно.

Я повидал достаточно аналитиков, и некоторым из них даже софт писал. Нет, не субъективно. Mobile-first пригоден тем, кто данные вводит и особо ничего не смотрит, и mobile-first очень нравится биг боссам, которые воображают что-то в духе «глянул в мобилку — а там пишут, всё ли у тебя в конторе хорошо, или есть проблема». Короче, как кнопка «сделать всё хорошо». В реальности так не бывает, но в демках востребовано, да.

ЗЫ: Планшет — это по приёмам работы всё тот же телефончик, только экран побольше. Показать больше информации (или столько же, но видной издалека) — отлично работает, работать с планшетом как с ноутбуком/десктопом — вообще не вариант, даже если какая-нибудь пристегивающаяся клавиатура есть.

Ну давайте идти дальше. Зачем нормальной ERP еще и аналитик? Тут на подходе ИИ.

Ну как только сильный ИИ запилят, так вот прям сразу, ага.
А без него — аналитик затем, что он новости читает, по сторонам смотрит, и в силу этого способен выдать не только отчётик по историческим показателям, но и прогнозы, например. Настоящие прогнозы, а не «запихаем график цены биткоина в нейросетку, чтоб сказать, куда цена дальше пойдет».
По тому как я вижу как работают аналитики, то ИИ уже текущий может справится уже наверно даже лучше.

Причем тогда к новостям ERP. В конце концов сделать что-то десктопное для аналитика на mobile-first erp будет более реальной задачей чем переписать на мобльную версию тяжелую ERP


Вот Вам пример. Знаменитый аналитик https://en.wikipedia.org/wiki/Mary_Meeker (это как Лебедев только а аналитике и в Америке) ничего раньше не говорила про коронавирус и теперь не сказала что будет после коронавируса. А простой парень из Америки, Билл Гейтс уже двадцать лет в эту тему миллиарды топит.

Ещё как субъективно. Я вот например дома в инете сижу в основном с планшета. И на нём мобильные приложения обычно гораздо удобнее чем соответствующие странички. Конечно бывают и исключения, но в большинстве случаев это так.

А уж если я захожу на смартфон, то там странички можно смотреть практически только в мобильной версии и это ещё хуже.

И я это считай уже «старпёр» и «ретроград». А молодёжь сейчас вообще большую часть времени в своих смартфонах сидит и всё на них делает. И они браузер гораздо меньше меня используют.

Реальность она не всегда соответсвтует нашим ожиданиям от реальности. Реальность такова что многие тяжелые ERP как раз сделали интерфейс для мобильных устройств для боссов чтобы могли со смартфона увидеть основные показатели в цветных графиках. А что касается производства — то здесь как раз бы и нужно внедрить мобильные девайсы чтобы можно с ними было бродить по цеху или лазить по штабелеру. Но увы. Для этого слишком много нужно переделывать.

Реальность такова что многие тяжелые ERP как раз сделали интерфейс для мобильных устройств для боссов чтобы могли со смартфона увидеть основные показатели в цветных графиках.

Угу. Полезность этого как правило очень грустная, но да, сделали как раз это. Но это не mobile-first ERP ни разу.

Об этом я и говорю. Изначально тред начлся с утверждения что тяжелые ERP не идут в мобайл, а если и идут только для галочки.

Интересно, а какие веские причины тянуть на бэк микросервисную архитектуру, которая основана на общении микросервисов по http-протоколу...

Что бы переложить часть компетенции с дорогих программистов на относительно дешевых админов.

Не буду спорить про дешевизну админов, хотя DevOps, которые сегодня поддерживают микросервисную инфраструктуру сейчас в цене, как раз по причини востребованности микросервисной архитектуры. Но почему все же эта инфраструктура дешевая? Не потому ли что прочие средства обмена данными, например CORBA, не будучи востребованной в таком количестве как http, требует привлечения редких специалистов и сложных инфраструктурных решений?


Да и речь тут не об этом. Тредстартер почему-то допускает, что для общения микросервисов можно привлекать дешевую инфраструткуру и массовых (не будем называть их дешевыми) специалистов. Хотя, по гамбургскому счету нужно было бы юзать, скажем J2ЕЕ beans. Но тут же, почему-то, для разработки этих же самых микросервисов, по мнению тредстартера, нельзя юзать простой, быстрый, надежный и массовый nodejs.


Какие-то двойные стандарты.

js уже есть на фронте. Так можно переиспользовать код и иногда даже людей.
Пример переиспользования кода — валидация полей форм.
Пример переиспользования кода — валидация полей форм.

На практике, кроме пресловутой валидации и каких-то мелких классов-утилит, переиспользовать-то особо и нечего. И людей особо не переиспользуешь — специфика работы сильно другая.
Океееей, но прикладные к вебу вещи (какую-то часть варидации данных инпута, серверный рендеринг SPA) — это ведь слезы на фоне размера кодовой базы бизнес-логики типичного приложения. ara пишет про «большие куски», что они из себя могут представлять и почему они не могут остаться на одной из сторон?
это ведь слезы на фоне размера кодовой базы бизнес-логики типичного приложения


У меня не типичное приложение, которое представляет набор веб форм, а что то вроде многопользователськой онлайн игры. В этом приложении идет обмен бинарными данными между броузером и сервером в обоих направлениях. Соответственно есть логика которая сериализует и парсит эти данные, есть много общих интерфейсов, описывающих данные и алгоритмов, применяемых к ним.
Я не особо люблю JavaScript, но в моем случае делать бэеэнд на NodeJS было отличной идеей по этим причинам:

  • Большие куски изоморфного кода которые без изменений работают как на сервере так и в броузере. Очень удобно, что не надо дублиповать одну и ту же логику на разных языках. У меня есть много модулей, которые используют чистый JavaScript без Node или Browser API, разница только в том, кто их вызывает.
  • Server-side rendering. React это самый лучший шаблонизатор, и очень удобно что из одних и тех же компонентов можно рендерить и в броузере и на сервере.
  • Сам по себе JavaScript это довольно уродливый язык. Но вот если взять TypeScript и обвешать его линтерами, чтобы избежать всех тех идиотских ошибок дизайна JavaScript (typeof null === "object" и т.д.), то получается очень хороший язык, который лично мне нравиться намного больше чем, например, Java.

Я всегда с трудом понимаю аргумент про «переиспользование фронт-энд кода на бэкэнде»… Моя основная специализация — бэк-энд разработка, но на нескольких проектах приходилось быть фулл-стэком, и, исходя из того опыта, могу сказать, что если возникает необходимость на бэк-энде выполнять тот же код, что и на фронт-энде, то в 90% случаев это сигнализирует о плохой архитектуре (а еще 10% — это вышеупомянутая валидация форм и что-то подобное).

Ещё вариант: offline first и прочий UX, с оптимизацией времени отклика и прочих UX метрик: сначала посчитаем, потом в фоне загрузим на сервер, посчитаем ещё раз, а если что-то пойдёт не так, то выведем ошибку и откатим.

Веб разработка особенна тем, что обращение к DOM API должно происходить из одного потока. Представьте, что у вас два или при параллельных потока и и все они в одим момент времени меняют свойство DOM. Как думаете, что произойдет?

Вот и повелось с тех пор, что JS это один поток. Сейчас появились WebWorker, но они удобны для вычислений, а вот с DOM из воркера напрямую вы работать не сможете, по причине описанной выше.

И зачем мне ваш DOM, если я ренделю в WebGL?

А в WebGL у вас и так параллельный рендеринг. Шейдеры на видеокарте запускаются.

Так можно сказать, что и под винду всё должно быть однопоточно, ведь UI поток он только один.
Странное оправдание, если честно.

Я не оправдываюсь, я просто указал почему так. Если у вас есть идеи, как сделать правильно и лучше, думаю вы можете написать разработчикам браузеров.

Кстати, рекомендую почитать статьи на тему «почему JS однопоточный». Вы найдете исчерпывающие ответы.

Так почему так? Веб не ограничен манипуляциями с DOM, как и софт на десктопе не ограничен работой в UI потоке. Изначальные причины из начала 2000х, конечно, понятны. Но аргументов, почему это продолжается в 2020 году, кроме «а скажите, как сделать лучше, а мы подумаем» не слышно.
Это как с многозадачностью на смартфонах, и много где ещё. Только не нужно про мовместимость со старым кодом и т.п., 6й осёл давно умер.

Веб не ограничен манипуляциями с DOM

Можете поподробнее в этом месте? Так веб, который я знаю, живет в браузере. А вот в браузере это DOM.

Кстати, приведу пример. Оговорюсь, я не противник и не сторонник, живу с тем что есть. Так вот. Давайте представим ситуацию, на странице у нас, пусть будут, два DIV.

Итак в классической однопоточной схеме, мы меняем ширину первого DIVа. Что делает браузер? Напишу примитивно, детали вы сможете нагуглить. Браузер пересчитывает всю сцену, все элементы, их размеры и стили. От верхнего левого угла и до нижнего правого.

Теперь представим, что у нас два потока. Итак первый поток, как я написал выше меняет ширину блока. Браузер проводит пересчет всех размеров… И в этот момент, второй поток меняет ширину второго блока.

Внимание вопрос — что произойдет?

PS осел конечно умер, но наследие осталось.
Добро пожаловать в canvas и в WebGL в частности. (Эту мысль выше несколько резко выразил несправедливо заминусованный nin-jin)
А в других языках можно работать многопоточно с OpenGL/Dx?
Я просто не в курсе, но интересно. По идее там те же самые проблемы будут и решены они, наверное, костылями вида «нельзя что-то делать из другого потока».
Ну это же не параллельная отрисовка разными потоками. Это параллельная подготовительная работа. А отрисовывает на экран — всё равно, в любом случае, один поток.
Тогда не понятна суть претензий к JS. Никто не мешает подготавливать вычисления в отдельном потоке, а потом передавать их в поток отрисовки.

Как раз-таки понятна: помимо манипуляций DOM можно ещё дела делать параллельно, синхронизуя по меобходимости с основным потоком. Как и написано выше в комментах — не UI единым.

Ну так а я о чем? Делайте дела параллельно в вебворкерах, кто мешает то?

Похоже на то. Тогда о чём тут ноют? :shrug:


Спасибо за информацию.

Я не знаю о чем тут остальные ноют. У меня ужасно глючат комменты на этой странице, тут слишком много нытья :(

Коротко: данные устарели и задержки не критичны, если подходить с умом.


Ну, 2015 года статья.
80kB/ms не так мало для того времени.


Единственный момент был у меня на мобильном железе (iphone [5:7] с 11-ым safari) перекодировка 2.5 минут PCM в MP3 с передачей в основной поток занимала 10-30 секунд. Перекидывание бинарника занимало много меньше чем перекодирование в MP3 JS кодировщиком (wasm там багованный). Даже в основном потоке там быстрее не перекодировать т.к. ресурсов мало выделяется на новый браузер на старом железе.


Спамить воркерами это вообще плохой тон (и вообще спамить). Хотя используется во всех примерах т.к. прописывать управление воркером (пулом) в них неразумно.
Тут мастера купиПасты и распространяют ересь. Так же поступают с Audio контекстами, с запросами к мультимедиа устройствам и ко многим другим API (это прививается с потребительского отношения к DOM, захочу — дёрну).


P.S.
Отсюда удалена портянка про заражённый разными болезнями браузерный зоопарк, их описанием и следствиями из этого


А JS как ЯП на своём месте. Достал Notepad++ закодил идею, кинул в консоль, сверил результат с ожиданиями и пошёл принимать решение (а как было бы весело подстраиваться под кучку браузеров в других языках...). Если JS браузерного не хватает, можно выкинуть на сервер в крайнем случае. А там в зависимости от задачи свои инструменты.


Респект разработчикам движка v8, меньше разработчикам nodejs (о производительности редко думают, приходится аддон нативный гонять для http сервера) и разработчикам браузеров (оставляют баги в API без фиксов).

данные устарели

Есть более новые, где цифры стали меньше на порядок?

задержки не критичны

Десятки миллисекунд — это очень критично. Настолько, что вы про пулы начали рассказывать и что нужно уметь готовить. Ведь это и был контр-поинт на комментарий, на который я отвечал. А ведь это в еще относительно примитивном вебе наших дней, когда клиент тонок, а бэкграунд таски — это скорее исключение, чем повсеместно используемая штука, имхо.

и вообще спамить

Флудить? Спам — это про рекламу обычно.

TLDR; Если найдёте пример, где критично время создания воркера и нельзя заранее его создать, то соглашусь, что оверхед при создании воркера значителен для современных устройств в работе с воркерами. Пропускная способность и RTT довольно хорошие.


А. Поддержка устройств, выпущенных раньше 2015 года, крайне мала. Автор скорее всего на них и тестировал. ОС-ы также поддерживают меньше старого софта. Железо дешевле и производительней.


Пересобрал бенч из статьи (лютый бред там, но для сравнения изменений с 2015 пойдёт). Все значения для стандартного postMessage.


'Latency' (в реальном приложении вы не станете бомбардировать воркер десятками сообщений каждую миллисекунду):


  1. Mob: средн. — .7ms, макс. — 2ms за тест.
  2. Desk: средн. — .091ms, макс. — .2ms за тест.

Создание воркера (тут накладываются расходы на подгрузку скрипта воркера — диск. кэш не мгновенный, в идеале inline worker нужно создавать и не страдать фигнёй, если нужно быстро):


  1. Mob: средн. — 24.6ms, макс. — 28ms за тест.
  2. Desk (localhost): средн. — 8.55ms, макс. — 9ms за тест.
  3. Desk (обычный домен): средн. — 15.6ms, макс. — 22ms за тест.

Скорость передачи данных (для забивания канала нужно передавать 100-1000MB+ в секунду):


  1. Mob: средн. — 98kB/ms, макс. — 120kB/ms за тест.
  2. Desk: средн. — 800kB/ms, макс. — 1200kB/ms за тест.

Советует не передавать больше 3MB/26MB в одном сообщении для Mob. и Desk. соответственно.


Б. На большинстве устройств можно в реальном времени аудио с микрофона в воркере в MP3 загонять и в это же время анализировать аудиопоток и выводить красивую графику в 60fps. Делал такое 2 года назад, только 1 устройство (iphone 5-6, не помню точно) не справлялось и пришлось на все iosы отложенную кодировку делать (на нём всё упиралось в железо и JS движок, т.к. даже в основном потоке оно не могло перекодировать данные за приемлемое время).


А пока 2-3 кадра основной поток может и подождать создания воркера (даже всю логику можно в воркеры вынести и оставить только изменения UI в основном потоке, а-ля локальный клиент-сервер). Всё упирается в умения разработчика.


Про пулы и прочее: либо вы хотите макс. скорость вычислений, либо макс. экономить потребление памяти. Это вечная проблема в программировании и от неё не уйдёшь.


В. И флуд и спам не подходят, но суть вы поняли.


P.S.
Проклинаю автора бенча и по совместительству статьи, которую вы подкинули. Судя по репе принадлежит к касте бездумных сборщиков. Куча ненужного Г в проекте.
И сам проект пришлось перелопатить/почистить, т.к. он не работает из коробки и имеет кучу ненужного хлама.


Вообще нужно иметь представление о технологии (лучше опыт работы с ней), чтобы не кидать результаты бенчей сомнительного качества. Также вы бы знали, что создавать воркер на лету и закидывать его данными плохой тон. Этот этап развития 'поток на каждый запрос' показал себя неэффективным, когда нужна макс. производительность, на front и end частях веба.

Так в JS тоже можно. WebWorkers, все дела

Разработчик может захотеть выполнить какие-нибудь вычисления, не дожидаясь окончания отрисовки. Это бывает полезно, например, в играх.

По поводу потоков — можно либо заблокировать второй поток при попытке обратиться к DOM на запись, либо поставить запрос на изменение в очередь, либо даже начать исполнять его параллельно, если браузер так будет уметь (например, инвалидируя часть результатов первого расчёта прямо в то время, пока он выполняется).
Лет 9 назад, когда я писал на C# для WindowsForms и WPF, там подобные действия вызвали бы исключение, в разработке на Java под Android, если мне не изменяет память, изменение UI из параллельного потока — тоже вызывает исключение. Возможно, в каких-то языках можно одновременно из нескольких потоков выполнять действия над UI, но в тех, с которыми работал я — нельзя. Нужно сначала вернуться в главный поток, который может работать с UI, и потом уже из этого потока выполнять над ним действия.
Веб разработка особенна тем, что обращение к DOM API должно происходить из одного потока. Представьте, что у вас два или при параллельных потока и и все они в одим момент времени меняют свойство DOM. Как думаете, что произойдет?
Вот и повелось с тех пор, что JS это один поток. Сейчас появились WebWorker, но они удобны для вычислений, а вот с DOM из воркера напрямую вы работать не сможете, по причине описанной выше.

JS это имплементация стандарта ECMAScript который нечего не знает о DOM. DOM это уже другой стандарт и API браузера. Как бы, что раньше, курица или яйцо. DOM не причина однопоточности JS :)


Так веб, который я знаю, живет в браузере. А вот в браузере это DOM.

Браузер это движок JS + движок рендера. Одно является имплементацией JS, другое имплементацией DOM и прочих стандартов по типу веб сокетов и интерфейсов.


Теперь представим, что у нас два потока. Итак первый поток, как я написал выше меняет ширину блока. Браузер проводит пересчет всех размеров… И в этот момент, второй поток меняет ширину второго блока.

В многопоточном мире есть огромное колво инструментов для работы с подобными задачами. JS обращается к DOM через event loop, который по своей природе однопоточный, но то куда ведет этот чудный мост, зачастую C++ который многопоточный. И рендер в браузере многослойный и часть интерфейса может рендерится отдельно от другой. Возьми тот же css transform и посмотрим на слои. Однопоточно все только для тебя, как для пользователя DOM.


а вот с DOM из воркера напрямую вы работать не сможете, по причине описанной выше.

Удачи — https://github.com/ampproject/worker-dom


Embedded content from a third party living side by side with first party code.
Mitigation of expensive rendering for content not requiring synchronous updates to user actions.
Retaining main thread availablity for high priority updates by async updating elsewhere in a document.
Не забывайте, что DOM появился раньше чем JS. И JS подстраивался под DOM. Собственно, почитайте историю развития. Повторюсь, я не защищаю JS. Мне самому не нравятся некоторые вещи.

Сейчас мы имеем то что имеем.
Удачи — github.com/ampproject/worker-dom

Когда приводите пример, хотя бя гляньте как это реализовано под капотом. Но если вам лень, то в кратце — реализация основана на обмене сообщениями из дочернего потока в основной. И уже основной поток работает с DOM.

Удачи.
тогда приводите пример, хотя бя гляньте как это реализовано под капотом.

Да какая разница, люди юзают его для обновы DOM с вычислениями в отдельном потоке и это главное.


Retaining main thread availablity for high priority updates by async updating elsewhere in a document.



И уже основной поток работает с DOM.

JS не работает с DOM, он работает с DOM API. C DOM работает движок рендера который умеет в асинхронщину.




Не забывайте, что DOM появился раньше чем JS. И JS подстраивался под DOM

Да да, сперва было яйцо, а попа у курицы под него подстроилась. DOM для JS — инструмент который не входит в стандарт языка. Посыл, что JS синхронный из за DOM попросту не очень




Твой пример выше


Итак в классической однопоточной схеме, мы меняем ширину первого DIVа. Что делает браузер? Напишу примитивно, детали вы сможете нагуглить. Браузер пересчитывает всю сцену, все элементы, их размеры и стили. От верхнего левого угла и до нижнего правого.

Это известный кейс когда происходит репейнт и рекалькуляция лаяута из за работы с размерами, офсетами и тд. Но есть куча других апдейтов и разные слои которые можно асинхронно обновлять. Сама структура DOM в виде дерева идеально подходит для асинхронных обновлений в разных местах.


Ты как пользователь ограничен одним потоком, и твои обновления не редко попадают в буфер, перед тем как движки выполняют апдейты, но тебе и не нужна чистая асинхронная возможность обновления DOM.

Да да, сперва было яйцо, а попа у курицы под него подстроилась

Но ведь это правда :-) Язык ведь изначально предназначался для "игрушечных" нужд, вот и не завезли в него многопоточности. Причина именно историческая. Стало быть, глядя на то что происходит сейчас, то и ещё будет, в него ещё завезут столько всего, что пожалеем.

Да да, сперва было яйцо, а попа у курицы под него подстроилась.


Минутка занудства — сначало было яйцо. Яйцо динозавра, который тысячами и миллионами лет эволюционировал в курицу.

Извиняюсь, но что вы мне хотите доказать? Что DOM API кривое? Так и так все знают что оно кривое. Что JS так себе? Так и мне не нравятся многи вещи в JS, примеру наследование на прототипах. Что в JS нет нормальной многопоточности. Ну ок.

Да, так история сложилась.

Хотите это улучшить — так я только «за». И если у вас получится выкатить лучший движок и язык — я с удовольствием буду его, и его инструменты, использовать. OpenSource позволяет сделать форки и улучшить что либо. А ломать копья и не предлагать что либо в замен — так себе.
Представьте себе, не все занимаются формошлёпством.

Написал гневно человек на сайте. Оказалось, что все пользуются сайтами, даже те самые, которые не формошлёпят.

Причина, по которой в JavaScript-е нет нормальной реализации многопоточности не в том, что язык какой-то не такой и он просто не способен на что-то такое, а в сфере его применения — web разработка

Вообще-то все больше и больше людей считают js языком общего назначения. И на нем пишут десктопные приложения вроде Skype.
Которые по факту — браузер в красивой обертке. Так что ничего не меняется.
UFO just landed and posted this here
Лично я против такого применения JS. Это очередная попытка превратить язык в панацею и спасти мир. И хорошо написанное нативное приложение будет работать лучше хорошо написанного приложения на electronjs

Вот только наивных приложений нужно штук пять писать, минимум, обеспечивая совместимость. Плюс веб

UFO just landed and posted this here
UFO just landed and posted this here
Вспоминается старая шутка: «Сделаем дешево, быстро, качественно. Выберите два пункта». Вы пытаетесь использовать инструмент не для целей, для которых он изначально был предназначен, а потом удивляетесь, почему что-то работает не так, как надо. Я понимаю, что подход «дешевле и быстрее» часто очень оправдан, но чтобы получить что-то, вы должны чем-то пожертвовать. Разве это проблема JS что кто-то решил применить его там, где этого делать не стоит ради простоты и дешевизны? Вы так в принципе и сайты клипать на C можете, генерируя HTML на вашем сервере, а потом отправляя клиенту, но зачем?

Помимо дешевизны есть ещё и вопрос долголетия. Правда, для его достижения нужно писать не абы как, но тем не менее 20 лет для JS — это раз плюнуть: https://habr.com/ru/post/462685/


Сравните это с постоянными обновлениями родных приложений, где нужно обновляться ровно потому, что так решил производитель ОСи.

Первым делом хотелось бы привести в пример следующий отрывок с кодом:

Проблема в том, что вы считаете, что кто-то специально пишет такие конструкции) Проблема-то не в том, что кто буквально пишет такое, а в том, что "звёзды так сложились" и оно "стрельнуло". И приложение где-то валится, а понять почему — хрен поймёшь. А пример гиперболиризирован, это же очевидно)

Иногда мне кажется, что почти весь хейт прет от хеллоуворлдщиков, которые скачут с одного языка на другой в поисках неизвестно чего, поэтому и выглядит гиперболизировано. Профессионал изучит свой инструмент, знает когда и как его использовать, а в свободное время фиксит код так, чтобы он меньше стрелял тебе в ноги) Минусы есть абсолютно везде, просто с некоторыми ты учишься работать и не замечаешь в дальнейшем, а из-за других спокойно меняешь инструмент.

TypeScript если и не спасет отца русской демократии, то очень облегчит ему жизнь

>В веб-разработке вам в принципе не должна понадобиться возможность исполнять ваш код в несколько потоков.
Вообще такие утверждения стоило бы как-то аргументировать. Потому что если бы это было так — то зачем, к примеру придумали Web Workers?
«В принципе» не значит никогда. Разумеется у всего есть исключения, но на то они и исключения, что редки. Да, веб-приложения стали большими и требовательными, иногда будет полезным вынести тяжелые вычисления в отдельный поток, чтобы не тормозить основной. Но встречаются такие потребности очень редко, а если вы прибегаете к многопоточности в вашем веб-приложении очень часто, то либо у вас слишком специфический проект, который лучше было бы реализовывать на другой платформе / используя другие возможности, либо вы просто неправильно построили свое веб-приложение. Но в первую очередь веб-разработка это манипуляция DOM-ом, а возможность манипулировать им в несколько потоков просто создаст больше проблем, чем решит. Поэтому даже с Web Workers у вас нет возможности работать в DOM напрямую
Да, про DOM я согласен — без него это будет уже не совсем веб приложение (хотя и не факт, WebGL уже выше упомянули, да и другие варианты придумать можно). Но я бы сказал, что невозможность (или сложность) работы с DOM многопоточно не имеет почти никакого отношения к наличию потребности работать многопоточно. Да, многопоточность — это вообще почти всегда трудно. Особенно — когда язык не поддерживает :) Но это совсем не повод говорить «нам это не нужно».

С другой стороны, многопоточность — это всего-лишь два потока. Один поток в практически любом приложении — это UI. Это значит, что второй поток — это всего-навсего асинхронный источник данных откуда-либо. Что тут специфичного? Вы не думаете, что именно по этой причине в веб парадигме так сложно писать даже что-то типа мессенджера?
Возможно мне стоило написать «в большинстве случаев» а не «в принципе», тогда было бы понятнее что я имею ввиду. Учту и в будущем буду стараться писать так, чтоб это было понятно всем, а не только мне.
Что же касательно того-же мессенджера, то думаю в вебе есть достаточно инструментов, которые позволят вам написать мессенлдер без труда. А если вы собрались писать инструмент для работы с WS с нуля, то дело ваше
>Возможно мне стоило написать «в большинстве случаев» а не «в принципе», тогда было бы понятнее что я имею ввиду.
Ну, меня больше всего смутило именно это. Если вы скажете, что большинству веб приложений многопоточность не нужна — то это скорее всего так и есть.
С чего вы взяли что это DOM? ReactNative, к примеру, не оперирует DOM в принципе. А это тот же самый JS
Потому что JS был создан для веба. А React Native это как раз тот случай, когда язык применяют не там где нужно
Вас послушать — язык как разработали в девятьсот желтом году, так он без изменений и существует :)
Да! И именно!
Корни JavaScript были заложены ещё раньше. Даже не в прямых предшественниках вроде Simula. Работы по проектированию вокрыг подобных ЯП велись намного раньше, просто было взято то, что быстро подходило под проект.
Версия событий от автора языка и редактора стандарта:
zenodo.org/record/3710954#.Xq6zO3Vfhzm

Сама идея React Native подразумевает применение JS, также как идея Electron

Ответ на ваш вопрос содержится в одном из комментариев выше.
В JS изначально была возможность работать только с одним потоком по той причине, что нельзя работать с API DOM с разу из нескольких потоков.
Так я и говорю о потребности, а не о технической возможности. Автор утверждал, что нет потребности в потоках. Ок, поребности нет. Зачем тогда воркеры придумали, если даже в текущем виде (без возможности работать с DOM) они где-то применяются? Разве это не заменители потоков в том или ином виде?

Я как раз пытаюсь до вас донести, что веб-воркеры появились по другим причинам. Использование DOM API однопоточное и потребности делать его многопоточным нет. Веб-воркеры решают другую проблему — они нужны для вычислений. Не нужно использовать их для рендеринга.

>Я как раз пытаюсь до вас донести, что веб-воркеры появились по другим причинам.
С чего вы взяли? Это и есть ровно те причины. Основной поток занят UI, и если в нем что-то считать — UI будет замораживаться. Это и есть ровно та самая потребность, которая в большинстве других случаев решается созданием потоков. Воркеры решают как раз те задачи, которые обычно решаются потоками (там, где они есть).
Я вас неправильно понял, извиняюсь. Полностью с вами согласен. Думал, вы о том, чтобы распараллелить рендеринг.
Также надо добавить, что многоядерных процессоров на тот момент тупо не было даже в проекте, промышленность ещё не могла такое освоить. А для однопроцессорной системы многопоточность UI тупо не имеет смысла (лишние тормоза при 0 профита).
JavaScript хорошо справляется с задачами, для которых его чаще всего используют.

На мой взгляд JavaScript со своими задачами справляется так себе. То есть где-то на троечку. И как минимум на мой взгляд он предоставляет людям слишком много возможностей «выстрелить себе в ногу» или даже «выстрелить в ногу» коллеге(ну или вообще кому-то кто использует твой код где-то у себя).

И единственная причина его популярности/распространённости это банальное «исторически сложилось».
И как минимум на мой взгляд он предоставляет людям слишком много возможностей «выстрелить себе в ногу» или даже «выстрелить в ногу» коллеге(ну или вообще кому-то кто использует твой код где-то у себя).

Внесите уже, наконец-то в студию приз язык, в котором этих возможностей не «слишком много».
Естественно при желании выстрелить себе в ногу можно практически на любом ЯП, но если вы спросие меня то тот же TypeScript уже даёт гораздо меньше подобных возможностей. Ну или скажем Java или C#.
Меньше, да. Но их всё так же остаётся «слишком много» (судя по количеству зафакапленого кода), так что so what?

А «тот же TS» и вовсе даёт возможность написать any и забыть про то, что это TS.
Меньше, да. Но их всё так же остаётся «слишком много» (судя по количеству зафакапленого кода), так что so what?

Какая-то для меня немного странная логика. Так можно дойти и до того что вообще все эти «немного лучшие» ЯП никому не нужны и можно просто всем на ассемблере писать…

JavaScript имеет определённые проблемы, которые отдельные другие языки не имеют. И это делает его менее «удобным». Конечно можно на это наплевать, но я бы не сказал что это особо рациональное поведение.
Вы думаете, что на ассемблере выстрелить себе в ногу сложнее? ;-)

JavaScript имеет определённые проблемы, которые отдельные другие языки не имеют.

Отдельные другие языки имеют другие определенные проблемы, которых не имеет JS.

Я вообще написал верхний коммент только для того, чтоб подчеркнуть, что выстрелить в ногу можно где угодно. И количество путей сделать это — зависит, главным образом, от домена: чем больше на языке можно сделать, тем и больше способов сделать это неадекватным образом. С тех пор, как JS стал языком общего назначения — стрелять себе в ногу в нем можно настолько же разнообразно, насколько и в других языках общего назначения. Только и всего.

Высокоуровневость и низкоуровневость тут и вовсе не при чём — высокоуровевые ЯП дают более удобные абстракции, но это никак не означает, что этими абстракциями сложнее воспользоваться ненадлежащим образом. Нисколько не сложнее. И даже разные идеологии написания программ (статическая типизация и прочее) — имеют очень опосредованное отношение к написанию плохого кода, так как сделать криво можно и с сильными статическими типами, а сделать хорошо можно и с динамическими (инструменты для этого более чем есть).

Конечно, JS далёк от идеала. Но от него настолько же далеки, скажем, С и плюсы — на них, по вашей классификации, тоже пишут только потому, что «исторически сложилось».
Вы думаете, что на ассемблере выстрелить себе в ногу сложнее? ;-)

Как раз таки наоборот. Но если для вас это не играет особой роли…

Отдельные другие языки имеют другие определенные проблемы, которых не имеет JS.

И это относится ко всем языкам? Ну или если перейти к конкретике, то скажем какие «определённые проблемы» имеют озвученные мною выше по вашей пррсьбе TypeScript, C# или Java?

Но от него настолько же далеки, скажем, С и плюсы — на них, по вашей классификации, тоже пишут только потому, что «исторически сложилось».

А вот такого я как раз таки не утверждал. То есть конечно и в их случае «исторически сложилось» тоже играет свою роль. Но горааааздо меньшую.
JavaScript живёт в основном за счёт веба. И грубо говоря в том числе и за счёт того что для того чтобы его заменить на что-то другое куча людей должна договориться. А это как мы знаем работает не особо хорошо.
Ну или если перейти к конкретике, то скажем какие «определённые проблемы» имеют озвученные мною выше по вашей пррсьбе TypeScript, C# или Java?

TS это надстройка JS, не более того.
В яве соседствует сильная типизация с плохо развитой системой типов, что легко порождает архитектурных уродцев. Собственно, не зря Enterprise FizzBuzz написан именно на яве ;-)
Насчёт C# спросите того, кто силен в сишарпе. Думаю, он вам много расскажет.

А вот такого я как раз таки не утверждал.

Это явно вытекает из ваших тезисов. Миллионы способов выстрелить в ногу в C и триллионы в плюсах, и море существующего кода, несмотря на многочисленные альтернативы. Что это по вашей классификации, кроме как «исторически сложилось»?
TS это надстройка JS, не более того.

И? Так какие у ТS есть «определённые проблемы», которых нет у JS?

В яве соседствует сильная типизация с плохо развитой системой типов, что легко порождает архитектурных уродцев.

Не сказал бы что это более простой способ выстрелить себе в ногу по сравнению с тем что нам даёт JS.
Насчёт C# спросите того, кто силен в сишарпе. Думаю, он вам много расскажет.

Не знаю силён я в шарпе или нет, но приличный опыт имею. И не сказал бы что в нём больше проблем чем в JS.

Это явно вытекает из ваших тезисов.

Для меня совсем не явно.

Миллионы способов выстрелить в ногу в C и триллионы в плюсах, и море существующего кода, несмотря на многочисленные альтернативы. Что это по вашей классификации, кроме как «исторически сложилось»?

Я бы не сказал что плюсам и С существуют(и особенно существовали) прямо таки многочисленные альтернативы. Особенно в контексте «стрельбы себе в ногу».
Ну и кто хочет, тот спокойно может эти самые имеющиеся альтернативы использовать. И куча народа так и делает.

С другой стороны я бы хотел посмотреть как вы в вебе вместо JS будете использовать какой-нибудь C# или Java.

Сразу в голову пришло, что в TS нет instanceof для интерфейсов. И неявного приведения типов полно в каждой программе — минимум if и циклы не требуют boolean

Сразу в голову пришло, что в TS нет instanceof для интерфейсов.

Как он работал бы? Пробегал бы по объекту (возможно полученному извне) и проверял поимённо, все ли члены на месте? Но это дорого, и не всё можно проверить так. Например, параметры и возвращаемый тип функции уже не проверишь. Выйдет ложная уверенность. Проще тупо проверить наличие нужного члена перед использованием, благо теперь есть x?.y.

`instanceof` про интерфейсы — это… )
Он бы мог работать как нужно, если бы интерфейс был экземпляром конструктора этого интерфейса. Но, боюсь, что если создать в народе понимание, что делать интерфейсы экземплярами классов в принципе можно, ещё возможно, то вот убедить их в необходимости будет гораздо сложней.
делать интерфейсы экземплярами классов

Какой смысл вы вкладываете в "интерфейс — экземпляр класса"? Ведь всё обстоит ровно наоборот: интерфейс — это абстрактный тип, голое описание набора методов без реализации; класс — это экземпляр интерфейса, т.е. некая частная реализация интерфейса; объект — это экземпляр класса, т.е. частная коллекция данных в памяти со ссылкой на конкретную коллекцию методов.

`instanceof` про интерфейсы — это… )
Он бы мог работать как нужно, если бы интерфейс был экземпляром конструктора этого интерфейса.
Интерфейсы в тех языках, которые приходят на ум, не особо отличаются от классов. И то, и другое для клиентского кода — сложный тип. И в коде нужен способ ответить на вопрос «A is B?» и не знать, от класса он зависит, или от интерфейса. Правда, не от хорошей жизни ЯП архитектуры это чаще всего нужно. Вроде в Typescript абстрагироваться полегче.

Вот со структурной типизацией, сложно, да. И даже не из-за функций как таковых, а что в рантайме надо обходить.


А с номинативной было бы достаточно какого-то поля.

В TypeScript у людей всегда соблазн писать максимально строгие типы.
"А вот это поле бывает [number, number] если в соседнем поле лежит string, а бывает [string, number, string], если в другом соседнем поле лежит boolean, а оба соседних поле зависят от чего-то ещё, давайте все это типизируем чтобы оно соответствовало, сделаем цепочку из 20 наследований, где у каждого типа в цепочке ещё и по 20 дженериков".


В итоге у тебя сверхзапутанная система типов, которые не помогают примерно никогда, с трудом читаются и требуют неделю вносить в них изменения при 5-минутных правках кода. Я не шучу, столько раз об это спотыкался.
Из живых примеров — недавно редактировал код, где у компонента Table в Props захотели сделать, чтобы Cols.length == Rows[any index].length. Как-то сделали. Я часа два над этими типами медитировал, так до конца и не понял, как это должно работать.
А в итоге по всему коду проекта раскидано as Rows<rowLength>, потому что у явно заданного массива ts почему-то длину не распознаёт, а у динамически полученного в рантайме понятно почему не распознаёт. При этом, очевидно, не проверяет такая проверка абсолютно ничего – во всех живых кейсах данные для таблицы получаются в рантайме.


Проблема абсолютно такая же, как с динамической типизацией. Есть динамическая типизация — люди ей злоупотребляют и стреляют себе в ногу. Есть статическая — аналогично. Только злоупотреблять ей можно иначе.

Есть подозрение, что это дизайн имеет сложности с кучей вариаций типов без какой-либо абстракции, а не TS, подсветивший эту проблему.

Понятно, что есть JSное легаси, которое писалось как умели, но вывод крайнего абзаца звучит так, будто это хорошо и нормально, просто TS со своей безопасностью не всегда уместен.
UFO just landed and posted this here
Внесите уже, наконец-то в студию приз язык, в котором этих возможностей не «слишком много»
С WebAssembly проблема частично разрешится: можно будет писать на любом языке, который будет его поддерживать.
Вы из тех, кто всё еще верит, что wasm — это чтоб можно было для веба писать на чём угодно? Ну, блаженны верующие.

ЗЫ: hint: wasm — это чтоб этот ваш богомерзкий JS и прочий веб мог числодробилку погонять, если очень уж нужно. Для других целей он никому не нужен и не будет нужен. Ну, кроме верующих в то, что в один прекрасный день они будут на каком-нибудь там си или расте фигачить сайтики.
Ну, кроме верующих в то, что в один прекрасный день они будут на каком-нибудь там си или расте фигачить сайтики.

Я боюсь что рано или поздно никаких «сайтиков» как таковых просто не останется. Мы на мой взгляд медленно но уверенно идём к тому что всё «переезжает» в клауд. И когда у нас действительно всё туда переедет, то веб в том виде как мы его сейчас знаем просто вымрет за ненадобностью.
А в клауде что, не «сайтики»? Какая-то новая форма источника данных для браузерного рендеринга?
Речь идёт не о том что «сайтики» будут хостится в клауде. Речь о том что весь компьютер туда «переедет». То есть все вычислительные мощности будут там, а мы будем коннектиться туда «по ремоту» с каких-то примитивных и простеньких «клиентов». Ну это если прокатит то, что хотят всякие гуглы-микрософты. А как бы мне не хотелось быть оптимистом, я бы сказал что оно рано или поздно так произойдёт.

И в такой ситуации обычные браузеры и обычные странички на мой взгляд уже теряют смысл. Ведь какая разница «стримите» вы себе из клауда запущенный браузер с контентом или сразу запущенную там любую другую программу/приложение созданную под этот контент? А если уже всё равно, то зачем создателям/распространителям контента придерживаться стандартов современных браузеров?
Я помню, как Sun Microsystems активно продвигала «тонкие клиенты»
Была пионером в этом бизнесе
Уверяла, что за их мэйнфремами (аналог клауда) будущее
Но люди выбрали PC улыбающегося Билли, и Sun Microsystems пошла по миру
Пришлось даже Java продать Oracle
Всемирная история, банк Империал…
Ну на мой взгляд одна из основных причин почему это тогда не особо хорошо сработало это медленный, а местами и просто отсутствущий интернет. Сейчас ситуация заметно изменилась.

Ну и плюс сейчас переход идёт медленнее, «гармоничнее» и незаметнее. Винда уже потихоньку отказывется работать без инета, офис потихоньку переезжает в облака, Майкрософт в принципе похоже уходит от идеи делать следующую «конвециональную ОС». Гугл везде пихает свои хромбуки и при этом не то чтобы безуспешно. Повсюду повылазили предложения играть в игры из облака. И так далее и тому подобное…
Винда уже потихоньку отказывется работать без инета, офис потихоньку переезжает в облака

Вы путаете выстраивание бизнес-процессов (венда не должна работать без инета, чтоб мы спокойно всех обновляли и не парились) с технологическими решениями. Венда, как OS, прекрасно работает без инета и будет продолжать это делать — все ограничения на этот счёт вводятся искусственно.

А офис никуда особо не переезжает. Да и нет в этом смысла, потому что там (целиком в «облаках») есть уже гугльдокс, и внезапно оказалось, что такая модель устраивает совсем даже не полностью всех.
Венда, как OS, прекрасно работает без инета и будет продолжать это делать — все ограничения на этот счёт вводятся искусственно.

Естественно они вводятся искуственно. И они будут вводится всё больше и больше. И тенденция на мой взгляд достаточно понятна и ясно куда это ведёт и чем кончится.
Майкрософт похоже считает что будет выгоднее не просто продавать саму ОС, а сдавать её в аренду вместе с мощностями в клауде на которых она будет крутиться.

И для кучи людей такой вариант тоже будет дешевле и удобнее. А кому такое не нравится, тем скорее всего придётся переходить на какой-нибудь линукс.
В долгосрочной перспективе дешевле купить железо локально, чем арендовать сервер. С учётом того, что требования к железу и не думают уменьшаться, на серверах пользователи разоряться.
А если уже всё равно, то зачем создателям/распространителям контента придерживаться стандартов современных браузеров?

Вы всерьез что ли думаете, что вот эти вот годы работы W3C и прочих сочувствующих — у этого нет никакой онтологической инерции? У этих сотен стандартов инерция уже нисколько не хуже, чем у С. Это не значит, что они идеальны, или даже очень хороши — это значит, что с их применением создано уже столько софта, что отмахнуться от него экономически нецелесообразно. Даже когда вы что-то там в терминальном режиме раздаете.
Естественно никто не откажется от веба за один день. Но потихоньку веб будет сходить на нет и рано или поздно станет достаточно «нишевой вещью» не играющей какой-то особенной роли.

И это конечно произойдёт не завтра и не через десять лет. Но я бы предположил что ещё при моей жизни. И возможно даже до того как я выйду на пенсию.
Но потихоньку веб будет сходить на нет

Так ну нет, не будет. Просто потому, что веб — это не решение одного игрока, и из него просто так не уйти, чтоб не порвать связи с остальными игроками. Это не только «сайтики», но и публичные API и вообще передача информации стандартизированными путями в общем смысле. Клепать какое-то собственное местячковое решение — можно только тогда, когда без этого ну вообще никак по технологическим причинам.
Ок, ну если у вас проблема с контекстом, то давайте я переформулирую: не веб как таковой сойдёт на нет, а конкретно «сайтики». Так вас устраивает?

Ну и где тогда в вебе будет использоваться именно JavaScript? И насколько массовым будет его использование если «сайтики» сойдут на нет?
Я предлагаю на этом месте сделать закладку и вернуться к разговору лет через 20 (я там как раз плюс-минус на пенсию пойду). Там уже должно стать заметно это ваше умирание сайтиков, если тренд на него и вправду имеется.

Может хабр будет еще жив, кто знает.
Мы на мой взгляд медленно но уверенно идём к тому что всё «переезжает» в клауд.

Я вижу вполне явные ограничения этого переезда: в облако едет только то, что на клиентах не обсчитывается (мало мощностей, мало памяти, или очень ценные данные, которые клиенту никто не отдаст для самостоятельного обсчёта).

Всё остальное — совершенно наоборот, переезжает на клиента. Зачем покупать серверные мощности (пусть и по сугубо оптовым ценам), когда каждый человек таскает в кармане технику с очень нехилой вычислительной мощностью? И это даже не говоря про более полноразмерную технику.

WASM — он вот как раз про то, что у клиентов вообще-то очень много вычислительных ресурсов, и в некоторых случаях их бы экономически очень потребно нагружать.
Я вижу вполне явные ограничения этого переезда: в облако едет только то, что на клиентах не обсчитывается

С каких это пор у нас компьютерные игры на клиентах не обсчитываются? Или скажем тот же майкрософтовский офис?
Гугл со своим хромбуками всё больше и больше продвигается на рынке в том же США.

WASM — он вот как раз про то, что у клиентов вообще-то очень много вычислительных ресурсов, и в некоторых случаях их бы экономически очень потребно нагружать.

Это их сейчас много. И именно потому что было необходимо держать у себя более-менее мощные компьютеры. Как только эта необходимость отпадёт, так очень многие перейдут на эти самые слабенькие клиенты вроде хромбуков. Просто потому что это будет дешевле. А для многих и удобнее. Я бы даже сказал что это сделает подавляющее большинство частников.
С каких это пор у нас компьютерные игры на клиентах не обсчитываются?

Эм. Вам правду сказать? Почти с самого-самого начала появления специализированных 3D-ускорителей и последовавшей гонки железа.
Вот от тех лет и до настоящего времени — некоторый довольно внушительный слой компьютерных игр не обсчитывается на абы каком железе, а только на очень даже заточенном под это.
Из этого целиком и полностью вытекает бизнес-модель всего этого облачного гейминга, кстати.

Или скажем тот же майкрософтовский офис?

Офис никуда не уехал из оффлайна, если что. И не уедет. Облачный офис — для тех, кто мог бы уйти пользоваться гугльдокс, но теперь не уйдет, потому что у MS альтернатива есть.

Как только эта необходимость отпадёт, так очень многие перейдут на эти самые слабенькие клиенты вроде хромбуков. Просто потому что это будет дешевле.

Для людей дешевле, а для поставщиков софта — дороже, потому что вычислительные мощности придётся оплачивать им. Не выходит каменный цветок.
Вот от тех лет и до настоящего времени — некоторый довольно внушительный слой компьютерных игр не обсчитывается на абы каком железе, а только на очень даже заточенном под это.

Я бы не сказал что игровые приставки прямо вот являются супер-пупер мощными клиентами.

Офис никуда не уехал из оффлайна, если что. И не уедет.

Это ваше личное предположение. Я это вижу по другому. Время покажет кто из нас прав.

Для людей дешевле, а для поставщиков софта — дороже, потому что вычислительные мощности придётся оплачивать им

Совсем необязательно. Вполне себе возможны какие-нибудь варианты с подписками. Или «оплата» за счёт просмотра рекламы.

То есть именно производителям софта будет всё равно. Им даже скорее будет удобнее так как не будет зоопарка миилионов-миллиардов разных конфигураций компов, а будет относительно небольшое количество конфигураций этих самых клаудов.

Проиграют в первую очередь производители пользовательского железа. А выиграют те кто будут предлагать эти самые клауд-ОС.
Я бы не сказал что игровые приставки прямо вот являются супер-пупер мощными клиентами.

А они, меж тем, являются. Не супер-пупер, но гораздо мощнее «среднего» офисного железа. Плюс, опять же, видеокарта.

То есть именно производителям софта будет всё равно. Им даже скорее будет удобнее так как не будет зоопарка миилионов-миллиардов разных конфигураций компов, а будет относительно небольшое количество конфигураций этих самых клаудов.

Производителям софта «сайтиков» уже всё равно, потому что миллионы-миллиарды разных конфигураций компов свели к 5-6 разным браузерам. Или трем, если у вас нет цели ублажить любого зашедшего, а только самых распространенных.

Собственно, браузер — это наиглавнейшая причина существования веба в таком виде, в котором мы видим его сейчас. Реализовали браузер бы принципиально иначе — веб был бы совсем не таким.
А они, меж тем, являются. Не супер-пупер, но гораздо мощнее «среднего» офисного железа. Плюс, опять же, видеокарта

При этом их стоимость не то чтобы особо велика. И не сильно выше стоимости среднего домашнего компа. Так что мне не совсем понятно почему их частники вдруг сменят на облачные решения, а свои домашние компы менять не будут.

Производителям софта «сайтиков» уже всё равно, потому что миллионы-миллиарды разных конфигураций компов свели к 5-6 разным браузерам

Но при этом их загнали в не особо удобные и приятные для них стандарты и ограничения. Пользователям это конечно удобно. А вот именно производителям софта не особо.

Собственно, браузер — это наиглавнейшая причина существования веба в таком виде, в котором мы видим его сейчас. Реализовали браузер бы принципиально иначе — веб был бы совсем не таким.

Мир не стоит на месте. Особенно что касается ИТ. Многое нынешние браузеры на данный момент не позволяют или позволяют, но с кучей геморроя. И в этом плане ситуация вряд ли улучшится.
Люди всё больше и больше времени тратят в эппах/мобильных приложениях и всё меньше на сайтиках. Особенно молодёжь и подростки.
При этом их стоимость не то чтобы особо велика.

Эм. Вы в курсе, что последние лет 20 консоли продаются в убыток? И что «навар» создаётся на продаже игр?

Люди всё больше и больше времени тратят в эппах/мобильных приложениях и всё меньше на сайтиках. Особенно молодёжь и подростки.

И причина этому — чисто технологическая. Чем лучше браузер вкручивают в мобилки, тем меньше резона тратить время и деньги на производство этих ваших аппликух отдельно от остального. Не зря определенные круги так возбуждаются на PWA, флаттер, и вообще всё что угодно, что позволит не делать отдельный апп, а совместить это с сайтиком и десктопом.

Люди же сидят в фейсбучике/инстаграмчике/вацапчике/тиндерчике. Им вообще глубоко положить, апп это, сайт, или вообще неведомый зверь. Это обёртка — какая удобнее, той и будут пользоваться.
И что это меняет в контексте нашей дискуссии? Ну будут вам «облачные мощности продавать в убыток» и навариваться на продаже игр.

Просто зачем сейчас среднему человеку держать дома мощный компьютер? Да и вообще зачем люди сейчас держат дома десктопы/нотебуки?

И чем вариант с каким-нибудь хромбуком будет хуже для среднего человека? Особенно если с него можно будет играть в ААА игры, обрабатывать фото-видео и работать с документами? Особенно если такой вариант будет дешевле чем держать компьютер и/или игровую приставку?
Просто зачем сейчас среднему человеку держать дома мощный компьютер? Да и вообще зачем люди сейчас держат дома десктопы/нотебуки?

Потому что это дешевле. Внезапно. И устойчиво к потерям связи.

Если хромбуки и облачные сервисы станут дешевле собственных вычислительных мощностей (пока что это совершенно наоборот), и качество связи достигнет такой величины, чтоб существенный процент населения никогда не покидал зоны с хорошим каналом (пока что это абсолютно не выполняется примерно нигде, и это даже с учётом того, что 3G/4G через стенки пробивает куда лучше 5G) — тогда да.

Сейчас модель распространения облачных сервисов — это только лишь «вам не надо платить много и сразу» и «если вы играете (например) по чуть-чуть, то вам будет дешевле облако». При этом для облачного гейминга вам реально надо играть не более, чем по чуть-чуть (десяток и менее часов в неделю, например, когда я в свое время считал цены уже дохлого onlive), чтоб говорить о паритете по сравнению с покупкой геймерского ПК на 8-10 лет.

А сейчас, когда эти сервисы предлагают подписочную модель (цена в месяц, и неважно, сколько вы пользуетесь) — это вообще просто финансово невыгодно, если у вас есть деньги на собственное железо. Тот же GF Now, по 8 баксов в месяц, за десять лет слупит с вас 960 баксов, в то время, как средний геймерский комп стоит 1000; при этом играть вы сможете только в ассортимент GF Now, который воображение решительно не поражает.
Потому что это дешевле. Внезапно.

В каком месте это дешевле? Сколько сейчас стоит игровой комп, который тянет новейшие игры? Как часто его надо менять? Сколько стоит комбинация «рабочей лошадки» плюс игровая приставка?
А сколько стоит хромбук? Даже если скажем добавить подписку на игровой сервис из облака?

И устойчиво к потерям связи.

А это для большинства уже сейчас не аргумент. Они уже сейчас без сети жить не могут. То есть им банально ни комп, ни игровая приставка без сети особо и не нужны.

Если хромбуки и облачные сервисы станут дешевле собственных вычислительных мощностей (пока что это совершенно наоборот), и качество связи достигнет такой величины, чтоб существенный процент населения никогда не покидал зоны с хорошим каналом

Это на мой взгляд не вопрос «если станут», это вопрос «когда» такое произойдёт. То есть если не будет каких-то глобальных катастроф и мир будет развиваться дальше, то это достаточно быстро произойдёт. Я бы даже cказал что самое позднее после массового распространения 5G.
А возможно ли добиться такой стабильности интернет соединения, которые нужны всем этим облачным сервисам? Не столько в технологическом плане, сколько в плане бизнеса. В США например ужасная интернет-связь, но не потому что США это страна третьего мира, а потому что там монополия на интернет. Вы либо берете что есть, либо не берете вообще. Возможно такое когда-то произойдет, но точно не на наш век. А возможно человечество к этому моменту вымрет и интернет никому не будет нужен
Ну на мой взгляд как раз таки «в плане бизнеса» как только гуглам-майкрософтам-амазонам будет выгодно чтобы у вас был этот самый стабильный интернет, то он очень быстро у вас появится.

То есть либо имеющихся монополистов прижмут немного, либо будет какая-нибудь альтернатива вроде того же старлинка.
В каком месте это дешевле? Сколько сейчас стоит игровой комп, который тянет новейшие игры? Как часто его надо менять?

Средний геймерский комп (который современные игры прекрасно «тянет», но не на максимуме) уже очень долгое время стоит около 1000$ и амортизируется за 5 лет наполовину. То есть, 1000$ сейчас и +500$ каждые 5 лет.

Для «топового» начальная цена раза в два (и более, там уже ценообразование идёт за «понты») больше, амортизация — процентов на 50% больше, за счёт того, что топовое железо гораздо дольше остаётся актуальным.

А сколько стоит хромбук? Даже если скажем добавить подписку на игровой сервис из облака?

Выше написал. В лучшем случае вы заплатите плюс-минус столько же и будете жить по правилам облачного сервиса, в уютном мирке, на порядки меньшем по размеру, чем собственный гейминг. В худшем случае (для сервисов, позволяющих играть в плюс-минус всё) вы заплатите гораздо больше.

А это для большинства уже сейчас не аргумент. Они уже сейчас без сети жить не могут.

Вы путаете наличие интернета «вообще» (с плохим каналом, с потерями, с перебоями, и так далее) и наличие хорошего канала в каждый момент времени потребления облачных сервисов.
Для облачных сервисов требуется второе, иначе оно просто не работает. Для всего остального, исключая потоковое видео, нужно только лишь первое. Да и потоковое видео накладывает на качество связи гораздо меньшие требования, чем облачные сервисы.
В лучшем случае вы заплатите плюс-минус столько же и будете жить по правилам облачного сервиса, в уютном мирке, на порядки меньшем по размеру, чем собственный гейминг

Ну у вас там получилось минимум 100$ в год. Я бы сказал что «подписка на облако» будет стоить не больше 5$ в месяц. А то и меньше. Плюс ещё где-то 100$ в пять лет на хромбук. Я бы сказал что это дешевле.
И вряд ли «правила облачного сервиса» будут хуже того бардака что мы сейчас имеем с приставками.

Вы путаете наличие интернета «вообще»

Нет, не путаю. Я просто учитываю что мир меняется. Десять лет назад и обычный интернет для большинства не был чем-то критичным…
Я бы сказал что «подписка на облако» будет стоить не больше 5$ в месяц.

Где и когда? Пока что самый дешевый провайдер (GF Now) предлагает 8$ в месяц, а для РФ и вовсе около 10$.

И вряд ли «правила облачного сервиса» будут хуже того бардака что мы сейчас имеем с приставками.

Приставки имеют примерно те же проблемы модели ценообразования, что и облачный гейминг — если вы не готовы играть только в уютном маленьком мирке с минимальным количеством покупок, то консоль + игры для вас быстро станет дороже в долговременном масштабе, чем ПК + гораздо более дешевые игры + гораздо более лучшая амортизация.

Нет, не путаю. Я просто учитываю что мир меняется. Десять лет назад и обычный интернет для большинства не был чем-то критичным…

Мир не меняется. Меняется общество. И в тех частях, которые упираются в законы физики (покрытие высококачественным беспроводным интернетом) или банально в социальные принципы (благодаря которым общечеловеческий тренд на специализацию и глобализацию всё еще не привел к унификации, например, государств, хотя казалось бы) — оно меняется очень-очень медленно и печально.
Где и когда? Пока что самый дешевый провайдер (GF Now) предлагает 8$ в месяц, а для РФ и вовсе около 10$.

Ну ок, давайте возьмём 8-10$. И это на старте/в первый год.
Сколько стоил тот же интернет в первые годы своего появления? Сколько он стоит сейчас? Или скажем мобильный интернет?

Приставки имеют примерно те же проблемы модели ценообразования, что и облачный гейминг

И при этом куча народа им пользуется. Особенно в США/Европе. Я бы наверное даже сказал что больше народа играет на приставках чем на десктопах. А уж если опять же посмотреть только на молодёжь и подростков…

Мир не меняется. Меняется общество.

О да, очень важная разница в контексте нашей дискуссии.

И в тех частях, которые упираются в законы физики (покрытие высококачественным беспроводным интернетом) или банально в социальные принципы

Лично я не вижу ни законов физики, ни социальных принципов, которые сделали бы в принципе невозможным «компьютер из облака». И ладно я, но похоже гуглы-амазоны-майкрософты их тоже не видят.
Ну ок, давайте возьмём 8-10$. И это на старте/в первый год.
Сколько стоил тот же интернет в первые годы своего появления? Сколько он стоит сейчас? Или скажем мобильный интернет?

Но интернет не особо дешевеет. Вернее, минимальная граница («самый дешевый интернет») не сильно-то и двигается. Сейчас в 2020 вы по этой границе получите то, за что в 2000 году нужно было отдать безумные деньги — но сама граница особо не двигается. Существует определенная доля fixed costs на каждого потребителя, которая и не позволяет опускать цену еще дальше.

С чего вы взяли, что у цен облачного гейминга есть какой-то существенный запас для падения? Наоборот, я бы сказал, что именно сейчас сервисы облачного гейминга как никогда заинтересованы в привлечении пользователей по минимальным ценам, а в дальнейшем, если «взлетят», то будут цены повышать (скорее всего не напрямую через увеличение подписки, а другими путями).

И при этом куча народа им пользуется. Особенно в США/Европе. Я бы наверное даже сказал что больше народа играет на приставках чем на десктопах. А уж если опять же посмотреть только на молодёжь и подростков…

ПК-гейминг хоронят еще с третьего поколения консолей, ага. Всё хоронят и хоронят. Сначала в пользу консолей хоронили, потом в пользу мобил продолжили.
Только до сих пор не хоронится чё-то. Наверное потому, что это не рынки с прямой конкуренцией.

Лично я не вижу ни законов физики, ни социальных принципов, которые сделали бы в принципе невозможным «компьютер из облака».

А тут кто-то говорил про «в принципе»? Я не сомневаюсь, что рано или поздно мы дойдем и до единого человечества (правда, возможно, для этого придётся сначала переехать в космос и создать там деление по пространственному признаку, так что единство будет только планетарное, не более), и до единой организационной стуктуры, и до одного большого компьютера для всех.

Вот только в сроках таковой глобализации я буду очень и очень консервативен. Я уже прожил немало событий, отчётливо говорящих о том, что антиглобализационных трендов у человечества столько, что глобализация хоть и идёт, но очень и очень медленно, и практически не ускоряется. То есть, главные причины антиглобализации — социальные и культурные, меняющиеся с примерно одной и той же скоростью (скоростью смены поколений).
Но интернет не особо дешевеет. Вернее, минимальная граница («самый дешевый интернет») не сильно-то и двигается.

Это может от конкретной страны зависит, но у нас это точно не так. Сейчас я спокойно могу себе взять пару-тройку гигабайт за пару евро. Поначалу минимальные цены измерялись в десятках евро. И отнюдь не за гигабайты.

С чего вы взяли, что у цен облачного гейминга есть какой-то существенный запас для падения?

Потому что эти самые «облачные мощности» не так уж и много стоят. А сейчас вы в этих самых сервисах получаете не только мощности, но и подписки на сами игры.

Только до сих пор не хоронится чё-то. Наверное потому, что это не рынки с прямой конкуренцией

Хорониться он конечно не хоронится, но потихоньку сдувается. Несмотря на то что это не рынки с прямой конкуренцией. А теперь есть ещё и шанс что эта самая прямая конкуренция появится.

Вот только в сроках таковой глобализации я буду очень и очень консервативен.

Причём здесь какая-то глобализация а ля единое человечество? Это банальный тренд вроде стриминга видео или музыки. И десять-двадцать-тридцать лет назад тоже мало кто мог подумать что мы сейчас будем себе в метро, автобусах или поездах стримить серии в Full HD.

И я ещё великолепно помню как мне кто-то лет десять назад доказывал что нетфликс и ему подобные никогда не «взлетят» и что большинство таким пользоваться не будет.
Поначалу минимальные цены измерялись в десятках евро.

Я про РФ — «поначалу» был dialup по времени, но его стоимость, с поправкой на инфляцию — была очень похожа на текущие минимальные цены. Конечно, сейчас за эти цены получаем 24/7 и безлимит.

Потому что эти самые «облачные мощности» не так уж и много стоят. А сейчас вы в этих самых сервисах получаете не только мощности, но и подписки на сами игры.

И что? От где-то там крутящихся серверов до возможности человеку поиграть в игру через облако — огромный путь. К оценке себестоимости нужно относиться серьезно, а не «ну это всё облако, значит дешево».

Хорониться он конечно не хоронится, но потихоньку сдувается.

Это именно то, что я и описываю словом «хоронят» — вера в то, что что-то там «сдувается». ПК-гейминг всё так же растёт все эти годы (по мере увеличения доли людей, охваченных компьютеризацией, и это увеличение всё еще очень далеко от остановки). Другое дело, что консолерынок одно время рос значительно быстрее, а теперь вот мобилорынок растёт быстрее.
Но когда у Пети в 2000 году было 10 яблок, а в 2020 1000 — говорить «это всё сдувается» на основании того, что Вася начал в 2010 году с одного яблока, а сейчас у него их 10 000 — в высшей степени странно.

И я ещё великолепно помню как мне кто-то лет десять назад доказывал что нетфликс и ему подобные никогда не «взлетят» и что большинство таким пользоваться не будет.

Нетфликс продолжает оставаться сильно убыточным, к слову. И живёт засчёт инвесторских вливаний. И не смог объединить рынок, из-за чего люди типа меня сказали «ага!» и вернулись на старую-добрую модель торрентов, потому что если платить нетфликсу подписку и смотреть кинцо — это для меня очень удобно и экономически обосновано, то платить нетфликсу, HBO, и еще полдюжине других провайдеров — экономически бессмысленно (это уже очень серьезные ежемесячные расходы), и плюс к тому крайне неудобно.

Это просто зарисовочка к вашему «нетфликс взлетел». Зато вот для потребления контента torrent edition стриминговые сервисы действительно делают великую вещь — получать высококачественный видеопоток для последующего выкладывания торрента никогда раньше не было так просто и удобно.
Я про РФ

Ну с тем что в РФ «облачность» в том или ином виде может придти с неким «запозданием» или в каком-то виде и вообще не придти я наверное спорить не буду…

К оценке себестоимости нужно относиться серьезно, а не «ну это всё облако, значит дешево».

Ок. Вы можете сказать сколь из этих 8-10$ составляет цена подписки на игры, а сколько сами мощности?

ПК-гейминг всё так же растёт все эти годы (по мере увеличения доли людей, охваченных компьютеризацией, и это увеличение всё еще очень далеко от остановки)

Это на мой взгляд всё-таки немного о другом. И это не будет продолжаться бесконечно. Особенно если вдруг появятся дешёвые и доступные альтернативы.

Ну с тем что в РФ «облачность» в том или ином виде может придти с неким «запозданием» или в каком-то виде и вообще не придти я наверное спорить не буду…

В определенных частях РФ с качеством каналов, в том числе беспроводных — сильно лучше, чем в этих ваших европах, и очень сильно лучше, чем в США.
Правда, неясно, что будет с 5G, но как я уже писал выше — 5G плохо пробивает стенки, так что я бы в обозримом будущем не надеялся на хорошее покрытие 5G за пределами сугубо отдельных мест и окрестностей.

Ок. Вы можете сказать сколь из этих 8-10$ составляет цена подписки на игры, а сколько сами мощности?

Эм. А помимо этого расходов никаких нет? Точно-точно?

Особенно если вдруг появятся дешёвые и доступные альтернативы.

Ну вот консоли и мобилы «альтернативами» ПК-геймингу не являются. У них свои рынки и свой охват, и конкуренция тут только окольная (за время пользователя, но за время много что еще конкурирует, тот же фейсбучик).
А еще не надо забывать про VR, который уже прошел фазу бесполезной игрушки сугубо для фанатов, и потихоньку выгрызает себе место под солнцем, несмотря на море технических проблем и сложностей. И это сейчас целиком и полностью относится к ПК-геймингу.
Эм. А помимо этого расходов никаких нет? Точно-точно?

Ну давайте опять переформулирую: сколько по вашему составляет стоимость подписки на игры и сколько будет стоить всё остальное?
Консоль с большой вероятностью можно будет в случае необходимости достать лет через десять и использовать по прямому назначению, особенно если есть либо физические носители, либо можно делать бекап файлов. Облако на такое не способно
Сколько стоит комбинация «рабочей лошадки» плюс игровая приставка?

Она(в моём, например, случае) стоит как одна "рабочая лошадка" без приставки. Области эти вполне могут пересекаться до полного совпадения — видеокарта нормальная, проц шустрый, памяти много, диск под разное и SSD под выделенное — это и для разработки, и для 3Д, и для игр пойдёт.
При этом рабочая лошадка одной эпохи с приставкой лучше приставки и по картинке, и по предложенному выбору.

UFO just landed and posted this here
Вы из тех, кто всё еще верит, что wasm — это чтоб можно было для веба писать на чём угодно? Ну, блаженны верующие.
Вы видимо из тех, кто верит, что JS — это язык на котором веб будет работать до погасания Солнца.
Нет конечно. Но веб не будет работать на всяких сях, шарпах, и прочем. Веб уже одно время на этом работал, и благополучно съехал с этого на JS. Подумайте над тем, почему.

А веб если и будет далее работать на чем-то другом, то это будет новая технология.
WebAssembly весьма перспективна и позволяет и писать фактически на чем угодно. Так что может еще как говорится при нашей жизни странный язык JS будет отправлен в историю, по крайней мере, частично.
Да, только на выходе — огромные бандлы, на которые даже всякие реакты-ангуляры смотрят с усмешкой, которые абсолютно никак не дробятся для того, чтоб можно было подгружать сайт по частям, и которые работают с обычной скоростью браузера — потому что если как числодробилка wasm может быть куда быстрее движка JS, то вот передача данных в документ там происходит с обычной скоростью, и манипуляции с DOM — аналогично.

Так что вы пишите, пишите. Если вдруг это кому-то станет нужным — сообщите отдельно.
Почему бандлы обязательно огромные и не дробятся?
Стандартная библиотека js уже идёт в браузере. Стандартная библиотека того что собрано в wasm должно идти уже вместе с этим wasm, иначе работать не будет.
Хм, а что конкретно вы в данном случае понимаете под «стандартная библиотека js»?
И почему какая-нибудь «стандартная библиотека wasm» не может точно также идти в браузере? Например если вдруг все заинтересованные стороны вдруг смогут договориться о каком-то общем стандарте?
Хм, а что конкретно вы в данном случае понимаете под «стандартная библиотека js»?
Реализация строк, массивов, списков, методов типа map, sort и так далее.
И почему какая-нибудь «стандартная библиотека wasm» не может точно также идти в браузере?
Может, но для этого надо договориться. Стандартная библиотека для rust и c# будет значительно отличаться, и переиспользовать это к примеру в golang — вряд ли получиться. Таким образом на каждый язык по стандартной библиотеке, а ещё нужно будет кешировать кучу популярных фреймворков для каждого языка.
ещё нужно будет кешировать кучу популярных фреймворков для каждого языка

С каких пор у JS с зоопарком пакетов здесь есть преимущество?)
Их суммарное количество. Одно дело закешировать 10 популярных файлов, и другое 100 не очень.
Это не может быть конкурентным преимуществом отдельной технологии. Юзер все равно будет качать что-нибудь, будть то react/angular очередной версии или же какой-нибудь популярный X.

То что у вас один зоопарк, а не помноженный на число языков.

Реализация строк, массивов, списков, методов типа map, sort и так далее.

Ну там скорее целый рантайм с движком.

Может, но для этого надо договориться

Ну с самим JavaScript как-то ведь договорились.

Таким образом на каждый язык по стандартной библиотеке

Ну или всё таки договориться и остановиться на каком-то одном языке.

кешировать кучу популярных фреймворков для каждого языка.

Ну вон сейчас что только не кэшируется и большинству на это похоже просто наплевать.
И почему какая-нибудь «стандартная библиотека wasm» не может точно также идти в браузере?

Полагаю, проблема здесь в том, что wasm — существенно более низкоуровневая вещь, чем js. В нём вообще нет понятия "строк, массивов, списков" и тому подобного, в отличие от js. Максимум, чего мы здесь можем ожидать, — некоторый C-подобный API, предлагаемый при компиляции, вместо прямого доступа к линейной памяти (как это сделано сейчас).

Да, вот именно. С WebAssembly каждый сайт будет загружать свою реализацию строк, массивов и других нужных типов.


Все пеняют на JavaScript за пакет left-pad (хотя его уже давно перенесли в stdlib, но хейтеры не унимаются), но при этом нормально относятся к тому что с WASM каждая страница загружает свою реализацию примитивов.

То что в WASM появятся интрисинки для строк/массивов и прочего вы не рассматриваете? Когда вы делаете JSON.stringify() там прям так и пишут [native code]. Что мне мешает вызвать магическую функцию, которая реализована в браузере?


Точно так же если дадут АПИ к браузерному ГЦ чтобы всяким шарпам и жабам не нужно было тащить свой, то все эти бандлы резко похудеют.


В общем, размеры не-жабовских васмов это инженерная проблема, а не теоретическая, которую думаю достаточно скоро порешают.

Я такой вариант рассматриваю и горячо поддерживаю.


Мой комментарий был про двойные стандарты – если какой-то фичи нет в Javascript – то всё, язык ни на что не годен. В то же время если какой-то фичи нет в другом языке/рантайме – ничего страшного, скоро добавят.

Вы следите за этим? Они вообще планируют это делать? Просто мне кажется что стоит только начать и сообщество сожрёт себя в извечных холиварах о том, какая структура данных лучше, какой подход правильнее и чья религия истинная… Или не сожрёт?

Вполуха. В целом считаю, что тенденция идёт к тому чтобы сделать что-то вроде жвм на браузере, где сам браузер предоставляет рантайм, а разные языки в этом живут и используют общую кодовую базу. Надо было сразу жабу в браузеры засунуть 25 лет назад, но что сделано, то сделано. У ВАСМа на официальном сайте есть неплохое объяснение "почему мы решили делать свою вм, а не использовали жвм/ллвм/...", в целом их мотивация понятна. Но если бы не было этой фрагментации, мне кажется, было бы куда лучше для всех.


В итоге, всё равно к этому идём, но длинным путём.

То, что собрано в WASM не требует всей стандартной библиотеки же, достаточно собрать только то, что используется. Да и есть поддержка динамической линковки, что вполне кэшабельно.

И все это в компактном бинарном формате.
чтоб можно было подгружать сайт по частям, и которые работают с обычной скоростью браузера — потому что если как числодробилка wasm может быть куда быстрее движка JS, то вот передача данных в документ там происходит с обычной скоростью, и манипуляции с DOM — аналогично.
Не факт, что и DOM и вообще веб в текущем состоянии останется навсегда, нужно мыслить в будущее:
habr.com/ru/post/500822

Blazor, так-то уже вполне позволяет на шарик писать сайтики. Ага.

Конечно позволяет. Вы главное не забудьте посмотреть на итоговый размер этого всего великолепия.

Альтернативы в истории были более-менее популярные: VBScript, JScript. Но рынок решил JavaScript лучше

Ну на мой взгляд в данной ситуации пожалуй не стоит использовать словосочетание «рынок решил». То есть да, JavaScript оказался «живучее». Но его выбоали совсем не из экономических соображений. И я бы даже сказал что основную роль сыграла скорее «политика».

Ну и как бы не надо забывать что JavaScript'у уже 25 лет и за это время в ИТ очень многое очень сильно изменилось.

А из каких соображений IE проиграл войну браузеров?

Ну на эту тему можно отдельную статью написать :)
Вот в конкретно упомянутом вами случае порешал не рынок, а федеральная антимонопольная служба.

Можно поподробнее?

Уф, напугали, я уж думал именно ФАС как-то порешала.


Но решил таки рынок, имхо, устранив искусственные ограничения со стороны MS. Хотя лично я во времена IE5+ писал на JS, просто чтоб не только под IE работало. А так, кто знает, как бы сейчас выглядел веб, если бы MS в те годы решила выложить исходники если не IE, то движка VBScript под MIT или Apache

Если выбирать между вб и жс, то лучше уж жс, право слово

Если отбросить идеологические убеждения, то я на 100% не уверен, что какой-нибудь ES3 по всем статьям лучше

Ну у меня в школе был бейсик (до того как я уже в универе начал паскаль изучать), и все эти DIM FOO BAR выбешивали, и казались очень многословными (хотя не с паскалем сравнивать, конечно).


Плюс я ж дотнетчик, периодически вижу как на вб.нет выглядит код, и перекрещиваюсь каждый раз))


С другой стороны, тайпскрипт на вб был бы куда ближе к обычным ооп языкам, и возможно было бы всё получше. А может и нет. Впрочем, ничего уже не поменять.

UFO just landed and posted this here

Так завезли же целочисленные типы недавно

При все при этом — потоки тоже есть. Причем сейчас даже не нужно и симулировать подпроцессами, достаточно require('worker_threads').

Проблема JS в том, что код на нём низкоинформативен. И когда вы пытаетесь вникнуть в чужой проект (или в свой собственный полтора года спустя), вам становится очень грустно.
Тут вот радовались, что в JS не нужно париться с явным преобразованием типов. Никаких дурацких strToInt и подобного, просто суй любые данные и они сами преобразуются. Но ведь тем самым мы лишаем себя важной информации. Теперь о типах переменных остаётся только догадываться. Тогда как встретив в коде strToInt, читатель сразу же поймёт, что передаваемые внутрь данные — строка, а то, что на выходе — число, причём гарантированно целое.
И так там везде. В итоге понять: а что же, чёрт возьми, должно передаваться в эту функцию — та ещё задача. JS — единственный язык на моей памяти, для изучения чужого кода в котором мне приходилось постоянно юзать отладчик. Потому что иначе ну просто не понять, что вообще должно падать в недра глубоко вложенных замыканий и прочих микро-функций.
Асинхронщина — отдельная пакость. Дело в том, что человеческий мозг намного лучше воспринимает алгоритм, действия которого выполняются последовательно, нежели когда на каждом шагу всего лишь создаётся «зарубка на память», которая потом сдетонирует при достижении определённых условий. Бывает так, что просто даже сообразить, при каких условиях выполнится данный участок кода, и выполнится ли он вообще, оказывается чрезвычайно сложно.
И вот вместо того, чтобы возложить формирование асинхронного кода на компилятор, позволяя кодеру работать с ним так, как будто бы он был синхронным, какому-то умнику показалось неплохой идеей вытащить концепцию монады из мира функциональщины и, изрядно покоцав её хакерской монтировкой, обозвать получившуюся хрень промисом.
Код на промисах выглядит гадко, его просто даже неприятно изучать — воображение словно бы «вязнет», приходится предпринимать дополнительные усилия, чтобы держать в памяти полную картину происходящего.
Не могу согласиться, что код на JS низкоинформативен, особенно если документировать его. Мне конечно однажды встретился проект, где код на jQuery был написан в одном файле и на несколько тысяч строк, но это не проблема языка, а человека, который все это написал. А работать с асинхронщиной довольно просто, если понять, как он работает и что к мультипоточности он никакого отношения не имеет. Но если вы пишите действительно большой проект, то скорее всего вам нужен TS, а не JS
UFO just landed and posted this here
Соглашусь с частью ваших замечаний, но с некоторыми не соглашусь.

код на нём низкоинформативен

Зависит от компетентности разработчика. Хороший разработчик способен писать читаемый, понятный, «чистый» код.

о типах переменных остаётся только догадываться

Порой сама среда разработки способна подсказать тип на основе синтаксического анализа. Также помогает jsdoc и принципы контрактного программирования. Если уж совсем хочется typesafety, то TypeScript ваш вариант.

Асинхронщина — отдельная пакость

В мире js используется кооперативная многозадачность. И по опыту скажу, что для простых задач это лучше вытесняющей многозадачности (aka многопоточность), где с синхронизацией (мьютексы, атомики, happens before, видимость памяти) можно голову сломать.

мозг намного лучше воспринимает алгоритм, действия которого выполняются последовательно

Все верно, для этого в спеку ввели синтаксис async / await, который позволяет писать код последовательно:

class RestApi {
  async doSome() {
     ...
  }
}

async function main() {
  const rest = new RestApi();
  const { result } = await rest.doSome();
  ...
}


В заключении скажу, js не идеален, никто с этим не спорит. Но язык развивается, совершенствуется, и думаю, он еще нас приятно удивит.
JS — единственный язык на моей памяти, для изучения чужого кода в котором мне приходилось постоянно юзать отладчик.

Питон имеет аналогичную проблему. По листингу Паскаля я почти сразу могу понять и рассказать что там происходит. В Питоне — увы, только отладка. И, ладно бы строки и целые. Хуже когда строки, целые, классы, кортежи — всё абсолютно одинаковое. И только отлаживая можно понять что происходит в коде.

А ещё ruby, php, groovy, lua, etc. Любой язык где нет достаточного контекста чтобы можно было быстро понять где что и как. Т.е. динамически-типизированные.

И вот вместо того, чтобы возложить формирование асинхронного кода на компилятор, позволяя кодеру работать с ним так, как будто бы он был синхронным, какому-то умнику показалось неплохой идеей вытащить концепцию монады из мира функциональщины и, изрядно покоцав её хакерской монтировкой, обозвать получившуюся хрень промисом.

Эммм, простите, а при чем тут функциональщина и при чем тут монады? Вот вам вполне мондический код на хаскелле:


getCommentsAsync :: (MonadHttp m) => m ([UserComment])
getCommentsAsync  = do
 commentIds <- httpGet "www.myserver.com/api/comments"
 let commentPromises = (\x -> httpGet "www.myserver.com/api/comments/" ++ x) <$> commentIds
 comments <- traverse toComment commentPromises 
 pure comments

Он непоследовательный? Может, компилятор тут недостаточно его переписывает, чтобы он выглядел и читался последовательно?


Ну я прям не знаю, "ФП" это какой-то "либерал" от мира программирования, все беды от него, и всегда стоит его пнуть мимоходом, даже если оно рядом не стояло.

Мне кажется многим не нравится js потому что он не похож на другие языки. Упомянутый Паскаль вполне похож на C, java похожа на C++. Питон отличается, но его спасает его простота. А js отличается от них всех. Лично мои ощущения от него можно сравнить с моим первым знакомством с языком запросов в базы данных. В них ведь всё «не как у людей», где простые циклы, условия, примитивные переменные, к которым я привык? Там переиначена общая концепция. По-другому нужно обращаться получаемыми объектами. JavaScript производит схожее впечатление.

После добавления сахара для классов уже нельзя, по-моему, говорить о каких-то качественных отличиях.

Приходилось разрабатывать движок JS, полноценный, ушедший в большой продакшен. Не существует цензурного слова, чтобы описать то количество брани, которое ушло в адрес авторов ECMAScript. А уж при анализе того, что пишут JS разрабы…
буду признателен статье на эту тему. И чем он отличается от V8.
Как-нибудь напишу.

tl;dr: Будь v8 супер гибким и конфигурируемым — все бы сели на него. А так пилятся движки для тех случаев, где V8 может не подойти

Отличия альтернативных от v8 движков — это то, для чего они заточены (кроме SpiderMonkey и что там у макоси). V8 — это монстр, который жрет и перформит, да еще и compliant со всеми стандартами (что местами порождает оверхед по перфу, зарубая оптимизации).

А помимо этого есть мир девайсов с меньшей памятью, с меньшей производительностью. Или, требуется только поддержка подмножества ECMAScript.

Или есть специальные юзкейсы. У Фейсбука был в разработке (сейчас уже вроде более-менее стабильный) Гермес — заточенный под React. У Pebble — JerryScript, заточенный под IoT кейсы.
Гермес — заточенный под React

под React Native (в частности Android)*
Зарегистрировался только ради этого коммента.

Для начала напомню эту статью. Ознакомились? Отлично, едем дальше.

Ответьте для себя на простой вопрос: можете ли вы написать не сильно сложное приложение на js без использования сторонних библиотек, которые фиксят большинство приятных особенностей языка, перечисленных в статье выше? Ага. А на ES5? А сложное?

«При чём тут вообще ES5? Зачем писать без библиотек? Зачем писать сложные приложения на js?» — спросит любопытный начинающий айтишник. А я ему отвечу: а потому, что, во-первых, твои коллеги утверждают, что жс прекрасен сам по себе, и, во-вторых, именно в ES5 и без библиотек жаваскрипт ещё не потерял свою идеологическую подоплёку. После ES5 жаваскрипт стал меняться, и все проповедники жаваскрипта возрадовались. Только чему? Тому, что их любимый необычный язык начал меняться в сторону нормальных языков? Как иронично. Жаль, что ребята не понимают, что это так и останется стремлением, и никакие косметические изменения и добавление синтаксического сахара не исправят убогость языка, заложенную на этапе проектирования (ха-ха, ну а что ты хотел за 15 дней?)

Современным жаваскриптом нельзя пользоваться без библиотек, которые являются, по сути, костылями для этого чудом выжившего порождения бездны. И в будущем ничего не изменится. Вы можете спросить, а что же тогда не придумали новый язык на замену js, а те, что придумали, не выжили на рынке? А я отвечу: потому что в арсенале жс-кодеров есть миллионы пакетов с костылями, которые и сортировку адекватную добавляют, и позволяют вменяемо работать с датами, и, прости господи, добавляют нормальные циклы! А если есть костыли, то зачем устраивать шоковую терапию уже устоявшейся индустрии костылепользования и костылеписательства? Наверное, первое задание для учеников всяких курсов войти в ойти — вызубрить список библиотек с костылями.

Можете включить классическую мантру «не нравится — значит, ты просто не осилил». Мне плевать, доказывать обратное я не буду, а моё мнение от этого не изменится — жаваскрипт должен умереть, и чем быстрее, тем лучше. Жаль только, что это случится не при моей жизни.

Кстати, попробуйте другие языки программирования — вдруг синдром утёнка пройдёт?
пока дешево — не умрет. И ваше (равно как и мое или кучи других комментаторов) мнение никого не будет интересовать.
Это просто бизнес.
Современным жаваскриптом нельзя пользоваться без библиотек, которые являются, по сути, костылями для этого чудом выжившего порождения бездны.
Можно. Есть несколько неприятных моментов, которые приходится постоянно держать в голове, но можно.
Не примите за осуждение, просто небольшие замечания по вашему репо:
1. Не хватает Readme с описанием проекта. Иначе, только провалившись в исходники, можно понять, что это свой игровой движок для шашек, домино и т.п.
2. Проект видимо живет очень очень давно, поскольку нет системы сборки, это же чудовищно неудобно оперировать десятками файлов. Также нет и намека на es6 и выше, а в вашем движке, думаю, это сильно бы упростило жизнь.
3. В html не хватает doctype (без него браузеры работают в quirk mode). Inline стилей в html лучше избегать, также как избегать абсолютных размеров вида 411px.

Думаю, если порефакторить код, сделать его читаемым, расширяемым, прикрутить webpack, дополнить документацией, то у вас выйдет очень популярный проект.
Поддерживаю все ваши замечания и возможно сейчас удивлю вас ещё больше. Весь проект написан в редакторе FAR-а, без всяких IDE. Не сомневаюсь, что есть куча вещей, которые упростили бы мне жизнь, но… я не вижу причин тратить на них время в рамках этого проекта. По работе, вот прямо сейчас, я использую NodeJS, Nest, Angular, но здесь не вижу им применения. До тех пор пока разработку веду я один, не вижу смысла менять свои привычки. И да, в том что касается html — верстальщик я хреновый (я вообще, по базам данных больше).
Вы видимо не прочли статью, раз пишете так, будто кто-то назвал JS лучшим языком в мире, который спасет мир. Я ни в коем случае такого не утверждаю и нигде такого не писал. Он способен решать задачи, для которых его создали и даже немного больше. Для разработки веб-приложений он хорошо подходит, особенно после появления PWA. Если вы его используете в другом месте, то это уже вы виноваты, что неправильно выбрали язык
Для фронта он хорошо подходит только потому, что нет альтернатив. Безальтернативность — это единственное, хм, преимущество js.

Способен решать задачи? Да, способен. Как и любой другой тьюринг-полный язык. Я же не спорю, способен. К сожалению. Иначе были бы надежды на прогресс.

Меня возмущает не то, что js так себе язык, а то, что его сообщество упорно отказывается это признавать. Вон комментатор ниже заявляет — у js нет косяков, у js есть особенности. Чем-то напоминает ультраполиткорректный SJW-язык. Не инвалиды, а люди с особыми потребностями. Не проблемы в дизайне языка, а язык с особыми архитектурными решениями.

В сообществе любого языка есть множество людей, которые будут доказывать его превосходство над остальными языками вопреки реальным фактам. Это не делает его плохим. У JavaScript была альтернатива в виде JScript, но по каким-то причинам она проиграла. Возможно мне никогда не приходилось работать с проектом, где все эти недостатки JS стали бы проблемой, возможно мне просто очень повезло, а вам нет. Но когда мне пришлось разрабатывать UI на JavaFX, это было ужасным опытом. Хоть там был не JavaScript, а к Java, как и в принципе к другим ЯП неприязни у меня нет

JScript — суть тот же ECMAScript, со всеми его недостатками.

Но когда мне пришлось разрабатывать UI на JavaFX, это было ужасным опытом.

Но ты же не будешь после этого говорить, что JavaFX — удобный инструмент, только потому что он может решить поставленную задачу? А почему жс-сообщество так говорит?
Могут ли другие считать тебя глупцом и неосилятором, если ты выразишь своё негативное мнение о JavaFX? А почему жс-сообщество так может?

Да нет. Я скорее всего откажусь работать с ним, если у меня будет такая возможность. Но если кто-то его использует и ему норм, то я не стану доказывать, что он ничего не понимает и ему срочно нужно сменить технологию, а его нынешняя должна умереть. У этой технологии есть свой ареал применения и я не собираюсь туда лезть ибо мне это не особо интересно.


Люди, которые утверждают что их технология лучшая есть везде. Это вызвано тем, что они ещё неопытные и не сталкивались с недостатками их технологий. Просто вкатиться в веб и изучить JS проще чем ту же Джаву, возможно поэтому таких в JS сообществе больше

Но если кто-то его использует и ему норм, то я не стану доказывать, что он ничего не понимает и ему срочно нужно сменить технологию, а его нынешняя должна умереть.

Но если кто-то использует и ему не норм, а тебе норм, то можно прийти и начать доказывать, это всё на самом деле норм, автор просто не понимает технологию.
Так что ли?

Если кому-то не норм и он неиронично начинает хейтить технологию, то да. Ведь это статься не про JS, она про хейт в сторону ткхнологий, которые применяют, которыми решают задачи и делают это довольно хорошо, но почему-то хейтеру это не нравится, ведь его ЯП работает по другому. Вместо JS ту мог бы быть любой другой язык, просто я прочел статью и комменты к ннй именно о нём, вот и решил написать свою. Печально, что я не смог донести эту идею правильно. Возможно мне ещё учиться и учиться правильно подавать информацию, а возможно вы попросту не хотите этого понимать, потому что статья про JS

кто-то обижает мой жаваскрипт

А вы достойный сын своего сообщества.

Так, давайте ещё раз: почему нельзя критиковать инструменты, которые применяют?
Современным жаваскриптом нельзя пользоваться без библиотек

Во-первых, можно, и сравнительно легко, если не выделываться и RTFMить. 20% фич языка покрывает 80% сценариев, в полном соответствии с древним правилом. С Typescript-ом же процесс вообще мало чем отличается от других языков, а местами становится даже много лучше, не в последнюю очередь благодаря дизайну, заложенному в JS. Любой дизайн языка даёт как плюсы, так и минусыж; хейтить минусы, не видя плюсов — это детский сад, штаны на лямках.


Во-вторых, как будто на других языках народ пишет без библиотек. Вот прям берут голый компилятор — и погнали, без единого импорта, ага.


попробуйте другие языки программирования

Какие советуете лично вы? Ужасно интересно увидеть языки, в которых всё так прекрасно, что стороние библиотеки никогда не нужны, и про них знать не нужно. А то вот когда я пишу на плюсах, то использую STL — костыль над голыми указателями, добавляющий адекватную сортировку, вменяемые даты, контейнеры, потоки и ещё туеву хучу всего. Если пишу на C#, то тоже использую всякие сторонние библиотеки и горожу интеропы, чтобы закостылить отсуствие/убогость нативной поддержки чего-либо нужного и важного.

Любой дизайн языка даёт как плюсы, так и минусыж; хейтить минусы, не видя плюсов — это детский сад, штаны на лямках.

Превозносить плюсы, закрывая глаза на минусы — это тогда что? Ясли?

Во-вторых, как будто на других языках народ пишет без библиотек. Вот прям берут голый компилятор — и погнали, без единого импорта, ага.

Прочитайте внимательно мой коммент.

Какие советуете лично вы?

Любые. Тогда можно будет наконец узреть минусы жс и больше не писать чушь в стиле «вы все просто не понимаете язык!»
Превозносить плюсы, закрывая глаза на минусы — это тогда что? Ясли?

Кто конкретно превозносит плюсы и закрывает глаза на минусы? У меня впечатление, что вы выдумали себе некоего персонажа, слепца, которому надо непременно раскрыть глаза, а то он сам не в курсе, какие в его языке недостатки.


Из того, что кто-то пишет про плюсы языка, вовсе не следует, что он не знает про недостатки или подводные камни. Или что он коварно скрывает эту инфу, чтобы никто не догадался.


И да, гыгы-статьи в духе "ой, смотрите, у них оператор равенство работает не так, как я ожидал, хотя я пишу совсем на другом языке" — это и есть "я не понимаю язык, не знаю, как работают его операторы, не знаю истории и почему так было сделано". Такие статьи можно написать про любой язык. "Хаха, в С++ в {кусок кода} UB, где казалось бы всё интуитивно ясно и никакого UB быть не должно!". "Ой, Rust не разрешает мне сделать {кусок кода}, что в моём любимом {подставить язык} делалось одной строчкой", и так далее.


Прочитайте внимательно мой коммент.

Я прочитал, но так и не понял, какие именно библиотеки я должен обязательно использовать, чтобы искоренить фатальные недостатки JS? Я как-то обхожусь без них. Можно назвать хотя бы одну, самую-самую необходимую библиотеку, исправляющую JS (полифиллы не считаем, потому что они костылят браузеры, а не язык)?


Любые

Ну возьмём С++ например. В нём недостатков? Нет костылей? Нельзя писать статьи про плюсы плюсов, не упоминая о недостатках в обязательном порядке? В каждую статью, где рассказывается чем хорош С++, приходите вы и расставляете точки над ё, раскрывая глаза на его убогости?

Кто конкретно превозносит плюсы и закрывает глаза на минусы?

Ну оглянитесь вокруг — что ни коммент или статья, так там минусы не минусы, а особенности, js же закономерно продолжает быть «the best language for awesome projects»

выдумали себе некоего персонажа

Да, я выдумал себе собирательный образ жс-сообщества. Не буду отрицать. Впрочем, изучите это сообщество поглубже, авось и поймёте меня.

а то он сам не в курсе, какие в его языке недостатки.

Если слепец перестанет быть слепцом и заявит об этом, то он станет изгоем среди своих бывших соратников.

Всё это хорошо описано в статье, на которую я ссылаюсь в первом после этой ветки. Не поленитесь прочитать, там много интересного, да и автор пишет более понятным языком, чем косноязычный я.
Да, я выдумал себе собирательный образ жс-сообщества. Не буду отрицать. Впрочем, изучите это сообщество поглубже, авось и поймёте меня.

С таким подходом у вас есть риск попасть в собирательный образ сообщества, в которое вы бы не хотели попасть :)

Как жаль, что я не получу вашего одобрения.
Может, по делу что-то скажете?
А, вы отредактировали коммент, вижу-вижу. Ну щас отвечу.
Кто конкретно превозносит плюсы и закрывает глаза на минусы?

Сообщество же.

И да, гыгы-статьи в духе «ой, смотрите, у них оператор равенство работает не так, как я ожидал, хотя я пишу совсем на другом языке»

Принцип наименьшего удивления. Если язык ему чаще не соответствует, чем соответствует, то невольно возникают вопросы. Особенно когда причин для такого удивительного поведения нет. Представьте, да, даже оператор равенства можно было сделать лучше, и я не вижу причин такого поведения, как и кейсов, когда жс-реализация лучше даже пхпшной. А ведь жс целиком состоит из материала на «гыгы-статьи»… Хотя и это не минус, не так ли? Гыгы-статьи это весело. Кажется, я начинаю понимать жс-сообщество!
Кстати, с радостью послушаю историю о причинах, побудивших разработчиков заложить в стандарт именно такое поведение оператора равенства.

Я прочитал, но так и не понял, какие именно библиотеки я должен обязательно использовать, чтобы искоренить фатальные недостатки JS? Я как-то обхожусь без них.

Хорошо, что вы обходитесь без фатальных недостатков жс. Не, если вас всё устраивает, то на здоровье.

Ну возьмём С++ например. В нём недостатков? Нет костылей?

Не знаю, не силён. Но я не видел сишников, которые так агрессивно реагировали бы на любое упоминание недостатков своего языка, как это делают любители жс.

В каждую статью, где рассказывается чем хорош С++, приходите вы и расставляете точки над ё, раскрывая глаза на его убогости?

Нет, я не знаю C++. А вот жс-кодеры приходят в каждую статью, где рассказывается об убогости js, и доказывают, что собеседник просто неосилятор.
Я же прихожу только в те дискуссии, где в принципе отрицают минусы.
Сообщество же.

Что это значит? Все члены сообщества закрывают глаза? Некоторые члены закрывают глаза? 51% сообщества закрывает глаза? Никто ничего не делает и не пытается улучшить язык?


Представьте, да, даже оператор равенства можно было сделать лучше

Оператор равенства — сам по себе вещь опасная, как ты его ни напиши. То же относится к сортировке. Особенно в языках с динамической типизацией. Хотите строгостей при сравнении/сортировке — пишите свои компараторы, всегда, потому что не существует ни универсального определения классов эквивалентности, ни универсального определения порядка элементов, а операторы сравнения прикидываются, что таковые есть. Операторы — это псевдо-математический синтаксический сахар, и он не всем одинаково полезен.


Это относится и к другим операторам (сложения, умножения и т.п.), и даже к более строгим языкам вроде С++, С#, Java и проч. Ок, в С++ вы не умеете, значит не в курсе тамошних забав с operator==, operator< или даже operator<=>. Может C# знаете? Сможете мне на одной интуиции, не заглядывая в доки, рассказать как работает встроенный оператор ==, как правильно реализовать метод Equals и интерфейс IEquatable в С#, в каких случаях это нужно делать, в каких — не нужно, и чтобы всё было по принципу "наименьшего удивления"?


Кстати, с радостью послушаю историю о причинах, побудивших разработчиков заложить в стандарт именно такое поведение оператора равенства.

Операторов сравнения в JS два — "строгое сравнение" (===) и "абстрактное сравнение" (==). Удивление и гыгыканье обычно вызывает абстрактное сравнение, потому что там величины не просто сравниваются, но ещё и приводятся к единому типу, а правила приведения типов сложны в силу самой природы задачи, даже при том небольшом количестве типов, что у JS. В строго-типизированных языках задача сравнения разнотипных значений ничуть не проще и не интуитивнее, потому что она принципиально не может быть интуитивной, т.е. решаемой универсальным всем понятным способом. Именно поэтому типовая рекомендация — использовать только либо строгое сравнение, либо кастомные компараторы.


Возьмите вот этот официальный алгоритм для абстрактного равенства, проанализируйте его и скажите, какая именно часть его абсолютно нелогична, и предложите свою поправку.


Но я не видел сишников, которые так агрессивно реагировали бы на любое упоминание недостатков своего языка

Им вакцину от холивары завезли? :) У сишников тоже есть постоянные темы для обсуждения, вроде " — Ой, int x; не инициализируется нулём, как в нормальных языках! — У нас zero-cost abstraction, а ты просто не врубаешься."


Нет, я не знаю C++.

А какой знаете хорошо? Может мы сможем вам раскрыть глаза :)

Речь не о том, что жс плохой, а о воплях сообщества о непогрешимости жс.
Что это значит? Все члены сообщества закрывают глаза? Некоторые члены закрывают глаза? 51% сообщества закрывает глаза?

Выйдите в интернет с таким вопросом. Посмотрите на комменты под статьями с критикой жс. Соцопрос проведите. Если жс-сообщество кажется вам непредвзятым, то говорить нам не о чем. Я буду считать, что вы подвержены когнитивному искажению, которое называется «склонность к подтверждению», а вы будете считать, что это я ему подвержен. На этом и закроем тему.

Возьмите вот этот официальный алгоритм для абстрактного равенства, проанализируйте его и скажите, какая именно часть его абсолютно нелогична, и предложите свою поправку.

Пункты 8, 9 и 10. Шиза полнейшая. По сути, именно из-за них и существуют все «гыгы-статьи».

Никто ничего не делает и не пытается улучшить язык?

Делает, и тем самым сдвигает язык с его особого альтернативного пути. Это и смешно. Например, когда гневные вопли о ненужности того же классического ООП и мощи прототипного превращаются в радостные вопли о ES6-классах, хех.

А какой знаете хорошо? Может мы сможем вам раскрыть глаза :)

А речь вовсе не об этом, если вы ещё не поняли.
Пункты 8, 9 и 10. Шиза полнейшая.

Почему именно, и что предлагается взамен? Приведение объекта к примитивному типу позволяет определить в любом вашем объекте метод toString или valueOf и использовать сравнение, как если бы это был value-type, например:


function Boxed(val){
    this.val = val;
    this.valueOf = () => this.val;
};
123 == new Boxed(123); // true

Этим редко кто пользуется, но, например, тип Date использует это, чтобы можно было сравнивать/упорядочивать даты как обычные числа (по значению), а не как объекты (по ссылке).


Ну и с теоретической точки зрения, если кому-то приспичило сравнить строку или число с объектом, то какой ваш вариант поведения? Всегда возвращать false, без альтернатив?


гневные вопли о ненужности того же классического ООП и мощи прототипного превращаются в радостные вопли о ES6-классах

ES6-классы используют то же самое прототипное наследование, только под сахаром. Классического ООП там нет.

Почему именно

Потому что это приводит к странностям в поведении, очевидно же.

что предлагается взамен

Где я вызывался исправлять фатальные недостатки?

Ну и с теоретической точки зрения, если кому-то приспичило сравнить строку или число с объектом, то какой ваш вариант поведения? Всегда возвращать false, без альтернатив?

Ну, это было бы консистентнее, чем классическое
[null, null] == ',' // true
[null, null] == [null, null] // false

Можете сказать, что тут опять проблемы массивов в жс, а не самого алгоритма сравнения, но кого волнует? Проблема никуда не делась, и часть её лежит в том числе и в стандарте оператора нестрогого равенства. Вы уж либо позволяйте сравнивать в том числе и объекты друг с другом, либо не позволяйте сравнивать с ними ничего.

ES6-классы используют то же самое прототипное наследование, только под сахаром. Классического ООП там нет.

Зачем нужен такой сахар, если прототипная парадигма в жс в сто раз удобнее?
Где я вызывался исправлять фатальные недостатки?

Ну, обычно критика подразумевает "я знаю лучше, как правильно". Если знаете, то разумно поделиться идеями.


Зачем нужен такой сахар, если прототипная парадигма в жс в сто раз удобнее?

Сахар сокращает число телодвижений, чтобы правильно настроить отношения с прототипом, и всё. Парадигма никуда не делась. Вас же не смущает, что вместо new Promise().then().then().tnen()... теперь рекомендуют async/await, чтобы читабельнее было? То же и с классами: вместо прямых манипуляций с .prototype теперь есть class ... extends, который делает то же самое, но понятно тем, кто пришёл из ООП. Даже миксины никуда не делись.

Сахар сокращает число телодвижений, чтобы правильно настроить отношения с прототипом, и всё.

А ты не понимаешь, в чём прикол. Сейчас объясню.
Вот у нас есть прототипная парадигма со своим «очень удобным» АПИ, на котором так просто делать приложения, что классический ООП не нужен. Всё было хорошо, жс-сообщество упивалось своей необычностью и повторяло классическую мантру «вы просто не понимаете».
Прошло много лет. Теперь JS имеет подобие классического ООП поверх столь удобного прототипного АПИ. Зачем? Неужели прототипная парадигма не такая уж и удобная? А если удобная, то зачем плодить сущности?
Но самое забавное, что сообщество резко переобулось и стало вещать об очередном прорыве в мире жс. А что же раньше оно камнями закидывало несогласных?
Даже миксины никуда не делись.

Скоро миллениалы зумеры жээсеры изобретут трейты и представят это как очередной прорыв…
Жду интерфейсы!

Где вы находите всех этих фриков и зачем вы их слушаете? :) Плюс учтите что у прототипного наследования как были фанаты, так и остались ещё. Не все вздохнули с облегчением увидев нормальный сахар для классов. Часть народу продолжает писать в замыканиях и тому подобное. Вы главное не рассматриваете их как цельное сообщество. Один выкрикнул одно, второй другое, третий третье. А вы, кажется, воспринимаете все 3 крика как мнение целого сообщества :-D

Где вы находите всех этих фриков и зачем вы их слушаете?

Они сами меня находят. Вот, например, автор этой статьи, лол. А слушает их куча юнцов, для которых авторитет измеряется в громкости воплей.

Один выкрикнул одно, второй другое, третий третье.

Но тот, кто выкрикнет что-то с критикой, будет немедленно отлучён от тусовки… Вот, посмотрите хотя бы сюда: любые комменты с критикой собирают кучу минусов, впрочем, как и кучу плюсов, но сумма оценок болтается чуть ниже нуля.
Вон фанатики даже мою карму полезли портить, хотя я с этим акком дальше этого срача никак связан не буду. Читать не умеют что ли?
Они сами меня находят. Вот, например, автор этой статьи, лол.

Как автор мог найти конкретно вас, если до этой статьи вас тут не существовало?

А кто тогда прочитал статью, если никого не существовало?

Надо полагать, прочитал тот, кто сам нашёл статью, а не тот, кого статья нашла. Автор не искал юзера JungerGinger, чтобы всучить ему очередную богопротивную статью, такого юзера до статьи даже не было.

А перед этим эта статья появилась на главной. Просто так совпало, что в очередной тысячный раз захотелось зайти и написать об этом.
Зачем? Неужели прототипная парадигма не такая уж и удобная? А если удобная, то зачем плодить сущности?

Потому что в индустрию приходят люди, неизлечимо поражённые ОМП синдромом утёнка ООП, и вместо того, чтобы разбираться, кричат "что это такое? мы не понимаем! мы не привыкли! нам неудобно! что за угрёбище?". Точно так же "ООП-сообщество" хейло функциональное программирование. Всё было хорошо, "ООП-сообщество" упивалось своей заурядностью, утверждало, что ФП не нужно, ПП не нужно и т.п., потому что у них была удобная им парадигма. Но когда ФП начало проникать в ООП, то "ООП-сообщество" резко переобулось и стало вещать об очередном прорыве в мире ООП. А что же раньше оно камнями закидывало несогласных?


Ну в общем, вы поняли — все ваши аргументы про "сообщество" легко обратить, поэтому силы в них никакой. Достаточно выдумать себе какое-нибудь "сообщество", решить для себя, что "сообщество" — это некий организм, действующий как единое целое — и можно выводить "общественные теории" любой степени бредовости. Можно даже дойти до того, что у этого организма есть "мозг", который им управляет — и здравствуй, конспирология!..


Жду интерфейсы!

Интерфейсы в интерпретируемом языке? Как вы это представляете?

вместо того, чтобы разбираться

Неправильно. Ты разбираешься, разбираешься, а потом понимаешь, что это всё несёт кучу неудобств ради сомнительных плюсов. Но жс-сообщество выпячивает эти сомнительные плюсы как офигенное преимущество, но при этом разрождается горой статей вида «как нормально реализовать наследование в нашей удобной парадигме». И никто, никто не замечает тут никакого подвоха.

Всё было хорошо, «ООП-сообщество» упивалось своей заурядностью, утверждало, что ФП не нужно

ООПщики вроде пригорали от преисполненных снобизмом заявлений ФПшников, что ФП очень удобное, понятное и вообще можно изучить лямбда-исчисление и всё писать в функциональщине, в том числе и очередной интернет-магазин. Ещё они дружелюбно интересовались проблемами сохранения функциональной чистоты языка и необходимости операций ввода-вывода. При этом никто вроде особо не спорил, что ФП полезно, когда с его помощью задача решается проще/понятнее, чем с помощью обычных императивных алгоритмов.

Интерфейсы в интерпретируемом языке? Как вы это представляете?

А как они в PHP существуют?
При этом никто вроде особо не спорил

Да, конечно. Если ООП, то "пригорали". Если JS, то "заклёвывали несогласных". Если ООП, то "никто особо не спорил". Если JS, то "замалчивали". Если ООП, то "дружелюбно интересовались", если JS, то "на ходу переобувались".


Извините, я устал от вашей демагогии. Прощайте.

И вам не хворать.
Не забудьте подумать на досуге об интерфейсах в интерпретируемых ЯП.

Я уже думал, но грешным делом решил, что вам есть что сказать по существу. Ну нет так нет.

Зачем?

Ну и вообще, JS позиционируется как мульти-парадигменный язык, так что почему бы ему не ввести те куски ООП, которые нужны людям? Хочешь, пиши в одной парадигме, хочешь — в другой.

Хочешь, пиши в одной парадигме, хочешь — в другой.

А хочешь половину кода в одной, а половину в другой? Да ещё и вперемешку? ;)

Это уже проблема из разряда "заберём у людей всё опасное, а то они убьют себя и друг друга".

Почему же сразу «заберём». Скорее «отрегулируем». А то вон представьте себе ПДД в которых одновременно разрешены правостороннее и левостороннее движения. Тоже ведь не дело.

Кто должен регулировать и решать, какие регуляции полезны, а какие вредны?
Команда? Не, вдруг разные команды будут следовать разным стандартам.
Компания? Не, разные компании будут проталкивать свои стандарты в угоду прибыли.
Дизайнеры языка? Не, каждый язык проталкивает свою парадигму в угоду парадигме.
Государства? Не, каждое государство будет проталкивать свои политически, идеологически и даже лингвистически мотивированные языки.


Решения тут нет никакого, кроме эволюционного: парадигмы должны существовать одновременно и бороться за своё выживание.

Кто должен регулировать и решать, какие регуляции полезны, а какие вредны?

Вы предлагаете вообще в принципе убрать любые регуляции? Или как это понимать?

Решения тут нет никакого, кроме эволюционного: парадигмы должны существовать одновременно и бороться за своё выживание.

Левостороннее и правостороннее движение тоже?

То есть на мой взгляд пусть там себе парадигмы сколько угодно «борются за выживание». Но всё-таки не в одном «куске кода». А то сначала такие вот «борцуны» макарон наварят, а кому-то это потом всё разбирать.
Вы предлагаете вообще в принципе убрать любые регуляции?

В принципе, регуляциям я предпочитаю соглашения. Регуляции вправе вводить только владелец. Владельцем языка является либо его изобретатель, либо комитет по стандартизации, и только он решает, каким быть языку. Решили в ECMA быть языку мульти-парадигменным, значит выбор конкретной парадигмы остаётся на профессиональной совести самих разработчиков.


Если кто-то выбрал смесь парадигм — это ещё не значит, что выйдет плохо. В ООП успешно применяются детали из ФП, и наоборот. Если у мейнтейнеров нет проблем это поддерживать, то смешивай на здоровье.


Левостороннее и правостороннее движение тоже?

На каких дорогах? У дорог общего пользования есть хозяин — государство, оно и определяет ПДД. На частных дорогах правила могут отличаться. Так и с софтом: кто хозяин ПО, тот и определяет правила.

Регуляции вправе вводить только владелец.

Вообще-то нет. Или владельцы заводов или скажем земельных участков могут у себя вводить и отменять любые законы?

У дорог общего пользования есть хозяин — государство, оно и определяет ПДД

А «государство» это у нас кто или что? И чем скажем демократическое государство принципиально отличается от какого-то сообщества?

Если кто-то выбрал смесь парадигм — это ещё не значит, что выйдет плохо.

Если это «гомогенная» смесь, о да. А вот если у вас над одним классом работает несколько человек и у каждого своя «парадигма», то это уже бардак. И кто-то однозначно должен следить чтобы этого не происходило.
Или владельцы заводов или скажем земельных участков могут у себя вводить и отменять любые законы?

Не любые, но устанавливать свои ПДД на своей территории — могут.


И чем скажем демократическое государство принципиально отличается от какого-то сообщества?

Правом на насилие по отношению к тем, кто нарушает регуляции.


И кто-то однозначно должен следить чтобы этого не происходило.

Вот я и спрашивал вас — кто именно должен определять, какие парадигмы правильные, а какие нет, а также следить за тем, чтобы программисты применяли правильные парадигмы, и определять способ и уровень наказания тех, кто применяет неправильные?

Кстати, попробуйте другие языки программирования — вдруг синдром утёнка пройдёт?

Писал много на Pascal, Delphi, PHP, JavaScript. И немного, отрывками, на Java, Python, Ruby, Scala, C++. Не очень понимаю, чего вас так от него бомбит. На данный момент из всего, что я пробовал, мне больше всего нравится TypeScript. Смотрю с большим интересом в сторону Rust и Haskell. Смотрю с лицом полным ужаса, недоумения и отрешения в сторону C++. И с некоторой неприязнью в сторону PHP (ни за что не вернусь к нему). Да в JavaScript хватает своих проблем, но я почти с ними не сталкиваюсь в TS и в целом доволен лаконичностью и удобством языка. Пожалуй синдром утёнка ко мне не применим.

Тайпскрипт — отдельная песня. Прочитайте коммент ещё раз.
Ответьте для себя на простой вопрос: можете ли вы написать не сильно сложное приложение на js без использования сторонних библиотек, которые фиксят большинство приятных особенностей языка, перечисленных в статье выше? Ага. А на ES5? А сложное?

Могу.
Непонятно правда зачем, ибо существование библиотек это by design фича языка, и никто ни на одном языке не пишет без библиотек.

А можно от вас конкретно, какие минусы вы видите в js? Пролистал все ваши комменты, не нашёл.
Попробуйте другие языки в каких задачах?
Если вообще использовать в работе, то я, например, кроме JS использу PHP и C++, пользовался C, Паскалем, Питоном, VB, Ruby. JS люблю больше всех. Но у меня и задачи сейчас практически все под него.
Не очень понимаю зачем хейтеры насилуют себя? Если вам нравится другой язык, то и пишите на нём. Я, например, не люблю суши. Вот терпеть немогу, до рвотных рефлексов. Нормально ли будет мне ходить по суши-барам и рассказывать всем как я ненавижу суши, какие они противные на вкус, опасные для здоровья (если неправильно готовить) и что суши «должен умереть, и чем быстрее, тем лучше»?
Извините, тут суши-бар? Если говорить вашими аналогиями, то один человек сказал, что суши могут вызывать гельминтоз, другой же говорит, что так и задумано и тот человек просто не шарит. Вот на это «просто не шарит» у меня самого рвотный рефлекс. Не на жс, хотя он тоже с запашком, а именно на «ты не шаришь ты не осилил ты тупой».
Задачи под жс я и сам решаю с помощью жс, странно было бы делать иначе. Да и не получится — альтернатив толком нет.
Тут не суши-бар, но и мы не про суши говорим :)
Но да, я понял о чём вы. Тут действительно общий ресурс, а не JS междусобойчик.

Что касается «не шаришь» — тут неплохо бы понимать, действительно ли так задуманно и «один человек» не шарит, и если таки задуманно, то к чему эта ненависть? Не ешьте суши и дело с концом.

И почему вы берётесь за задачи под JS если вам неприятно его использовать?
Есть же огромное количество вакансий, и в WEB в том числе, где иметь дело с JS вам не прийдётся практически совсем, так в чём прикол?
Ладно ещё PHP все активно ненавидели (как сейчас я не в курсе). Тогда, когда его активно поливали, рынок был меньше, специальностей меньше, многие вынуждены были совмещать и пользоваться «мерзким PHP» против своей воли. Ну а сейчас то в чём дело?
Вы так и не поняли, в чём проблема. Не сколько в js, сколько в его сообществе. Я бы не испытывал такого отторжения к js, если бы него, мягко говоря, странное и максималистически настроенное сообщество. Может, я и сам недалеко ушёл от них, а может это какая-то защитная реакция: я же вижу, что в языке проблемы, и действительность об этом говорит, но сообщество в основном утверждает, что проблем нет, а если и есть, то они несущественны или вообще являются преимуществами. Смешиваться с толпой я не могу, я не настолько глуп, но и быть изгоем по причине не таких взглядов мне не в кайф.
Тут уже либо у меня и у разработчиков языка неполадки с головой (не, ну а почему они тогда дорабатывают его, если проблем нет, почему вводят все те фишки, о ненужности которых сообщество вещает ровно до момента анонса в следующем стандарте?), либо у сообщества.
Ну, не знаю. На сколько я вижу большинство популярных языков постоянно дорабатывается, что-же они все плохи?
А такого прямо единого «в JS всё отлично и менять ничего не надо» я, например, от сообщества никогда не слышал. Да взять хотя-бы jQuery. Эта далеко не идеальная библиотека стала, по сути, стандартом на годы именно благодаря тому, что в ней реализовывались фишки, которых не хватало сообществу. И других популярных библиотек было вагон. Сейчас очень многое из тех библиотек перенесено в язык и я не помню, что-бы сообщество как-то активно сопротивлялось этому процессу.
Да нет же, это здорово, что языки дорабатываются. И что жс дорабатывается — тоже отлично. Плохо то, что жс-сообщество вопит об идеальности своего языка.
Вот, например, до стрелочных функций главной болью было поведение this. И жалующимся на this всё жс-сообщество говорило, мол, вы просто дураки и не хотите выучить язык, на котором сами и пишете, всё и так удобно, поведение адекватное. После анонса стрелочных функций все резко переобулись и сказали «а так и правда лучше».
jQuery? Сколько себя помню, адепты великого js всегда говорили, что jQuery нинужон. А когда анонсировали нативную реализацию какой-нибудь фишечки из jQuery, члены сообщества начинали вопить что-то в стиле «а я вам говорил, что jQuery нинужон, а вы мне не верили!» Действительно, и возразить нечего.
Если плюшки какого-нибудь Lodash внесут в стандарт языка, то адепты только укрепят свою веру.
Понимаете, проблема не в том, хорош js или плох, а в сообществе. В том, что сообщество в любой момент времени уверено в непогрешимости js, и готово с потрохами сожрать несогласных.
до стрелочных функций главной болью было поведение this

Да и после… если честно. В целом концепция this и прототипного ООП оказались, имхо, не самой, лучшей особенностью в JS. Какие-то совершенно неочевидные плюсы и масса очевидных минусов. Интересно как с этим делом обстоит в python. Я в него не углублялся, но насколько я помню там примерно аналогичная схема. Они довели её до ума?


Плохо то, что жс-сообщество вопит об идеальности своего языка

Пффф. Никогда не слушайте таких категоричных товарищей. Как рьяных хейтеров, так и упоротых фанатов проще просто игнорировать.

Понимаете, проблема не в том, хорош js или плох, а в сообществе

Вот сообщество у нас довольно неплохое. Во многом очень непрофессиональное, много хипстерского хайпового мышления, но оно обычно не очень токсичное. Вот для примера в Delphi сообществе (во всяком случае когда я на нём писал) сообщество было столь токсичным, что человек 30 раз подумает, прежде чем хоть что-нибудь спросить. Обычно никого не интересовала проблема новичка, важно ему напомнить кто он есть, и где его место в этой жизни. У меня до сих пор "глаз дёргается", как вспоминаю.

И жалующимся на this всё жс-сообщество говорило, мол, вы просто дураки и не хотите выучить язык, на котором сами и пишете, всё и так удобно, поведение адекватное.

То, что говорили "учите язык" — верю. И правильно говорили. Неидеальность языка не освобождает от ответственности его учить и правильно применять.


То, что говорили "поведение адекватное" — не верю. Все статьи, касающиеся поведения this, по сути повторяют: "да, динамическая смена контекста в функциях — это одновременно и благо, и проклятие, для многих это ловушка, но куча полезного кода заточено именно на это, поэтому смиритесь просто выучите и запомните до лучших времён".


Ну и, если бы это считалось адекватным, то его бы оставили и в стрелочных функциях, но его изменили — почему? Наблюдения прямо противоречат вашей гипотезе.

Простите, я вот хейтер JS.
Я пользуюсь только TypeScript, потому что не могу, например, без участков синхронного кода, без аккуратно выраженной модификации классов и без классов тоже.
Потому что иначе всё превращается в нечитаемую помойку, хуже кода ядра FreeBSD без комментариев.
Возможно, это говорит обо мне, как об ущербном «программисте», но мне кажется, что всё то, что создавал Андерс Хейлсберг — это лучшее, что случалось с быстрой и безопасной разработкой UI, и огромное количество разработчиков, пользующихся его идеями и разработками, подтверждает это.
Ответьте для себя на простой вопрос: можете ли вы написать не сильно сложное приложение на js без использования сторонних библиотек, которые фиксят большинство приятных особенностей языка, перечисленных в статье выше? Ага. А на ES5? А сложное?

Хотелось бы уточнить, что подразумевается под словом "сложное"? Просто у каждого свои критерии. Но, в целом, на все вопросы ответ — "да".


Современным жаваскриптом нельзя пользоваться без библиотек, которые являются, по сути, костылями для этого чудом выжившего порождения бездны.

Какая лютая чушь. Современным как раз можно пользоваться и писать приложения любой сложности. Ситуация драматически изменилась в лучшую сторону после релиза ES6.


Как иронично. Жаль, что ребята не понимают, что это так и останется стремлением, и никакие косметические изменения и добавление синтаксического сахара не исправят убогость языка, заложенную на этапе проектирования

Никогда не говори никогда. Вспомни 'use strict' например. Впрочем так можно сказать и о любом другом языке.


Кстати, попробуйте другие языки программирования — вдруг синдром утёнка пройдёт?

Пробовали С++, C#, Python, PHP. И JavaScript сейчас является одним из самых удобных и понятных языков. А если в связке с суперсетом TypeScript, то работа вообще превращается в удовольствие

Подобные разговоры напоминают споры о том, у какого телефона круче камера. В таких спорах самое прикольное в том, что спорят на эту тему те, кто кроме фото с самим собой и фото мест, где побывал, не умеет делать больше ничего, а мастера фотографии просто делают фото-шедевры на том, что оказалось под рукой, делая мимоходом поправку на специфику имеющейся на руках техники.

В свое время для проекта JetCalc (https://github.com/leossnet/jetcalc), в котором есть и довольно сложный интерфейс, и большие серверные вычисления, мы выбрали JavaScript, и до сих пор еще не столкнулись с принципиальными ограничениями этого языка. При этом единственный факт, что сегодня JavaScript встроен во все браузеры на всех платформах, превращает его недостатки в особенности, которые нужно просто учитывать в своей работе.
В таких спорах самое прикольное в том, что спорят на эту тему те, кто кроме фото с самим собой и фото мест, где побывал, не умеет делать больше ничего, а мастера фотографии просто делают фото-шедевры на том, что оказалось под рукой, делая мимоходом поправку на специфику имеющейся на руках техники.

Классическое «вы просто неосиляторы». Представь — ты хочешь устроиться фотографом в фотостудию. Оффер от какой студии ты примешь в первую очередь: от студии, где из оборудования есть только китайский фотоаппарат от дяди Ляо, который из коробки по функционалу приближен к допотопной мыльнице, но который добрая студия позволяет с помощью изоленты, пластика и стекляшек приблизить к нормальным камерам, да ещё взамен, судя по всему, требует везде восхвалять такой подход к фотографии, или от студии с нормальным оборудованием? Да, первый вариант позволяет творить вещи не хуже, чем второй, но… зачем? Почему бы не признать, что второй вариант банально удобнее? С каких пор показателем профессионализма стало умение использовать убогие инструменты? Почему порицается стремление к удобным инструментам? Нет, обвешивание костылями не прибавляет удобства!

Стокгольмский синдром какой-то.