Как стать автором
Обновить

Комментарии 411

Так можно совершено обо всем сказать, ведь все что есть в нашем мире имеет проблемы и может, да и должно стать ещё лучше.
Вкусная статья, посмотрим что автор предложит.
НЛО прилетело и опубликовало эту надпись здесь

Автор как всегда предлагает убить то, в чём не разбирается. Достаточно было дочитать про Flux. Flux/redux имеют весьма посредственное отношение к скорости рендеринга. Это методология организации кода. REST api, разрабатывается всегда с предположением, что клиент скомпроментирован. Для жизнено важных приложений используется дмз и другие способы отсечь удаленное управление, что небесполезно и для защиты десктопных прилад. Зато так приятно ощутить, а то и возглавить панику)

Да и http был разработан исходя из модели запрос-ответ, что безо всякого «выворачивания» ложится на REST api.
Это методология организации кода

Которая воссоздаёт модель программирования, которую использовала Windows 1.0, выпущенная в 1985 году
Это не про веб, это про конец времени разработчиков-одиночек (плач, продолжающийся с 80-90хх). Веб-платформу нужно не со стороны иконок рассматривать, а со стороны стандартов, REST, масштабирования, развёртывания, кроссплатформенности. Веб не хорош или плох, это просто данность, закономерный результат развития человеческих технологий, решивших по пути своего становления естественно возникающие задачи. Статья вообще ниочём, если есть предложения — предлагай, если есть вера в конструктивность этих предложений — внедряй и конкурируй с вебом. А не смог — смирись с наивностью своих претензий.
Мне кажется Вы несколько недооцениваете про конец-времени и уж тем более плач… каждый то вообщем выбирает для себя формат деятельности, который его радует и позволяет жить с удовольствием… местами статья перегиб, но в целом попытки последних N лет запихать все что можно и нельзя в какие то веб-решения лично у меня вызывают изжогу… Вы путаете «данность» и притягивание за уши всего что вокруг к этой технологической «данности»…

Мне скажем не жалко памяти моего компьютера… как бы сколько надо столько и купим =), я понимаю _почему_ так получается, но мне кажется что-то с «данностью» не так если десктопный Slack под win10 прямо сейчас жрет у меня 523Mb памяти… представляя из себя окно, показывающее одновременно 20-30 текстовых сообщений и при этом с невозможностью посмотреть историю если нет сети, при этом считаясь почти эталоном корпоративного общения…

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

Вот опять же, глубокое IMHO, банк-клиент ВТБ24 — обычный для «физиков»… 10 лет назад он был легким, быстрым, работал почти на любых каналах… имел нормальные человеческие функции поиска платежа по описанию, по типу, по строчкам в получателе итд… на тот момент это объективно был лучший банк клиент для физ лиц… да и для юриков тоже был не плох… за 10 лет после 4-5 реинкарнаций, первую кстати начала студия Лебедева… он превратился в чуть шевелящегося уродца с невнятным, абсолютно неочевидным интерфейсом, весом в полтонны… зато обзавелся кучей модных свистелко-перделок…

Я понимаю вашу точку зрения, и сам тоже «страдаю» от потери того чувства всемогущества, которое испытывал будучи школьником, сидевшим перед ассемблерным кодом на сферическом мониторе своего 486-го :). Но подобные идеализмы всегда разбиваются о твёрдость физической и экономической реальности, увы :).
ну когда я был школьником то больше как-то мне запомнились мк-52, паяльник и синклеры=) 486 уже ближе к концу института… но не в этом дело… я не расцениваю это как «всемогущество», скорее просто лично мой взгляд на высказанное в статье мнение как человека, который последние лет 25 каждый день пишет код ) моя область деятельности далека от веба, хотя в несольких проектах я поучаствовал, поэтому в данном случае я могу позволить себе высказаться просто как пользователь-обыватель… я не пытаюсь разбить голову ни о физические не тем более об экономические реалии, поэтому смело шагаю в магазин за соотвествующим железом, но опять же это не мешает мне иметь точку зрения состоящую в том, что за последние N лет, скажем так — added value для конечного пользователя (меня) в разделе веб продуктов носит очень сомнительный характер, особенно в пропорции к тем ресурсам которые все это добро требует… опять же я не хочу что то агрегировать или делать какие то выводы «за всех», я лишь говорю о том что по сути лично мне не стало удобнее за последние годы читать gmail (если я читаю его в онлайне) или пользоваться своим банк клиентом…
за последние N лет, скажем так — added value для конечного пользователя (меня) в разделе веб продуктов носит очень сомнительный характер, особенно в пропорции к тем ресурсам которые все это добро требует…

Поддерживаю на все 100!
С ВТБ24 в точку! Я даже из-за этого ублюдочного интерфейса закрыл там все вклады.
Не забудьте написать отзыв в их суппорт, а то они там и не поймут причину оттока клиентов… :)
Для интернет-банков это наверно нынешний тренд.
НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

Тем не менее, проблема SQL injection "успешно" возникла в Web, как и buffer overflow в C/C++ за 20 лет до этого. Вот автор и говорит о том, что Web повторяет путь десктопного софта, включая схожие грабли.


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

НЛО прилетело и опубликовало эту надпись здесь

Так SQL и не является частью Web (deprecated WebSQL не в счет).


Автор говорит именно о Web и его протоколах, которые до недавних пор были исключительно тесктовыми, да и сейчас ключевые протоколы остаются таковыми.
Так что он предлагает (во второй чати статьи) заменить текстовые протоколы на бинарные.

НЛО прилетело и опубликовало эту надпись здесь

Протокол общения backend'а с базой данных здесь вообще ни при чем. Ни с какого боку (подозреваю, они и так бинарные в большинстве DB).


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

НЛО прилетело и опубликовало эту надпись здесь
Сам-то запрос бинарный, но внутри него хакнутая SQL-инструкция.

Неверно. Хакнут был HTTP запрос, а не SQL. В таком случае замена протокола общения сервера с базой на бинарный, либо введение обёртки поверх SQL (как вы предлагали) вообще ничего не даст.


Наивно полагать...

А я и не полагаю наивно ;-)


Автор предлагает не просто бинарный протокол, а еще и типизированный, что автоматически делает невозможным в принципе любые вставки в нетекстовые данные, потому что они фиксированной динны (а в HTTP можно сделать вставки в любые данные, не только текстовые, но и числа, даты и т.д.)


С текстом посложнее, но тоже решаемо. Например, в ряде случаев от текста можно вообще отказаться -> проблема решена полностьб — см. выше. Можно работать с текстом фиксированной длинны. И т.д.


К тому же, основная цель NewWeb (как автор это называет) не в устранении всех возможных уязвимостей на 100% (сам автор считает это невозможным), а в минимизации возможных ошибок, что приведет к уменьшению числа дыр.


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


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


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

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


Да, это следствие текстовой природы SQL. Но это сейчас общепринятый стандарт работы с реляционными СУБД и другого у нас нет.

Как я уже говорил, SQL injection — просто частный случай. Проблема в самом текстовом протоколе без всяких средств контроля данных.

НЛО прилетело и опубликовало эту надпись здесь
Вы неправильно понимаете суть SQL Injection. Она не в проблеме передачи данных.

Сам хак SQL Injection происходит только на этапе передачи данных, и никак иначе (если мы о Web говорим). Если вы этого не понимаете, то… это вы не понимаете суть SQL Injection ;-)


Например, если вы передаете числовые данные в бинарном виде (т.е. с фиксированной длинной и в строго определенном формате), то SQL Injection невозможен в принципе. Как видите, проблема решена полностью именно выбором способа передачи данных.


сериализация/десериализация всё равно будут нужны.

Конечно. Это должна быть стандартная часть протокола, и будет делаться через стандартный API.

Сам хак SQL Injection происходит только на этапе передачи данных, и никак иначе (если мы о Web говорим).

SQL Injection это всегда отсутствие валидации входных данных

Да, вы можете валидировать текстовые данные, добавиви в ваш стек еще одно место потенциальных ошибок и дыр. Именно так и делается в современном Web, и именно это критикует автор.


А можно перейти на другой протокол, который в ряде случаев вообще не допускает SQL injection "by design".

НЛО прилетело и опубликовало эту надпись здесь

Используя SQL с параметрами.


А что в этом такого? :-)
Разве автор статьи призвает отказаться от этого?
Он предлагает уменьшить количество потенциальных дыр, считая избавление от них на 100% невозможным.

добавиви в ваш стек еще одно место потенциальных ошибок и дыр

Без ошибок только тот код, которого нет. Переход на другой протокол, это просто перенос валидации на уровень протокола, а не приложения. Но да же и тут без валидации на уровне приложения никак.

Но ведь можно попробовать хотя бы уменьшить количество потенциальных дыр. В этом и состоит предложение автора статьи.

Или выгнать плохих разработчиков.

Или и то, и другое :-)

НЛО прилетело и опубликовало эту надпись здесь

Даже в текущем стеке Web постоянно появляются новые технологии, и никто особо не переживает по поводу небыстрого избавления от багов :-)

НЛО прилетело и опубликовало эту надпись здесь

У среднестатистического пользователя Web-приложения есть только браузер в качестве клиента, который вы не можете контроллировать. Как вы будете доставлять все это (Java, Thrift etc.) к нему в браузер? Особенно если он не хочет ваших плагинов.


Вот автор и "предлагает" сделать новый Web (NewWeb) с улучшенным дизайном для улучшения безопасности и производительности. Чтобы клиенты (e.g. браузеры) "из коробки" поддерживали новые протоколы.

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

JSON — тоже текстовый. Вставка во время транспорта делается также легко, как и в URL простого HTTP GET.


Да, вы можете использовать JSON валидацию — так же как программисты, допустившие SQL injection, могли бы использовать SQL с параметрами. А можете и не использовать, что является дырой.


Автор предлагает NewWeb, в котором накоторые дыры будут закрыты "by design", независимо от того, что вы используете (или не используете) на своем backend'е.


А вот что насчёт подмены строки как в моём примере?

Использовать параметризированный SQL :-)


Еще раз повторю: проблема — в возможности очень легко подменить данные в HTTP запросе с текстовым протоколом. Это будет источником новых уязвимостей.

НЛО прилетело и опубликовало эту надпись здесь
Сам хак SQL Injection происходит только на этапе передачи данных, и никак иначе (если мы о Web говорим).

С чего это вдруг? Он происходит после передачи данных, при обработке в приложении.


Например, если вы передаете числовые данные в бинарном виде (т.е. с фиксированной длинной и в строго определенном формате), то SQL Injection невозможен в принципе.

С чего это вдруг? Какая разница, передали мы значение $client в виде "OR 1=1\n" или в виде "0x06OR 1=1"?

и возможности очень легко подменить данные в HTTP запросе с текстовым протоколом

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

> Тем не менее, проблема SQL injection «успешно» возникла в Web

Это с чего бы? SQL-инъекции возможны в любом приложении, которое принимает данные от пользователя и подставляет их в запрос. Не важно, десктоп это или веб.
дичь, потому что есть Prepared statement
НЛО прилетело и опубликовало эту надпись здесь
Если знать что следующие n байт буффера это текст, а не исполняемый код мы можем просто игнорить эти n байт пока не возникнет желание провернуть какие-нибудь еще манипуляции именно с данными.
Flux, последнему модному веб-фреймворку от Facebook

В вебе минули геологические эпохи с тех пор, как Flux был последним и модным (не то чтобы пришедшее на замену шибко лучше, но все-таки).


На C++ невозможно написать безопасный код, а виноват, конечно, веб, ну да.


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


Как только появится что-то кардинально лучшее, мы все немедленно на него перейдем: разработчики, если они не застряли в ностальгии, как им любовно и прельстиво кодилось в 90-ые под Win3.x, любят вскакивать на hype-train как никто другой. Боюсь, только, что оно будет организовано на примерно тех же принципах: гипертекст и скриптовый язык.

> Как только появится что-то кардинально лучшее

Не «что-то», а «что-то + экосистема». Именно поэтому надеяться на то, что оно само появится… Не стоит?

Я прошел путь от Rails до собственной lightweight библиотеки по типу React, и тут понял… Что HTML и пр. тут просто не нужен… Бери себе C++/Python/Ruby/etc. + xWidgets, замути такую библиотеку и… Ну разве что, еще нужны всякие API для доступа к сенсорам (если нужно). Но экосистемы-то нет, потому, что нет моды, потому, что нет…

А мода на комбайны под названием «браузеры» (заметьте, еще и несколько!) — плохая. Даже с учетом налаженного процесса стандартизации… Это я спустя десяти лет web programming говорю, спустя годы восхищений… Сейчас я понимаю, что даже идея комбайна JVM — возможно, лучше…

Иллюстрация? Восхищения по поводу WebAssembly: взяли ОС, создали браузер со своей «ОС», сделали «стандартный» высокоуровневый ЯП, а WebAssembly — инновация, которой нам не хватало! Ассемблер внутри всего этого.

