Зачем современную веб-разработку так усложнили? Часть 1

Автор оригинала: Victoria Kirst
  • Перевод
  • Tutorial
Современная фронтенд-разработка оставляет полярные впечатления: одни её любят, другие презирают.

Я большая поклонница современной веб-разработки, хотя она мне напоминает некую «магию», со своими плюсами и минусами:

  • Когда вы поймёте, как использовать волшебные инструменты (babel! бандлеры! вотчеры! и так далее!), ваш рабочий процесс становится быстрым, мощным и восхитительным
  • Если вы не понимаете волшебные инструменты, всё ужасно запутанно
  • …и попытки освоить магию слишком часто неудачны, если вам кто-нибудь не поможет продраться через джунгли жаргона, преувеличений и устаревшей информации в интернете

Недавно мне пришлось объяснять «современные рабочие процессы веб-разработки» людям, далёким от этого, и…

Пришлось реально МНОГО объяснять!

Даже поверхностное объяснение оказывается довольно длинным. Но всё же попытаемся проследить эволюцию веб-разработки:

Часть 1: Как мы добрались со статических сайтов до babel




Самый простой сайт: статический


Начнём с «классической» веб-разработки, которая всем должна быть понятна.

В классической разработке мы непосредственно изменяем файлы HTML/CSS/JavaScript. Чтобы просмотреть результат изменений, открываем HTML-файл локально в браузере, а по мере разработки обновляем страницу.

Рабочий процесс


Рабочий процесс выглядит следующим образом:

  1. Редактируем HTML/CSS/JavaScript в текстовом редакторе, таком как Atom.
  2. Сохраняем файл в текстовом редакторе.
  3. Открываем или перезагружаем файл в браузере.


Редактируем JavaScript, сохраняем файл, обновляем страницу

Развёртывание


Когда вы хотите опубликовать свой сайт в интернете, то просто куда-нибудь загружаем эти файлы HTML/CSS/JavaScript.

С помощью сервиса типа Netlify вы можете просто перетащить папку с файлами, чтобы опубликовать страницу в интернете. Вот пример опубликованной страницы.

Это так просто! Зачем всё усложнили?!


Если вы понимаете, как работает «классический» рабочий процесс, то можете сказать: чёрт, это действительно просто и удобно. Зачем вообще нужно было его изменять?! Почему современная веб-разработка настолько сложна?

Короткий ответ… Окей, два коротких ответа.

Два коротких ответа:

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

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

Старая проблема: ограничения JavaScript


До недавнего времени JavaScript и Web API имели множество ограничений (по множеству причин, которые мы опустим).

Вот некоторые из них:

  • Не было модулей
  • Не было констант
  • Не было промисов / async
  • Не было Array.includes() (!!)
  • Неуклюжий / отсутствующий синтаксис для многих общих примитивов (нет for-of, литералов шаблона, синтаксиса стрелочных функций, распаковки шаблона…)
  • (Web API) Бесчисленные операции DOM были бесполезно сложными (например, добавление/удаление имён классов, скрытие элементов, выбор элементов, удаление элементов…)

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

Отдельно: Какая разница между JavaScript и Web API?


Возможно, вы заметили, что выше я сказала «JavaScript и Web API». Это две разные вещи!

Когда вы пишете JavaScript для веб-страницы, любой вызов API, взаимодействующий с самой веб-страницей, представляет Web API (которые, так получилось, написаны на JavaScript), но это не часть языка JavaScript.

Примеры:

  • Web API: document и каждый method в document; window и каждый method в window; Event, XMLHttpRequest, fetch и т. д.
  • JavaScript: функции, const/let/var, массивы, Promise и т. д.

Например, если вы пишете сервер на Node.js, то пишете на JavaScript и можете использовать, например, промисы, но не можете использовать document.querySelector (и это не имеет смысла делать).

Старое решение: jQuery и друзья


Ещё в 2006 году вышла библиотека jQuery, которая помогла обойти многие недостатки JavaScript и Web API.

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

Итак, по сути: всё это было технически возможно с использованием старого JavaScript и старых Web API, но процесс был очень раздражающим, утомительным и часто сложными для разработки. Поэтому вместо написания утомительного кода, например, для загрузки и обработки файла JSON, вы могли просто загрузить библиотеку jQuery и использовать отличные jQuery API.

Новое решение: давайте улучшим сам JavaScript


Однако с 2006 года прошло много времени!

С тех пор JavaScript и Web API значительно улучшились, в том числе благодаря помощи от jQuery и других, показавших путь!

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

Возможно, вы слышали термин “ES6”. Он означает “ECMAScript 6” и относится к 6-й итерации ECMAScript. ECMAScript — это ещё одно название JavaScript. Просто в разговорной речи люди обычно используют “ECMAScript” для ссылки на саму спецификацию, а “JavaScript” — для ссылки на код.

(Кстати, ещё одна путаница и моя любимая мозоль: JavaScript не является реализацией/диалектом ECMAScript; это как называть “HTML” реализацией/диалектом «спецификаций HTML». В любом случае, это неправильно! Википедия, ты ошибаешься! JavaScript и ECMAScript — это одно и то же).

ES6 (выпущенный в 2015 году) примечателен тем, что добавляет много действительно приятных языковых функций в JavaScript, таких как const, модули и промисы (а ES8 представил мою любимую языковую функцию: async).

Параллельно и Web API значительно улучшились с 2006 года, с добавлением document.querySelector, fetch и мелочей вроде classList и hidden.

Поэтому вместо jQuery или других подобных библиотек в 2019 году мы можем, по большей части, просто напрямую использовать JavaScript и Web API.

…вроде того!

Новая-старая проблема: кроссбраузерная поддержка


Когда выходит обновление языка JavaScript, браузеры также следует обновить для поддержки новых функций (то же верно и для Web API, но для простоты оставим только JavaScript).

Тем не менее, есть задержки между 1) определением новой функции в языке; 2) реализацией функции во всех браузерах; 3) обновлением браузеров у всех пользователей (а это может никогда не произойти).


Дилемма: писать на старом или последнем JavaScript? У обоих подходов есть плюсы и минусы (конкретный пример кода взят отсюда)

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

Эту конкретную дилемму решает Babel.

Babel — это компилятор JavaScript, который преобразует код JavaScript в… другой код JavaScript! В частности, он преобразует код JavaScript, написанный с использованием последней версии JavaScript, в эквивалентный код, написанный с использованием более старой версии JavaScript, которая поддерживается в гораздо большем количестве браузеров.


С Babel мы можем наслаждаться преимуществами кодирования на последнем JavaScript, не беспокоясь о совместимости браузеров

Оговорка: Babel не поддерживает Web API


Например, если вы используете fetch в своём JavaScript, то babel не предоставит резервной поддержки (она называется «полифиллинг»), потому что fetch — это Web API, а не часть самого JavaScript (эта проблема сейчас решается).

Таким образом, вам понадобится отдельное решение для полифиллинга Web API! Но мы вернёмся к этому в следующей статье.

Возвращаясь к рабочему процессу: статический сайт + babel


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

Ниже приведён простейший рабочий процесс, который обычно не используется на практике (потому что более удобен бандлер вроде Parcel или webpack, но об этом позже).

Установка


  1. Установить* Babel
    (*Можете следовать инструкциям CLI, понимая, как работает npm. И эти инструкции рекомендуют устанавливать babel локально в качестве зависимости npm dev для каждого проекта, а не глобально на вашем компьютере)

Рабочий процесс разработки


  1. Разработайте свой сайт как обычную статическую веб-страницу.


    Пример: ванильный JavaScript размещается в каталоге src

Развёртывание


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

Вместо этого, вы хотите:

  1. Скомпилировать JavaScript с помощью babel, чтобы получить совместимый с браузером код:



    Это создаст новый, скомпилированный файл JavaScript в отдельной папке:


    Пример: Babel создаст второй “script.js”, уже с кроссбраузерной совместимостью
  2. Загрузить скомпилированный JavaScript в интернет вместе со своими HTML и CSS:


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


    (*Надеюсь! Иногда есть различия в сборках Debug и Release, но это баги!)

Различия между кодом в разработке и в продакшне




Обратите внимание, что теперь у нас есть разделение между кодом «разработки» и кодом «релиза» (продакшна):

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

Мы намеренно хотим разделить эти вещи, потому что:

  • Код разработки хорош для разработчиков, но плох для пользователей
  • Код продакшна хорош для пользователей, но плох для разработчиков

Во фронтенд-разработке не каждый использует или должен использовать Babel.

Но! Общая картина такова:

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

Это не просто распространённый, а часто ожидаемая картина для современной фронтенд-разработки.

(Обратите внимание, что наличие отдельных сборок Debug и Release является общим шаблоном в программной инженерии, а не чем-то особенным для веб-разработки. Но он особенно актуален для фронтенда, как по причине распространённости, так и из-за большой разницы во фронтенд-коде Debug/Release).

Краткий список технологий, где ожидается такое разделение между версиями разработки и продакшна:

  • модули npm
  • Любой препроцессор CSS
  • React/Vue/Angular/любой веб-фреймворк

Это общий шаблон, так что обратите на него внимание уже сейчас!

В следующей статье: npm и бандлы


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

