Почему несмотря на устаревание HTML, CSS и JavaScript не делается шагов в сторону альтернатив, отвечающим спросу рынка веб-разработки?

Question

[Wylaroren]

Сперва хотелось бы сказать, что аналогичный вопрос был закрыт на StackOverflow потому, что на него якобы невозможно дать объективный ответ. Я, конечно, уважая время других людей, не надеюсь увидеть в ответах диссертацию, но ответ в форме "это трудно потому что аргументация, и ещё потому что аргументация" будет вполне объективным.

Итак, ни для кого из опытных веб-разработчиков (особенно тех, что начал это ремесло в 90-е) не секрет, что когда создавались такие технологии, как HTML, CSS и JavaScript, никто и не думал, что в будущем с из помощью будут делать что-то вроде Wordpress или онлайн версии Word и Excel.

HTML и CSS отстают от запросов рынка, а видя список нововведений HTML6 и CSS4 так и хочется спросить: "И это всё, что вы сделали со времён HTML5 и CSS4 в ответ на спрос современного рынка?". JavaScript несмотря на свой статус монопольного клиентского браузерного языка и самого востребованного языка в мире (на момент 2021 года) в год пополняется лишь тремя-четырмя функциями (после стандарта ES6). Крупнейшей проблемой языка является его врождённая медлительность при работе в DOM, что подробно рассмотрено в этой книге. Такие фреймворки, как React и Vue - это в чистом виде хак JavaScript-а с целью хоть как-то повысить производительность.

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

Статья "Мы делаем веб приложения ради экономии — но этот путь ведет нас во тьму", пользователь Philipp Ranzhin (добавить ссылки не даёт валидатор).

Парадокс состоит в том, что несмотря на востребованность веб-разработки совсем нет статей о разработки альтернатив, полностью заменяющих не отвечающие потребностям рынка HTML, CSS и JavaScript. Подчёркиваю: я не имею ввиду, что все во всём мире разом должны броситься переписывать свои проекты на эти гипотетические альтернативы. Я говорю о добавление в браузеры поддержки новых языков описания разметки, стилей и логики, а поддержка HTML, CSS и JavaScript, разумеется, ещё долго остается. Поэтому разработчики вроде как и страдают от HTML, CSS и JavaScript, но ничего нового не разрабатывают. Чем же объяснить этот парадокс?

Comments

[Вадим]

Подскажите, а как устаревает HTML и CSS?
CSS, как и JS, сейчас развиваются быстрее, чем когда-либо.
Браузеры постоянно добавляют новые API, в том числе и для доступа к различным функциям устройств и информации о них.
Книга от 2012 года.

React и Vue - это в чистом виде хак JavaScript-а с целью хоть как-то повысить производительность.

Полностью не верно. Фрэймворки не для увеличения производительности, а для улучшения опыта разработки, переиспользования кода. И это никакой не хак. С чего вдруг библиотеки стали хаком?
Ну и какие Вы видите альтернативы для указанных технологий? Что должно заменить html css js?

[zorca]

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

[. .]

Bavashi,

Если работает - не трогай. (c)

Главный постулат в IT :D

[Roman Sokolov]

WebAssembly добавили, насколько знаю, чтобы увеличить производительность JS для определённых задач. Не то?

[Серафим Прозоров]

Roman Sokolov, WebAssembly к JS не имеет отношения никакого от слова «абсолютно» и его сделали точно не для того, чтобы повысить производительность JS. Более того общаться с браузером и DOM WebAssembly не умеет от того же слова, то есть операции с DOM (не самые, кстати, быстрые) всё равно, хоть обложись WebAssembly вдоль и поперёк, выполняются на JS.

[Roman Sokolov]

Серафим Прозоров, не имеет никакого отношения? А это зачем?

[Серафим Прозоров]

Roman Sokolov, это описывает то, как WebAssembly живёт в браузере, однако, WebAssembly-приложение может жить и за его пределами: https://habr.com/ru/post/446764/
WebAssembly же это просто стандарт байт-кода, который при наличии рантайма может выполняться где угодно, и она не ускоряет сам JS.

[Roman Sokolov]

Серафим Прозоров, если не понятно, я имел ввиду, что можно разгрузить медленный код в определённых задачах, переложив их выполнение с JS на wasm. В итоге время выполнения сократится.
Вот тут можете почитать, как wasm взаимодействует с JS:
https://habr.com/ru/post/475778/