Но, наверное, во всех других бизнес-моделях была бы куча стандартов (например, API доступа к сенсорам), ну и тоже бы ничего путного не вышло…

Боль.
Скриптовый язык — вряд ли: это замена шила на мыло. Скорее наоборот, появится броузер приложений, который будет скачивать архив с исходным кодом, собирать его на клиентской стороне, и запускать как обычное desktop-приложение в контейнере с ограниченными правами. На мой взгляд, лучше всего для таких целей сейчас подходит язык Go в связке либо с Qt, либо xwWidgets.
НЛО прилетело и опубликовало эту надпись здесь
Office 2000 вполне довольствовался CPU на 75 МГц и 32 МБ памяти

А сейчас этого мало даже дня нативного десктопного мессенджера, да и для мобильного тоже. Так что вы правы, html — зло. Хотя, при чем здесь html?
Подмена понятий же)
Подмена понятий происходит тогда, когда из технологий, основанных на веб-страницах, делают веб-приложения. Backend должен быть ничем иным, как веб-сервисом, а между браузером и сервером должен быть стандартизованный API.
А что не так с вэб-приложениями и чем оно отличается от вэб-страницы? Второе ваше предложение вообще не связано с первым, о чём вы??
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
сейчас куча приложений на десктопе внутри html рисует и имеет webkit в зависимостях, в том числе месенджеры. Разумеется, это не целиком веб-приложение, но и не целиком нативное.
В отличии от веба, авторы десктопных приложений вольны выбирать любой вариант форматирования текста. Если кто-то выбрал для этого полноценный html, то это не вина html. Хотя и с его отображения Operа когда-то справлялась на 75 МГц и 32 МБ памяти.
На самом деле и сейчас есть броузер dillo, который может показывать Web-страницы с очень небольшими затратами ресурсов. В частности на эту страницу ему потребовалось всего 32 Мб памяти. Только вот JavaScript в нем нет и поддержка CSS неполная.

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

Мир не идеален и решения не могут быть идеальными, всегда будут проблемы, всегда будут те, кто будет пользоваться этим, по крайней мере такая песня будет ещё долго.
Только не пинайте сильно ногами. Но почти всё то, за что тут ругается веб, решено во Flash…
НЛО прилетело и опубликовало эту надпись здесь
Кроме безопасности

А с ней там плохо по другим причинам.

Да все те же упомянутые буферы переполняли. Ну и песочниц так и не сделали. Если отдадут таки флеш в OpenSource, то может найдутся желающие переписать его на Rust.

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

Каких, например?

Ну самое очевидное — то что там изначально аналог shadow dom, т.е. один компонент не может что-то сломать в родительском приложении или его стилях. Или в другом компоненте. Т.е. только публичный API, и ничего больше. Такой вещи, как глобальный window, как document.write — вообще никогда не было за ненадобностью. Там нет загрузки скриптов, как таковой — есть загрузка swc, но это совсем другая история.

Чистая правда. Я сейчас после длительного перерыва смотрю на веб-фреймворки, и вижу, что да, shadow dom и кастомные элементы все-таки сделают революцию рано или поздно — но все это уже было в Flash/Flex, причем много лет назад.

Автор об этом и говорил: «Suggesting that Macromedia Flash might actually be good would get your geek card revoked.»
Простите, конечно, но мне почти половина всей статьи показалась дичайшим бредом.

Серьезно? В другой половине вы смысл нашли?

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

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

WebAssembly+WebSocket+WebGL? А все остальное вопрос фреймворков.

НЛО прилетело и опубликовало эту надпись здесь
на платформу вообще без стандартной библиотеки

С чего это вы взяли? Можно хоть существующие фреймворки на других языках прикрутить

НЛО прилетело и опубликовало эту надпись здесь
Это автора(Mike Hearn) и zugo не устраивает.
Речь-то шла про замену современного «фронтенда» на какой-нибудь гипотетический нормальный унифицированный стек технологий, а не о том, чтобы дать возможность запихнуть в браузер .NET целиком.
запихнуть в браузер .NET целиком.

Так он уже там есть. Unity называется.

Зачем тянуть каждому приложению? Можно сделать систему зависимостей.

Зачем Использовать WebAssembly, WebSocket и WebGL, есл можно использовать Assembly, Socket и GL, чуть-чуть поменяв популяпные ОСи и добавив полслоя абстракции?

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

Клиенты хотят запускать всё не из браузера, а из унифицированной платформы, которая на сегодняшний день имеет только одну реализацию — браузер.
Если бы существовала другая реализация унифицированной платформы, причём более быстрая (то есть использовала Sockets, Assembly и GL без приставки Web), то про браузер бы никто не вспоминал.
Об этой другой, воображаемой и желаемой реализации и ведёт речь автор этой статьи.

Осталось прикрутить к ним работу приложений без установки и безопасность

Я бы не назвал Java платформой. Хотя, я конечно имею посредственное представление обо всех её возможностях, но это скорее ВМ в моём видении. Браузер унифицирует большее количество вещей, чем ВМ.
Вот Android SDK уже можно назвать такой платформой. Потому что унифицируется доступ к ресурсам ОС, файловой системе, взаимодействию между приложениям, забавушкам.
Вот только она не унифицирована :)
Если слить вместе Android, iOS и .NET стек (а не кросскомпилировать как в Xamarin), унифицировать его, плюс убрать слой абстракции между ОС и ВМ, которая несёт эти приложения — т.е. так, как сделано в мобилках и так как не сделано в десктопах — HTML+JS утонет в Лете.


Flash по сути не решает проблему из-за проприетарности и ограничений. Помоему флеш не умеет UDP, не умеет работать с файлами и тыды

Платформа — это то, от чего можно уверенно отталкиваться. Пока что, так называемая, Java Platform имеет ряд минусов:
— Строгая типизация
— Необходимость обработки исключений
— Необходимость установки среды исполнения
— Принудительное ООП
— Управление памятью и системным треем доступно только через платформозависимый JNI
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Платформа — это то, от чего можно уверенно отталкиваться. Пока что, так называемая, Java Platform имеет ряд минусов:
— Строгая типизация
— Необходимость обработки исключений
— Необходимость установки среды исполнения
— Принудительное ООП
— Управление памятью и системным треем доступно только через платформозависимый JNI

Какая-то ерунда, вы про такой язык как Groovy не слышали, который в JVM позволяет писать функциональные скрипты без ООП с динамической типизацией?
>> Строгая типизация — даже в Java можно использовать переменные Object и явное приведение типов везде, вот вам динамическая типизация. На JVM платформе достаточно языков с динамической типизацией.

>> Необходимость обработки исключений — в чем необходимость? В новом JVM языке не используйте проверяемые исключения, оборачивайте все возможные вызовы старых Java методов в непроверяемые исключения на этапе компиляции и не будет такой необходимости.

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

>> Управление памятью и системным треем доступно только через платформозависимый JNI

Есть много способов низкоуровеневой работы в JVM, вплоть до подключения C/C++/машинных кодов и вручную обращения к api ОС. JNI это лишь один из них.

>> Необходимость установки среды исполнения — а вот тут не понял, что это значит? Необходимость наличия на устройстве JRE в принципе? Но странно если платформа могла работать без платформы. Или вы предлагаете в каждому приложение тащить весь JRE (сотни мегабайт) с собой? Есть возможности компилировать Java байт сразу в машинные коды и тащить все с собой, но ими мало кто пользуется.

В общем, странные у вас представления о Java платформе.
Да, согласен, Андроид больше подходит под замену браузеру. У него есть очень жирный плюс в виде стандартной интерфейсной библиотеки, которой достаточно удобно пользоваться, как накидывая контролы редактором, так и в коде. А поскольку интернет у нас — про порно котят визуальные интерфейсы, удобный и гибкий способ графического отображения информации играет решающую роль.
НЛО прилетело и опубликовало эту надпись здесь
Нет, не поэтому. Браузер это браузер, где CSS, верстка, интерпретатор JS и прочие ужасы, и к построению приложений таким образом прибегают только в случае совсем уж примитивных приложений, либо с надеждой написать один раз для всех платформ, что очень быстро упирается в потолок производительности. В нативных же приложениях — байткод, существенно более быстрый и безопасный.
НЛО прилетело и опубликовало эту надпись здесь
Когда на несчастном телефоне одновременно запущены несколько приложений, написаных в стиле «производительность не нужна», внезапно оказывается, что она таки нужна.
Осталось добавить плеер Android приложений в… браузер!
Эту платформу все равно нужно будет устанавливать на телефон, комп.
т.е. это будет некое приложение. ладно представим что оно будет вмонтировано в операционные системы, т.е. как браузер по умолчанию.

Что делать с гуглом, как он теперь будет анализировать приложения, нажатия, переходы? мы не имеем DOM, мы имеем байткод, т.е. черный ящик.
Создавать разметку? тогда мы вернемся к созданию браузера.
google врядли будет создавать технологию которая убьет их основной бизнес.
А как уже сказали выше, кроме гугла и майкрасофта это никто не сделает

Создавать разметку?

Да, создавать разметку. Специально для поисковиков.


Вообще, её даже создавать не надо, такая разметка уже есть, и она как раз изобретена поисковиками для поисковиков — schema.org. Просто берём её готовую и не паримся.

Просто берём её готовую и не паримся.

Она прибита к HTML. Возможно, её можно применить к похожим языкам разметки документов. Но она никак не приспособлена для приложений.
Она прибита к HTML.

Нет, microdata в HTML — это лишь один из вариантов представления schema.org, там же есть и, например, JSON-LD (который к тому же рекомендуется для использования гуглом), не связанный с HTML вообще никак; ну и в любом случае никто не мешает придумать ещё один формат представления по необходимости.


А вообще нахрена индексировать приложения, лол?

Так идея то не создать облако приложений, а заменить сайты на эти приложения. Заходишь на vasya.ru и тебе генерируется в неком контейнере нечто похожее на сайт.
Если нужно облако приложений то тупо создавайте apple store/google play, точней его аналог и накатывайте туда свои приложения.

что делать с 10000000 сайтами? как вырастить репку, как починить люстру, кулинарные сайты. и т.д.
Нужен поисковик, если делать так как предложили выше(тупо на основе разметки), то вернемся в 2007 год, алгоритмы яндексе и гугла раньше анализировали текст и ссылки (в 2007+ была жесть в выдаче)

Гиблое это дело. Веб устраивает веб программистов.
Веб не устраивает C# / java программистов.

Я часто слышу такое мнение именно от C# C++ Java android программистов, вдумайтесь, люди с другой ниши, переживают за бедненьких веб разработчиков))


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

Самое забавное вот что: C#/java программисты переживают за душевные страдания веб разработчиков, они искренне недовольны что в вебе все плохо. Переживают за чужой мозг, что бедным веб разработчикам приходится так напрягаться на работе.

Кому не нравится стандартный JS берут что-то вроде react/angular и прикручивают TS/flow
Меня устраивают, если ты хочешь разрабатывать не веб приложения, то тебе вообще закрыта дорога в веб, бери C++ и пиши драйвера, делай мир лучше.
Зайдите в профили к людям которые яро хейтят веб, в 90% случаях это будет Java/ c#/C++ программист.
5 лет назад никто не жаловался на JS

Я жаловался :D


C#/java программисты переживают за душевные страдания веб разработчиков

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


Кому не нравится стандартный JS берут что-то вроде react/angular и прикручивают TS/flow

Обёртки над обёртками над обёртками над тормозящими HTML-CSS-JS, а в итоге чятики, по своим возможностям едва превосходящие IRC из 1989-го, еле шевелятся на моём относительно новеньком ноуте из 2014-го (да, это камень в Slack).


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

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


1) Все начинают делать веб-приложения без десктоп-альтернатив — взять хотя бы те же Slack и Skype. Как пользователь я вынужден использовать их тупо по причине отсутствия альтернатив (замену на какой-нибудь XMPP пока опустим, представим производственную необходимость).


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


Нужна платформа, которая не содержала бы ничего лишнего (условный один-единственный canvas плюс API для доступа к системе, как я уже ранее упоминал), имела бы эффективно интерпретируемый байткод без костылей (в том же V8 уже работает чуть ли не ИИ, пытаясь скомпилировать наиболее эффективные версии js-функций, хотя всё можно легко порешать тупо статической типизацией) и как следствие не тормозила бы. Варианты, как могла бы выглядеть такая платформа, уже неоднократно предлагались здесь в комментариях, да и в более старых хабрапостах с нытьём про веб.


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


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

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


Речь при electron (десктопные приложения написанные на JS)? Соглашусь, это лагучая фигня, не стоит с JS лезть в десктоп, Но это экономит кучу денег работодателю черт возьми))
В скайпе работают не лохи, относительно простых контор, если скайп умудрился написать лагучее приложение, представляю что будет в простых Московских конторках, так что тут я поддерживаю.