Похожие публикации

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

    +21
    Самый кайф начинается, когда девелоперский код работает, а продакшн нет.
      +6
      Наступали на эти грабли:
      class CustomError extends Error {
        constructor(...args) {
          super(...args);
        }
      }
      
      const error = new CustomError('asdasd');
      const isCustomError = error instanceof CustomError; // false, если транспайлим в es5...
      const isError = error instanceof Error; // true
      
      +2
      Помню прикол с safari. В проекте был такой код:

      this._removeResizeFunc = setAndCallResizeFunc(async () => {
        /* ... */
        await this.$timeout();
        /* ... */
      });
      


      На всех браузерах он отрабатывал нормально, кроме safari 10. В нем он выдавал ошибку:

      Can't find private variable: @derivedConstructor
      


      В дев режиме ошибка не воспроизводилась.

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

      Переписали на промисы и все заработало :)
        +1
        Переписали на промисы и все заработало :)

        А не проще было настройки компиляции для Safari 10 подкрутить?

          0
          Проще было одну функцию переписать на промисы, чем играться со сборкой

          this._removeResizeFunc = setAndCallResizeFunc(() => {
            /* ... */
            this.$timeout().then(() => {
              /* ... */ 
            });
          });
          

            +1

            Ничего, скоро таких функций станет две и баг вернётся :-)

              0
              Пускай возвращается, safari 10 мы уже не поддерживаем ¯\_(ツ)_/¯
                0

                А зачем тогда на промисы переписывали?

                  0
                  Потому, что раньше пользователей safari 10 было больше и нужно было как-то поддерживать его работоспособность.

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

      П.С. И практически везде где в тексте статьи стоит «усложнили» я бы поставил «упростили». Или это я просто сарказм/иронию не уловил? :)
        +4

        Не упростили, а переложили с рантайма на девелоп.

          +19

          Упростили для тех, кто знал в чём проблема и усложнили порог входа для всех остальных. Хотя я вообще не frontend-guy (на самом деле даже не web-guy), но мне в целом не тяжело понять зачем и почему существуют все эти сложности. Однако, я уже умею программировать и это сильно упрощает мне понимание. Думаю для новичков погружение в современный фронтэнд просто сущий ад)

            +8
            Думаю для новичков погружение в современный фронтэнд просто сущий ад)

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

              +1

              Не знаю, мне уже поздно рассуждать :) Я пишу на С++ и первую программу написал году где-то в 2012м. И уже тогда объем исторических знаний, который необходим для понимания какие проблемы решались теми или иными инструментами был почти неподъемным. Сейчас разрыв стал еще больше :) Везде, не только в JS и C++.


              Так что да, наверное вы правы — для новичка абсолютно все — ад :)

                –1
                Какой ад? Сидишь и куришь мануал и всё потихоньку решается. Куча людей вокруг, которые могут придать ускорение в сторону необходимого мануала, стоит только рот открыть.
                  +5

                  Если знаешь что спросить — ты уже решил проблему. Но чтобы сформировать вопрос, нужно хотя бы нужные термины знать и иметь способность понять ответ :) Мне, как программисту, понять что такое транспайлер не составляет труда. Я отлично понимаю что означает "скомпилировать" JavaScript в JavaScript :) Но человеку с чистым разумом это тяжело понять в целом, как концепцию, мне кажется.


                  Как пример из мира С++ — впервые встретив такую аббревиатуру, как ABI, я погряз в гуглении на неделю, а чтобы хоть как-то глубоко разобраться в местах, где возникают проблемы с ABI и реально осознать как их решать, ушло наверное больше полугода, да и то, до сих пор всплывают пробелы в познаниях.


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


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

                    +1
                    Это просто желание получить всё и сразу. Не стоит торопиться, можно просто поглощать одну статью за другой, сортируя их в порядке простоты понимания. К концу первого квартала придёт осознание, в каком порядке дальше копать.

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

                        Такой вопрос задают те, кто не умеет гуглить.
                      0
                      Подскажите хорошую книгу для новичка. Я как С++ начал осваивать )
                        0
                        например, библиография в конце статьи ru.wikipedia.org/wiki/%D0%9C%D0%B0%D0%B9%D0%B5%D1%80%D1%81,_%D0%A1%D0%BA%D0%BE%D1%82%D1%82
                          0

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


                          Сейчас же уже С++20 на подходе и я не знаю книг для новичков, которые бы постепенно раскрывали язык начиная хотя бы с С++11.


                          Из хороших книг по С++, которые подойдут для уже хотя бы немного разобравшихся, я бы наверное порекомендовал:


                          • "Эффективный и современный С++", Скотт Мейерс. (Но лучше читать более свежий оригинал на английском)


                          • "Язык программирования С++", Б. Страуструп. (Спорная книга. Написана просто ужасно скучно, но в ней я в своё время находил много всяких интересных деталей о внутреннем устройстве С++)



                          Если честно, не знаю ни одной хорошей книги по шаблонам, я как-то в своё время с шаблонами и compile-time вычислениями разбирался методом проб и ошибок.


                          Крайне рекомендую когда что-то непонятно в языке — ходить на
                          https://en.cppreference.com/w/cpp/language

                            0
                            Думаю, стоит посмотреть книги в следующем порядке:
                            1. С. Прата — www.williamspublishing.com/Books/978-5-8459-1778-2.html — это C++ до C++11;
                            2. Потом C++17 STL — www.piter.com/collection/all/product/s17-stl-standartnaya-biblioteka-shablonov — докинуть обзор по C++14 и C++17.

                            Правда просто читать будет невероятно тяжело — по крайней мере, в одиночку. Так что, либо ищи себе друзей, с кем будешь вместе осваивать, либо пытайся найти что-нибудь на GitHub, что будет тебе интересно.
                            Только учитывай, что я сам не плюсовик, так что могу и фигню тебе нести. ;) Однако я читал обе и, по крайней мере, вторая мне очень понравилась лёгким и компактным изложением.
                        0

                        это вы еще современного PHP не видели ;-)

                          0
                          А что там?
                            0

                            Фреймворки, IoC-контейнеры, entity-менеджеры, репозитории, object-relation mappings, template engines, PSR-0,1,2,3… 19, "бессмертный" react-php и конечно же "один composer, чтоб править всеми" :)
                            Ну и язык тоже немного изменился с версии 3, на которой я когда-то давно начинал.

                              0
                              И Wordpress.
                                0

                                что это?

                                  0
                                  Самая популярная CMS.
                                –1

                                Когда на собеседованиях спрашивают про то, что в изменениях PHP нравится, я отвечаю "ООП появился". Некоторые собеседующие и не знают, что его не было в 3, а в 4 оно было очень специфичное :)

                                  0
                                  Каков слишком общий вопрос, таков и самый ключевой ответ! Очень интересный ответ, правда.
                                  Главное, выдержав небольшую паузу добавить более узкие ответы про фичи пятёрок и семёрок.
                          0
                          вордпресс =)
                            +2
                            Простите, а погружение в какую практическую область разрабоки для новичка не ад? :)

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

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

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

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

                        Главная проблема современной веб-разработки — это количество инструментов. Никто, даже эта статья, не рассказывает про эти инструменты, не сравнивает, не даёт анализ. Все просто говорят, что есть первое, второе, третье. А потом ты ставишь себе пакет, а он тянет первое. Ты ставить другой пакет, а он тянет второе. Таким образом, элементарная задача собрать бандл выливается в 100500+ пакетов, вотчеров и прочего бесполезного мусора. Как решают эту проблему? Никак, её просто откладывают, создавая новый инструмент-обёртка а-ля бандлер бандлов и т. п.

                          +1
                          Как будто это проблема веб-разработки… В том же самом браузере зависимостей ничуть не меньше. Просто они лежат глубже и их сложнее вытащить на свет.
                            +1
                            Современная веб-разработка возможна и без обвешивания себя этими инструментами. Все зависит от задач. Я занимался разработкой нескольких средних по размерам SAAS сервисов. Там по обе стороны не использовались никакие сложные инструменты.

                            Фронтенд писался прямо в том же PHPStorm. Это был HTML + CSS без библиотек + нативный JS + jQuery. Скажем так, у меня больше сложностей вызывала бекенд разработка (вел обе одновременно, и даже немного администрировал сервер, например, настраивал bind9 чтобы юзеры прямо в ПУ сервиса могли свои домены подключать, почту на них делать и т.д.).

                            Если вы занимаетесь огромным проектом, который обслуживает кластер из десятка серверов. У вас миллионы пользователей в сутки, а чистый написанный код весит десятки мегабайт — тогда может быть есть смысл задействовать различные инструменты. Но мне кажется, 80% разработчиков в жизни с таким не сталкивались. У нас пиковая посещаемость была 2,7 млн. пользователей в месяц. На это и «блокнота» бы хватило. В PHPStorm просто удобней.
                              0
                              Согласен, но есть ситуации, когда нужны специальные инструменты. Конечно, можно все решить с помощью jquery, но это будет неэффективно.
                                +3
                                Проблема в том, что с таким количеством инструментов новичок не сможет понять, нужны ли инструменты в его случае или нет, и какие именно нужны.

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

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

                                  0
                                  Инструменты важны. Инструменты нужны. Но только там, где они действительно нужны. Знаю, многие люди придерживаются единого стиля во всех проектах. Мол, если пишем на JS, то только c библиотекой. И в этом есть определенные преимущества, да и в команде без этого часто ни как. Но когда к примитивному проекту подключается jQuery лишь для примитивного выпадающего меню (для использования какого-нибудь .on + .toggle). Которое в точности можно не то что на нативном JS, на CSS сделать то же самое 1-в-1. Такого я все равно не понимаю.
                                    0

                                    Как я понимаю, в целом тут речь больше о инструментах времени разработки, а не исполнения. Типа раз пишем на JS, то используем SCSS-in-JS, ES-next со stage-3 и даже некоторыми stage-2 и одну вообще отмененную используем, babel, webpack, минификаторы для прода и дев-сервер c хотрелоадингом для дева. Плюс линтеры-форматтеры в гитхуках (гит вообще мастхэв), BDD-тесты, докер, CI/CD. А можно на ES-3 в блокноте писать и по ftp заливать на прод

                                0

                                Полностью согласен. И практически на любом уровне есть выбор из нескольких похожих вариантов: grunt/gulp/webpack/rollup/parcel, angular/vue/react, less/sass/postcss, typescript/flow, karma/jasmine/jest/mocha... — а еще есть всякие адаптеры, типа "директива, интегрирующая выпадалку Selectize в Angular" — и их тоже бывает несколько, каждая со своими особенностями (одна удобная, другая работает стабильнее). В итоге количество возможных комбинаций растет геометрически, и есть вполне реальный шанс наткнуться на проблему, с которой никто до вас не сталкивался, потому что она возникает из конкретного вашего набора инструментов.

                                0
                                Буду скидывать эту статью коллегам, чтобы всё это не объяснять.
                                  +2
                                  Это так просто! Зачем всё усложнили?!

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

                                  Мы намеренно хотим разделить эти вещи, потому что:

                                  Код разработки хорош для разработчиков, но плох для пользователей
                                  Код продакшна хорош для пользователей, но плох для разработчиков


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

                                    0

                                    Так проблема в том, что браузер не умеет код модели. Это как компиляция какого-нить C# или Java в JS — вынужденная мера.

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

                                        Он же принципиально тормозной.

                                          0

                                          Я уже почти собирался предложить TAL-0, но потом до меня дошло: раз не надо ничего компилить, по-вашему, то на этом языке сразу что ли все писать будут?

                                            –3
                                            Он же принципиально тормозной.

                                            не думаю что особо по сравнению с JS. К тому же это чисто фейл интерпретации и разных моментов питона. При нормальном интерпретаторе можно эквивалентом С сделать.
                                            не знаю что такое TAL-0.
                                            то на этом языке сразу что ли все писать будут?

                                            скорее всего не начнут, там колоссальная инерция всякого уже написанного быдлокода. Никто ж не будет отменять node или react и т.п.
                                            Коменты натолкнули на идею что интерпретатор языка может быть самостоятельным от браузера, и вы с удивлением увидите что коллосс веб дева не нужен. Например на машине стоит Питон, на нём же хоть и не обязательно написана тонкая оболочка браузера. Веб страница соответствует некой компонетне унаследованной например от TK если его взять для GUI. Текст веб страницы — это модель для GUI, просто исполняется функцией exec, и не нужны танцы с бубном для DI в код оболочки потому что в питоне всё DI. Можно и песочницу встроить.
                                            Нет, они сделают 10 браузеров и 30 скрепящих огромными шестернями технологий с крутыми именами.

                                            +2

                                            Как по мне, заменить JS на Python ничего особо не изменит. Были одни косяки и странности, будут другие:


                                            1. Объявление переменных без ключевых слов var/let/const, приводящее к опечаткам. Раньше в ES3 такое тоже было, но в ES5 добавили strict mode, который это запрещает.
                                            2. Модульная система, в которой очень неочевидно делаются относительные импорты. В ES6 модули работают намного понятнее.
                                            3. Отсутствие приватности в модулях. Любая переменная или класс, будет доступна снаружи. Опять-таки, в ES6 экспорты явно отмечаются ключевым словом export.

                                            Недавно пришлось поработать с проектом на Flask и после нескольких лет работы с Javascript эти странности вызывали некоторое недоумение.

                                              –2
                                              Опа, пошли минусы ставить, ну вот за что в этом посте, а?
                                              Объявление переменных без ключевых слов var/let/const

                                              и так понятно. Мне например надоедает писать модификатор, потому что он может легко определяться автоматически.
                                              Да импорты и приватность в питоне немного проседают нужен модификатор вроде private-set и импорт только модуля, да и много чего…
                                              Зато настолько гибкий язык, что фактически в базу (ненадо никаких Flask) занесён функционал например шаблонов, json- подобного синтаксиса обьектов, легкой модифицируемости под свой домен-специфический язык. Суть в том что там это уже есть даже в базе языка и работает в обычных прогах, а чтоб это было в вебе, дуплицируя это придумали XHTML, XPATH, CSS, JS там node, react всякие и т.п. делая тупую работу и абсолютно нереюсабельный код.

                                                +3
                                                Мне например надоедает писать модификатор, потому что он может легко определяться автоматически.

                                                Модификаторы за тем и пишутся, что их нельзя определить автоматически.

                                                  0
                                                  с какой стати нельзя определить это константа илои переменная и точный тип при компиляции/ интерпретации что ли?
                                                    0

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


                                                    Модификатор const в любой корректной программе всегда можно заменить на let без изменений в поведении (единственное исключение — если вы используете eval в нестрогом режиме, но так делать не надо). Он нужен только для того, чтобы явно запретить самому себе из будущего менять переменную и попросить компилятор или интерпретатор за этим проследить.


                                                    Ну а модификатор var просто устарел и точка.

                                                      –2

                                                      "у меня есть мечта". с недавних пор. с тех самых, как слово const стало одним из самых частых в js. мечта о том, чтобы объявление переменной без модификатора и означало const. несбыточная мечта :(

                                                        +1

                                                        Совсем без модификатора не получится — интерпретатору нужно же как-то узнать, что это именно объявление переменной, а не ошибка.

                                                          0

                                                          del

                                                          0

                                                          А как понять транслятору, что это объявление переменной, а не использование с забыты объявлением? const, let и var не модификаторы, а разные типы объявлений.

                                                          0
                                                          Он нужен только для того, чтобы явно запретить самому себе из будущего менять переменную

                                                          не, на этапе компиляции переменная которая «чуть чуть» меняется может замениться несколькими константами. «Чуть чуть» — значит изменения понятны на этапе компиляции.Пример:
                                                          a = 5, не в непредсказуемом цикле
                                                          делаем что то дальше
                                                          a = 10, не в непредсказуемом цикле
                                                          все значения a можно заменить на константы. Нельзя заменить только если присвоения определяются только в рантайме например в непредсказуемом цикле или по внешним данным например вводу с консоли или чтению файла.
                                                          чтобы явно запретить самому себе из будущего

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

                                                          Что скажешь поповоду гипотетического языка с таким обьявлением:
                                                          • Если модификатора нет, компилятор/ интерпретатор сначала пытается сделать переменную константой
                                                          • если не получается и переменная зависит от рантайма но в компайлтайме известны все типы, можно её статически типизировать. Это фактически предсказуемое число переменных с постоянным типом
                                                          • иначе типизируем её динамически
                                                          • также кто хочет мудохаться, можно задавать явные ограничители, вроде const или типов, причём можно применить или для типов например
                                                            Str|Int a
                                                          • что действительно надо это модификатор private set потому что в компайл(интерпрет)тайме видны все присвоения переменной
                                                            +1

                                                            А неважно на что переменная меняется в процессе оптимизаций, важно лишь что означает написанное вами определение.


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

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


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

                                                            Как вы вынесете в отдельный файл переменную цикла: for (const item of array) {... }?

                                                              0
                                                              А неважно на что переменная меняется в процессе оптимизаций,

                                                              как меняется? каких оптимизаций?
                                                              то у него не может быть никаких «непредсказуемых» циклов.
                                                              если значения переменных или вообще переменной цикла зависят от ввода или генерации случайного числа в рантайме. Иначе цикл просчитуется при компиляции и схлопывается, как делает gcc
                                                              for (const item of array)
                                                              а, просто чтоб не присваивали item? зачем?
                                                              А вообще я смортю тут много сторонников лишней писанины, для установления ограничений… самому себе??
                                                                0
                                                                как меняется? каких оптимизаций?

                                                                Не важно каких, всё равно от этого ничего не зависит.


                                                                Иначе цикл просчитуется при компиляции и схлопывается, как делает gcc

                                                                Вот вы привели пример оптимизации. Эта оптимизация не важна, она никак не меняет смысл переменной.


                                                                а, просто чтоб не присваивали item? зачем?

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

                                                          +1

                                                          Если вкратце, то с теоремы Райса.

                                                            +1
                                                            с какой стати нельзя определить это константа илои переменная и точный тип при компиляции/ интерпретации что ли?

                                                            Ну вот я написал:


                                                            a = 10;
                                                            a = 20;

                                                            Возможно, в первой строке должно было быть const и, с-но, вторая строчка — ошибка, компилятор должен эту ошибку выдать. А возможно, в первой строке должен быть let, и тогда вторая строка — корректна, ошибки быть не должно.
                                                            Каким образом компилятор может догадаться, какой вариант правильный? Никаким.
                                                            Точно так же как никаким способом не догадаетесь и вы. А вот если стоит const — вы точно знаете, что переменная не меняется.

                                                              0

                                                              Хм… "Если при первом упоминании не написано let, значит это константа и вторая строка ошибочна". Практика показывает, что если последовательно пользоваться const и let, const встречается гораздо чаще.
                                                              Но такое изменение спецификации радикально ломает обратную совместимость, потому и невероятно :(

                                                                0
                                                                я как раз писал о том что простые присвоения можно рассматривать как константы. То есть при компиляции после a = 10 а заменяется константой, если можно, потом a=20 опять константа.
                                                                Так становится нельзя делать уже например при
                                                                a = input() или a = rand() и другое что неизвестно при компиляции.
                                                                  +1

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


                                                                  Ужасная идея.

                                                                    0
                                                                    я как раз писал о том что простые присвоения можно рассматривать как константы.

                                                                    Зачем? Смысл const как раз в том и есть, что если явижу const a, то знаю что оно присвается только раз — при объявлении. И компилятор мне это гарантирует. А если я вижу a = 10, то что?

                                                                      0
                                                                      const — это не для вас, это как раз для компилятора. Чтобы он понимал, что это выражение можно посчитать один раз и дальше в коде подставлять его результат. Вам-то какой смысл иметь дополнительное указание, что это выражение, дескать, дальше не изменяется? Это и так всегда из контекста понятно, кроме случаев, когда код намеренно превратили в какашку.
                                                                        0

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

                                                                          0
                                                                          Хм. Меняет. В наборе x86 у многих инструкций есть режимы и «взять операнд по адресу», и «взять операнд из регистра», и «взять операнд, непосредственно идущий за командой». Последнее, как вы понимаете, быстрее.
                                                                            +2

                                                                            А каким боком тут const? Вот есть два куска кода:


                                                                            // 1
                                                                            const foo = JSON.parse(await readFile(...));
                                                                            return foo.bar.baz;
                                                                            
                                                                            // 2
                                                                            let foo = JSON.parse(await readFile(...));
                                                                            return foo.bar.baz;

                                                                            Какой из кусков кода будет использовать операнд по адресу, а какой — из регистра? :-)

                                                                              +1
                                                                              «взять операнд, непосредственно идущий за командой». Последнее, как вы понимаете, быстрее.

                                                                              Ох не факт. Из регистра должно быть самым быстрым.

                                                                                0
                                                                                Я так понимаю «взять операнд, непосредственно идущий за командой» — это так immediate обозвали. Это может быть быстрее обращения к регистру.
                                                                                  0

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

                                                                                    0
                                                                                    immediate, по идее, быстрее. Данные из регистров ведь все равно должны в ALU загрузиться. Это, как минимум, одну микрооперацию экономит.
                                                                                      0
                                                                                      Загрузка из регистра в ALU никогда не была отдельной микроопераций. Максимум что можно наэкономить — один физический регистр и (что важнее) один логический.

                                                                                      Но да, это какую-то экономию даёт.
                                                                                        0
                                                                                        Загрузка из регистра в ALU никогда не была отдельной микроопераций

                                                                                        Я не буду особо спорить, т.к. процессоры не проектирую, но подозреваю, что в современных процессорах, где есть большой пул регистров, для которого блок спекулятивного выполнения решает «а вот для этой операции мы тебя назначим в роли EAX» и есть пул исполнительных блоков, это всё-таки отдельная микрооперация.
                                                                                          0
                                                                                          Вы бы хоть википедию почитали перед тем, как чушь писать. В процессоре нет никакого отдельного «блока спекулятивного исполнения», переименование регистров может исполняться многими разными способоами, а главное — всё это ровным счётом никакого отноешения к μopsам не имеет.

                                                                                          μops'ы просто преобразуют CISC в RISC, если говорить условно. И всё. В ARM они не используются даже на современных суперскалярах, например.
                                                                                            0
                                                                                            Да читал. В Википедии нет ничего, противоречащего тому, что я написал. И почему оно не имеет отношения к микрооперациям? Разве микрооперации — это только команды ALU и тому подобных блоков? Микроопераций управления там нет, что ли?
                                                                                              0
                                                                                              Микроопераций управления там нет, что ли?
                                                                                              Не очень понятно, что вы подразумеваете под «операциями управления». Да собственно вообще не очень понятно как вы себе представляете микрооперации и что они, по вашему, вообще делают.

                                                                                              Разве микрооперации — это только команды ALU и тому подобных блоков?
                                                                                              В микрооперациях нет никаких «команд ALU» и «блоками» они не управляют.
                                                                                                0
                                                                                                Ну а что такое «микрооперации»? В моём понимании это набор элементарных инструкций, исполняемый каким-либо устройством процессора, в который декодируются «высокоуровневые» команды, например, набора x86. Разве не так?
                                                                                                  0
                                                                                                  Это вопрос в стиле «вы прекратили пить коньяк по утрам?».

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

                                                                                                    Ясно. Ну тогда наш спор возник на пустом месте. Если есть инструкция, то естественно, есть и устройство исполнения. Если в процессоре можно выделить блоки FPU, ALU, MMU и прочие штуки, и они выполняют какие-то действия по микроинструкциям, то считать или не считать их устройствами исполнения, это уже вопрос философии или там словесности, а не техники :)
                                                                                                      0
                                                                                                      Если есть инструкция, то естественно, есть и устройство исполнения.
                                                                                                      Совершенно неестественно. Потому что может быть много таких устройств.

                                                                                                      Если в процессоре можно выделить блоки FPU, ALU, MMU и прочие штуки, и они выполняют какие-то действия по микроинструкциям
                                                                                                      В том-то и дело, что выделить блоки можно, но эти блоки не выполняют никаких «действий по микроинструкциям». В процессоре имеются десятки отдельных блоков и каждая микроинструкция обрабатывается далеко не в одном из них. Более того, в процессорах со спекулятивным исполнением даже нельзя сказать, что они последовательно обрабатывается. Одна и та же микроинструкция может быть обработана одним и тем же блоком много раз (Pentium 4 этим был особенно знаменит).

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

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

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

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

                                                                                                        Элементарно — устройство декодирования разбивает какой-нибудь MUL EAX, EBX на группу команд «загрузить слово из регистра 1», «загрузить слово из регистра 2», «перемножить», «сохранить результат в регистр 1». Затем этот самый блок спекулятивного выполнения (не важно, так он называется или нет, но устройство, которое выбирает порядок и конкретного исполнителя для микрокоманд там определённо есть, не так ли?) назначает блок-исполнитель и конкретные регистры для арифметической операции, возможно, проставляя им какие-либо атрибуты, превращая их в «загрузить слово из регистра X», «загрузить слово из регистра Y», «перемножить на ALU2», «сохранить результат в регистр Z»
                                                                                                        И после этого по атрибутам они выбираются из конвейера в конкретный блок-исполнитель.
                                                                                                        Ну и уточню — это ответ на «как я себе это представляю». Представляю вполне логично и адекватно, но как оно в реальности реализовано, я на самом деле не знаю, поэтому могу ошибаться. Если я не прав, напишите как на самом деле, если вы сами это знаете, а не догадываетесь точно так же, как и я.
                                                                                                        Только плиз, не придирайтесь к формулировкам. Это за возражение и понимание не считается ;)
                                                                                                          +1
                                                                                                          Элементарно — устройство декодирования разбивает какой-нибудь MUL EAX, EBX на группу команд «загрузить слово из регистра 1», «загрузить слово из регистра 2», «перемножить», «сохранить результат в регистр 1».

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


                                                                                                          • Выходной мультиплексор регистра 1: выдать данные на шину первого операнда
                                                                                                          • Выходной мультиплексор регистра 2: выдать данные на шину второго операнда
                                                                                                          • Подать на вход "код операции" ALU некий набор бит соответствующий операции ALU (может совсем не совпадать с кодом операции к команде)

                                                                                                          *** Тут тактовый генератор говорит Бумс!!!
                                                                                                          ALU слышит этот Бумс!!, пытается разобраться с тем, что у негона входах и сформировать что-тоосмысленной на выходе. Иногда ему нужно для этого много Бумс!!! Для умножения точно много… Наконец все получилось и ALU выдает сигнал "Я готова, мой повелитель". И тут в дело снова вступает УУ и выдает


                                                                                                          Шаг 2:


                                                                                                          • Входной мультиплексор регистра 1: подать данные с шины результата
                                                                                                          • Подать на регистр 1 сигнал write.
                                                                                                            *** Тут тактовый генератор говорит Бумс!!! И регистр 1 записывает в себя то, что у него на вхдах данных.

                                                                                                          Это все настолько сильно абстрактно и упрощенно, что почти некорректно, но какое-то представление о работе внутренностей процессора дает.


                                                                                                          Что же до непосредственного операнда, то он вообще говоря совсем не обязательно находится "прямо в команде". Гораздо чаше он находится в последующих байтах ОЗУ и его считывание вообще говоря ничем не отличается от считывания из ОЗУ любых других данных. Просто индексным регистром будет выступать PC/IP. Опять же все это очень абстрактно, ибо в разных архитектурах это все очень по разному реализовано.

                                                                                                            0
                                                                                                            Затем этот самый блок спекулятивного выполнения (не важно, так он называется или нет, но устройство, которое выбирает порядок и конкретного исполнителя для микрокоманд там определённо есть, не так ли?)
                                                                                                            Конечно. Планировщик называется.

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

                                                                                                            Не забывайте: ALU у нас штуки 3-4 всего. Представьте, что у вас есть команда, обращающаяся в память и вы её куда-то там запланировали. Что будет если данных ни в L1, ни в L2 не окажется? Не забыли ещё? Двести тактов мы будем ждать этих данных. Двести! И всё это время ваше ALU будет тупо греть воздух! Потому что пока не загружены данные мы не может ничего вычислять — а мы уже всё распланировали! И ALU «тупит и ждёт данных»? Так, что ли?

                                                                                                            Нет — так дело не пойдёт. Процессоры проектируют так, чтобы назначение операции на ALU происходило после того, как станут известны её операнды, а не до. Беречь надо ALU, у нас их мало. А вот регистров зато много, их беречь не нужно (AMD в последнем поколении увеличила их количество со 168 штук до 180 штук, к примеру).

                                                                                                            Потому в микрооперациях прописаны регистры (не архитектурные, конечно, а железные — для этого у нас есть переименование регистров), а вот ALU — там не прописано. Какое будет свободно — то и «подберёт» инструкцию…

                                                                                                            Вот отсюда и мои вопросы:
                                                                                                            Элементарно — устройство декодирования разбивает какой-нибудь MUL EAX, EBX на группу команд «загрузить слово из регистра 1»,
                                                                                                            Куда загрузить? Зачем загрузить? Вот взяли вы это число из регистра 1 — куда вы его пошлёте? В воздух? Оно будет сиять над процессором божественным сиянием?

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

                                                                                                              Ок, без проблем. А если результат предыдущей арифметической операции сразу же является операндом для следующей? Он все равно будет сохраняться в регистр, и ждать, когда его кто-то подберёт? Может, планировщик современного процессора всё-таки чуть умнее? ;)
                                                                                                              Куда загрузить? Зачем загрузить?

                                                                                                              В ALU. Разве оно в современном x86 производит операции непосредственно над содержимым регистров общего назначения? Очевидно же, что раз есть некая адресация и переименование этих регистров, то между ними и ALU есть схема выборки и непосредственно операции выполняются во внутренних регистрах ALU, а не в РОН.
                                                                                                              Вы же не разработчик процессоров, а такой же, как и я, т.е. интересующийся, верно?
                                                                                                                0
                                                                                                                Он ведь в курсе и какие команды последуют потом, и какие данные операнды каких регистрах готовы.
                                                                                                                Про то, какие команды следуют потом он мало задумываются (ибо на частоте в 4GHz мы можем заставить работать только очччень ограниченную по сложности схему), а про то какие данные будут готовы и когда — он может знать только лишь ex post facto: далеко не все команды исполняются за одинаковое, предсказуемое, время. Особенно непредсказуемы команды загрузки данных из памяти: они мало того, что могут заставить вас ждать 200 тактов… они ещё и исключение могут вызвать и вообще весь конвеер вам сбросить.

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

                                                                                                                Может, планировщик современного процессора всё-таки чуть умнее? ;)
                                                                                                                Вы про operand forwarding? Да, в некоторых случаях он позволяет экономию в один такт получить. Но данные всё равно направляются и в регистр тоже.

                                                                                                                В ALU
                                                                                                                Сказка про белого бычка. В какое ALU? Их у нас несколько, не забывайте. И портов в этих ALU, кстати, тоже несколько.

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

                                                                                                                Вы же не разработчик процессоров, а такой же, как и я, т.е. интересующийся, верно?
                                                                                                                Непохоже, чтобы вы этим реально интересовались, судя по владению предметом. Потому что представление у том, что внутри процессора происходит у вас, мягко скажем, приблизительное. И непохоже, чтобы таблички Agner Fogа или LLVM-MCA могли бы вам какую-нибудь пользу принести…
                                                                                                                  –1
                                                                                                                  далеко не все команды исполняются за одинаковое, предсказуемое, время

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

                                                                                                                  Не понимаю ваше, кхм, непонимание. Чем операция «сложить в ALU два операнда» отличается от операции «загрузить операнд из регистра в ALU»? Почему первую можно передать в свободное ALU, а вторую якобы нельзя?
                                                                                                                  По моему, это уже спор ради спора. Вы увидели пару неточностей в моих рассуждениях, и кинулись махать секирой «всё неправда, вы ничего не понимаете». Давайте прекращать.
                                                                                                                    +1
                                                                                                                    Для планировщика все операции абсолютно детерменированы и выполняются известное количество времени, за исключением загрузки данных из оперативной памяти.
                                                                                                                    Не только. Деление непредсказуемо, корни и тригонометрия. Даже умножение только на самых «больших» процессорах реализовано на сетках с гарантированным временем исполнения. Ну а загрузка (и выгрузка, кстати) — это, собственно, «слон в комнате и есть». На x86, с его нехваткой регистров, временные результаты очень часто в памяти хранятся — потому вам важно «не тормозить» с локальными данными… но и устраивать безумные задержки, когда кто-то обращается к массивам — тоже не годится.

                                                                                                                    Чем операция «сложить в ALU два операнда» отличается от операции «загрузить операнд из регистра в ALU»?
                                                                                                                    Ничем не отличаются. Обе не имеют смысла.

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

                                                                                                                    Вы увидели пару неточностей в моих рассуждениях, и кинулись махать секирой «всё неправда, вы ничего не понимаете».
                                                                                                                    Не совсем так. Если вы не читали Фейнмана, то почитайте — отличная вещь. А нам оттуда нужен всего лишь маленький фрагмент:
                                                                                                                    Занимаясь тригонометрией самостоятельно, я никогда не пользовался символами, которыми принято обозначать синус, косинус и тангенс, потому что мне они не нравились. Для меня выражение sin f выглядело как s, умноженное на i, умноженное на n, умноженное на f! Тогда я придумал другой символ, — ведь придумали же символ для обозначения квадратного корня, — сигму с длинной горизонтальной палкой, под которой я и ставил f. Тангенс я обозначал буквой тау с удлиненной крышечкой, а для косинуса я придумал букву вроде гаммы, но она была немножко похожа на знак квадратного корня.
                                                                                                                    Арксинус я обозначал с помощью этой же сигмы, но зеркально отраженной, так что она начиналась с горизонтальной линии, под которой стояла буква, и уже потом шла сигма. Вот это был арксинус, а НЕ sin-1 f, что выглядело как полный бред! В учебниках были такие выражения! По мне так sin-1 обозначал 1/ sin, величину, обратную синусу. Так что мои символы были лучше.
                                                                                                                    Также мне не нравилось обозначение f(x), для меня оно выглядело как f, умноженное на x. Не нравилось мне и dy/dx — всегда возникает желание сократить d, поэтому я придумал другой знак, что-то вроде &. Логарифмы я обозначал большой буквой L с удлиненной горизонтальной чертой, над которой
                                                                                                                    писал величину, из которой брал логарифм и т.д.
                                                                                                                    Я считал свои символы не хуже, если не лучше, стандартных — ведь нет никакой разницы в том, какие символы используются, — однако впоследствии я понял, что разница есть. Как-то в школе я что-то объяснял другому парнишке и, не подумав, начал писать свои символы, а он говорит: «Что это за чертовщина?» Тогда я понял, что если я разговариваю с кем-то еще, то мне следует использовать стандартные символы, поэтому, в конце концов, я отказался от своих обозначений.

                                                                                                                    Слова имеют-таки значение, хотите вы этого или нет.

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

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

                                                                                  Сильно зависит от архитектуры, но обычно нет.

                                                                                +1
                                                                                const — это не для вас, это как раз для компилятора. Чтобы он понимал, что это выражение можно посчитать один раз и дальше в коде подставлять его результат.

                                                                                Вообще-то нет. const — это для меня, чтобы я знал — эта переменная не меняется. А компилятору оно не надо.


                                                                                Это и так всегда из контекста понятно

                                                                                Если const стоит — конечно, понятно, а если не стоит — совсем непонятно. Вот написано: "a = 10" — по каким критериям я должен определить, что а — это константа и она не меняется?

                                                                                  –1
                                                                                  Вот написано: «a = 10» — по каким критериям я должен определить, что а — это константа и она не меняется?

                                                                                  А очень просто. Это какая-то переменная, либо это говнокод. Вот если было бы написано MESSAGE_TYPE_TEXT = 10, то очевидно, константа.
                                                                                  И не забывайте про другие важные критерии: по каким критериям вам это вообще нужно знать, кроме любопытства? Знание предполагает использование, верно?
                                                                                    +3
                                                                                    Вот если было бы написано MESSAGE_TYPE_TEXT = 10, то очевидно, константа.

                                                                                    Какой интересный критерий. Мне вот например такое ну вообще не очевидно. В отличие от «const» :)

                                                                                    Я понимаю что такое могло где-то исторически сложиться, но как минимум если следовать clean code, то пытаться запихать в имя переменной в каком либо виде её тип или любую другую аттрибутику, это не особо хорошая идея.
                                                                                    0
                                                                                    Вообще-то нет. const — это для меня, чтобы я знал — эта переменная не меняется.

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

                                                                                      Это не константы типа #define TRUE FALSE; это иммутабельная переменная

                                                                                        –1
                                                                                        это делает одно и то же ну кроме того что нельзя определить бред как
                                                                                        #define TRUE FALSE;
                                                                                          0

                                                                                          Не одно и тоже. "си-образные константы" не создают переменной, они разрешаются в компайл-тайме. const в js/ts создаёт переменную!

                                                                                            –2
                                                                                            const в js/ts создаёт переменную!
                                                                                            при должной оптимизации тоже разрешался бы в компайл/интерпрет тайме, что я писал выше. Собственно я неправильно думал что js/ts делает это с const потому что там уж точно написано что переменная не меняется, переоценил интерпретатор. Более того, так замещаться может также изменение переменной вида
                                                                                            a = 10…
                                                                                            a = 20 создаст 2 константы, известные в компайл тайме.
                                                                                              –1
                                                                                              всё, начинаю вести список дурных минусований коментов, не только моих а вообще, и потом выложу. Уже на такой пост ставить минус это вообще
                                                                                                +1

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

                                                                                                  –1
                                                                                                  это тогда не иммутабельная переменная раз зависит от рантайма.
                                                                                                  У меня выше
                                                                                                  Так становится нельзя делать уже например при
                                                                                                  a = input() или a = rand() и другое что неизвестно при компиляции.
                                                                                                    +1
                                                                                                    это тогда не иммутабельная переменная раз зависит от рантайма

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

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

                                                                                          Ну вот:


                                                                                          function yoba(x, y) {
                                                                                              const z = x + y;
                                                                                              return f (z);
                                                                                          }

                                                                                          как и куда мне вынести z?

                                                                                        +1
                                                                                        Вам-то какой смысл иметь дополнительное указание, что это выражение, дескать, дальше не изменяется?


                                                                                        Это ещё и «запрет» для вас или кого-то другого на смену значения. То есть если вы решите поменять значение const, то обычно самое позднее при компиляции вам выдадут ошибку.
                                                                                        И тогда вы как минимум задумаетесь почему там стоит const и проверите нужен ли он там.
                                                                              0

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

                                                                                –1
                                                                                так я и о том что его следует малость подкорректировать в некоторых аспектах но потом он станет языком пригодным для любой задачи програмирования и определения структур данных типа XML CSS. Ненадо городить 100 инструментов, когда можно иметь один.
                                                                              0

                                                                              Полноте, в яваскрипте не меньше странностей, причем более серьезных. Например, неявное приведение типов. Или 2 типа undefined и null. Или параметры по умолчанию, которые вычисляются каждый раз при вызове и зависят от контекста. Или странный метод join у массива, который почему-то возвращает строку, хотя массив никакого понятия о строке и ее создании не должен иметь (в том же питоне это метод у строки, принимающий любой итератор, а не только массив). Все эти странности при сравнении переменных разных типов. В общем, то ещё веселье.
                                                                              У меня кстати как раз обратный опыт. После питона яваскрипт кажется очень многословным, избыточным, такие вещи, как проверка вхождения значения в итерируемый объект в каждом случае требует вызова разных методов в зависимости от объекта. В общем, после питона все это выглядит как-то топорно и сложно.

                                                                                –2

                                                                                Вот именно так и получается, меняем шило на мыло, один набор странностей на другие.


                                                                                Хотелось бы нормальный удобный язык, но это, видимо, из области фантастики

                                                                                  –2
                                                                                  ну хуже всего в JS это гении софтваре-дизайна которые умудряются городить вырвиглаз. Тогда нормальный удобный язык должен не давать програмисту делать странные вещи такие как обьявление функции внутри функции, или постоянно какие то обработки рутинных вещей типа исключений или интеракции, что давно должно быть вынесено в модуль утилит.
                                                                                    +2

                                                                                    А чего это локальная функция стала чем-то странным? Их вовсе не в JS впервые придумали...

                                                                        +13
                                                                        Если вы не понимаете волшебные инструменты, всё ужасно запутанно

                                                                        Есть иной вариант: вы понимаете эти волшебные инструменты. Но вы до веб-разработки писали под десктоп, и вы знаете, что да, всё действительно ужасно запутанно и неудобно. И нифига они не волшебные :(
                                                                          0
                                                                          Под десктоп тоже всё неудобно, если это конечно не Windows-only десктоп.
                                                                            0
                                                                            Да и там было все не так чтобы сахарно:
                                                                            TranslateMessage(&msg);
                                                                            DispatchMessage(&msg);
                                                                            

                                                                            Но работало зато быстро.
                                                                              0

                                                                              Предположим, вы правы. Это как-то опровергает тезис предыдущего комментатора?

                                                                                +2

                                                                                Очень все удобно, если какое-нибудь Qt взять.

                                                                              0
                                                                              волшебные инструменты (babel! бандлеры! вотчеры! и так далее!)

                                                                              Да уж, прям верх магичности.

                                                                                0
                                                                                Есть еще страшные слова — react angular vue
                                                                                +3

                                                                                5 копеек по поводу сложности и ES vs JavaScript. Вся проблема вот этой сложности в том, что стандарт ES браузерные вендоры имплементируют не целиком, а по частям. Из-за этого вся е**я с проверками наличия функций и API и транспиляцией. В угоду того, чтобы сайт открылся любой ценой.


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


                                                                                Было бы идеально при разработке указывать версию ES, на которой ты работаешь и браузер бы это понимал и запускал соответствующую версию интерпретатора.


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


                                                                                Но, сожалению, версии стандарта не корректируют с версиями CSS и уж подавно с реализациями WebAPi, у которых вообще нет версий.

                                                                                  0
                                                                                  Было бы идеально при разработке указывать версию ES, на которой ты работаешь и браузер бы это понимал и запускал соответствующую версию интерпретатора.

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

                                                                                    +1

                                                                                    Бизнес такую идею не оценит :)

                                                                                      +1

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

                                                                                        +1
                                                                                        Так это только из-за попытки усидеть на двух стульях. На одном — требования бизнеса, чтоб юзер даже с калькулятора мог зайти на сайт, а на втором — удобство разработки и поддержки. Плата за оба стула — использование всяких бабелов, вотчеров и гиговых папок модулей ноды, высокий порог вхождения новичков в рабочий процесс и отсутствие необходимости понимать, как работает каждый винтик в этом чудном механизме.
                                                                                        И как вишенка на торте — теперь уже нельзя просто открыть исходник JS, там сам чёрт ногу сломит. Абстракция на абстракции и абстракцией погоняет. А все эти новые техники по типу ангуляра и вью вообще ломают привычный jQuery — подход.
                                                                                        Нет, я не буду утверждать, что стало хуже. Но вся грусть-печаль в том, что сложно (да и не надо уже) в этом зоопарке знать и понимать, как работает твоё приложение.
                                                                                        Достаточно понимать, как добиться требуемого результата, пользуясь новыми удобными конструкциями языка, а об остальном голова будет болеть у инструментов.
                                                                                          0

                                                                                          18 лет назад Дуглас Крокфорд опубликовал JSMin – первый минификатор Javascript. С тех пор понятие "сборка Javascript" стало нормой для мало-мальски больших проектов. Разработчикам нужен отформатированный читаемый код, а пользователям – наиболее компактный. Довольно странно, что столько лет спустя есть еще люди, которых это удивляет.

                                                                                            +1
                                                                                            Вы правы за исключением одного — пользователям не нужен никакой код. Им нужен рабочий, быстрый и не глючный сервис. А минификация преследует другие цели — скрыть/обфусцировать исходник или ускорить загрузку. В случае, если бы сжатие не влияло на скорость загрузки, ценность для пользователя стремится к нулю. Для разработчика в обоих подходах есть свои положительные и отрицательные стороны.
                                                                                            Например, в случае сборщика, требуется подгрузить и обновить все зависимости. Некоторые из которых могут сильно устареть и попросту не собраться. И тогда начинается самое интересное. И это не только в JS.
                                                                                            Подход к разработке через сборщик сейчас настолько популярен, что есть люди, которых удивляет желание контролировать все этапы разработки лично и хранить статические библиотеки необходимых версий вместо поручения этого сборщику с указанием нужных версий и зависимостей.
                                                                                            0
                                                                                            Может для кого-то ангуляр и вью «новые техники», потому что эти люди начинали с базиса js, а базис — это лапша на jQuery. Любой человек, который занимался даже 10 лет назад десктопными UI или например геймдевом, найдет лишь привычные, нормальные паттерны программирования, слегка допиленные до ума в плане реактивности/декларативности и с поправкой на особенности исполнения в браузере. Более того, эти нормальные паттерны (MVVM например, реактивность) и особенности среды исполнения (event loop aka render loop) не были чем-то магическим и от джунов ожидалось их понимания в кратчайшие сроки. Я сам писал декларативные UI на C# со state management + реактивностью аля mobx X лет назад задолго до того, как занялся веб-разработкой, поэтому сентименты в духе «вот раньше то хеллоуворды простые были, на один codepen влезали!» мне непонятны. Раньше и вебприложений с непростым UI и максимальной приближенностью к native по отзывчивости и usability не писали, генерили разметку на веб-сервере и обвешивали jQuery плагинами. Про CSS вообще молчу, то как его писали «раньше» — это стыд и позор и за такое вообще деньги нельзя брать.

                                                                                              0
                                                                                              Как будто веб-разработчики десять лет назад ничего не знали о паттернах вроде того же МVVM. Но знать это одно, а иметь возможность нормально использовать это совсем другое :)
                                                                                                –1
                                                                                                Дык нет возможности «нормально использовать» — в этом-то и беда.
                                                                                                  +1

                                                                                                  Ну не знаю, на мой взгляд современные веб фронтенд-фреймворки вполне себе умеют MVVM.
                                                                                                  А если сравнивать с тем что мы имели 10-15 лет назад, то просто небо и земля;)

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

                                                                                                    Я уже предлагал пролистать какой-нибудь Web-комикс на пару лет назад тут (MVVM, React и куча всего вкусного и можного) и тут (тупо по старинке, технологии 10-летней давности).

                                                                                                    Потому что MVVM и прочие акронимы — это прекрасно, а вот конечный результат, зачастую — ужасен.
                                                                                                      0

                                                                                                      Если какую-то технологию кто-то не умеет правильно применять, то это на мой взгляд не является виной или проблемой технологии ;)

                                                                                                        0
                                                                                                        Если кто-то один не может использовать какую-то технологию — то это вина тех, кто её использует.

                                                                                                        Если подавляющее большинство этого не могут сделать — то это уже вина технологии.

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

                                                                                                        Если вы видели — покажите, у меня есть образ PCemu с [вирутальным] процессором 300MHz, можно будет посмотреть на отзывчивость.
                                                                                                          0

                                                                                                          А давайте зайдём с другой стороны и вы мне просто покажете сайты с функциональностью а ля amazon, facebook, web.de или хабр, но написанных на "старых технологиях" и не тормозящих/жрущих ресурсы :)

                                                                                                            +2
                                                                                                            Ой, а можно я покажу?
                                                                                                            facebook 10 лет назад, хабр 10 лет назад, вконтактик 10 лет назад и т.д…
                                                                                                            У меня все эти сайты прекрасно работали 10 лет назад на машине с 2Гб ОЗУ, браузер отжирал примерно 20% от того, что отжирает сейчас. На Хабре с тех пор появилась боковая панелька со стрелочками перехода к непросмотренным комментариям, ну и он несколько «мобильней» стал. В FB дизайн подрихтовали, ещё там мессенджер какой-то добавился, и картинки стало большего размера пихать. Что, стоят эти 5% функционала в пять раз большего потребления ресурсов? ;)
                                                                                                              +1

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


                                                                                                              Ну а во вторых за последние 10 лет добавилось всё таки больше чем "5% функционала". Одни только мобильные версии многого стоят.
                                                                                                              И кстати кроме функционала для пользователей добавилась ещё и куча функционала для владельцев.


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

                                                                                                                +1
                                                                                                                Вот только давайте вспомним что во первых 10 лет назад точно так же было достаточно людей, называющих эти странички «тормозящими и жрущими ресурсы»:)
                                                                                                                И что интересно — они тогда тоже были правы.

                                                                                                                Одни только мобильные версии многого стоят.
                                                                                                                А чего они стоят? У всех перечисленных сайтов есть приложения — зачем при их наличии ещё и web-сайт уродовать?

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

                                                                                                                П. С. Ну и «раньше» оно всегда всё было лучше :) Это по моему закон человеческой психики :)
                                                                                                                В данном случае, спасибо Archive.org, мы можем сравнить напрямую. Хабр 10 лет назад: 300 килобайт человеческого JavaScript'а, без всякой обфускации. Хабр сегодня: 900 килобайт обфусцированного… добра. Потребляемые ресурсы увеличились примерно на порядок… что мы получили за это?
                                                                                                                Давайте сравним
                                                                                                                — Адапативная вёрстка стала менее адаптивной
                                                                                                                — Облако тегов пропало
                                                                                                                — Найти популярные блоги стало сложнее
                                                                                                                + Хотя популярность вычисляется теперь за сутки/неделю/месяц

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

                                                                                                                  Тогда я всё ещё жду примеры «правильных страниц»:)

                                                                                                                  А чего они стоят? У всех перечисленных сайтов есть приложения — зачем при их наличии ещё и web-сайт уродовать?

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

                                                                                                                  Не знаю что там с владельцами, но для пользователей всё только хуже стало.

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

                                                                                                                    Но если хотите пример… пожалуйтста: LWN 10 лет назад — 400 килобайт. LWN сегодня — 160 килобайт.

                                                                                                                    Конечно и то и другое, так-то, для 15-20 килобайт текста многовато… но Web-платформа дурная… хорошо сделать сложно. Уже то, что наблюдается прогресс, идущий в правильном направлении — само по себе неплохо.

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

                                                                                                                    Серьёзно? Времени нет? Притом что сайт больше 10 лет существует? Ну дык его и не будет никогда если вместо одной, нормально сделанной вещи, порождать 100500 кучек дерьма…

                                                                                                                    Субъективное мнение, которого придерживаются далеко не все пользователи.
                                                                                                                    Это всё достаточно объективно и измеряется. Вот как раз «стильно и молодёжно» — это измерить сложнее. Но реклама творит чудеса, только вот взамен — требует порождать дерьмо во всё больших количествах.
                                                                                                                      +2
                                                                                                                      Вы меня конечно извините, но измерять качество веб страницы исключительно через её размер это маразм.

                                                                                                                      И лично мне на сегодняшний день абсолютно наплевать грузит страничка 300кб или 600кб или даже 900кб. Всё равно при современных скоростях и девайсах лично я не замечу разницы.

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

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

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

                                                                                                                        И чтобы у неё было куча разных удобных для меня «свистелок и перделок».
                                                                                                                        Ну и какие конкретно «свистелки и перделки» на Хабре оправдывают 5-10 кратное уверличение в требованиях к системе и что конкретно вам не нравилось в Хабре десятилетней давности?

                                                                                                                        На LWN, кстати, кой-какие фичи за прошедшие 10 тоже появились. И некоторые — мне вполне себе интересны. Но при этом они не требуют увеличения потребления ресурсов в 10 раз. Удивительно, правда?

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

                                                                                                                        Но вот только наушники с дерьмовым звуком «хорошими» никто не называет, как бы они ни походили на Airpods (хотя спрос есть, то есть «пипл хавает»), а в случае с вебсайтами — всё совсем не так. Почему, собственно?
                                                                                                                          +3
                                                                                                                          А я — замечу.

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

                                                                                                                          Есть ещё потребляемая памяти и скорость реакции

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

                                                                                                                          Ну и какие конкретно «свистелки и перделки» на Хабре оправдывают 5-10 кратное уверличение в требованиях к системе и что конкретно вам не нравилось в Хабре десятилетней давности?

                                                                                                                          Например мобильная версия, новaя лента, хабы, новый редактор, трекер…
                                                                                                                          И самое главное лично я никаких ограничений или повышенных требований к системе не заметил. Даже если они были.

                                                                                                                          Почему, собственно?

                                                                                                                          Потому что наушники с дерьмовым дизайном и удобством использования хорошими тоже никто не назовёт. Вне зависимости от того какой хороший у них звук.
                                                                                                                          Об этом и речь: «хороший» в данном контексте это понятие субъективное. И похоже ваше понимание «хорошего» в случае со страничками сильно отличается от понимания большинства и акцентируется на абсолютно других критериях.
                                                                                                                    +2
                                                                                                                    У всех перечисленных сайтов есть приложения — зачем при их наличии ещё и web-сайт уродовать?

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

                                                                                                  0
                                                                                                  Раньше и вебприложений с непростым UI и максимальной приближенностью к native по отзывчивости и usability не писали
                                                                                                  А сейчас пишут разве? Почти любое web-приложение засунутое в нативное (популярный в последнее время подход) легко опознать по «дёрганью» (если тормоза при запуске не выдали). Потому что в таких «ультрапродвинутых» средах, как MacOS System 1 (1984й год) и Windows 1.0 (1985й год) была возможность «заморозить» изображение, изменить состояние контролов и атомарно это изменение вывести на экран. А Web-технологии — до этого не доросли. Максимум, что они могут предложить — не показывать изменения элементов, которые возникают, когда вы меняете DOM и CSS. Все рассчёты — всё равно просходят после каждого изменения чего угодно, а если не думать очень внимательно над тем, что и где происходит (а это очень сложно сделать, если у вас программа подтягивает сотни компонент, которые неизвестно что и где делают) — то это всё, в итоге, вываливается на экран.

                                                                                                  И да, разработчики Chrome и Firefox очень стараются всё это скрыть и ускорить, сделать в ленивом режиме… но результат, в любом случае — это дикое потребление ресурсов и весьма паршивая отзывчивость.

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

                                                                                                  Вообще не могу сказать, что Web совсем не стоит на месте. Но просто все «новейшие» достижения типа Shadow DOM (ура-ура, ещё полгода и мы получим то, что в MacOS/Windows было лет 30 назад) — вызывают скорее улыбку и недоумение.

                                                                                                  Напоминает фантастические романы, где люди, уже тысячи лет летающие на звездолётах забыли математику от слова «совсем» и теперь с удивлением «открывают для себя» дистрибутивность и ассоциативность… вот то же самое и здесь. Скоро и до известного прикола таким образом доберёмся.
                                                                                                    –1
                                                                                                    ура-ура, ещё полгода и мы получим то, что в MacOS/Windows было лет 30 назад

                                                                                                    Тут вопрос возникает, насколько корректно сравнивать ОС с приложением просмотра гипертекстовых страниц :) При том, что никто в здравом умер наверное не ожидает, что приложения MacOS System 1 и Windows 1.0 можно запустить на современных версиях без костылей, а вот нормального показа http://info.cern.ch/hypertext/WWW/TheProject.html ожидают...

                                                                                                      +1
                                                                                                      Тут вопрос возникает, насколько корректно сравнивать ОС с приложением просмотра гипертекстовых страниц :)

                                                                                                      С тех пор, как приложение для просмотра гипертекстовых страниц стало использоваться как среда для выполнения приложений, это стало совершенно корректно :)
                                                                                                      а вот нормального показа info.cern.ch/hypertext/WWW/TheProject.html ожидают...

                                                                                                      Раз на раз не приходится. Технологий, которые объявлены Legacy и убраны из современных браузеров, тоже не счесть.
                                                                                          0
                                                                                          Было бы идеально при разработке указывать версию ES, на которой ты работаешь и браузер бы это понимал и запускал соответствующую версию интерпретатора.
                                                                                          С обратной совместимостью все хорошо, современный V8 или SpiderMonkey код древнем варианте JS переварит без проблем, а вот в обратную сторону как раз проблема: где браузер возьмёт «соответствующую версию интерпретатора», если к моменту релиза браузера версии интерпретатора с поддержкой нужной фичи ещё не существовало, а обновлять браузер пользователь не хочет, или политики админов не позволяют. Поэтому и городчт всякие бабели, иначе останется только вариант ставить пользователя перед выбором — либо он обновляет браузер до актуальной версии, либо не может смотреть сайт вообще.
                                                                                            0
                                                                                            где браузер возьмёт «соответствующую версию интерпретатора», если к моменту релиза браузера версии интерпретатора с поддержкой нужной фичи

                                                                                            Это проблема, согласен, но как-то все справляются с этим на бекенде. Есть же разныеверсии ОС, десктопные и мобильные. Софт делают не универсальным, а под каждую платформу и/или версию.

                                                                                              +4
                                                                                              Это проблема, согласен, но как-то все справляются с этим на бекенде.
                                                                                              Открою страшную тайну: на бекенде с этим справляются… за счёт наличия фронтенда.

                                                                                              В XX веке, когда фронтенда не было поддержка старых версий MacOS, Windows и так далее — была тем ещё цирком…
                                                                                                0

                                                                                                Ерунда это все. Просто в требования очередной версии софта писалось: Windows XX, DirectX YY. И дальше проблемы индейцев разработчика не волнуют. Вот бы сейчас в зависимости от версии браузера показывать соответствующую версию страницы с соответствующей функциональностью.

                                                                                                  +1
                                                                                                  Просто в требования очередной версии софта писалось: Windows XX, DirectX YY.
                                                                                                  Ну может у кого-то и писалось. А я наблюдал код, который должен был работать на всём, начиная от NT 4.0 и заканчивая Windows 7… там было несколько тысяч строк на какие-то совсем банальные вещи.
                                                                                                    0

                                                                                                    Что же, и такое видимо бывает. Но гораздо чаще приходилось видеть две версии одного софта под 32- и 64- (а до этого еще и 16-) разрядные варианты одной и той же версии ОС/окружения.

                                                                                              0

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

                                                                                            +2
                                                                                            Проблема не в бабеле и не в js. А в том что современные инструменты разработки не позволяют писать код не вникая в то как оно работает на клиенте.
                                                                                            Никто(возможно почти никто) не вникает в то как работает его C# или Java код после компиляции.
                                                                                            Когда пропадет надобность разбираться в babel, webpack и всём этом мракобесии. Когда написание веб кода превратится именно в программирование с компиляцией за 1 клик(сейчас это так и есть, но после кучи настрое), тогда и уйдет вся сложность.
                                                                                              0
                                                                                              Никто(возможно почти никто) не вникает в то как работает его C# или Java код после компиляции.

                                                                                              Мм, это позволительно только юниор, имхо. Не вникать, как работает исполняемый код — плохая история.


                                                                                              Тут проблема немного шире


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

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


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

                                                                                              +2

                                                                                              Автор не осилил Википедию поправить, как он с такой сложной веб-разработкой справляется?

                                                                                                0
                                                                                                Все на Flutter, товарищи! Долой узы проклятого js-изма, css-изма, фреймворк-зоопаркизма!
                                                                                                  +1
                                                                                                  Причем тут Flutter? Он в основном для мобильной разработки. Там есть ответвление для браузера, но оно до релиза не дошло еще.
                                                                                                  Все на Flutter, товарищи!

                                                                                                  Другими словами, переходите на Dart! Не скажу, что это лучшее решение
                                                                                                    0
                                                                                                    Чего далеко? Можно переползти и забить не только на Web-zoo-hell но и автоматом порешать для десктопов, мобайлов и серверов (Node тоже идет лесом по всем параметрам). Dart не Nim и Kotlin конечно но с сравнении с шарпами/жавами культями гребет бодро.
                                                                                                      0
                                                                                                      >Другими словами, переходите на Dart! Не скажу, что это лучшее решение
                                                                                                      Почему? Язык на порядок адекватнее и JS и Python.
                                                                                                        0
                                                                                                        Вот-вот. Не только адекватнее но и универсальней по применимости несравнимо! А если народ начнет пинать гугел сильнее, то через 2-3-10 лет будет даже симпотишный.
                                                                                                    +7

                                                                                                    Некорректен сам тезис статьи.


                                                                                                    Именно разработка фронтенда упростилась в разы. Мы получили абстракции и готовые решения над всеми основными болями фронтенда за последние несколько лет: сеть, синхронизация состония и представления, управление состоянием, инкапсуляция стилей, асинхронность, модульность и так далее. Только посмотрите как далеко ушли инструменты разработки в браузере! С точки зрения Developer Experience фронтенд развился очень сильно: от alert() и console.log до дебагера который умеет отлаживать асинхронные вызовы сохраняя весь стек. От script.js со всеми скриптами в одной куче до асинхронной подгрузки модулей по мере надобности. Современному фронтендеру нужно держать минимум информации в голове при разработке, за него это уже всё делают автоматизированные системы (линтеры, тесты, сборка, CI) и инкапсуляция. С этой точки зрения разработка стала даже проще.


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


                                                                                                    Выше правильно отметили об избытке инструментов в современном фронтенде, даже был в своё время такой термин как Javascript Fatigue. Но этот период уже скорее прошёл, среди всех инструментов появились явные лидеры и выбирать приходится не из 10-25 вариантов, а из 3-4. При этом у вас всегда есть возможность попробовать что-то новое, даже если не на проекте, то для личного развития.


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


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


                                                                                                    А вот из действительно больших нерешённых болей фронтенда я бы отметил кроссбраузерность. И это не про поддержку фичей, а про поведение браузеров. До сих пор в 2019 году вам придётся городить велосипеды для исправления поведения браузеров. Может показаться что со смертью IE и Edge эта проблема решилась, но на самом деле нет потому что появились различные мобильные браузеры которые в некоторых аспектах работают совсем иначе чем десктопные. И далеко не факт что под ваш конкретный баг есть готовое решение.

                                                                                                      +1

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

                                                                                                        0
                                                                                                        а почему сразу не webpack а babel? :-( а то теперь мне в отделе самому рассказывать что лучше webpack и зачем
                                                                                                          +3

                                                                                                          А разве это альтернативы?

                                                                                                            0

                                                                                                            Мне кажется, вы путаете теплое с мягким

                                                                                                              0

                                                                                                              Популярные сетапы webpack используют транспиляцию babel'ем как один из этапов "упаковки".

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

                                                                                                              Про память вообще никто не думает (а зачем, это же JS). От сюда одностраничники жрущие гигабайты памяти!
                                                                                                                0
                                                                                                                Не «Зачем усложнили», а «Почему усложнили». А ответ — технический прогресс.
                                                                                                                  0
                                                                                                                  Полезная статья, можно, например, коллегам бекендерам скинуть у которых бомбит из-за непонимания того, что происходит на фронте.

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

                                                                                                                  Но чаще всего, конечно да, если проект не однодневный и будет расти экспоненциально, то тут уж нужно пилить какой-то boilerplate с webpack'ами и с JS фреймворками, чтобы кодовая база росла, а сложность — нет.
                                                                                                                    0
                                                                                                                    Тут уже многие отметились в том, в чем, по их мнению, проблема веба. Не могу не вставить свое ИМХО:

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

                                                                                                                    2. Сегментиция. В вебе решаются ОЧЕНЬ разные задачи. Кому-то нужно отобразить простой html-документ, а кому-то сделать сложное интерактивное приложение. А кому-то нужно сделать нечто среднее. В каждом случае, нужны свои подходы и архитектурные решения.

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

                                                                                                                    4. Безопасность. Многие, рассуждая о веб-технологиях, заводят старую шарманку, про то, какой JavaScript плохой и непродуманный язык, и вообще сайты нужно писать на условных «плюсах» со строгой типизацией и жестким ручным контролем памяти. Подумайте о том, что веб — это открытая среда, и в ней водится очень разная «рыба». Вы хотите, чтобы на вашей машине исполнялся чей-то «замечательный» скомпилированный высокопроизводительный код, написанный неизвестно кем и с какой целью? Браузер — это песочница, и определенная доля компромиссов с производительностью — плата за свободу в вебе. JavaScript — мощный и выразительный язык, и его дизайн — прямое следствие его главного назначения. (WASM — совсем не панацея, как некоторым кажется).

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

                                                                                                                      Браузер — это песочница, и определенная доля компромиссов с производительностью — плата за свободу в вебе.
                                                                                                                      Очень малая. C++ что в PNaCl, что в WebAssembly — всё равно гораздо эффективнее JS. При полном контроле.

                                                                                                                      JS — это «первородный грех» Web'а. Задуманный как «дерьмо собачье» (вот прямо из первых рук: “I was under marketing orders to make it look like Java but not make it too big for its britches. It’s just this sort of silly little brother language, right? The sidekick to Java.”) он, даже после десятилетий полировки, всё равно остаётся довольно-таки… эксцентричным языком.

                                                                                                                      Ну вот как в C++ есть «первородные грехи» (в частности тот факт, что есть как нормальный std::array, так и «полутип» — «обычный» массив), так и в JS они есть.

                                                                                                                      Браузер — это песочница, и определенная доля компромиссов с производительностью — плата за свободу в вебе.
                                                                                                                      Doker — это тоже песочница… и никаких ограничений на языки она не накладывает. И Linux приложения на ChromeOS — тоже в песочнице живут и ради этого никто не переходит на прототипное наследование. Странно, да?

                                                                                                                      JavaScript — мощный и выразительный язык, и его дизайн — прямое следствие его главного назначения.
                                                                                                                      Вот же ж блин. Все слова правда — а смысл… ровно на 180%. Действительно его дизайн — рождён из основной идеи: не быть хорошим языком. Как, собственно, его автор совершенно честно и признал. При этом JS сегодня — это действительно мощный и выразительный язык… ну потому что фирма, которая «заказывала» этот язык давно исчезла и сегодня эту «свинью» обмазали буквально тоннами помады. Но это не делает его хорошим. Он по-прежнему плох, просто так получилось, что в определённых областях — он безальтернативен…
                                                                                                                        +1
                                                                                                                        Блин, вы серьезно не видите разницы между виртуализацией/контейнеризацией, при которой вы сами решаете что именно пускать в песочницу и «окном в мир» в которое легко можно увидеть условную «жопу», независимо от вашего на то желания?

                                                                                                                        всё равно гораздо эффективнее JS

                                                                                                                        Это в каком месте оно эффективнее? В воронке производительности, узким местом является работа внутренних механизмов браузера, при работе с ними через API. Открою Вам секрет: там все очень сложно, куча комбинаторики, и написано оно вовсе не на JS.
                                                                                                                          0
                                                                                                                          Открою Вам секрет: там все очень сложно, куча комбинаторики, и написано оно вовсе не на JS.
                                                                                                                          Спасибо, я в курсе. Люди, которые этим занимаются сидят через коридор от меня. Вы только к кучке эпитетов забыли добавить ещё один. Важный: там сложно, куча комбинаторики, а главное — всё это не нужно. Вернее — не нужно было бы в идеальном мире, где фронтэнд можно было бы разрабатывать не только на HTML+JS.

                                                                                                                          Это в каком месте оно эффективнее?
                                                                                                                          Во всех, которые имеет смысл сравнивать: скорость работы, отзывчивость, потребление памяти. Любое приложение на QT или FLTK требует в разы меньше ресурсов, чем типичный высер на HTML+JS. Даже какой-нибудь YouTube.apk требует на порядок меньше ресурсов и работает гораздо плавнее, чем YouTube.com в браузере. И так далее.

                                                                                                                          И не надо рассказывать про безопасность — с этим всё тоже в порядке. Единственное, в чём вы проигрываете — это в возможности использования «условных дешёвых индусов». Ну и в кроссплатформенности — но тут есть другие подходы.
                                                                                                                            0
                                                                                                                            Вернее — не нужно было бы в идеальном мире, где фронтэнд можно было бы разрабатывать не только на HTML+JS.

                                                                                                                            Пожалуйста — native apps.

                                                                                                                              0
                                                                                                                              Вернее — не нужно было бы в идеальном мире, где фронтэнд можно было бы разрабатывать не только на HTML+JS.

                                                                                                                              Так браузеры и пишутся не на js/html. С-но, тот код, который по факту тормозит — это не js. Это та условная сишка, на которой написан дом и рендер. Потому что за редким исключением 90% времени тормозящее приложение апдейтит дом и рендерит его. А уже остальные 10% исполняется клиентский js.
                                                                                                                              И основная часть оптимизаций для страниц сводится к тому, чтобы пооптимальнее дергать дом-апи и эффективнее использовать рендер.


                                                                                                                              Любое приложение на QT или FLTK требует в разы меньше ресурсов, чем типичный высер на HTML+JS.

                                                                                                                              Еще раз — браузеры пишутся не на js+html. И те ресурсы, что жрет страница — жрет не код страницы. Жрет код браузера.
                                                                                                                              Почему он такой тормозной и требует такого количества ресурсов (несмотря на то, что на условной сишке) — ну это сами можете ответить.

                                                                                                                                +2

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

                                                                                                                                  +1
                                                                                                                                  Почему он такой тормозной и требует такого количества ресурсов (несмотря на то, что на условной сишке) — ну это сами можете ответить.
                                                                                                                                  Легко: потому что вместо примитивов «провести линию из точки с координатами X₁Y₁ в точку X₂Y₂» какой-то архитектурный астронавт ему навязал DOM-деревья с CSS-свойствами, которые в принципе не реализуемы ни на какой архитектуре эффективно, а также черезвычайно неэффективный язык, который далёк как от того, что думают программисты, так и от железа.

                                                                                                                                  Добавлением 100500 уровней абстракции эту проблему не решить.

                                                                                                                                  Ну не думаете же вы, что ответ в том, что горстка программистов, разрабатывающих FLTK умнее, чем десятки тысячи разработчиков браузеров и фреймворков на JS?
                                                                                                                                    +1
                                                                                                                                    провести линию из точки с координатами X₁Y₁ в точку X₂Y₂

                                                                                                                                    Так это вполне доступно на canvas, и в SVG (там тоже DOM, но более быстрый). А теперь попробуйте нарисовать «примитивами» простенькую табличку и заполнить ее ячейки текстом произвольной длины.