[Серафим Прозоров]

Roman Sokolov, да, извините, действительно не понял Вашей формулировки. В таком разрезе полностью согласен, но имхо, автор говорит немного о другом: о замене HTML/CSS/JS на что-нибудь вообще новое, типа как в свое время были Flash/Silverlight/Java-апплеты.

[Дмитрий Беляев]

Roman Sokolov, все мнимое "ускорение" от wasm становится ничем из-за издержек на общение между js и wasm вроде постоянной сериализации/десериализации данных.
wasm больше про возможность запускать код написанный на многих языках отличных от js в браузере и не только.
Да и с производительностью у js все просто замечательно, особенно у v8, который на сегодня лучше многих других компиляторов оптимизирует быдлокод, которого сейчас большинство в силу его дешевизны.

[Дмитрий Беляев]

Roman Sokolov, ну и так, для сравнения, возьмем условный
<p>Hello world!</p>
на Yew оно будет весить примерно 1 мб .wasm + 0.5 мб .js обертки
на Svelte - меньше 1 кб и работать в разы быстрее

[Wylaroren]

Вадим,

Благодарю Вас за комментарий!

Честно говоря, не ожидал такой ярой защиты в пользу HTML, CSS и JavaScript (я не только про Ваш комментарий).
Но я не раскаиваюсь, что спросил. Очень интересно наблюдать, какую негативную реакцию у общества
вызывают попытки усомниться в том, что принято считать само собой разумеющимся :)

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

Очень интересно... Зачем же тогда понадобилось изобретать такой велосипед, как Virtual DOM?
Это получается, что если мне не нужна та архитектура, которую навязывают фреймворки, то я могу писать приложения по-старому, на ненавязчивом JavaScript-e, на JQuery или вовсе нативно не волнуясь о производительности?

> Подскажите, а как устаревает HTML и CSS?
> Ну и какие Вы видите альтернативы для указанных технологий? Что должно заменить html css js?

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

HTML

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

CSS

1. Возможность полной стилизации всех нативных HTML-элементов. Например, если нам нужен красивый DataPicker, то стилизуем нативный как обычную кнопку, а не берём его из фреймворков и тем более не реализуем сами. На данный момент стилизовать некоторые нативные элементы очень сложно. Например списки (к примеру, невозможно кроссбраузерно задать расстояние между маркером и началом текста), некоторые input-ы, в частности радиокнопки и загрузчики файлов. Отдельно хотелось бы сказать про таблицы, которые при определённых условиях игнорируют min-width, имеют проблемы с вертикальным выравниванием нетекстового контента (например, кнопок) и не поддерживают скроллинг.

2 Изменение стилей в зависимости от доступной ширины родителя Проблема отсутствия данного функционала рассмотрена в этом вопросе.

3. По синтаксису идеальную замену CSS я представляю себе наподобие вроде Stylus-а со всеми его возможностями.

JavaScript

1. Если интегрировать JavaScript с TypeScript-ом, с точки зрения синтаксиса будет почти идеал. Который год в JavaScript не могу ввести ключевые слова interface, abstract, private, protected.
2. Проблема медленного доступа к DOM должна быть полностью решена.

Одна из самых трудных задач, которая востребована на рынке и простых решений которой нам не даёт нативный JavaScript - это создание WYSYWIG-редактора. Редко когда заказчики горят желанием верстать статьи для своих корпоративных блогов, гораздо чаше просят наподобие: "Нам пожалуйста WYSYWIG-редактор, заточенный под наши нужды и наш дизайн, и ничего лишнего не надо." Как много редакторов, которые имеют русскую локализацию? Я знаю только CK и MCE. О чём это говорит? О том, что его создавать их могут только гении или те, у кого много оплачиваемого свободного времени. А если бы JavaScript действительно бы отвечал на спрос рынка, был бы нативный класс типа Editor наравне с Array или Promise, в котором мы через опции указываем, что нам надо, и вся логика для WYSYWIG-редактора готова.

И напоследок хотел бы сказать, что обилие фреймворков, таких технологий AMP и PWA, говорит не в пользу HTML, CSS и JavaScript, а о том, что нативно очень многого не хватает, а реализовать всё это - непросто, иначе у каждого новичка был бы Bootstrap и React собственного производства.

[Вадим]