Обёртки над обёртками над обёртками над тормозящими HTML-CSS-JS, а в итоге чятики, по своим возможностям едва превосходящие IRC из 1989-го, еле шевелятся на моём относительно новеньком ноуте из 2014-го (да, это камень в Slack).


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

Мне как веб разработчику не вредит обертка, что бы сделать из JS нормальный язык, мне нужно ровно 3 минуты, что бы развернуть всю экоститему, react+ redux + Eslint + flow +…
Из коробки JS — плох, все согласятся.

Без «обертки» рендеринг страницы был 0.1s с обертками стал 0.2 s, разница вообще не ощущается. TS/FLOW удаляется на момент компиляции JS бандла.

Фреймворки есть во всех языках и почем-то хейтят только JS фреймворки. (Мы не собираемся создавать на вебе в браузерах аналог фотошопа(по крайней мере в 2017 :D))

Дальше не стал комментировать, вы там рассуждали про electon, как я уже сказал, что соглашусь что не стоит писать десктопные приложения на JS (по крайней мере в 2017 :D)

Фреймворки есть во всех языках и почем-то хейтят только JS фреймворки.

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

Возьмем C# Entity Framework
Я считаю это полным шлаком, с ним все лагает, криво распознает META Таблиц.
Но ты мне скажешь: он идеален, просто ты не умеешь его готовить и что-то делаешь не так.

C# веб сервисы, кому пришло в голову писать веб сервисы на C#, я видел код этих сервисов и ужаснулся, 2000 строк кода, ради создания простого REST API (куки, сессии, подмена заголовков, CORS)
Это считаю шлаком, зачем они лезут в ВЕБ сервера с своим говном?
ASP.NET такое же дерьмо, сейчас эра SPA, и ваши проекты, которые перезагружают страничку никому не нужны.
Знаешь что я еще видел, я видел C#, PHP, JAVA который генерирует JS код (пишешь на PHP. JAVA, а тебе генерируется JS код на ангуляре)
Какой дурак до такого додумался? Ваш язык не предназначен для современного веба.

Во-первых, написать REST-сервис на ASP.NET MVC можно быстрее и качественнее, чем на любом PHP-фреймворке.

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

Правда, к сожалению, работодатели очень часто требуют именно PHP — чтоб потом проект можно было поддерживать силами дешевых макак (что, конечно, заблуждение — писать на PHP хорошо куда сложнее, чем на нормальном языке, и почти никто из «PHP only» разработчиков на это не способен).
И тянуть за собой WINDOWS sever?

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

Я видел приложения на IIS+ASP.NET + react, шлак шлаком, куча оберток для JS, куча костылей, господи там даже некоторые генерировали react на коде через C#, а не разделяли на rest + client, и вы что-то про костыли в JS говорите.

Понимаю конечно что это экономия на сотрудниках.

PHP разработчики могут писать хороший код, но для этого нужен не PHP Junior За 60 000 рублей, а PHP Разработчик за 170 000 рублей, если работодатель не готов платить такие деньги, то может ему и качество не нужно? Почему все работодели считают что человек за 60 000 рублей должен быть спецаилистом? это оклад джуниора. и они никак не может быть спецаилистом и он будет, как вы выражаетесь — макакой.


Это тоже самое, если для ремонта квартиры нанимать не бригаду за 150 000 рублей в месяц, а алкаша, который только только скоречник мастерил, нанять его за 1000 рублей и жаловаться что специалистов почти не осталось, одни неумехи и шарлотаны.

а у нас как получается:
— Нам нужен специалист, но на рынке никого нет, жаль что одни немехи
— Шев может повысим зп, будем искать хотя бы от 120 000 ну и опыт от 7 лет, а не за 30 000?
— ты что? кто он такой что бы я ему столько платил? там же просто кнопки рисовать, открой авито или циан, ну что там сложного? кнопка, кнопка, текст, любой справится, нет ищем за 40 000 максимум! Веб это игрушки, HTML учить 1 неделю, нет, максимум 42000, как найдем начинаем делать свою соц сеть для знакомств(с)

И тянуть за собой WINDOWS sever?


.NET Core (существует с 2014 года) прекрасно работает на Linux. Это если не упоминать Mono (неофициальную реализацию, которая еще старше).

Я видел приложения на IIS+ASP.NET + react, шлак шлаком


А уж сколько приложений на PHP, которые «шлак шлаком»… Более того, я абсолютно уверен, что их больше, т.к. уровень среднего PHP-разработчика близок к уровню макаки.

PHP — объективно плохой язык. На нем, конечно, можно писать хорошо, но зачем, если есть нормальные языки?

PHP разработчики могут писать хороший код, но для этого нужен не PHP Junior За 60 000 рублей, а PHP Разработчик за 170 000 рублей


Ну так за 170к можно найти и специалиста по более серьезному стеку, чем PHP. Но «бизнес» не хочет платить 170к, он хочет брать макак с улицы. Это, в том числе, и вина скриптовых языков с низким порогом вхождения — что в принципе возникла такая идея, что программист может быть дешевым.
Макаки есть даже в С++ нише.
Хотите избавится от макак, платите им вместо 60 000 рублей, минимум 140 000 — 200 000 и сразу же найдутся специалисты с 5-10 летним опытом.
(если меня сейчас читают начальники и руководители, HR спецы, поймите, ну нельзя найти специалиста за 60 000 рублей и требовать от него постановки архитектуру на 3 летний проект, сейчас охранник больше получает, минимум 200 000 рублей — и будет вам специалист)

Про стек согласен, если есть деньжатки то можно и стек сменить.

А зачем PHP программисту знать как устроена память, как работать с битностью? это сделает его не макакой и C++ программисты перестанут их опускать?)

Самое главное что ему нужно знать по моему мнению — уметь строить грамотную архитектуру и писать быстрые SQL запросы) ну и чистый код еще)

Считаете ли высокий порог вхождения у Frontend (современный с его 10 обертками и 100 конфигами, кросбраузерность)?
НЛО прилетело и опубликовало эту надпись здесь
Они, быть может, не решают _ваши проблемы_. А если бы они не решали проблем пользователя — то их бы никто и не использовал, не-спа сайты просто побеждали бы спа в конкурентной борьбе.
Покажите мне пример лагучего SPA пожалуйста.
Меня веб не устраивает не как программиста, а как пользователя. Веб чудовищно жирный и тормознутый, он неэффективно расходует аппаратные ресурсы. Я, как пользователь, не хочу чтобы веб приходил в мобильную разработку, иначе мы увидим приложения уровня «список покупок», которые требуют для работы 8 ядер процессора и 16 Гб оперативки, и при этом сажают батарею за полчаса.
Не понял проблемы. Сайты пусть будут сайтами, приложения пусть будут приложениями, и нечего их смешивать, как это происходит сейчас. В каком-нибудь скайпе индексировать в поиске вообще нечего, кроме самого факта существования скайпа как онлайн-приложения. Для какого-нибудь гуглдока для публичных документов в нём не составит никакой проблемы накатать этот самый JSON-LD. Кулинарные сайты пусть остаются кулинарными сайтами на HTML+CSS, они же не приложения.
Возможно у нас разные понятия просто
Я называю веб-приложением некий масштабный сайт.

Например cian — веб приложения
Яндекс карты — веб приложение
Фейсбук — веб — приложение.
Яндекс Маркет — веб приложение.
Ютуб — веб — приложение.
рецепты ру — сайт
пикабу — сайт/Портал

Вот эти веб приложения, что я перечислил я считаю нужно писать их на JavaScript + css+ html + svg и ничего не нужно менять, нужно расширять эти языки.
Кому не нравится отсутствие типизации, подключают TS или flow
Кого напрягают всякая магия JS, просто не идут в веб разработку и пишут себе драйвера на C++, забудьте про веб разработку если она вам не по душе, вот что я хотел донести.

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

Это пишут не веб разработчики, это пишут C++ / C# /Java разработчики, которые и CSS то в руках никогда не вертели, не говоря уж о JS(ts)

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

вы под веб приложениями подразумеваете… когда на JS пытаются писать десктопные приложения?

Да


Коммент получился длинный, запихнул под спойлер

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


Тогда:


cian

Не доводилось юзать. Если это «база недвижимости», то на первый взгляд это по сути лишь пара простых формочек для поиска и текст с его результатами. Можно запилить аналог хоть для IE4 без каких-либо скриптов. Не приложение. (Могу ошибаться, ибо не юзал)


Яндекс карты — веб приложение

Вся суть в интерактиве, так что да. И в поиске индексировать нечего, кстати. (Точки интереса можно оформить отдельными документами)


Фейсбук — веб — приложение.

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


Яндекс Маркет — веб приложение.

Нет по той же причине, что cion и ВК.


Ютуб — веб — приложение.

Спорно. По идее видео уже выходит за рамки текстового документа, но его, наверно, можно считать дополнением к документу, к тому же в HTML5 есть тег video, работающий без скриптов. Если рассматривать ютуб как базу видеофайлов и комментов к ним, то наверно не приложение. А вот имеющиеся там средства для редактирования видео наверно уже тянут на приложения.


рецепты ру — сайт

А если это рецепты.яндекс.ру с миллиардом рецептов блюд всего мира всех времён, то по вашей логике будет уже приложение? :)


пикабу — сайт/Портал

Ага.


нужно писать их на JavaScript + css+ html + svg

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


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

Просто все по разному называют, для меня веб-приложение это некий сервис (Яндекс метрика или гугл адденс — я считаю это приложениями написанными на JS+html+CSS. кто-то назовет это сайты)

На рынке таких приложений как яндекс карты очень мало.
давайте будет честны, 95% работы (заказы по вебу) это: Сайты визитки, интернет магазины, интерфейсы для оборудования (для роутеров, камер и маршрутизаторов), корпоративные мини CRM (формочки, список сотрудников, парочка графиков), библиотеки данных (авто ру, циан), админки для биллингов(привет мтс билайн итд)

Веб справляется на ура с этими задачами.
под какие задачи вы собрались всю эту кашу заваривать?
Все хотят ускорить веб, сделать его крутым, грубо гоовря, но зачем? Пилить фотошоп и редактор видео в браузере?
Пилите на C++
95% работы (заказы по вебу) это:

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


Пилить фотошоп и редактор видео в браузере?

Я-то этого не хочу делать, проблема в том, что другие хотят! Компиляторы из C++ в JS есть уже несколько лет, так что появление полноценного веб-фотошопа — лишь дело времени. А потом десктоп-фотошоп возьмёт да и прекратит своё существование (торренты, конечно, никто не отменял, но пользоваться устаревшим ПО тоже не очень круто). Как прекратил своё существование десктоп-клиент скайпа для линукса (некоторые утверждают, что он ещё работает, но это тоже дело времени)

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

Почему вы не хотите пользоваться фотошопом в веб?
Потому что это не удобно?
Кто запрещает в браузере сделать кнопочку: «Убрать служебные кнопки браузера, сконвертировать вкладку в обычное окно window»

Скорость — да, согласен, но я и говорю, в близжайшие 10 лет о таком даже думать не стоит,

Почему вы не хотите пользоваться фотошопом в веб?

Потому что скорость.


в близжайшие 10 лет о таком даже думать не стоит,

В этом-то и проблема! Через десять лет появится условный веб-фотошоп, и, если веб останется примерно таким же что и сейчас, скорость его будет как на компьютерах 2002-го! За эти условные 25 лет процессоры ускорились на десятки гигагерц и десятки ядер, техпроцесс всё нанометровее, оператива начинает измеряться чуть ли не терабайтами — а производительность конечных приложений не меняется! Весь прогресс уходит в обсуживание многочисленных слоёв абстракции, половина которых к тому же не используется. Меня вот это жутко бесит. Тот же стопицот раз упоминавшийся скайп, который когда-то давно успешно работал на компьютерах 2005-го, не способен работать на компьютерах 2010-го из-за того, что он стал веб. Пора убить веб.

Почему вы не хотите пользоваться фотошопом в веб?

Зависимость и небезопасность. Отключили интернет — работать не могу. Набежали хакеры на сервера — работать не могу. Устроили конкуренты DDOS — работать не могу. Поменяли интерфейс, он не понравился, а не обновляться уже не получится, буду жрать чего дают. Где мои файлы гиговые, на серверах? Как мне их, условно, в типографию отнести? Как мне их в других приложениях использовать? Порисовал в шопе, экспортировал, скачал импортировал в другое приложение. Понадобилось что-то подкрасить, опять экспортировать, скачать, импортировать?
Вот, кстати, хорошая-годная платформа для онлайн-приложений должна позволять эти самые приложения кэшировать для последующей работы в оффлайне. Вроде пару лет назад намечались какие-то веб-стандарты на эту тему (точные названия уже забыл), но потом от всего отказались и всё, что успели нареализовать, выпилили :(

Проблемы работы в оффлайне уже решены. Гуглить по ключевым словам «Progressive Web Apps» и «Service Workers».

Загуглил, спасибо, буду знать
Проблемы, согласен, но со временем и их решат.
Биткойн кошельки видели? веб версия грузится за 10 секунд через сайт, локальная версия кошелька весит ~200 гб.
Хочешь надежность, качаешь локальную версию кошелька.

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

… сделанное на базе Electron со всеми вытекающими )

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

Давайте будем честны, 95% задач на рынке разработчиков это проекты для работы с данными: показать формочку сотрудников, получить данные, отправить данные, нарисовать на графике информацию за 1 год. Эти задача не требует высокой производительности. слабое место всегда БД!!!

Понятное дело что если вам нужна какая-то 3D игра, то не стоит ее пилить на react native, и никто и не пилит. Но если вам нужно приложение для заказа Пиццы,(Task менеджер) то react native идеальное решение.
Это очень выгодно работодателям.

Тоже самое и с electron, нужен фотошоп — берите С++
Нужно пара формочек (мини CRM) — берем electron

Эти задача не требует высокой производительности.

Это не даёт им право жрать ресурсы как фотошоп. Вообще-то я хочу, чтобы ресурсы использовались для дела этим самым фотошопом, а не какой-то жалкой формочкой :) Если не запускать формочку и фотошоп одновременно, то проблемы нет, но блин, и нахрена тогда нужна многозадачность в ОС?


Нужно пара формочек (мини CRM) — берем electron

То же самое: в результате «мини CRM» не умеет почти ничего, а ресурсов жрёт как тот же фотошоп. Не кажется ли вам это абсурдом?


Кстати, у меня сейчас открыт Adobe Illustrator CC с двумя совсем не маленькими файлами с кучей слоёв, векторов и встроенных растров, занимает это всё в оперативе 300 мегабайт. Нижеупомянутые гуглдоки с простым текстовым документом жрали те же 300 мегабайт. Мессенджер Slack, когда я его юзал, в котором кроме текста, разбавленного редкими картинками, толком ничего и нету, временами кушал памяти раза в полтора больше.


Хочется разбить монитор.

если рассматривать CRM мини.
Ваше приложение на C# хавает 120МБ, мое хавает 350.
Разница прям ощутимая? 21 век на дворе, у всех минимум 8гб оперативки, в игровой индустрии тоже разработчики виноваты, что их игры не запускаются на 4 пеньке?

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

Но какие мы имеем плюсы?
— Выгода работодателям в плане денег на разработку под все платформы.
— Визуализация 78 уровня, вы с своим C++ C# все на канвасе будете рисовать пол века, а веб разработчик нарисует за 1 неделю.
— Кросплотформенность, нам не нужны 10 разработчиков, теперь достаточно 3-4
— скорость разработки

Может стоит пожертвовать 20% оперативки ради таких плюсов?
Бизнесу важны деньги, а не красивый код и оперативка.

Сейчас очень мало кто вообще слышал что-то про react native и electron, мало кто понимает что это выгодно для бизнеса, мало кто доверяет этим технология.

Тогда вопрос к вам:
1) Cкайп это технология Microsoft
2) Visual studio code это технология Microsoft

Почему они пишут на JS вместо своего любимого C#?

Продукт сырой, в будущем косяки с оперативкой продумают, мне так кажется.

У GNU нет такой проблемы, соблюдается принцип KISS (Keep It Simple and Small), благодаря OpenSource не приходится постоянно изобретать велосипед, разделяемые библиотеки помогают экономить память. А если чувствуются тормоза, смотрим что в памяти жрёт больше всех, оставляем столько, на сколько хватает ОЗУ и делаем
# swapoff -a
# swapon -a

и нет тормозов
Ваше приложение на C# хавает 120МБ, мое хавает 350.

Мое приложение на Rust+GTK3 будет хавать максимум 40МБ :D


Разница прям ощутимая?

Да. В 230МБ можно запихнуть очень много полезного. Например, Adobe Illustrator с двумя тяжёлыми файлами.


в игровой индустрии тоже разработчики виноваты, что их игры не запускаются на 4 пеньке?

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


Но какие мы имеем плюсы?

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


мало кто понимает что это выгодно для бизнеса

Мы все понимаем, что «выгодно для бизнеса» и «выгодно для пользователя» — вещи противоположные. Сейчас всё делается на «выгодно для бизнеса»: бизнес берёт js-макак-первокурсников, которые за еду клепают веб-приложения (можно вместо «веб-приложения» подставить любую другую модную абстракцию), веб-приложения жрут ресурсы и тормозят, пользователи идут покупать новый комп чтоб не тормозило, веб-приложений становится больше, всё снова начинает тормозить, пользователи идут покупать ещё более новый комп, и всё по новому кругу. В результате компы становятся в десятки-сотни раз мощнее, а возможности те же, что и у компьютеров восьмидесятых. Прогресс имеется разве что в играх, думаю потому что там до сих пор старый добрый C++ без лишних абстракций: ещё 10 лет назад о каком-нибудь VR никто и мечтать не мог (жалкие попытки в 90-х вспоминать не стоит), а сейчас вполне годный шлем можно в любой эльдораде купить, и будет неплохо работать. Или в нейросетях, которые, вовсю эксплуатируя GPU, автоматизируют кучу полезных вещей, которые раньше автоматизировать было почти нереально. А теперь сравним какой-нибудь Word 95 и гуглдоки. Какие есть существенные отличия, кроме онлайна? Куда тратятся три сотни мегабайт? Почему оно жрёт три сотни мегабайт, а тормозит и глючит сильнее, чем Word 95 на компах того времени? Почему текстовый документ оказывается тяжелее, чем пара тяжёлых графических файлов в том же иллюстраторе, который у меня до сих пор запущен? Хотя чего это я — потому что «выгодно для бизнеса». А мне как пользователю нихрена не выгодно.


Почему они пишут на JS вместо своего любимого C#?

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

Ваши 40 мб никому не нужны, это нужно только вам.
Пользователю и бизнесу срать на ваши 40мб.
Это писькомерство среди программистов.

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

Я сейчас проверил VS CODE (написан на JS), нацепил на него плагины и загрузил большой проект, оперативки заняло 100мб.
Загрузил этот же проект в WEbstorm — 500мб.
Саблайм — 60мб.

Так что не все так плохо даже сейчас, дальше будет еще лучше.

Веб никак не убить (html+js+css) и ничего не поменять, смиритесь.
Google себя убивать не станет.
Microsoft подстроился под современные тенденции и взял в стек JS.
кто остался? больше никто массово не может повлиять на пользователей.

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

JS не идеален, но многие проблемы у него уже решены через обертки, фреймворки. установить обертку дело 2 минут, если вы не можете установить обертку, то вы не веб разработчик.
Да… круто было бы без оберток, но лет через 5-7 JS к этому придет думаю и все будет из коробки.

Вебасембли, это тоже не убьет веб, это даст ему очень сильный буст, JS станет еще сильней, а за ним и Node.JS и Electron.

Никто не будет писать ан C# байткод для сайтов и простых веб приложений, напомню 95% проектов рынка не нуждаются в скоростях уровня «фотошоп».

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

Веб будет жить еще долго.

Ваш комментарий целиком и полностью верен. Но он никак не противоречит тому, что веб говно. Можно сделать конфетку на js типа VS Code (я установлю его и проверю ваши утверждения про память), можно написать говнокод на сишапре. Однако вы же сами говорите, что «JS не идеален». Он не просто «не идеален» — он ужасен. HTML и CSS также ужасны и до сих пор не решают многих задач, нужных приложениям (весь список проблем прям щас не приведу; но в комментах тут по чуть-чуть уже упоминали). В конце концов все делают один canvas и рисуют на нём, а HTML и CSS лежат без дела и жрут память и процессор, потому что браузер всё равно выполняет какую-то логику для их обработки. Если писать конфетку на веб-технологиях и конфетку на не-веб-технологиях, то в общем случае не-веб будет меньше и шустрее; тот же ваш Sublime это подтверждает (при том что у него плагины на Python, который даже хуже чем JS, лол).

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

Веб будет жить, конечно. Но было бы намного лучше, если бы вместо него жило что-нибудь другое. Но, думаю, каждый комментатор здесь понимает, что этому не бывать и вы правы, так что всё, что остаётся — писать нытьё подобное моему в комментах. Ну и ещё я ярый сторонник, как вы выразились, «писькомерства», да.)
Даже если завтра вместо JS сделают C# и уберут DOM, думаете говно кода убавится в проектах?
Все равно будут нанимать батраков за 50 000 рублей, они так же будут писать говно код (но рабочий), кому нужен хороший код нанимают специалистов за 160 000 рублей условно.

И не забывайте про поисковики, без поисковика нет смысла в интернете и всем обилии сайтов, информации.
Поисковик индексирует и анализирует сайт по тексту и разметке, они шли к этому 10++ лет и сейчас сделали вроде бы нормальные алгоритмы анализа.
Как анализировать сайт который не имеет текста(DOM)? так же как Flash? это отбросит всех на 10 лет назад.

Круто было бы иметь не DOM, а холст где будут элементы меню и прочее добро (Canvas), Но это уже есть и в 2017 году, google свою карту рисует не на DOM а в холсте.

Для сложных задач веб плох (5% рынка)
Для остальных задач — веб хорош)
Кому нужна типизация — подключают TS / flow, там почти все тоже самое что в вашем C#
Как анализировать сайт который не имеет текста(DOM)?

JSON-LD, я уже писал про это в комментах. И да, сайту DOM нужен, я ничего против этого не имею. DOM не нужен только приложениям, не стоит меня передёргивать.


google свою карту рисует не на DOM а в холсте.

«… а HTML и CSS лежат без дела и жрут память и процессор» и далее по тексту предыдущего и всех остальных моих комментариев.)

Это тоже самое что было с Flash сайтами, поисковикам отдельно подкидывали разметку, а тут вы предлагаете прокинуть текст в Json.
На основе текста нельзя провести анализ сайта, мы вернемся в 2000 года, в 2000 годах все обманывали поисковики путем манипуляций с внутренней разметкой, потому что в те времена анализ был только за счет текста и ссылок.
Потому что такие манипуляции больше не работают (по крайне мере в Yandex)

Сейчас я открыл Ctrl+alt+del, у Меня браузер жрет 2 гб.
не так круто, соглашусь, но я сам виноват, у меня открыто 50 вкладок, играет музыка, открыт ютуб)

Хотите сократить оперативку до 30мб? настраиваем в хроме, что бы сайт выгружался из памяти, при активации вкладки он подгружался заново :D

Моё сообщение о том, что против DOM-сайтов я ничего не имею, вы успешно проигнорировали
Вы имеет что-то против elctron приложений? (таких как Skype и Vs Code, дескоп приложения у которых под капотом JS + Node + Хромиум)
Напомню что в бизнесе 95% задач простых и только 5% сложных. (как правило эти задачи в Google Adobe Yandex и т.д.)

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

95% — задачи не требуют высокой производительности, веб (JS) там хватает за глаза, не нравится язык? берем фреймворк и статичную типизацию + EsLint и проче едобро. Хотите сделать так что бы приложенеи хавало 40мб оперативки вместо 700мб? Нанимаете разработчика не за 40 000 рублей, а за 130 000 рублей условно. (тут вы согласны?)

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

тут почти все работают над CRM, какими-то аналитическими системами, все это не требует производительности, слабое место всегда в расчетах, т.е. в бд и сервере.

Сложные задачи оставим гигантам, и как сделать круто — они сами разберутся, вон взять VSCODE — они сделали круто, у меня ничего не Лагает.
Сколь бы правы вы ни были, это никак не изменит того, что новый веб-скайп не идёт у моей мамы на ноутбуке, выпущенном в 2010 году. Я готов отказаться от всех своих слов, если вы дадите тысяч 60 рублей на покупку ей нового ноутбука и ещё тысяч 60 на апгрейд моих собственных железок, чтобы я мог все свои задачи запускать не по очереди :)
Не знаю, как насчёт Flash, но вот Silverlight, например, очень даже можно анализировать по тексту и разметке, ибо XAML.
Вот тут вы не правы: 40 Мб и быстрое время запуска приложений нужно всем тем, кто сел за компьютер до середины 2000х или просто в силу тех или иных причин вынужден сидеть за старым компьютером. Кстати, замечу, что еще в конце 2013 года типовой комплектацией ноутбука среднего ценового класса было всего 4 Гб оперативки, и далеко не все считают нужными менять компьютеры так часто.
В остальном же соглашусь с andreymal: есть информационные сайты, и для них действительно не надо придумывать новый стек технологий, а заставлять людей эффективно использовать уже существующие (т.е. оптимизация картинок, минификация CSS и JS, поддержка HTTP/2 и просто минимализм и отказ от злоупотребления красивостями), а есть именно приложения, где важна интерактивность. И вот для них и нужно создать новое решение, к чему и призывает автор исходной статьи (хотя соглашусь, спорных заявлений у него хватает).
Свежеустановленный и свежезапущенный VS Code незамедлительно выкушал около 450МБ оперативы, хотя я не успел ещё сделать вообще ничего.