Wylaroren, ну давайте рассмотрим всё по пунктам.

Зачем же тогда понадобилось изобретать такой велосипед, как Virtual DOM?

Для оптимизации работы того, что дают на выходе фрэймворки и защиты "от дурака".

если мне не нужна та архитектура, которую навязывают фреймворки,

Между React, Vue и Angular - только последний пытается Вам что-то втереть про архитектуру.

я могу писать приложения по-старому, на ненавязчивом JavaScript-e, на JQuery или вовсе нативно не волнуясь о производительности

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

я всё-таки укажу, что не хватает HTML, CSS и JavaScript, но что нужно заказчикам и исполнителям.

В сухом остатке заказчикам нужно чтобы были клиенты и продажи. И чем быстрее и больше, тем лучше. Что там за технологии им нет никакого дела.

2 Изменение стилей в зависимости от доступной ширины родителя Проблема отсутствия данного функционала рассмотрена в этом вопросе.

Скоро появится.
https://groups.google.com/a/chromium.org/g/blink-d...
https://github.com/dbaron/container-queries-implem...

3. По синтаксису идеальную замену CSS я представляю себе наподобие вроде Stylus-а со всеми его возможностями.

Вкусовщина.

1. Если интегрировать JavaScript с TypeScript-ом, с точки зрения синтаксиса будет почти идеал. Который год в JavaScript не могу ввести ключевые слова interface, abstract, private, protected.

Ага, в веб пришли дяди и тёти с серьёзных языков, потому что веб отжимает у них работу и стали жаловаться что тут нет их любимого ООП. А многим ли он нужен? А все ли кто перешёл на TS счастливы? А что там с порогом входа? Ну и к слову, не помню уже что, но что-то уже ввели из этого или вот вот введут в js.

2. Проблема медленного доступа к DOM должна быть полностью решена.

Да, это старая песня. Но проблема ли это JS, HTML или CSS? Или может это проблема браузерного движка, который на Cи? А так ли актуальная эта проблема в 2021?

создание WYSYWIG-редактора

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

Как много редакторов, которые имеют русскую локализацию? Я знаю только CK и MCE. О чём это говорит? О том, что его создавать их могут только гении или те, у кого много оплачиваемого свободного времени.

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

если бы JavaScript действительно бы отвечал на спрос рынка, был бы нативный класс типа Editor наравне с Array или Promise,

Не нужно делать борщ из всего что есть в холодильнике. Я что-то вот не могу вспомнить ни одного класса в JS, который реализовывал бы хоть какой-то UI.
Array и Promise используют скажем так, 100% разработчиков.
А если и внести это в JS, то можно ли угодить всем?
Другой вопрос, чтобы внести это в HTML. Благодаря HTML Custom ELements это будет возможно. И выкидывать наружу ручки для управления.

И напоследок хотел бы сказать, что обилие фреймворков, таких технологий AMP

Наличие AMP говорит на самом деле о двух вещах
1) большая часть разработчиков не умеет делать быстро. А не о том, что технологии плохие.
2) "Мы крутая компания(Читай как гугл или яндекс) сделали для вас крутую технологию, с которой будет всё быстро и круто, если Вы согласны пожертвовать дизайном. И да, мы совсем забыли упомянуть, что мы таким образом замыкаем весь трафик на себе, а Ваш сайт можете выбросить в помойку. Кстати спасибо за данные ваших пользователей. Теперь наша реклама будет ещё лучше."

а о том, что нативно очень многого не хватает

А что под капотом у реакта, амп, спа? Нативные технологии.

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

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

[Wylaroren]

Для оптимизации работы того, что дают на выходе фрэймворки и защиты "от дурака".

Понял. Этот пункт исчерпан.

Между React, Vue и Angular - только последний пытается Вам что-то втереть про архитектуру.

Если в Nuxt.js нельзя изменить имена папок и их расположение по умолчанию, то он тоже навязывает.
На Next.js не разрабатывал.

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

Понял. Этот пункт исчерпан.

В сухом остатке заказчикам нужно чтобы были клиенты и продажи. И чем быстрее и больше, тем лучше. Что там за технологии им нет никакого дела.

Понял. Всё верно с точки зрения теории бизнеса.

Изменение стилей в зависимости от доступной ширины cкоро появится.

Благодарю Вас за эту хорошую новость!