Кажется, что-то пошло не так.

Кстати, свежезапущенный Chromium выкушивает примерно столько же.

Не свежезапущенный Sublime с открытым проектом и несколькими плагинами кушает примерно 100МБ. По-моему тоже многовато, но не полгига всё-таки)
Мы все понимаем, что «выгодно для бизнеса» и «выгодно для пользователя» — вещи противоположные.

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

Глупость глупостью, только вот тогда почему бизнес этого не делает, лол?)
Очевидно потому, что это невыгодно пользователям.

Бизнес именно это и делает.

Действительно.


Всё ради пользователей.


Предоставим пользователю право выбора, ага.


Безопасность пользователей превыше всего.


Супер выгода — всего $0.99 за одну небольшую настройку!


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

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

А вы не пытайтесь решать за пользователей ;)
Большинство пользователей предпочитает иметь работающее приложение (пусть и медленно работающее, допустим), чем не иметь вообще.
Тогда вопрос к вам:
1) Cкайп это технология Microsoft
2) Visual studio code это технология Microsoft

Почему они пишут на JS вместо своего любимого C#?


1) Только linux-версия скайпа на электроне. Виндовая на Qt. Видимо, им по понятным причинам плевать на Linux-юзеров.

2) В VS Code как раз критические части были переписаны на С++, в следствие чего тормозит она в разы меньше, чем изначальный Atom

Ну и да, они на TS пишут, который, хоть и компилируется в JS, но статически типизирован, и создан автором C#.

Вы согласны платить за мини-CRM цену Фотошопа?

Для начала, web — (с англ) это сеть. Сеть подразумевает стек технологий в рамках OSI. Туда входит много, проще сказать что туда не входит или к ней не относится.
Site — (с англ.) место, то что имеет адрес в сети.
Приложение — дополнение чего либо, например операционной системы ПК или мобильника. Приложение может работать через веб, тогда это веб-приложение.
Точнее web — паутина, www — всемирная паутина.
ну и в любом случае никто не мешает придумать ещё один формат представления по необходимости.

Картинка с форматами.
А вообще нахрена индексировать приложения, лол?

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

Можно какой-нибудь пример? Я сходу чё-то ничего не могу припомнить помимо гуглдоков

Я не любитель приложений, и мало где зарегистрирован, поэтому не знаю. Инстаграм подходит или у него инфа дублируется на сайт?

Инстаграм — обыкновеннейший веб-сайт с картиночками, который хрен знает зачем сделали как SPA, так что не. А индексируется он, похоже, тупо через meta-тег description

Тогда не знаю, видимо, зря проверил той статье. Сейчас конкретно её найти не могу, но всплывает куча статей про то, как же круто, что приложения индексируются и как все этого ждали.
Гугл-поисковик выполняет js, и, наверно, «та статья» (или «те статьи») радовалась именно этому. Но, похоже, инстаграм этим не пользуется, в результатах поиска отображается только содержимое meta-тега description. В любом случае это использование технологий не по назначению: сайтам уровня инстаграма js нахрен не нужен.

UPD: Кстати, картинок из инстаграма в поиске гугла нету)
как это зачем? SPA удобен тем, что мне не нужно жддать перезагрузки страницы, тыкаю кнопку, интерфейс остается на своем месте, подгружаются новые фоточки и меняется структура сайта. без мерцания интерфейса. (если я накходился в центер страницы, мне не нужно заново прокручивать до центра)

Идеология SPA Такая: Для пользователей включаем режим SPA, для поисковиков и тех кто перешел по GET Запросу — грузим слепок DOM с сервера.
Обычное поведение, работают все те же принципы SEO
SPA удобен тем, что мне не нужно жддать перезагрузки страницы

SPA тут вообще ни разу ни причём и нахрен не нужен. Для этого достаточно прикрутить какой-нибудь PJAX или аналог, который будет аяксом подгружать куски HTML-кода с сервера. При этом с включенным js получаем ускорение без всякого мерцания, а с отключенным js просто отваливается PJAX, а сайт остаётся полностью работоспособным, а не с белым экраном, как у инстаграма сейчас. (Я лично не измерял, но поговаривают, что так получается даже быстрее, чем с «классическими» SPA.)


Идеология SPA Такая: Для пользователей включаем режим SPA, для поисковиков и тех кто перешел по GET Запросу — грузим слепок DOM с сервера.

Ну и зачем так мудрить и оверинжинирить, когда можно сгружать DOM и пользователям тоже? Все мерцания фиксятся PJAX'ом.

Простите, но в чем тогда принципиальная разница между SPA и не SPA, если все равно прикручиваем AJAX для асинхронного изменения контента, только кашу на сервере и клиенте наводить. Или у Вас каждый день встречаются случаи, когда у пользователя отключен JS?
в чем тогда принципиальная разница между SPA и не SPA

SPA-cайт типа Instagram создаёт HTML на клиенте и не работает без JS. Сайт на PJAX/Turbolinks и аналогах создаёт HTML на сервере и успешно работает без JS. Во втором случае JS занимается лишь ускорением сайта AJAX-запросами и ничем больше (в контексте данного обсуждения; пихать дополнительные скрипты никто не запрещает, конечно).


Или у Вас каждый день встречаются случаи, когда у пользователя отключен JS?

Во-первых, лично знаю нескольких таких человек. Во-вторых, я выступаю за то, чтобы абсолютно все сайты могли работать без JS и чтобы абсолютно любой пользователь мог его спокойно отключить.

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

выступаю за то, чтобы абсолютно все сайты могли работать без JS и чтобы абсолютно любой пользователь мог его спокойно отключить.

А зачем? Этот момент мне лично не понятен.
Если есть намек на какую-то динамику на странице

Я инстаграмом сильно не пользовался, просветите, что там есть такого очень динамичного?


А зачем?

Все избаловались включенными по умолчанию скриптами, а на самом деле вопрос должен стоять по-другому: зачем я должен включать JS? Типичное времяпрепровождение в вебе (не считая веб-приложений) — это чтение статей, текстов и постов, иногда оставление каких-нибудь комментариев (типа этого), гуглинг, копипаст из stackoverflow и всё такое. Всё это умеет HTML без лишних дополнений, зачем для этого JS? Хорошо, JS может служить неплохим дополнением ко всему этому (предпросмотр коммента без обновления страницы, кнопки HTML-редактора над формой, экономия трафика и времени за счёт ajax-подгрузки только новых комментов, тот же PJAX и т.п.), с этими вещами всё понятно, но это всё лишь дополнительные плюшки; зачем делать на JS такие вещи, которые могут работать и без JS?

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

Мне как пользователю какая выгода от того, что вам проще взять React? Я вам сегодня доверился и включил JS ради вашего удобства, а завтра вы подсовываете майнер, а послезавтра собираете fingerprint моего браузера и продаёте меня рекламщикам.


Я бы сидел с отключенным JS, но, к сожалению, ВСЕ сайты его требуют. И альтернатив у веба не существует. Приходится прогибаться под любителей реакта :(

> Мне как пользователю какая выгода от того, что вам проще взять React?

Та, что вы получите работающее приложение (пусть и с js).

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


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

> А работающий сайт я могу получить и без js. Но я его не получаю,

Ну почему же можете? Именно что не можете! Чтобы получить работающий сайт — его кто-то должен сделать. Либо у вас есть работающий инстаграмм в виде спа, либо у вас нет работающего инстаграмма, потому что разработчики инстаграмма решили, что не хотят делать его не-спа. При этом вам, конечно, никто не мешает сделать свой инстаграмм, без жс и всего такого. Только вот тогда ваш продукт не сможет конкурировать с продуктами тех разработчиков, которые жс используют свободно, и вы к хренам собачьим вылетите с рынка.

Вылечу я или нет, от наличия или отсутствия JS никак не зависит. ВК прекрасно работает без JS (кроме аудиозаписей из-за копирастов; а, например, видеозаписи работают). Что-то не похоже, чтобы он куда-то вылетал.

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


Не у всех компаний есть возможность потратиться на такую спец.версию.

Ни за что не поверю, что нет возможности потратиться у фейсбука :)

Тем не менее всё равно не вижу никаких серьёзных проблем совмещать JS и не-JS и делать полнофункциональную версию веб-сайта (ещё раз: не онлайн-приложения) в обоих случаях, кроме лени разработчиков. Ну и даже если брать реакт, можно ж было хотя бы server-side рендеринг прикрутить, он это умеет блин
лени разработчиков

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

Всё время существования веба свистелки делались прикручиванием скриптов сбоку к существующему HTML-коду, и всем было норм. Не знаю причин, почему это должно было измениться.
Всё просто- свистелки и перделки возобладали над содержимым.
> Ни за что не поверю, что нет возможности потратиться у фейсбука :)

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

Разработчики Instagram решили, что реализуя приложение как SPA, им будет проще его сопровождать, а может им просто нравился тот инструментарий, получать удовольствие от работы тоже важно. Эти простые истины переписать не так легко.
Для вас есть консольные браузеры, пользуетесь ими.
Во-первых, лично знаю нескольких таких человек. Во-вторых, я выступаю за то, чтобы абсолютно все сайты могли работать без JS и чтобы абсолютно любой пользователь мог его спокойно отключить.

Доля бомжей равна 0.00001% на весь мир, «7 одного не ждут.»©
Есть 4 пеньки на многих предприятиях, под них тоже подстраиваться? На них идеально встает Window xp, но на XP не запускается много приблуд.

Есть разумный минимум в 2017 и я вам его опишу.
1) у каждого должен быть мобильный телефон на базе Android / IOs / Window OS ( цена от 10 000 рублей)
2) Компьютер или ноутбук (4гб — 8гб ОЗУ / 500ГБ, core i3-i5) (цена от 15 000 рублей)

Вы можете отказаться от JS хоть сегодня, вам никто не запрещает делать сайты без анимации, без JPG и SVG.
Можно сделать просто в виде текста, это будет грузится за 1 секунду и занимать 1 МБ в оперативной памяти.

Но вы не сможете конкурировать с другими игроками, ваш сайт будет сильно отставать. Я могу предложить пользователю Autocompete с картинкой, а вы просто Input, я предложу realtive фильтры, а вы клик на чекбокс с перезагрузкой страницей.

Ответьте на вопрос: Кому выгоден отказ от JS?
А никому, всех все устраивает кроме Java и С# разработчиков, которые переживают за свой рынок.




Опять доводим до абсурда?


Во-первых, про JPG, SVG и графику я ничего не говорил. Они не являются исполняемым кодом. (а в SVG пихать скрипты тем более нефиг)


Во-вторых, я в этой ветке нигде не говорил про отказ от JS. Я говорил про отказ от обязательного JS. Сайты, которые я делаю и буду делать, тоже имеют автокомплит, аякс и прочую дребедень — только, если захочется, всё это можно отключить, и сайт останется работоспособен. Опять же, смотрите мобильную версию ВК — там сделано именно так.

Во-вторых, я в этой ветке нигде не говорил про отказ от JS. Я говорил про отказ от обязательного JS.


Имеется ввиду по умолчанию отключить JS, но если пользователь захочет, то для конкретного сайта включит JS.
Что мешает вам сделать это сейчас?
Вы можете это сделать, отключаем JS в браузере, но включаем для определенных сайтов через плагин браузера.
Хотя я знаю что мешает — 99% сайтов поломаются.

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



Только зачем это пользователям? Не вам лично, а пользователям и всему миру, какая в этом польза?

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


Мне всё ещё плевать, что это сложно и не выгодно для бизнеса.

ну если вы такой молодец, то утрите всем нос, напишите свой сервис без JS но со всей функциональностью.


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

Я и пишу, не волнуйтесь. Только вот одного меня не очень хватает, чтобы «переписать» весь интернет.
Минус ещё одна потенциальная дырка в безопасности, минус майнер на The Pirate Bay, минус шпионство через fingerprint, плюс свобода выбора у пользователей, которые получат возможность выбирать, доверять разработчикам или не доверять, плюс возможность отрезать потенциальный вектор атаки на девайсы людей, плохо умеющих в интернет, вроде всяких бабушек да дедушек (как минимум на первое время, пока не освоятся). Вам этого мало? (В теории ещё экономия электричества и как следствие благоприятное влияние на экологию, но это уже на грани бреда.)

Мне всё ещё плевать, что это сложно и не выгодно для бизне

1) На WIN тоже полно дыр и они будут всегда. последние 3 года я не слышал о серьезных уязвимостях в вебе, пробив связок сплойтов с годами пришел к 5%
2) Я создал сайт и хочу заработать на нем денег, не хочешь пользоваться моим сайтом, иди в библиотеку читать книги, там не будет рекламу и прочей фигни.

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

Сайты создаются не для вас, уважаемые пользователи, сайты создаются для заработка админов.
Только в России люди думают что им обязаны предоставлять бесплатный контент, я потратил 100 000 рублей на разработку сайта для вас любимых, вот такой вот я добряк, да плевать мне не вас всех. Если реклама перестанет приносить деньги, я включу майнер.
Но зачем я создал этот сайт? что бы на нем заработать

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

Зачем на все? Вводите на свои, это исключительно ваша воля. Кстати, такие сайты уже давно существуют и здравствуют.
Вот лично я был бы не против возможности купить платную подписку на поисковые системы, социальные сети, электронную почту, и т.д. Но с условием: на этих сайтах никакая информация обо мне не будет собираться ни в каких целях. Думаю, не только я хотел бы такую услугу…
SPA неудобен тем, что чтоб увидеть что сайт мне не нужен, нужно дождаться:
а) загрузки всего этого вороха скриптов
б) загрузки данных от этих скриптов
в) рендеринга всего этого.
Если сайт мне нужен, то плюсом ко всему этому:
г) непонятно то ли сеть отвалилась, то ли просто тормозит
д) а, нет, это всё-таки сеть отвалилась, и приложение не хочет дальше загружать — придётся обновлять страничку: IF (RANDOM() > 0.2) GOTO а)
е) найти бы то место, где бросил читать
ж) в особых случаях: ссылку на текст можно получить, соответственно можно закладку поставить.
НЛО прилетело и опубликовало эту надпись здесь
Как пользователю включить его?
НЛО прилетело и опубликовало эту надпись здесь
Ну вот о том и речь — если программист позаботился, то любой сайт будет комфортен. Только вот что-то всё больше неудобных сайтов.
НЛО прилетело и опубликовало эту надпись здесь
SPA неудобен тем, что чтоб увидеть что сайт мне не нужен, нужно дождаться:
а) загрузки всего этого вороха скриптов
б) загрузки данных от этих скриптов
в) рендеринга всего этого.
Если сайт мне нужен, то плюсом ко всему этому:
г) непонятно то ли сеть отвалилась, то ли просто тормозит
д) а, нет, это всё-таки сеть отвалилась, и приложение не хочет дальше загружать — придётся обновлять страничку: IF (RANDOM() > 0.2) GOTO а)
е) найти бы то место, где бросил читать
ж) в особых случаях: ссылку на текст можно получить, соответственно можно закладку поставить.

Средний размер JS бандла около 2МБ.
7 одного не ждут, слышали такую пословицу?
Чините свой компьютер, вызывайте системного администратора, повышайте скорость интернета.
Разумный минимум в 2017 году это: 4ГБ ОЗУ + Core i3 + 30 Мбит интернет.

Почему всех людей на планете все устаривает, а вас нет? Под вас никто не будет подстраиваться, у нас 21 век и если вы сидите с Window XP, то это ваша проблема, а не наша.
Хотите пользоваться современным вебом установите себе разумный минимум, который я описал выше.

Ладно, я могу поверить что вы живете в Якутии где скорость интернета равна 10 Мбит и Core I3 Там роскошь, я предлагаю вам воспользоваться альтерантивами:
1) новости читайте через RSS
2) Не пользуйтесь Хромом, он не выгружает сайты из памяти и забивает оперативку, он оптимизирован под современные компы
3) вместо фотошопа берите paint
4) Вместо goole Maps берите бумажную карту или скачиваете приложение внутрь системы.

Если у вас лагает сайт под мобильный интернет что делать?
1) осознать что создатель сайта вам ничего не должен., россияне привыкли что им должны все нахаляву делать качественно.
2) платите создателю денег что бы он развивал свой сайт и вкладывал в SSR
3) у крупных компаний как правило есть отдельное мобильное приложение, которое оптимизировано под мобильники
Разумный минимум в 2017 году это: 4ГБ ОЗУ + Core i3 + 30 Мбит интернет.

У меня 24ГБ ОЗУ, Core i5 на 4ГГц и 100 мегабит, и экономичная Windows XP на борту. Но я недоволен SPA, особенно первой загрузкой.
у нас 21 век и если вы сидите с Window XP, то это ваша проблема, а не наша.

Под XP сижу я, проблем с ОС нет.
И сколько он у вас грузится? целую секунду?
Как вы поняли что проблема именно в SPA? замеряли скорость?
можно пример глючного SPA сайта?
5 секунд на белой странице, иногда с издевательским прелоадером. Примеры не приведу уже, я такие сайты стороной обхожу, а не вношу в закладки на память.
2МБ это только чтоб оно начало что-то делать. Следом идут «типа» данные, которых бывает сильно по-разному. Потом программисты почему-то считают что раз какой-то скрипт начал грузиться, то всё остальное просто обязано загрузиться.
Жить в Якутии совсем не обязательно, такого счастья и в Москве предостаточно: от слабого компьютера до отсутствующего интернета. Но конечно, сайту дела нет до того 0,0..1% пользователей.

1) Через RSS и так основная часть настроена. Но его по-тихоньку все задвигают назад. Новые сайты делают сразу без RSS (и не уверен что в SPA вообще где-то видел такое счастье), а старые сайты ломают имеющееся (привет, MS). Ну и целиком мало кто хочет новость отдавать в RSS (ЖЖ и youtube, к примеру, не вставляют видео в эту разметку, хотя когда-то давно вставляли превьюшку; хабрахабр выгружает пост до ката), все хотят чтоб я зашёл на их миленький сайтик.
3) picasa достаточно, фотошопом пользовался когда он был версии 5. Если нет — darktable
4) этим невозможно пользоваться, даже если б оно не жрало память и было быстрым. К счастью альтернатив больше двух.

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

Если Гугл в AndroidSDK в класс android.widget.Button влепит колбэк на отправку нажатия на кнопочку в Гугл — большинство андроид приложений будет всю свою статистику слать прямиком туда. Потому что никто свои виджеты не делат (разве что в играх на Unity каких нибудь).
А если будет слать через сокет а не через http-запрос — то раз в стопицот быстрее чем Google Analytics.
Так что не вижу принципиальной разницы.


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

НЛО прилетело и опубликовало эту надпись здесь
Хм… Flash, Silverlight…

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


И, по моему мнению, если бы вместо html мы бы писали TeX, Веб лучше бы не стал.

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


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

Что-то слабо себе представляю его применение. Как там с изменением размеров окна, например?
Вангование ниже:
Скрытый текст
Я посмотрел в блог Майка и мне кажется, он будет во второй части продвигать Kotlin
Веб ущербен от начала и до конца. Но он там же и останется, потому что выгода получаемая от дырявого говнокода перекрывает потенциально возможные проблемы от взломов. Почему тот же Facebook, огромнейший гигант, как и Amazon всё ещё не используют для загрузки, например websockets и https/2? а) возможность взлома сведена к минимуму кучей надстроек внутри API. 2) проще докупить ещё аппаратной части для обеспечения производительности, чем менять инфраструктуру. Корпорации в данном случае решают _как_ должен выглядеть веб.
У меня, как у фронтенд разработчика, конечно довольно много претензий к современному вебу, но хотелось бы сначала увидеть альтернативы причем, с вменяемыми средствами разработки и примерами сценариев использования.
Татарский, конечно, ненавидел советскую власть в большинстве её проявлений, но все же ему было непонятно – стоило ли менять империю зла на банановую республику зла, которая импортирует бананы из Финляндии.
В виду того, что сейчас все завязалось веб стек, других средств вменяемых появляться не будет.
А если соединить все лучшее из мира десктопа и Web?
Например, реализовать единый стандарт байт-кода. Основать его на байткоде CLR, JVM, V8. WebAssembly же смогли сделать, смогли договориться, так и тут)
И реализовать его поддержку на уровне ОС. В этот байткод будет компилироваться JS, .NET, Java-приложения и т.д.
Для поддержки приложений реализовать единый стандартный язык разметки, можно например на основе XAML. Обеспечить поддержку модных нынче компонентов. Можно встраивать в систему готовые компоненты.
На уровне ОС обеспечиваем удобный интерфейс, похожий на браузер, для просмотра HTML-документов(которые останутся документами, максимум интерактивными страничками).
Также в этом интерфейсе можно будет зайти на сайт, а он предложит установить приложение, либо автоустановка в безопасном месте, только с пользовательскими правами. Можно сделать на основе идей мобильных приложений)
В разных вкладках этого браузера 2.0 можно будет запускать как просмотр документов, так и приложения.
При этом исполняющая среда не будет по одной копии на вкладку, а общая на систему.
Таким образом, получаем настоящие кроссплатформенные приложения, удобство для разработки, красивые интерфейсы, при этом решаем проблему Electron(где отдельный Chromium на каждое приложение), и можно делать на любом языке программирования.
А ОС будут уже соревноваться между собой кто как лучше реализует эти стандарты и быстрее исполняет этот байткод.
И можно будет вводить стандарты на API к различным элементам системы, при этом делать их безопасными. Все равно все корпорации так или иначе стараются выполнять веб-стандарты)
Это будет ОС 2.0 и Браузер 2.0.
Эх, мечты…
Например, реализовать единый стандарт байт-кода… В этот байткод будет компилироваться JS, .NET, Java-приложения и т.д.
Уже есть. «Система команд x86» называется.
реализовать единый стандартный язык разметки
Уже есть. HTML называется. На мой взгляд, ужасен.
На уровне ОС обеспечиваем удобный интерфейс, похожий на браузер, для просмотра HTML-документов(которые останутся документами, максимум интерактивными страничками).
Чем эти «документы» тогда будут отличаться от приложений? А уж интерфейс для запуска приложений в ОС и так хорош.
При этом исполняющая среда не будет по одной копии на вкладку, а общая на систему.
Копию на вкладку сделали не просто так, а ради стабильности и безопасности.

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

Имелось в виду байт-код, не привязанный ни к платформе, ни к языку программирования. Что-то похожее на WebAssembly или LLVM IL.
Уже есть. HTML называется. На мой взгляд, ужасен.

HTML — предназначен для текстовых документов. Я же предлагал XAML. Можно взять любой другой, tex и т.д. Сделать поддержку компонентов в первую очередь.
Чем эти «документы» тогда будут отличаться от приложений? А уж интерфейс для запуска приложений в ОС и так хорош.

А чем сейчас документы отличаются от приложений? Я имел в виду единый интерфейс, чтобы юзер захотел — открыл сайт, документ, захотел — запустил приложение и было удобно. Это будет скорее tabbed shell, чем браузер, где каждая вкладка может быть окном, а каждое окно — набором вкладок.
Копию на вкладку сделали не просто так, а ради стабильности и безопасности.

Я критикую подход электрона, который запускает Chromium на каждое окно. При этом можно было бы вынести все таки эту общую часть и не грузить ее каждый раз по новой.
> Думаю, что веб стал таким, потому что HTML вышел с вполне вразумительной философией дизайна и инструментарием как платформа для документов, но в качестве платформы для приложений HTML пришлось закреплять на соплях, и ничего хорошего до сих пор не получилось.

это ключевое, давно об этом пишу и говорю — HTML это язык разметки гипертекста, а для современных задач нужен язык разметки приложений. Javascript это клей для вывода alert окон и т.п., а сегодня нужен полноценный, грамотно спроектированный язык.
О, очередной вой очередного «бородатого ортодокса». Друг мой, сейчас маленький гуманитарий, который очень долго соприкасался с миром разработки, но так и не стал его частью, объяснит тебе, почему Web — это хорошо. Я понимаю, что это перевод, но переводчик же должен разделять идеи оригинала, так?

Так вот, переводчик, Web — это не замена десктопным приложениям, это альтернатива им. «Каждый дрочит так, как хочет» — слыхал? Если тебе нравится обмазываться десктопом — флаг в руки. Не мешай наяривать другим.

Web не должен быть быстрым, это понятно любой мартышке.

Люди пользуются Web-приложениями типа Google Docs, потому что они дают свободу от сраных десктопных приложений. Я могу править документы откуда угодно, все что мне нужно — не удариться по пути головой и помнить данные моей электронной почты.

Возможно, ты, мой друг, еще с года 2001 перетаскиваешь с винта на винт всякий хлам, типа альбомов Арии или КиШа в качестве MP3 в 64 битрейте. Твое право. Но то, что ты не способен понять и принять парадигму альтернативы — лишь твоя проблема. Не будет универсального «единого приложения», которое придет на смену Вебу, не будет вообще приложений. Потому что Web в том смысле, в котором мы его сейчас обсуждаем, возник как раз для того, чтобы ничего не качать, чтобы все крутилось на стороне больших и умных дядь. Кстати, это, как раз таки, одна из альтернатив на тему и Информационной Безопасности. Да, чтобы за ней следили большие, умные и совсем не ленивые дяди-разработчики на местах. Согласись, это проще, чем пытаться латать дыры у миллионов пользователей на их устройствах. Или нет?

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