Вкусовщина.

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

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

Так то-то и оно, что JavaScript - несерьёзный язык :)

А так ли актуальная эта проблема в 2021?

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

Далеко не всем нужны визуальные редакторы. Именно поэтому их решают на стороне CMS

Ладно, не будем об этом, а то возникнет бессмысленный спор, нужно ли использовать готовые CMS.

А если и внести это в JS, то можно ли угодить всем?

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

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

Благодарю Вас за такую ценную информацию! А что значит "замыкаем трафик на себе"? URL AMP-версий страниц не принадлежат тому же домену, что и канонические страницы?

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

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

[Вадим]

Wylaroren, Nuxt и Next js Это уже обёртки над фрэймворками. То есть кто-то собрал в кучу всякого разного и предлагает как решение определённых задач. Ниодна из перечисленных изначально технологий тут не причём. Даже сам vue или react тут не причём. Вам там условия диктуют не технологии, а авторы этих "сборок".

Вы не посмотрите на разработчика как на больного

Жду когда все вернутся на нативный CSS. К слову эта тенденция уже пару лет как идёт, но до вебстудий и снг в целом ещё не особо добралась.

Так то-то и оно, что JavaScript - несерьёзный язык :)

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

Ну так кому не надо, тот путь и не использует.

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

А что значит "замыкаем трафик на себе"? URL AMP-версий страниц не принадлежат тому же домену, что и канонические страницы?

Не могу ответить разом за все предлагаемые амп-подобные технологии, так как опыт их использования очень мал. Однако, например, турбо страницы яндекса открываются на https://yandex.ru/turbo/myDomain.ru/url.
У Вконтакте такая же, насколько я помню, история.
Так или иначе, Вы подключаете скрипты этих компаний, чтобы работали указанные технологии, которые хавают ваших пользователей.

бэк-енд команда часто перекладывает свою работу на фроне-енд команду,

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

Answer 1

[Леонид Роженцев]

Какие-то странные у вас рассуждения. Пользователь выше уже ответил, что эти технологии проверенные временем. Если копнутт глубже, то можно увидеть, что эти веб технологии постоянно развиваются, появляются новые cms и фреймворки на основе html, css, JavaScript или pho/python. Появились новые веб-технологии (asp net например). Давайте пройдёмся по пунктам:
1. HTML, CSS, JS являются единственными языками, которые поддерживают браузеры. Html + css - основа любой веб-страницы, JavaScript - единственный скриптовый язык, который поддерживают все браузеры.
2. На данный момент просто не существует альтернатив этих технологий, а если они и будут, то очень нескоро вытеснят старые по объективным причинам (см пункт выше).
3. Эти технологии довольно легко освоить, некоторые иищ них изучают в старших классах и в вузах, по ним есть огромное количество обучающих пособий.
Думаю что этих аргументов достаточно.

Comments

[Wylaroren]

Благодарю Вас за конструктивный ответ!

Answer 2

[Lord_Dantes]

Почему несмотря на устаревание HTML, CSS и JavaScript не делается шагов в сторону альтернатив, отвечающим спросу рынка веб-разработки?

Потому-что спрос рынка заканчивается на том что уже есть.
Какие альтернативы могут быть для html/css? Это примерно как альтернатива алфавиту языка, почему до сих пор не придумали 2-й русский ?

Answer 3

[mletov]

Ну так как раз все идет не в сторону разработки альтернатив, а в прямо противоположную.
Flash убили, Silverlight давным давно схоронили, ActiveX уже никто особо не пишет. Про Java аплеты я последний раз слышал в "Теории большого взрыва".
Все имевшиеся альтернативы имели проблемы с безопасностью и требовали доп разрешений от пользователей.
Видимо, решили не наступать на те же грабли и развивать нативный JS.

Comments

[Серафим Прозоров]

Вот Silverlight, кстати, лично мне ой как жаль...

Answer 4

[Серафим Прозоров]

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

Answer 5

[Валентин Судаков]

Вообще где вы устаревание то увидели ? О_о. Всё развивается по мере необходимости. Раньше когда не хватало возможностей HTML был придуман Flash Player, но теперь и от него отказались потому что современные решения на том же стеке HTML более эффективные, позволяют делать всё то что нужно народу, а те кто жаждет скорости недавно получили и вэб ассемблер... Так что я не вижу никакого устаревания ....

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