Без уважения, мимо пробегающий гуманитарий.
+1
Как одним неловким комментарием молодой хабраюзер может уничтожить свой аккаунт. Глянул, в целом комментарии нередко годные писал Toshiro, но тут его настиг лютый фейл и хабрахаммер силой в минус двадцатку кармы, даже как-то жестоко.

Относительно предыдущего коммента — не разделяю хейта к десктопу и прям обожания к вебу, и про дядь всё понимаю. Да и облака оно такое, сегодня есть, завтра ветром развеяло. С винта на винт таскаю конечно всякое нужное, и если о музыке говорить, то в годном качестве, включая флаки. Но это не отменяет того, что к вебу тоже отношусь с теплотой и моё следующее приложение будет разрабатываться на REST JSON API и всё такое этому сопутствующее. А будет что-то лучше, так посмотрим.
PS:
Хотя может и не из-за этого коммента, было ещё парочку с непопулярным мнением, а оно тут нередко карается, свобода слова ж такая она. :) Имел место наблюдать не единожды. Beware, %username%.
Возможно, ты, мой друг, еще с года 2001 перетаскиваешь с винта на винт всякий хлам, типа альбомов Арии или КиШа в качестве MP3 в 64 битрейте. Твое право.

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

Почему веб должен умереть

Целый подзаголовок. Или там должно было быть «Почему текущий стек веб-технологий должен умереть»? Что-то не склеивается, знаете ли.

Кстати, как гуманитарий я читать умею внимательно, и карту текста делать в уме. А как активный автор Хабра и Гика — отличить «Веб» как явление от «стека технологий».

НЛО прилетело и опубликовало эту надпись здесь
Мы о веб-приложениях, кстати, или о клиентских сервисах? Если мне не изменяет память, то Веб-приложение подразумевает клиент в лице браузера, который работает в качестве «форточки», если совсем утрировать. Все остальное — на стороне разработчиков (сервера). А вы мне про приложения Gmail и скачивание обновлений.
Редактор форм для хамарина? Это где ж такое? Они предварительный просмотр запилить толком не могут, чушки мохнорылые
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
«Каждый дрочит так, как хочет» — слыхал? Если тебе нравится обмазываться десктопом — флаг в руки.
Если бы мы все жили и работали каждый в своём маленьком индивидуальном пузырьке, то да. После этого вашего высказывания можно было бы поставить точку и закрыть тему.

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

Перетаскиваю с винта на винт (rsync'ом) всякий хлам вроде техникал детха во флаке и не завишу от наличия интернета, прихотей правообладателей и кривости реализации gapless playback в онлайн-плеерах.


При этом пользуюсь стимом, потому что удобно. Что не так?

хорошая толковая статья. а что делать?
Как вариант: избавиться от гегемонии корпораций, думающих не об индустрии, а о собственной выгоде, а для этого, наверно, построить коммунизм, а для этого…
… а для этого надо быть better Red than dead.
:)
Но серьезно, если бы не закрытость и платность его прародителя — Ребола, сейчас все могло было бы быть совсем иначе… Только представьте: вместо сотен мегабайт диска и памяти браузера — рантайм в ОДИН мегабайт, а функциональность — выше.
Эксель электронная таблица в 15 строк кода (прилетает целиком в одном сетевом пакете), жрущее 1 мегабайт памяти (на самом деле 8, ладно уж)? Да легко! Там еще и другие чудеса есть, только осторожнее открывайте там другие статьи и особенно корень сайта, ибо коммунизм пока еще не наступил и мы все еще живем в вебе мире, где норма — ужасы типа «по 100+ метров памяти за каждую страницу с 3 гифками и анимированным древовидным меню»… :(
IMHO: все проблемы из-за JS.

Стараюсь пользоваться web'ом с отключенным JS, включаю его только на тех сайтах, которые без него не работают, но мне очень нужны, либо включаю временно, что бы получить нужный функционал.

Изначально созданный в гонке за фичами, JS стал огромной проблемой для всего web'а…
НЛО прилетело и опубликовало эту надпись здесь
Не надо передёргивать.
Именно так. Если бы JS был бы отключён в Хроме по умолчанию, экосистема со временем бы приучилась использовать JS только там, где он реально необходим.

Или не использовать хром, там где…
Нигде не использовать.

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

Слепить несложный стандарт из готовых штук, и впилить в тот же Chromium второй режим вкладки для его поддержки — вполне посильная задача. Там не надо никаких гипертекстов даже — достаточно будет JVM, WebGL, API для мышки/клавиатуры, и RPC. И сразу уже игрушки можно будет по ссылке открывать. А с остальным — заменой для CSS/HTML, accessibility, индексированием, и прочим всем — вполне можно по ходу дела разбираться, добавляя стандарты и библиотеки.

JVM какой версии держать будем? Обновлять как будем? Сэндбоксом для JVM кто будет управлять? RPC как построить так, чтобы можно было получить ограничение по доменам? На стороне клиента нужен какой-то стандарт для хранения данных? Окей, будем считать с десктопом вопрос зарешаем. Тут ходовых платформ всё же всего полторы — x86 + unix/windows.


Теперь дело за малым, перенести эту референсную реализацию на ARM да под android, windows phone, ios… tizen, remix, sailfish, symbian, webOS и заставить на телевизорах работать.


Это я всё к чему? Если сделать замену вот такую: JVM -> V8, WebGL -> WebGL, API мышки/клавиатуры -> MouseEvents, RPC -> Ajax/XHR то получится, внезапно, то что сейчас есть, только оно более-менее работает почти на всех платформах старше IE9.

Собственно, вся суть нытья в том, что то, что сейчас есть, кривое. Будь у меня достаточно квалификации, я бы предпочёл попытаться порешать вопросы из первых двух абзацев)

Да ну ёлки, где оно кривее остальных-то?
Я года три назад перескочил из уютного Java мира с Java/Scala в node + frontend. Нормальное оно. Другое просто сильно.
Стандарты менее стандартные, но если не упарываться по всякой разработке игр на WebGL и другим крайне интересными, но не мейнстримовым вещам, то нормальное оно. И даже работает.


Берёшь Babel — и практически все проблемы с JS закрыты. Берёшь bootstrap, и не надо даже начинать думать о чем-то кроме того, в какой цвет кнопки покрасишь. Фреймворков для того, чтобы формочки и кнопки рисовать уйма. Начиная от крайне ванильного HTML/CSS/JS, заканчивая всякими Elm, ReasonML, ClojureScript, в связке с чем угодно, которые вполне себе работают.
Ну и React, раз уж столько хайпа про него. Автор про Flux упомянул. Он может быть и из времен Win3.1, но проблему-то он решает вполне неплохо. Если сравнивать, условно, Redux, который, конечно не совсем Flux, но из той же оперы, с правильным и расово-верным Qt (или что там автор предлагает?), то хм… кто из этих двоих ребят позволяет сделать replay приложения практически искоробки?


В общем, я конечно не могу сказать, что во фронтенде всё такое классное и блестящее — нужно ещё пилить и пилить. Но сегодня большинство проблем кривизны решается с помощью npm install left-pad… OH WHAI~~

если не упарываться по всякой разработке игр на WebGL и другим крайне интересными, но не мейнстримовым вещам, то нормальное оно

Это утверждение из разряда «в принципе, если ничего не покупать, цены нормальные». Если не упарываться и ограничиваться примитивными вещами, можно даже продолжать сидеть в IE5 — его возможностей хватит почти для всего «не упоротого». Веб нужно убить именно потому, что как только задача становится капельку сложнее примитивной — начинается лютый трэш и угар. USB, нормальная многооконность, трей, протоколы помимо HTTP(S), FTP, WebSocket и WebRTC, UDP, вменяемый доступ к файловой системе и прочие плюшки — всё это или в зачаточном состоянии, или отсутствует вообще. У меня прямо сейчас запущены мессенджер с протокол XMPP, почтовый клиент с протоколом IMAP, торрент-клиент, аудиоплеер читающий flac-файлы с внешнего жёсткого диска, виртуальная машина с виндой, клиент Steam умеющий запускать заранее установленные игры в оффлайне, VNC-клиент и VNC-сервер. Вполне обычные вещи, но вебу о них остаётся только мечтать. Хотя в том же нижеупомянутом андроиде проблем с этим почти нет.


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


Берёшь Babel — и практически все проблемы с JS закрыты.

Высокоуровневый язык, компилируемый в другой высокоуровневый язык. Это же полный бред! Особенно когда что-то строгое и статическое компилируется в слабое и динамическое (TypeScript, C++). К счастью, с приходом WebAssembly эпоха полного бреда, возможно, закончится.


Берёшь bootstrap

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


Фреймворков для того, чтобы формочки и кнопки рисовать уйма.

По-хорошему должен быть один-единственный canvas, на котором рисуется всё что нужно приложению любым нужным фреймворком. Но нет, будем использовать язык разметки текста! И будем обходить его заточенность под текст многочисленными CSS-костылями, включая ранее упомянутый бутстрап. При этом выровнять блок по вертикали возможно лишь пару лет как, а прижать футер резиновой высоты к низу страницы невозможно до сих пор (а с js нельзя, потому что будет мерцать из-за асинхронности). А canvas — лишь один из элементов внутри потока текста. Хотя должно быть наоборот. Опять полный бред получается.


React и Flux это в данном контексте больше про архитектуру (ибо есть ещё React Native, например). Но работают-то они всё равно поверх ущербных HTML/CSS/JS.


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

> По-хорошему должен быть один-единственный canvas, на котором рисуется всё что нужно приложению любым нужным фреймворком.

А клиент будет каждый раз качать 100мб этого фреймворка?

> Но нет, будем использовать язык разметки текста!

Есть альтернативы? Почему в современных десктопных гуи-фреймворках тоже используется язык разметки текста, а не что-то иное?
А клиент будет каждый раз качать 100мб этого фреймворка?

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


Есть альтернативы?

QML, XAML, GTK XML, XUL в конце концов?


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

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

> А это просто враньё. Выше я перечислил, что используется на самом деле.

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

Они все — языки разметки интерфейса (или приложений, суть не изменится), а не языки разметки текста. Я ничего не имею против языков разметки. Я против использования языков разметки не по назначению, как это сейчас происходит с HTML (вы ведь в курсе, как расшифровывается HTML вообще?)

HTML5 уже не разметка для текстов, это именно платформа (стек технологий) для построения веб-приложений. А название досталось в наследство.
В наследство досталась и заточенность именно под текст. Любая страница по умолчанию до сих пор является потоком слов и символов со всеми присущими им проблемами. Некоторые можно исправить в CSS3 (в частности, с flexbox жить стало лучше), некоторые нельзя до сих пор. Кстати, в HTML5 сильно прокачали именно семантику именно для текста, а не для приложений.

Что особенно странно, если вспомнить, что на заре своей юности HTML5 назывался именно «Web Applications 1.0» :)

> Они все — языки разметки интерфейса (или приложений, суть не изменится), а не языки разметки текста.

В каких конкретно факторах проявляется, что HTML — язык разметки текста, а не интерфейса?

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

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


Тут, например, растут уши у тысячи и одного костыля для того, чтобы web-приложение вело себя подобно десктопному/мобильному.


Более того, из-за этого HTML и CSS имеют очень слабую поддержку постраничного отображения информации (для печати, к примеру).

Времена, когда HTML использовали для разметки текста давно прошли. Сайты, представляющие собой текстовый документ с навигацией сегодня большая редкость, практически каждый сайт — веб-приложение, которое куда как проще создать с использованием какого-нибудь языка разметки интерфейсов, чем с современным HTML. Поэтому, было бы очень выгодно заменить HTML на что-то похожее на XUL или XAML — от этого бы выиграли как веб-разработчики, так и конечные пользователи.
На QML смотрели?
А клиент будет каждый раз качать 100мб этого фреймворка?

У нас свой фреймворк на C++ и приложение в wasm весит 10Mb, в жатом виде 2.7 Mb. Что бы каждый раз не скачивать используется кеширование.

Ключевое слово здесь — _ваш_ фреймворк.
НЛО прилетело и опубликовало эту надпись здесь
Что-то не видно, что бы современные веб-приложения были адаптированны под слабо видящих.
НЛО прилетело и опубликовало эту надпись здесь

Выгружать дерево UI-контролов в примитивный невидимый кусок DOM без CSS с aria-тегами. Если фреймворк изначально портируется с десктопа, то там кроссплатформенная поддержка скринридеров скорее всего уже есть и к ней такое прикрутить не сильно сложно.

USB, нормальная многооконность, трей, протоколы помимо HTTP(S)
Стойте. Причём здесь веб? Многооконность и трей, к счастью, не очень про веб. Веб — это про рисовать странички. Многооконность, трей и всё остальное — это про операционную систему. Должен ли это уметь веб? Возможно, но зачем? Кстати, как многооконность с треем должна работать на андроиде, допустим?

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

Если веб — платформа для приложений, то должно присутствовать всё перечисленное и не только.


Должен ли это уметь веб? Возможно, но зачем?

Затем, что веб нынче считается платформой для приложений. Если же рассматривать веб как HTML для разметки текста и его связи гиперссылками, CSS для его разукрашивания и скрипты сбоку для капельки интерактивности (чем он и является на самом деле), то тогда всё мной перечисленное действительно не нужно, но это же означает, что две трети сайтов используют веб не по назначению. Гуглдоки, скайп, слак, дискорд, трелло, Unreal Engine 4 — это всё нихрена не про разметку текста блин!


Да даже горячо любимый Qt не позволяет без плясок с бубном использовать системную тему.

Во-первых, у меня он подхватывает Numix без плясок. Во-вторых, даже если вдруг пляски где-то и нужны, прикрутить системную тему всё-таки можно, и пляски это в минус Qt, а не в плюс вебу.

НЛО прилетело и опубликовало эту надпись здесь
По-хорошему должен быть один-единственный canvas, на котором рисуется всё что нужно приложению любым нужным фреймворком.

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


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

Да вроде можно тем же флексом прижать, если устраивает скролл в рамках области контента

Так это и сейчас можно.

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


а рисовать на канвасе

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


Да вроде можно тем же флексом прижать

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

C приходом WebAssembly эпоха полного бреда, возможно, закончится.
Хотя есть надежда, что с приходом WebAssembly тормозить и лагать станет чуть меньше


Кому выгоден отказ от JavaScript? Подумайте и ответьте на этот вопросы.
1) Конечных пользователей все устраивает.
2) Веб разработчиков все устраивает
3) Не устраивает только Java и C# программистов, потому что их рынок пытаются занять выскочки из JavaScript области.

Я вас расстрою, но WebAssembly усилит JS в 100 раз, люди так и будут писать на JS, только к супер тяжелым задачам, такие как: «Web Photoshop» будут подключены Толковые С++ программисты. Но все проекты как были на JS так и будут. React / angular как был на JS так и останется, только критические участки кода будут переписаны на C++.

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

К чему это приведет: Распад рынка на 10 секторов. Представим что у всех равная доля, представим что часть JS-программистов пересели на С++, часть на C#.
А еще Python подтянется, далее PHP программисты начнут пилить FRONTEND На PHP (да, будут все пилить костыли в виде фреймворках, С++ можно а нам нельзя что ли? мы тоже хотим на фронте писать на своем любимом языке)

Опять ответьте на вопрос, какую проблему бизнеса это решит и какие выгоды миру будут даны? Скорость отдачи странички?
у 99% людей интернет работает быстро. Если у вас 4 пенек и 2GB ОЗУ, то это ваши проблемы. никто не будет подстариваться под бомжей, доля на рынке которых составляет 0.00001%

ОГРОМНЫЙ сдвиг будет в крупных бизнес приложениях.
Будет Photoshop на WEB, Но 95% рынка это никак не каснется.

какую проблему бизнеса

Да плевал я на бизнес, я страдаю как пользователь


Если у вас 4 пенек и 2GB ОЗУ, то это ваши проблемы.

Почему я должен доставать кор-ай-девятьтысяч и 32+ГБ для задач, которые без напряга способен решать даже какой-нибудь третий пенёк с 128МБ оперативки? Почему лет десять назад скайп на компьютерах того времени нормально работал, а сейчас, умея всё абсолютно то же самое, тормозит не то что на мамином, а даже на моём новеньком кор-ай-пять из 2014-го? Почему у меня забирают право пустить ресурсы моего компьютера на что-то полезное и заставляют или тратить проц и оперативу на абстракции над абстракциями, или отказываться от чуть ли не всех приложений вообще? (Вообще десктоп-приложений это тоже касается, но там наглеют ещё не так сильно, как ленивые веб-макаки, клепающие скайпы на электронах.)


Вспоминается классика:


Удивительное это дело — прогресс. Чтобы набрать и распечатать одну страничку красиво оформленного текста мне уже не хватает мощности компьютера, который с легкостью может управлять двумя тысячами советских боевых спутников одновременно. Есть мнение, что если бы не microsoft веб-макаки, то мы давно бы уже покорили вселенную.
Да плевал я на бизнес, я страдаю как пользователь

А на вас плевал сам бизнес, никто не будет ждать 1 человека с 4 пеньком, у которого в кармане Nokia 3310 с Os Симбиан.

Если вы страдаете как пользователь, то вызовете системного администратора на дом, возможно у вас какие-то проблемы с жестким диском, оперативной памяти или компьютером в целом.
Либо ваше оборудование устарело.

Смените браузер, Croome не отчищает память минут 5 и не закрывает соединения даже если вы закрыли вкладку, это нужно для глаз пользователя, что бы все было моментально, но жертвуется оперативка :)
Есть всяческие браузеры, которые выгружают сайт из оперативной памяти сразу после того как вы снимете фокус с вкладки, у вас будет хаваться около 50 оперативки, но при каждой активации вкладки будет отправляться новый GET запрос.

Вот какие варианты предлагает современность для бедных людей с Nokia 3310

Почему я должен доставать кор-ай-девятьтысяч и 32+ГБ для задач, которые без напряга способен решать даже какой-нибудь третий пенёк с 128МБ оперативки? Почему лет десять назад скайп на компьютерах того времени нормально работал, а сейчас, умея всё абсолютно то же самое, тормозит не то что на мамином, а даже на моём новеньком кор-ай-пять из 2014-го? Почему у меня забирают право пустить ресурсы моего компьютера на что-то полезное и заставляют или тратить проц и оперативу на абстракции над абстракциями, или отказываться от чуть ли не всех приложений вообще? (Вообще десктоп-приложений это тоже касается, но там наглеют ещё не так сильно, как ленивые веб-макаки, клепающие скайпы на электронах.)


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

Поверьте, я могу написать продукт на ASM за 4 года.
Но мой конкурент сделает это за 2 месяца, такой же продукт.

Да, 0.0001% рынка будет потеряна, продуктом не смогут пользоваться люди с старыми компами, но для рынка эти люди не являются ценными, если человек не может купить себе комп за 15 000 рублей, то наш продукт то он точно не купит.

Есть разумный минимум в 2017 и я вам его опишу.
1) У каждого должен быть мобильный телефон на базе Android / IOs / Window OS ( цена от 10 000 рублей)
2) Компьютер или ноутбук (4гб — 8гб ОЗУ / 500ГБ, core i3-i5) (цена от 15 000 рублей)

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

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



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

Именно это я сам и писал аж позавчера.)

Мы все понимаем, что «выгодно для бизнеса» и «выгодно для пользователя» — вещи противоположные.

Вот эту фразу я там увидел.

Пользователи довольны, не довольны лишь 0.0001% бомжей.
Но и у бомжей есть альтернатива: берите себе браузер, который рвет соединение при закрытии вкладки и выгружает сайт из памяти.
Вкладки будут грузится долго, но это решит проблему с оперативнйо памятью.
Вместо Photoshop у вас есть альтернатива paint.
WORD 2016 -> Nodepad

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

То есть вами помыкают, и теперь вы хотите помыкать другими?
Я вот на ХР, и никуда не собираюсь пересаживаться, пока железо работает.
1) Конечных пользователей все устраивает.
2) Веб разработчиков все устраивает

Отучаемся говорить за всех.
Берёшь Babel — и практически все проблемы с JS закрыты.

Ну да, щаз. Это вам никогда видимо не приходилось пытаться запускать поделки на JS не в той среде, в которой ожидает автор. Т.е. не в браузере и не в ноде. А такие бывают, поверьте.

>Берёшь Babel — и практически все проблемы с JS закрыты

В какой-то момент, фронтендеры решили что JavaScript настолько ущербный, что лучше в него какой-нибудь другой язык компилировать, чем на нем писать. Можно было выбрать любой язык. И что же они выбрали? JavaScript 6!
НЛО прилетело и опубликовало эту надпись здесь
В какой-то момент, фронтендеры решили что JavaScript настолько ущербный, что лучше в него какой-нибудь другой язык компилировать, чем на нем писать. Можно было выбрать любой язык. И что же они выбрали? JavaScript 6!

Не вижу ничего в этом плохого, теперь я трачу на 0.05s больше, раньше я просто нажимал CTRL+S, теперь мне надо подождать 0.05s :)
Конечно я был бы рад что бы все это было из коробки, подождем лет 5, возможно появится.
Я вижу плохое в JS то, что он слабый и не удобных для больших приложений, таких как WEB Photoshop или WEB AutoCAD:(

И мы разрабатываем WASM, он позволит нам нанять лучший С++ программистов, которые создают критические участки кода для web Photoshop

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

Но у всех на хабре появилась надежда в WASM, многие считают что он убьет JS, но вот что будет (впечатлительным C# разработчикам не читать):

Предположим что будет все по вашему, все языки мира создали свой фреймворки, которые переводят их код в байт-код(WASM).
Вы думает только С /С++ такие умники? этого захотят все топовые языки в мире.
К чему это приведет: Распад рынка на 10 секторов. Представим что у всех равная доля, представим что часть JS-программистов пересели на С++, часть на C#.
А еще Python подтянется, далее PHP программисты начнут пилить FRONTEND На PHP (да, будут все пилить костыли в виде фреймворках, С++ можно а нам нельзя что ли? мы тоже хотим на фронте писать на своем любимом языке)

Хватит гнать на C#-разработчиков. У вас словно травма из детства, в каждом комментарии упоминаете. Вас обидели как-то?
C# Разработчики гонят на JS разработчиков.
На хабре от С++, PHP, JAVA разработчиков не слышно говнf в сторону JS.
Вот и весь секрет.

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

Смотрю никакие контр-аргументы не стали писать, надеюсь я вас убедил что никакие WASM не свергнут JS :)

Не устраивает только Java и C# программистов, потому что их рынок пытаются занять выскочки из JavaScript области.

И штук 10 еще таких цитат в основном вашего авторства. Вы сами себе противоречите, говоря только о C#.
На хабре от С++, PHP, JAVA разработчиков не слышно говнf в сторону JS.
Вот и весь секрет.

Пруфы? На хабре принято использовать аргументы. А про языки — нет идеального языка. PHP стал источников мемов, JS странный и далек от идеала, С++ монстр во плоти, а а Шарп это лазерная пушка, которая не работает без ослика.
Не нужно быть психологом, что бы понимать почему они это делают.
JS не лезет в драйвера, контроллеры и банковский сектор, но JS лезет в средний бизнес, там где обосновался C# разработчик.

C# можно много где использовать — банки, энтерпрайз, хайлоад, десктоп и т.д. Тут JS-у до него ой как далеко. Упадок C# на десктопе связан не с JS, а с общим умиранием десктопа.
Ах да, есть еще Unity и игры. И что-то как-то там C++ и C# правят балом, а не JS.
Смотрю никакие контр-аргументы не стали писать, надеюсь я вас убедил что никакие WASM не свергнут JS :)

WASM — посмотрим, что за зверь, пока что выглядит незрело.
А JS свергать не надо, отличный язык для задачи придания интерактивности на HTML-страницах) Пусть и остается им))

Я уже выше писал про новые стандарты приложений. Они — лучший путь, чем WASM или HTML+JS
Ты все правильно пишешь, но проблема — в другой плоскости. У нас сейчас есть единственный работающий стандарт чтобы делать приложения, которые более-менее везде запускаются. И этот стандарт такой, что:
— писать эти приложения очень дорого. Что-то примерно 10x по баблу, против Delphi 7, наверное. Т.е. для приложений веб — отвратителен.
— реализовать этот стандарт, по-факту, могут две конторы в мире — Microsoft и Google. Есть только две работающих реализации. Победи одна — и будет нам полное и безоговорочное самодурство одной конторы. А Google что-то не сильно интересно, чтобы было удобно делать на вебе приложения. Реклама крутится, бабло мутится. Нет ни у кого 100500 баксов чтобы написать что-то лучше Gmail? Ну и хорошо, Google это вполне устраивает.

Да, можно поверх веба поверх собрать POC на WebGL. Но это будет лагать, геморройно по тулам, и канет в лету. Нужна реализация с нуля, чтобы ничто не мешало. Как минимум — как выхлоп для кучи идеалистов, которые сейчас делают всякие ReactOS. Будет источник идей, будет фонтан идей, в который можно кунать авторов очередного border-radius или flexbox.

Короче, я считаю, что хайп тут — в тему. Надо всем миром замутить проект «веб X.0 с нуля» — пусть он не выстрелит, и вообще пусть будет вечным, и будет раскалываться на ветки. Но что-то должно быть, что конкурирует с вебом.