Кто похоронит современный веб?

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



    Правильное начало


    Когда вы создаете веб-страницу, компонент, или пишете API, вы так или иначе сталкиваетесь с решениями заложенными 25 лет назад. То, что казалось логичным и правильным в дни создания первых графических броузеров, до сих пор аукается нам каждый день. Врядли у создателя Javascript была в голове концепция создания чего-то похожего на современные веб-приложения. Мобильных устройств, создающих сегодня большую часть интернет трафика, тогда не было и в помине. CSS рассматривался как способ стилизации документа, а не как тьюринг-полный язык для создания презентаций. И т.п.


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


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



    Больше чем один веб


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


    • текстовые сайты типа блогов и википедии
    • CRM/ERP приложения
    • мультимедийные приложения
    • игры
    • коммуникационные приложения
    • шЫкарные продающие лэндинги
    • социальные сети

    Каждая из упомянутых категорий приложений требует от веб-платформы свой набор API. Но каждый такой набор упирается в ограничения другой категории. У лэндингов огромные требования к CSS, которые почти нигде больше не нужны. Для текстовых сайтов 90% спецификации веба излишни. API для мультимедийных приложений недостаточен для игр и коммуникационных программ. CRM/ERP и социальные сети требуют более мощных языков программирования, способов организации кода, которые не по карману, да и не нужны текстовым сайтам и лэндингам. И т.д.


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


    Имея низкоуровневое API можно будет значительную часть платформы засунуть в библиотеки. Да, это трафик. Но мы и так уже пришли к CDN с кэшированием(Press Ctrl+f5 to fix). Набор распространенных и нечасто обновляющих библиотек(там ведь должны быть базовые вещи) принципиально не ухудшит ситуацию. Более того, на фронтенде и так уже привыкли, что много где можно писать только с полифиллами. И те же минорные версии библиотек можно будет накатывать в виде полифиллов, не заставляя пользователя качать все, если только у него не совсем древняя версия.


    Нужно спросить себя, а нужен ли в принципе DOM, как центральная структура документа? Может быть достаточно применять его только для некоторых виджетов на странице? А нужна ли сама концепция документа, как центра всего? Нужны ли все трансформации CSS в том виде в каком они есть? Нам точно нужен евент-луп в том виде в каком он есть?


    И самое главное — нужна ли нам одна платформа для сайтов и веб приложений? Или нужно смириться, что с современными требованиями мы все равно придем к среде выполнения приложений типа JVM? Но только в одном случае получим ее с тоннами legacy и костылей, а в другом — с чистого листа.



    По ту сторону иконки «Интернет»


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


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


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



    Монополия


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


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


    Ведь даже самому гуглу может оказаться в перспективе дешевле поддерживать броузер нового типа. Часть платформы можно будет спихнуть на сообщество, которое будет пилить библиотеки. А сама работа станет проще, потому что движок будет не таким монструозным by design.


    Будет ли такое решение от монополистов обязательно лучше? Думаю да. Почти в каждой дискуссии посвященной проблемам веба можно найти людей, которые раньше писали приложения на Delphi/QT/WPF/WinForms и т.п. При этом они были глубоко несчастны, и только переход на веб-стэк открыл им способ безболезненного создания GUI приложений. Возможно это и так. Но есть и мнение, что написание приложений для современного веба — это удаление гланд через задницу, причем операция затянулась минимум на 10 лет.


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


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



    Возраст дожития


    Конечно, неприятно хоронить свой опыт по работе с имеющейся платформой. Но количество легаси хватит минимум лет на 10, даже если прямо завтра гугл разродится новым решением, а послезавтра App Browser будет стоять на 100% компьютеров в мире. Тем более, что будучи спроектированной с нуля, платформа(возможно) не заставит вас учить несколько форматов модулей или способов отцентрировать элемент по вертикали. И вы сможете применить свой прошлый опыт программирования, а не вызубривать исторически сложившиеся костыли. Хотя бы первые несколько лет.


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



    Экономия на чем?


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


    Если попытаться с нуля сделать нормальный движок того же веб-магазина, то выяснится, что это ни разу не просто. Да, я знаю, что многие тут сидящие делали это. Но насколько вы оцениваете безопасность своего решения? Вы точно можете по памяти перечислить все типы атак, которым может быть подвержено веб-приложение? Проверяли ли как ваш магазин будет выглядеть на разных экранах, начиная от 4-дюймового смартфона-заглушки и кончая здоровыми десткопными мониторами? Рассчитывали на работу в устаревших броузерах и без JS? Хотя бы за пределелами Firefox и Chromium-based броузеров.


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



    Заключение


    Современный веб это чистейшее легаси живущее по принципу «так исторически сложилось». Технология умирающая под своей тяжестью, для работы с которой только одна компания в мире может поддерживать 100% работающий инструмент. И тем не менее критика веба воспринимается многими как святотатство. Мы привыкли к DOM настолько, что уже просто не мыслим другими категориями. Хотя тут же берем и строим интерфейс опираясь на веб-компоненты. И не думая при том, что коль мы все равно оперируем абстракциями, то почему бы не поменять их реализацию на более эффективную? Тем более, что сейчас, в связи с наличием на рынке интернет сервисов крупных монополистов, создание новой платформы более чем реально.

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +4
      И самое главное — нужна ли нам одна платформа для сайтов и веб приложений?
      Да, нужна. Потому что разделения на «классы приложений» на самом деле нет. И как вы это себе представляете со стороны пользователя, отдельный браузер под каждый класс приложений?
        +1
        Со стороны пользователей я наблюдаю повальный рост популярности мобильных приложений для популярных сайтов, так что идея в принципе жизнеспособна.
          +20
          Со стороны пользователей я не наблюдаю «мобильных приложений вместо популярных сайтов», за небольшим списком исключений.
          Не забывайте, вы собираетесь похоронить веб, а не сделать к нему пристроечку сбоку.

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

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


            И не должно было. Нативные приложения и раньше веб ортогональны. Веб был в первую очередь источником информации и средством коммуникации, с кастомными «приложениями»(форумами, чатами) внутри. Т.е. это уже тогда была в каком-то роде среда выполнения, а не просто приложение.
            0
            Но разве что для популярный. Установить приложение всё-таки чуток геморройнее, чем просто зайти на сайт. На телефонах редко бывают установлены сотни приложений, так что это всё-таки более нишевая вещь.
              0
              Десятки — легко. Фейсбук, контакт, беру, озон, тикток, клиент-банк, инстаграмм — достаточно распространенный набор из того что мне попадается на обслуживаемых телефонах. И харкатер трафика поменялся, сейчас мало кто лазает по интернету(кроме дней когда надо писать реферат), в основном пользователи зависают на нескольких основных сайтах, так что приложения оправданы.
                0
                Геморройно только зарегистрироваться в гуглплее/апсторе, и то только для тех, кто с техникой на «вы». Дальше — пара нажатий, со сканером отпечатков или с хлебало-айди даже пароль не спрашивается.
                И искать обычно не приходится — веб сам определяет, что вы на айосе/андроиде, и показывает соответствующий банер со ссылкой в магаз приложений.
                  +1
                  ну всё равно во-первых пара лишних кликов, а во-вторых нужно ещё выработать привычку заходить в приложение. Не сильно сложнее, но это тоже порог.
                  0

                  Когда у вас сайт тормозит и жрет батарейку, а есть приложение, то иногда проще поставить приложение.

                    +1
                    Если это приложение не жрёт батарейку ещё больше, ибо может теперь работать в фоне, а не только когда запущен браузер.
                  +9
                  Когда меня заставляют установить мобильное приложение, вместо возможности дать мне пользоваться сайтом (большим ли, мобильным ли — лично мне без особой разницы, я и на форумах из 2000-ых могу позависать с мобильного), я посылаю этим людям лучи ненависти. К примеру, казалось бы — какого фига мне не дают сделать перевод по номеру телефону с веб-клиента, а требуют приложения?

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

                  Поэтому, когда мне в очередной раз навязывают приложение, я начинаю напевать:
                  «Кто вы? Идите на ???! Я вас не знаю!»

                  Впрочем, для некоторых, особо «одаренных», я напеваю другую версию:
                  «Кто вы? Идите на ???! Я вас знаю!» (и это еще хуже!).
                0

                Современный веб будет жить и здравствовать еще лет 5, а то и 10. Пока технологическая сложность не превысит разумных пределов. Уже сейчас мало знать html+css+js. Все чаще встречается TypeScript, да и react или vue, это уже совсем не то, что придумывали отцы основатели. Думаю дальше будет только хуже. По этой причине, уже существующие технологии будут выжимать по максимуму.

                  +6
                  Никакой связи что-то я не уловил между «мало знать html+css+js» и typescript,ract,vue. Новая либа или фреймворк — это всего лишь вспомогалка, да и огульно говорить, что без этих технологий никуда — это довольно смело. Миром всё равно в итоге правит контент, а способы его «обернуть» — они менятся будут и дальше.
                    0

                    На счет ценности контента я не сомневаюсь. Я о другом.
                    За все время своего существования html, css и js поменялись не особо сильно, особенно если сравнивать с инструментами и технологиями, которые появились рядом с ними.
                    Typescript принес новые возможности, свойственные "настоящим" языкам, но в итоге он все равно транслируется в js. React и vue сделали более удобным переиспользование кода и реактивность, но все это опять приходит к html+css+js.
                    Говорить о смерти современного веба можно будет тогда, когда будут исчерпаны все возможности тройки html+css+js и будет разработано что-то не менее гибкое, и не менее удобное. А пока сети расширяются, ресурсы компьютеров растут и всего этого хватит еще лет на 5 точно.

                  +4
                  Проблема с legacy в web та же что и в windows. Существует огромное количество сайтов, которые написаны и 20 и 30 лет назад и которые до сих пор работают, например сайты разных государственных служб по всему миру. Так же как и для windows существует софт, написанный 20-30 лет назад и всё еще используемый людьми в каких-нибудь научных или государственных структурах. Так что проблема legacy не решится одним махом никогда.

                  Проблема современного web в том, что разработчики привыкли к фреймворкам и пытаются запихнуть их везде где только можно. Классические html/css/js живее всех живых и используются наверное даже на большем числе проектов, чем современные монструозные стеки. В мире веб есть не только приложения и сервисы, есть еще множество проектов, где хватает обычного js без необходимости лепить туда что-то ещё. А js развивается и современные API позволяют написать код на чистом js чище и красивее чем когда-либо.

                  Суть в том, что действительно лучше всего разделить среды для web сайтов и web приложений. А с разделением сред создать и инструменты, элегантные и простые, заточенные именно под разработку web приложений. Было бы круто, если бы эту новую среду вшили в операционные системы, чтобы web приложения работали независимо от клиентского браузера, а не как сейчас вся эта история с PWA. Вот тогда бы остался классический браузер, в котором мы бы и дальше просматривали классические web сайты. А для использования web приложений нам было бы достаточно нажать один клик и приложение заработало бы сразу в OS, как нативное, и не зависело бы от наличия браузера на устройстве.
                    +2
                    Существует огромное количество сайтов, которые написаны и 20 и 30 лет назад
                    С датами преувеличили. Сайты сделанные в 90-х может быть ещё и остались где-то, но уж точно не в огромном количестве.
                      +3

                      Строго говоря, 30 лет назад — в 1990 году — сайтов еще не было, да и первый браузер только появился в декабре. Первый сайт заработал годом позже.

                      +4
                      Так, камни полетели, ну, ладно. Как будто 20 лет для сайта — это много или свидетельствует о какой-то там допотопности :) Ну, например, на моём сайте (http://lingvisto.org) морда и часть страниц остаётся практически одинаковой вот уже более 17 лет! :)) Я вручную тогда в ноутпаде писал. И не знал даже, что такое резиновые дизайны и всё такое. Cмотрится главная страница и сейчас хорошо на всех планшетах, телефонах, мониторах и калькуляторах. Просто обычный хтмл. Но рынок и мода требуют другого, конечно. И якобы технологии 20-летней давности не отвечают современным требованиям… хм, ну, смотря в каком секторе, наверное, но в контентой нише больше ничего и придумывать не надо.
                        –3
                        Cмотрится главная страница и сейчас хорошо
                        В наверное и монитор 17 лет не меняли? На широком мониторе без зума ничего не разобрать. На мобильном нужно скролить горизонтально.
                          +1
                          Это зависит от сайта. У меня есть сайты, которые я делал в 1999 году, с последним редизайном где-то в 2003. Они до сих пор живут, но мне их тема уже неинтересна, да и не хочется тратить времени чтобы всё это переделать. В случае потери обратной совместимости мне проще будет отказаться от этих сайтов вообще. Но пока сайты работают, люди на них заходят. А так было бы на несколько сайтов в интернете меньше.
                            +1
                            У меня 32 дюймовый монитор. Шрифт читаем и сравним с хабром по размеру.
                              +1
                              У меня iPhone 5 SE (эт не самый большой экран), и никакого горизонтального скролла не появлятеся… хм. Вы меня удивили.
                              +2
                              автор видимо из тех, кто лет 10 назад топили за флэш (который слава богу умер). Приложения под каждый сайт это даунгрейд, куда удобнее через браузер иметь доступ ко всем
                              0
                              Проблема легаси в данном случае легко решается. Старые сайты будут доступны как и раньше. Новые будут доступны через новую программу. При этом даже хостить старые и новые сайты можно будет с одного и того же сервера из одной и той же папки.
                              +9

                              Хоронить веб — это занятие из той же категории, что и хоронить доллар.

                                +5
                                Лучше и не скажешь.
                                Самое смешное — есть определенная категория людей (не все, лишь токсичная часть) из мира Java, C, C++, которая необоснованно называет всех веб-разработчиков веб-макаками, обосновывая это тем, что JavaScript, PHP, Python и остальные интерпретируемые языки программирования гавно по сравнению с серьезными языками и особого ума не надо, чтобы на них писать, и они (настоящие программисты), за вечер лучше напишут. И при упоминании конечно же хоронят веб каждый день.
                                Когда в силу определенных обстоятельств таким людям все-таки приходиться что-либо сделать серьезное в веб-сфере, НЕОЖИДАННО оказывается — УУУ! СЛОЖНА! СЛОЖНА!© ВЕБ РАЗДУТЫЙ! АПИ ГАВНО! УСТАРЕВШИЕ СПЕЦИФИКАЦИИ! ПРИМУС! МОСКВАШВЕЯ! ПРИЗНАНИЕ РОССИИ! АБЫР… AБЫР… АБЫРВАЛГ!
                                Фреймворки, библиотеки, спецификации, браузерные API, паттерны, другой синтаксис языка, компиляторы и остальные инструменты — всем этим ОКАЗЫВАЕТСЯ необходимо знать как правильно пользоваться.

                                Приходишь ты потом на такой проект после такого НАСТОЯЩЕГО программиста и смотришь на него со слезами, чешешь свою веб-макаковскую репу, думая, как спасти этот тонущий в говнокоде проект.
                                В итоге хочу лишь сказать что, веб платформа хоть и имеет недостатки (порой и серьезные), при этом вполне зрелая платформа, которая вполне отвечает современным требованиям и хоронить и переделывать ее в ближайшее время вряд-ли будут без веских причин.
                                  +3

                                  Честно скажу, что текущая инфраструктура для сборки веб-приложений слишком переусложнена. Знаете когда внезапно npm накачивает в проект 200 мегабайт зависимостей чтобы потом на выходе сделать 1.4 мегабайт несжатого js я начинаю грустить.

                                    –3
                                    Я вчера грустил, скачивая 56 мегабайт инсталлятора Microsoft Visual Studio Code. Казалось бы, это просто текстовый редактор. Sublime Text всё ещё умещается в 10 мегабайт.
                                      +4

                                      Как-бы 200 мегабайт зависимостей в бекенде это ты уже можешь сделать практически все :) А во фронтенде ты там только добавил vuejs, axios, bootstrap и lodash %)

                                        +3
                                        Я грустил, когда Visual Studio (не Сode) на моём не самом медленном ведре устанавливалась 2 с лишним часа. А вы пару мегабайт пожалели :)
                                          +1
                                          Просто нормальный редактор написан нативно, а этот — на JS и тащит за собой браузер. Вот и вся разница. А так, в качестве простого текстового редактора и Far сойдёт…
                                          +2
                                          200 мегабайт node_modules явно вытекают вовсе не из цепочек зависимостей, а из того, что паблишить можно всё что угодно. Вот и паблишат. Более того, паблишить непожатые библиотеки очень неплохо — они позволяют разобраться, как проходит tree shaking на финальном этапе (и проходит ли он вообще), минифицированный код же запросто может включиться полностью, а вы еще и не поймете, так ли это.

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

                                          ЗЫ: Ну и я бы не сказал, что на бэке ноды всё так гладко. Да, там пакеты не те — в них меньше мусора, и они обычно уже пожаты, ибо заточены под выполнение, а не под дальнейшую сборку. Но — вот у меня есть всякие домашние вещи на ноде — и одна из зависимостей, обновив свою мажорную версию, «похудела» мои node_modules в ПЯТЬДЕСЯТ (с 50Мб до 1Мб) раз. Не все пакеты одинаково худые, одним словом.
                                            0

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

                                            +5
                                            Были в моей рабочей практике похожие проекты. Проблема на самом деле не в сборке такого проекта, а в нем самом. Начнем с претензий к NPM и сразу посмотрим на другие платформы
                                            1. Почему то никто особо не грустит, когда, чтобы написать на MacOS нормальное приложение размером пару мегабайт, нужно скачать Xcode размером 8 гигабайт, которое при установке занимает 16 гигабайт.
                                            2. Ладно идем в QT. Качаем онлайн установщик — убив куча времени на регистрацию устанавливаем последнюю версию QT — 19 гигабайт. А я всего лишь хотел приложение на пару мегабайт.
                                            Про Visual Studio уже ниже написали.

                                            Вернемся к NPM, вернее к node_modules. Для начала условимся, что эта папка нам нужна только на момент разработки и в любой момент после сборки мы можем ее удалить, а используя yarn — библиотеки очень быстро устанавливаются из кеша. Допустим, по какой-то неведомой причине нам очень критично место на компьютере, а проектов на диске много — можно установить один раз общие devDependencies глобально, а для проектов ставить только dependencies. Это звучит немного бредово, так же как и жалоба на размер node_modules.

                                            Теперь к проекту:
                                            Размер приложения 1.4 мегабайт — это очень много для одного js файла. Скорее всего допущены ошибки в процессе сборки или проектирования.
                                            0. Проанализировать зависимости приложения — действительно мне нужна целая библиотека для реализации или достаточно использовать только ее часть (к примеру lodash, underscore, date-fns и тд.)? Возможно ли вообще обойтись без стороннего кода? Есть ли библиотеки с меньшим размером кода?
                                            1. Нужно убедится что vendor зависимости не входят в файл приложения. Их можно вынести в отдельный файл (chunk) либо подключить по сети через cdn. Зависит от ситуации.
                                            2. Проанализировать насколько монолитен код проекта. Разбит ли код на части или модули? Действительно ли для Login страницы необходима загрузка логики остальной части приложения? Насколько зависимы эти части? Повторяется ли код (copy-paste) из одних компонентов или классов в других? Насколько компоненты переиспользуются? Нужна ли, к примеру, библиотека WYSIWYG редактора на каждой странице? Использован ли tree shaking и работает ли он?

                                            Сделав подобный небольшой рефакторинг — я более чем уверен что размер приложения изменится и вместо одного огромного app.js у вас будет несколько файлов по 100-200 килобайт.

                                            Проблемы у таких проектов начинаются на самой зачаточной стадии еще до написания кода. Из за несерьезного отношения и плохого менеджмента сроки ужимаются, никто не тратит время на проектирование «на бумаге» до того, как писать код. Все сразу бегут начать писать код. «А что там проектировать?» — говорят они. Накидал по быстрому библиотек, написал портянки копипастного кода, подключил всех возможных полифилов чтобы IE6 работал (хотя по факту не будет), сгенерил, не зная того, бабелем легаси код, где вместо async/await и промисов инклюдится transform regenerator и на выходе получаем ЭТО — 2-3 и более мегабайт тормозящего легаси JS кода.

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

                                              Это с vedorchunk. И не упакованное. Само приложение весит 175 килобайт. Вы мне сейчас скажете это норма? :)


                                              Скорее всего допущены ошибки в процессе сборки или проектирования.

                                              Как бы ребят вам не кажется что вот все вами описанное должен делать не я а упаковщик? Почему линкеры того же бинарного кода умеют резать бинарники и выкидывать не используемые части а webpack не осиливает?


                                              Накидал по быстрому библиотек, написал портянки копипастного кода, подключил всех возможных полифилов чтобы IE6 работал (хотя по факту не будет), сгенерил, не зная того, бабелем легаси код, где вместо async/await и промисов инклюдится transform regenerator и на выходи получаем ЭТО — 2-3 и более мегабайт тормозящего легаси JS кода.

                                              Это и есть проблема. Проблема всего JS. А выкинуть никак нельзя.

                                                +1
                                                Это с vedorchunk. И не упакованное. Само приложение весит 175 килобайт

                                                Ну по нормам это не ко мне а к Малышевой :). Если честно немного странно почему у вас так много vendor chunk весит. Возможно его стоит раздерибанить.

                                                вам не кажется что вот все вами описанное должен делать не я а упаковщик?

                                                Если пишите не под старые браузеры — современные браузеры это умеют уже даже без сборщика (нативные es6 модули). Грамотно настроенный линтер уже делает почти все за вас. Кроме Webpack есть еще Parcel, Rollup — что еще надо? Куда проще?

                                                Это и есть проблема. Проблема всего JS. А выкинуть никак нельзя.


                                                Нет. Это не проблема JS. Как и любого другого языка. Так же как это не проблема платформы. JS не виноват что вы включили полифил и 1000 библиотек.

                                                Ксати, давайте возьмем к примеру Java. Идем на страничку wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
                                                Ой! Прийдется брать старую Java для поддержки старой операционки.
                                                Ой! Есть и такие ограничения? habr.com/ru/post/314416
                                                Почему билдер не решает это за меня?

                                                Проблема кроется обычно в нежелании открыть документацию, потратить небольшое время на изучение платформы и ее возможностей, выделить время на проектирование приложения и один раз написать нормально.
                                                А и еще. Хочу посмотреть на компиляторы, билдеры из других языков, которые могут сами в архитектуру приложения. Убрать лапшу, копипаст, вынести все автоматом в модули, выносить логику и вьюшек, а вьюшки из логики, патерны использовать, семантически генерировать и именовать расово правильные методы и классы по вызову одной команды?
                                                  +1
                                                  Нет. Это не проблема JS. Как и любого другого языка. Так же как это не проблема платформы. JS не виноват что вы включили полифил и 1000 библиотек.

                                                  Как бы если это умолчание это так себе затея.


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

                                                  Окей. Давайте нормальную документацию по тому же webpack. Мне тут в прошлой теме про npm тоже рассказывали, что я не умею готовить npm и правильно упаковывать nodejs приложения. Правда вот когда я сказал окей вот пример упакуйте. Работоспособного приложения не получилось. Причем было сказано там либа кривая, из-за этого вебпак не пакует как надо. Ну здорово.


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


                                                  Все варианты этого что я встречал различные свои велосипеды.


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

                                                  Я прошу убрать не используемые методы. Простой пример подключаем date-fs, насколько я помню по умолчанию туда затаскиваются все переводы для всех языков. Зачем? И так много в каких модулях. В итоге бандл ведора разбухает прям на глазах. И я должен специально идти изучать специализированные методы, чтобы отключать лишнее. Лучше бы я изучал как подключить.

                                                    0
                                                    правильно упаковывать nodejs приложения

                                                    А разве упаковка nodejs приложения обязательна?

                                                    Окей. Давайте нормальную документацию по тому же webpack

                                                    А что не так с существующей документацией? Особых проблем с ней у меня не возникало. И кто вас заставляет использовать только webpack?

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


                                                    Ну камон. Серьезно? Дайте мне пожалуйста документацию как правильно строить архитектуру на Rust. Или C++. А и еще на Swift под MacOS пожалуйста заверните.

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

                                                    Это было бы крайне странно. Реализаций самой авторизации может быть множество. Откуда им знать какая вам нужна? Мало того, было бы странно если бы фреймворк или библиотека диктовала структуру директорий.
                                                    А если уже говорить о структуре самого проекта — всегда есть здравый смысл:
                                                    Компоненты должны быть в папке компоненты, страницы в папке страницы, константы в папке константы, утилиты в папке утилиты, а модели в моделях. Это очевидно как мне кажется. Тем более для реакта и вью есть cli утилиты которые все настраивают сами.

                                                    Простой пример подключаем date-fs, насколько я помню по умолчанию туда затаскиваются все переводы для всех языков. Зачем?


                                                    Разработчики библиотеки предоставляют ресурсы необходимые для ее правильной работы. Эта библиотека по умолчанию поддерживает tree shaking. Вы можете не импортировать ее полностью. Идем в документацию
                                                    date-fns.org/v2.13.0/docs/webpack

                                                    Я не очень понимаю в чем проблема использовать тот инструмент который подходит для вашей ситуации и проекта и почитать документацию?
                                                      +1
                                                      А разве упаковка nodejs приложения обязательна?

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


                                                      А что не так с существующей документацией? Особых проблем с ней у меня не возникало. И кто вас заставляет использовать только webpack?

                                                      То что оно особо не рассказывает как оно упаковывает, больше про ручки написано.


                                                      Ну камон. Серьезно? Дайте мне пожалуйста документацию как правильно строить архитектуру на Rust.

                                                      Для java spring есть описание каркаса и как и куда что раскладывать. Для того же flask на питоне тоже есть. Более того и под C++ наверняка есть.


                                                      Реализаций самой авторизации может быть множество. Откуда им знать какая вам нужна?

                                                      Угу в итоге везде описывается одна и та же схема с токенами и jwt токенами. Различается только точка откуда этот токен берется :)


                                                      Мало того, было бы странно если бы фреймворк или библиотека диктовала структуру директорий.

                                                      В Django к примеру это никого не удивляет.


                                                      А если уже говорить о структуре самого проекта — всегда есть здравый смысл:
                                                      Компоненты должны быть в папке компоненты, страницы в папке страницы, константы в папке константы, утилиты в папке утилиты, а модели в моделях. Это очевидно как мне кажется. Тем более для реакта и вью есть cli утилиты которые все настраивают сами.

                                                      Это как раз не очевидно и более того я видел сильно разные по структуре проекты. Какой-то хотя бы рекомендованной нет. Если будем говорить за vuejs то там кхм. По умолчанию vue cli делает следующие каталоги


                                                      • asserts
                                                      • components

                                                      В components лежит ровно один файл :) Как-то не похоже на структуру :)


                                                      Так что там они настраивают? Да в документации есть упоминания пресетов. Только вот ни одного пресета в документации не указано. А мне бы хотелось иметь пресет к примеру сразу с vue-router и vuex. Вот к примеру генератор проектов под spring-boot https://start.spring.io/
                                                      Просто сравните. Причем после его установки в том числе будут и каталоги к стандартной структуре приложений под spring.


                                                      Разработчики библиотеки предоставляют ресурсы необходимые для ее правильной работы. Эта библиотека по умолчанию поддерживает tree shaking. Вы можете не импортировать ее полностью. Идем в документацию
                                                      date-fns.org/v2.13.0/docs/webpack

                                                      Отлично. Теперь смотрим результат команды


                                                      vue create hello-world
                                                      ...
                                                      added 1206 packages from 851 contributors in 69.346s
                                                      
                                                      40 packages are looking for funding
                                                        run `npm fund` for details
                                                      
                                                        Invoking generators...
                                                        Installing additional dependencies...
                                                      
                                                      added 54 packages from 39 contributors in 25.426s
                                                      

                                                      И 100 мегабайт в node_modules. Я так понял чтобы уменьшить бандл мне нужно будет каждую библиотеку таким образом изучить и посмотреть не напихали ли туда лишнего? Я отдельно промолчу, про альтернативно одаренных авторов библиотеки которые включают ВСЕ локализации по умолчанию. Хотя логичнее сделать их подключаемыми. Про них кстати была целая статья на хабре.


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

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

                                                        +1
                                                        Ну мне к примеру не нравится, что тривиальное приложение за счет node_modules весит 200 мегабайт. Как-то в концепцию микросервиса не укладывается :)

                                                        А вы микросервис по размеру исходников определяете?
                                                        Это размер c devDependencies или без? При деплое приложения размер зависимостей намного меньше. Кстати, я только что скачал Spring и распаковал — 297 мегабайт. Вкладывается Sping в концепцию микросервиса?

                                                        То что оно особо не рассказывает как оно упаковывает, больше про ручки написано.

                                                        А вам надо чтобы в документацию инструмента входило детальное описание процесса упаковки? Если да интересно послушать зачем.

                                                        Угу в итоге везде описывается одна и та же схема с токенами и jwt токенами.

                                                        Я даже не знаю как на это отреагировать.

                                                        В Django к примеру это никого не удивляет.

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

                                                        В components лежит ровно один файл :) Как-то не похоже на структуру :)


                                                        В этом и есть смысл — вам достаточно стартовать с папкой компонент.

                                                        И 100 мегабайт в node_modules. Я так понял чтобы уменьшить бандл мне нужно будет каждую библиотеку таким образом изучить и посмотреть не напихали ли туда лишнего?

                                                        Используя vue-cli вы устанавили библиотеки для дев окружения, линтер, сборщик, вебсервер… etc. Чем так мозолят эти 100 мегабайт?

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

                                                        Так можно сказать о любой платформе.
                                                          –2
                                                          А вы микросервис по размеру исходников определяете?
                                                          Это размер c devDependencies или без? При деплое приложения размер зависимостей намного меньше.

                                                          Это nodejs. Там меньше не получается сделать dedup позволяет ужать его его до 80 мегабайт. А сборка в bundle приводит к нерабочему приложению, хотя и ужимает его до 1.4 мегабайта что куда бы не шло.


                                                          Кстати, я только что скачал Spring и распаковал — 297 мегабайт. Вкладывается Sping в концепцию микросервиса?

                                                          Если собрать будет jar в приделах 50 мегабайт. Там еще внутри будет еще web сервер. И для java это микросервис. И он будет включать именно те jar которые использутся. И да эти самые 297 мегабайт могут быть переиспользованы в других проектах, что хоть частично компенсирует размер.
                                                          В npm я вот вижу что каждый проект кладет к себе зависимости.


                                                          А вам надо чтобы в документацию инструмента входило детальное описание процесса упаковки? Если да интересно послушать зачем.

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


                                                          Я даже не знаю как на это отреагировать.

                                                          Попробуйте погуглить vuejs authentification. Везде нагугливается именно это. Может я как-то не так гуглю.


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

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


                                                          В этом и есть смысл — вам достаточно стартовать с папкой компонент.

                                                          Окей у меня предполагается приложение, с 10-20 CRUD и 30-40 различных страниц. Какую структуру приложения предложите? Ключевой момент количество может увеличиваться. В качестве UI-kit bootstrap. Фигачить линейно компоненты? В какой-то момент каталог components превратится в помойку.


                                                          Используя vue-cli вы устанавили библиотеки для дев окружения, линтер, сборщик, вебсервер… etc. Чем так мозолят эти 100 мегабайт?

                                                          Мне просто не совсем понятно зачем нужно 100 мегабайт не понятной шелухи. Там же из полезного и реально используемого от силы 10 процентов. Остальное различный мусор.


                                                          Так можно сказать о любой платформе.
                                                          Если бы. Просто сравните документацию на vuejs и flask. Документация аналогичная vuejs в flask была 3-4 года назад.
                                                            +1
                                                            Это nodejs. Там меньше не получается сделать dedup позволяет ужать его его до 80 мегабайт. А сборка в bundle приводит к нерабочему приложению, хотя и ужимает его до 1.4 мегабайта что куда бы не шло.


                                                            Скиньте github/bitbucket ссылку с примером проблемы. Может на выходных получиться посмотреть и помочь вам.

                                                            Если собрать будет jar в приделах 50 мегабайт. Там еще внутри будет еще web сервер. И для java это микросервис. И он будет включать именно те jar которые использутся. И да эти самые 297 мегабайт могут быть переиспользованы в других проектах, что хоть частично компенсирует размер.

                                                            Мне просто не совсем понятно зачем нужно 100 мегабайт не понятной шелухи. Там же из полезного и реально используемого от силы 10 процентов. Остальное различный мусор.


                                                            Не находите противоречий самому себе? То есть вебсервер с линтером в 100 мегабайтах это мусор, а веб сервер в 300 мегабайтах это не мусор. Не надо так. И к тому же что вы будете делать, если другой проект потребует другую версию Spring? Опять скачаете 300 мегабайт с сервером? Зачем вам два одинаковых сервера?

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


                                                            Мне кажется в этом случае вам нужно начинать с понимания того, как работает NodeJS и его модульная система.

                                                            Окей у меня предполагается приложение, с 10-20 CRUD и 30-40 различных страниц. Какую структуру приложения предложите? Ключевой момент количество может увеличиваться. В качестве UI-kit bootstrap. Фигачить линейно компоненты? В какой-то момент каталог components превратится в помойку.


                                                            Не совсем понимаю, по какому принципу вы определяете, что определенное количество компонентов превратилась помойку.
                                                            Для меня помойка в структуре, когда файлы и папки не следуют общему стилю наименованию и их названия не отражают содержимое, а не когда большое количество. И даже если количество компонентов увеличится, их всегда можно разделить по смыслу/семантике/группе. К примеру есть подход Atomic Structure
                                                            bradfrost.com/blog/post/atomic-web-design.
                                                            Или можно сгруппировать по другому принципу — переиспользуемые UI компоненты хранить в ui директории, а частные компоненты в partials, служебные теплейты и слои в templates и layouts директориях.
                                                              0
                                                              Скиньте github/bitbucket ссылку с примером проблемы. Может на выходных получиться посмотреть и помочь вам.

                                                              Да легко https://github.com/Koenkk/zigbee2mqtt


                                                              Не находите противоречий самому себе? То есть вебсервер с линтером в 100 мегабайтах это мусор, а веб сервер в 300 мегабайтах это не мусор.

                                                              300 мегабайт это зависимости для сборки. А после сборки встроенный вебсервер занимает 4 мегабайта. Ну и в node_modules реально километр мусора.


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

                                                              В каталоге стало больше 30 компонентов. Надо разбивать. А рекомендаций нет. В итоге часто наблюдаем люди не думают про это и просто наваливают как есть.


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

                                                              И я про это. Просто MVVP и прочего натащили а рекомендуемую структуру нет.


                                                              Или можно сгруппировать по другому принципу — переиспользуемые UI компоненты хранить в ui директории, а частные компоненты в partials, служебные теплейты и слои в templates и layouts директориях.

                                                              Это вот еще один вариант. В итоге каждый раз заглядывая в очередной веб-проект по новой изучаешь куда что тут разложено. И как накреативлено. Единственный фреймворк который как я понял хоть как-то пытается этот бардак изменить это angular 2.


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

                                                      +1
                                                      Давайте нормальную документацию по тому же webpack.

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

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

                                                      Так вот, в отличие от мавена, альтернативы вебпаку на фронте уже таки быстренько появились, и самые крутые из них уже прошли первые фильтры публичности. Бандлите чем-нибудь другим, никаких проблем. Или вообще делайте всё в task-based сборщике, gulp до сих пор прекрасно работает, и для небольших проектов по прежнему актуален (как и ant для явы).
                                                        –1
                                                        Есть и другие бандлеры. Есть и такие, которые намного проще и документация у которых получше

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


                                                        Как Maven для явы — тоже абсолютно ужасен, но тоже серьезных альтернатив нет.

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

                                                          0
                                                          Например?

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

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

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

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

                                                            Проще говоря все одинаковы и какого-то сильно лучше webpack нет? Ну тогда смысл перекатываться? К примеру чем rollup лучше чем webpack? Киллер-фича есть?

                                                              0
                                                              Эм. Вы выше выкатываете вполне определенную претензию к вебпаку, а теперь вам нужна какая-то «киллер-фича» у альтернатив в добавок? Вы уж определитесь.

                                                              Если вас волнует непредсказуемость вебпака при отсутствии хорошей документации о том, что там внутри него и как происходит — это можно починить переходом на rollup. Если вам надо какой-то совсем не такой бандлер, да еще и желательно с одной кнопкой «сделать всё хорошо» — ну, ожидайте.
                                                                0

                                                                Товарищ вы меня отправляете в rollup вы можете внятно сказать чем он лучше? Документация лучше? Или нет? Или я должен лично сходить перепробовать все 100500 упаковщиков и выбрать тот который подходит?

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

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

                                                                    Окей попробую собрать то проклятое node js приложение. Глядишь соберется нормально.

                                                                  0
                                                                  Тут скорее всего последний вариант.
                                                                0
                                                                Кстати я прихожу постепенно к мнению что и упаковщики практически не нужны (после поддержки большой четверкой Chrome, Firefox, Safari, Edge нативных ES6 modules, caniuse.com/#feat=es6-module), кроме как сборки зависимостей из npm и стилей. На этом фоне даже появился на базе Rollup еще один сборщик — www.snowpack.dev
                                                                Идея отличная но у Rollup и основанных на нем сборщиках нет поддержки Hot Module Replacement из коробки (те два сторонних плагина что есть работают откровенно говоря плохо). Тем более для нативных модулей.

                                                                Поэтому в свободное время я занят написанием своего бандлера на основе rollup.

                                                                Идея проста как и у snowpack — анализируем наши зависимости из node_modules и собираем их через rollup для импорта в браузере. Наш клиентский код оставляем без изменений (либо компилируем ts -> mjs без участия бабеля), пишем современно и используем нативные модули.
                                                                Грубо говоря наш исходный код будет таким же, каким его будет исполнять браузер. Бандлер имеет встроенный devserver и hot-reload
                                                                нативных модулей (реализовать это было мягко говоря непросто), а также интеграцию с eslint. В продакшин режиме фалы сжимаются, index.html генерируется автоматически.

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

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

                                                                  Так что да, времена наступают куда более лучшие, но бандлеры еще долго будут востребованы.

                                                                  Идея отличная но у Rollup и основанных на нем сборщиках нет поддержки Hot Module Replacement из коробки

                                                                  Учитывая концепцию бандлера — это можно понять. Это не задача для самого бандлера ну никак. Сторонние плагины к роллапу далеко не все хорошие, да. Но можно свой написать, если совсем уж не хватает. HMR в виде плагина фундаментально всегда будет приделываем к бандлеру, если тот module-based.
                                                                    0
                                                                    HTTP/2 многое улучшает, но во-первых, он должен быть, а во-вторых — всё-таки не всё (хотя бы то, что надо будет минимум 2 последовательных обращения вместо одного для загрузки кода, даже если глубину импортов оптимизировать).

                                                                    HTTP/2 — вроде как прицел и был на то, чтобы решить проблему множественных соединений. При условии, что мы контролируем server — почему бы и не перейти на него, если проект с нуля?

                                                                    Плюс необязательно всегда следовать правилу 1 класс/компонент = 1 файл при условии микро компонентов/классов.
                                                                    К примеру файл buttons.mjs может экспортировать несколько разных кнопок. Но это так — мысли в слух.

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


                                                      Только это стабильно срабатывающий фактор. Нормальная разработка под веб дорогая и долгая, поэтому ничего не поменяется, углы будут срезать и дальше. И все ваши предложения будут упираться в этот факт, что нужно еще вчера и за доширак. Единственный способ побороть это — как то уменьшить пляску на костылях.
                                                        +1
                                                        Но ведь этот фактор работает и на других платформах/языках?
                                                          0
                                                          Работает. И потому особо важно, чтобы на платформе было как можно меньше костылей.
                                                        0
                                                        В онлайн-инсталлере Qt можно же выбрать только то, что нужно. Или вообще выбрать оффлайн www.qt.io/offline-installers download.qt.io/archive/qt
                                                          0
                                                          Все равно как минимум 2 — 3 гигабайта надо скачать
                                                            0
                                                            Qt SDK 5.14 под GCC x64 грозится занять аж 553.09 MB.
                                                            скриншотr
                                                            image
                                                              0

                                                              Что тем не менее все равно в 2 раза больше 200Мб, за которые предъявляют претензии Node.js

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

                                                          Да. Потому что докер для такого не нужен. Его часто используют не по назначению. Под докер нужно всегда адаптировать софт. Но когда люди упаковывают в него nginx чтобы отдавать spa это уже за гранью зла.

                                                            0
                                                            А не подскажете, как это сделать за гранью добра?
                                                              0

                                                              У вас уже есть машина куда вы собираетесь втыкать докер, ставите туда nginx создаете отдельного пользователя кладете в него сайт. Показываете через nginx. В итоге это все занимает заметно меньше места. Если хотите чтобы пользователь мог сам что-то настраивать и показывать не проблема, даете ему пользовательский nginx с unix-сокетом, а запросы проксируете вторым или просто пробрасываете порт при помощи iptables как это делает docker. Как это раньше делали с домашними страничками.

                                                                0
                                                                Зашибись, как всё это сделать одной командой на ЛЮБОЙ тачке, которая умеет поддерживать докер?
                                                                  0

                                                                  А как сделать одной командой ГДЕ нет докера?

                                                                    0

                                                                    И да в докере вы запускаете фактически скрипт. Без докера такое делается элементарно на ЛЮБОЙ тачке где стоит настроенный anisble, puppet или chief.

                                                                      0
                                                                      Хотите сказать, что сделать «в чистом поле» тачку с «anisble, puppet или chief.» и запустить на ней 4 инстнса сервиса разных версий одновременно проще, чем в докере? А потом так же просто снести, чтобы и следов не осталось?
                                                                        0

                                                                        Напоминаю мы тут про SPA разговаривали. Это штука запускается где угодно и под каким угодно http сервером раздающим статику.

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

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

                                                                              0
                                                                              Чем вам nginx так не угодил? Он вас в детстве покусал?
                                                                              Базовый образ поверх alpine занимает 9 с копейками мегабайт. У вас собранный SPA может больше места занимать.
                                                                                0

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

                                                                                  0

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

                                                                                    0
                                                                                    А ещё, когда люди начинают использовать anisble, puppet или chief, у них пропадает культура ручной настройки окружения. Но в этом случае вы почему-то не против.
                                                                                      0

                                                                                      Не пропадает :) Рецепт то все равно писать.

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

                                                                                          Еще скажите из сорцов ага.

                                                                                            0
                                                                                            Погодите, вы же топите за максимально возможную производительность и экономию 0,1% ресурсов сервера. Как вы можете быть против сорцов, которые дают самые широкие возможности по оптимизации?
                                                                                            Ну и например у php установка модулей из pecl — это по сути и есть автоматизированная сборка из сорцов.
                                                                                              0

                                                                                              Вы забыли что я еще топлю за безопасность. А в этом случае ставить надо из пакетов.

                                                                                      0

                                                                                      А зачем нужна культура деплоя без докера?

                                                                                        0

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

                                                                              0
                                                                              Конкретно Ansible работает «издалека» и на инсталлируемой системе ничего ставить не надо.
                                                                                0

                                                                                Ну кстати да он же через ssh соединение

                                                                              0
                                                                              Кроме того, в докере вы не «фактически запускаете скрипт», вы путаете со сборкой образа, для которой, кстати, иногда используются " anisble, puppet или chief", чтобы не писать вручную монструозные команды инсталляции и сборки.
                                                                              А при запуске скачивается уже готовый слепок файловой системы, монтируется и запускается.
                                                                                0

                                                                                Для этого его сначала надо сделать

                                                                        +2
                                                                        А не задумывались, может это не докер не нужен? Может, просто стоит уже перестать трястись над 200 мегабайтами из node_nodules? Диски сейчас достаточно большие, времена 10 гб на всю систему уже давно прошли. Не хотите — у вас всегда есть альтернатива в виде «vim index.html» и ничего лишнего.

                                                                        А мне было очень удобно скачать и запустить в докере готовый сервис speech-to-text на смеси питона и плюсов, не пытаясь даже думать, как мне это скомпилировать вручную и где скачать зависимости под мою платформу. И то, что это стоило мне нескольких лишних гигабайт, я считаю разумным разменом.
                                                                          +1

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

                                                                            0
                                                                            Докер как запускалка своих сервисов с большим количеством зависимостей вполне выход

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

                                                                              0

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

                                                                              +1
                                                                              А скажите, чем nginx настолько отличается от любого другого сервиса, что запускать его через докер — это сразу «фу, позор»?
                                                                                +1

                                                                                Тем что он есть в любом дистрибутиве в виде пакета. Плюс увеличивается число прослоек. Что лучше запускать nginx на сервере или запустить docker в нем запустить nginx, а затем на него пробросить еще сеть? По мне второй вариант явно будет жрать больше ресурсов.

                                                                                  0
                                                                                  По мне второй вариант явно будет жрать больше ресурсов.
                                                                                  Экономия на спичках. Подключение CDN, даже самой дешёвой, даст на пару порядков больший прирост и в пропускной способности и в отклике, чем выпиливание «лишних прослоек».
                                                                                    0

                                                                                    На СDN там думаете что nginx обслуживающий ваш закешированный контент стоит в докере? Вот как раз нет. Потому что это вот там это выливается в реальные деньги.

                                                                                      0
                                                                                      На СDN там думаете, что просто пакеты из публичных репозиториев стоят? Раз «это выливается в реальные деньги», они могут некоторые части спускать вплоть до кастомного софта на голом железе.
                                                                                      Но мы то тут про SPA, которые засовывать в докер плохо всегда без оглядки на масштаб.
                                                                                +1
                                                                                Значит, установить ноду нужной версии, все зависимости, в том числе которые скомпилировать надо, pm2, вебсервер для SSR этого самого SPA — это типа нужно ручками ставить на каждом сервере. А какую-нибудь пыху или go — можно и докер рубануть, потому что это типа сервис, а не жалкая спа. Ну-ну.
                                                                                  0

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


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

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

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

                                                                                      Что именно? nodejs?


                                                                                      А кто будет обновлять либы в пакетах? Или вы предлагаете автоматически последнюю версию всего ставить, а там будь что будет?

                                                                                      Эм. Товарищ есть такая штука как дистрибутив LTS. В его рамках фиксируются версии библиотек. И никто не будет туда вносить библиотеки которые что-то ломают. А обновлять их надо. К примеру ssl. Весьма часто разработчики дистрибутивов просто добавляют патчи справляющие проблемы безопасности и только.

                                                                                        0
                                                                                        Что именно? nodejs?
                                                                                        Всё, что требуется для запуска продукта на локальной машине. Это вы первый сузили тему до spa, неявно подразумевая простой хостинг статических файлов. Хотя, как я уже писал выше, даже для спа может быть много всего.

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

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

                                                                                          Только в случае если SSR есть.


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

                                                                                          Зависит от того как он ставится. Но вообще если требуется множественная установка собираем пакет.


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

                                                                                          Это зависит от того что за библиотека у вас используется.


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

                                                                                          Вообще говоря не все. Далеко не все.


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

                                                                                            +1
                                                                                            Я предлагаю подумать а надо ли его использовать.
                                                                                            Вы предлагаете думать, а надо ли городить отдельный пайплайн на отдельном стеке ради одного узко специализированного кейса, чтобы снизить потребление ресурсов с просто маленького до очень маленького.
                                                                                              +1

                                                                                              Товарищ еще раз. Если вы собираетесь, запускать только nginx со статическим сайтом на одной машине зачем вам для этого докер? Может еще для этого сразу CI притащим и настроим?


                                                                                              Еще раз для тех кто читает между строк. Когда docker используется в рамках оркестровки и деплоинга большого числа сервисов да сколько угодно. Хотя лучше взять podman.
                                                                                              А вот для деплоя статического контента на один комп, использовать docker это забивание гвоздей микроскопом.

                                                                                                0
                                                                                                Если у вас есть свалившийся с неба готовый скомпилированный SPA и его надо только разместить на одной единственной машине, на которой уже стоит настроенный Nginx — то да, докер — это излишество.

                                                                                                Но в современном «переусложнённом» мире готовый SPA — это почти всегда продукт CI.
                                                                                                А даже если нет, его часто нужно установить минимум на 3-4 очень сильно отличающиеся машины, к примеру — боевой и тестовый сервер на CentOS, машина верстака на Mac и машина бекендщика на Windows.
                                                                                                  +2
                                                                                                  Если у вас есть свалившийся с неба готовый скомпилированный SPA и его надо только разместить на одной единственной машине, на которой уже стоит настроенный Nginx — то да, докер — это излишество.

                                                                                                  И внезапно именно про эти и только про эти случаи и говорил.

                                                                                                    0
                                                                                                    Тогда получается как-то так:
                                                                                                    На длинном жизненном пути SPA в самой конечной точке отказ от докера в некоторых случаях (ручной деплой на 1 машину) позволяет сэкономить долю процента от производительности.
                                                                                                    Вывод: SPA в докере — за гранью зла.
                                                                                                      +1

                                                                                                      Мда… я людям про Фому они мне про Ерему. Внезапно есть куча людей у которых продукт разрабатывает команда меньше 10 человек. И там деплоит тот же человек что и пишет софт. На кой ему CI? Для скуки?


                                                                                                      Один раз настроил дальше git push у себя git pull на сервере и все.

                                                                                                        0
                                                                                                        Но когда люди упаковывают в него nginx чтобы отдавать spa это уже за гранью зла.
                                                                                                        Где тут все эти уточнения? Знаете, между «делать что-то» и «делать что-то, что объективно не нужно в конкретно этом случае» есть огромная разница.

                                                                                                        Да и я уже запутался, то человеку самому не нужен CI и докер, и он всё напрямую на деплой пулит, то этот же человек внезапно беспричинно начинает заворачивать билд в докер, скорее всего тоже вручную.
                                                                                                          +1

                                                                                                          Я вам пишу раз в третий что когда люди используют docker для деплоя простого одного сервиса на машину это так себе идея. А так делают сплошь и рядом.

                                                                                                            –1
                                                                                                            А я вам пишу уже не помню какой раз, разовый ручной деплой на одну машину — это далеко не всегда ВЕСЬ жизненный цикл сервиса, даже если лично вы видите только его.
                                                                                                          0
                                                                                                          На кой ему CI? Для скуки?
                                                                                                          Зря вы так, очень хорошая практика. С недавних пор я даже для своих пет-проектов начал CI использовать, крайне удобно это. Запушил код, а дальше оно сами и тесты прогонит, и скомпилируется, и задеплоится куда надо. Даже банальный статический сайт — и то надо скомпилить и залить в ветку gh-pages, так зачем это делать руками каждый раз?
                                                                                                            0

                                                                                                            CI это может делать и без docker. А можно просто через скрипты. Это уже как кому удобнее.

                                                                                                            0
                                                                                                            Ээээ… Вы как будто из 90-х свалились. «На кой ему CI?»??? Так может это, «на кой ему git?»? Чтобы упростить процесс и автоматизировать то, что можно оптимизировать. Банальная проверка стиля кода, чтобы ни у тебя, ни у того, кто будет после тебя, не вытекали глаза от мешанины стилей и при этом чтобы ты сам об этом не думал — написал «как работает», а в CI все автоматически переформатировалось к нужному стилю. Или там тесты запустить? Или в вашем мире «на кой тесты?»?

                                                                                                            И это самый-самый очевидный пример, у меня даже на пет-прожекте из буквально 1 файла есть 5 файлов тестов, 1 файл настройки линтера и 1 файл конфигурации CI. И все это в отдельном гит-репозитории, конечно. И, знаете — это поразительно удобно. Хотя мог бы обойтись 1 файлом проекта на локальном диске и FTP-деплоем. Но почему-то не хочется к такому возвращаться.
                                                                                                              0

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

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

                                                                                                                  Автоматический деплоинг, как и докеризация должна приносить пользу. К примеру сокращать время на деплой. Если у вас весь деплой состоит скопировать скрипт, то зачем его его тащить через CI? Особенно когда кроме скрипта больше ничего нет. А то получается к в классической картинке


                                                                                                                  image

                                                                                                                    0
                                                                                                                    О, у меня тоже есть не менее классическая картинка

                                                                                                                    image
                                                                            0

                                                                            То, что Вы описываете — это лишь проблема токсичных людей, которых не так уж и много(но они заметны). На деле большинство понимают, что много исторически сложилось. К JS больше всех вопросов, язык не выглядит зрелым, оч легко выстрелить в ногу, я думаю Вы его проблемы в 100 раз лучше меня знаете. Люди понимают проблемы и появляется TS,Go, rust для веба. Хотя для фронта конечно мало что получается изменить, но все же. Это значит, что много действительно умных людей, которые могут что-то изменить — осознают проблемы, и все потихоньку к лучшему меняется ведь. Я не за всем слежу, но часто ведь попадаются статьи, переехали на что-то новое, увеличилась скорость в разы, кода меньше стало и тд.
                                                                            На мой взгляд, в текущих условиях, веб разрабам надо стараться что-то новое использовать (нормально писать), чтобы хотя бы проблемы прошлого века не плодить. И тогда и бизнес будет доволен, и люди работающие с этим кодом потом не будут хотеть найти и покалечить своих коллег)

                                                                              +3
                                                                              Частично c вами согласен. Да — JavaScript не идеален, но зная язык и особенности платформы можно писать хорошо даже без TypeScript. Да и в том же C и C++ выстрелить себе в ногу не намного тяжелее, а иногда и легче — зависит от опыта разработчика и его инструментария. Веб меняется как и другие сферы — иногда в правильную сторону, иногда и нет. Но хоронить его потому что браузер очень сложный, сайт сделать сложно и тд. это неправильно.
                                                                              0

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

                                                                            0
                                                                            Видимо у автора накипело). Для себя лучше веба ничего не вижу). Халиварить на тему что лучше можно бесконечно. Любая система, язык имеет свои недостатки и преимущества
                                                                              +1

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

                                                                                +3
                                                                                Опыт кроме js имеется(Delphi, c# winform, asp.net). На Flutter смотрел примеры. Ничего особо выдающегося выделить не могу. Все хорошо и ровно, пока работаете в рамках правил. Как только сделать шаг влево, вправо будут костыли). Наш мир не идеален, костыли — это следствии
                                                                                  –1

                                                                                  Оно банально лучше тем что не требует обкладывать таким количеством костылей ванильный html/js/css как это сделано сейчас. Если же закрыть на это глаза, то на том же vuejs формы формошлепятся вполне успешно и удачно.

                                                                                  0
                                                                                  Костыли — это мягко сказано. Я бы сказал, что всё идёт к упрощению, а в итоге получается усложнение, но на другом уровне. Часто бывает, что нужна одна функция, а тащат всю либу. В итоге получается раздутые приложения, где не то, чтобы шлак… а просто куча ненужного. Для программиста — это упрощение, для сборки — это самолёт, который нужен для того, чтобы съездить за угол за продуктами.
                                                                                +7

                                                                                Тут всё упирается в графический UI. Раньше был зоопарк различных ОС — AmigaOS, OS/2, BeOS, Unix/Linux/Solaris, MacOS, Windows (это всё с "оконным", а не текстовым интерфейсом). Программы создавались под каждую операционку отдельно. Я пробовал делать "окошки" для Windows на Pascal/C++ — довольно замороченно, особенно, если нужно с меняющимися размерами делать. Ребятам из Sun'а пришла в голову мысль сделать Java, в которой бы "работало всё одинаково" под разными ОС. Java'вский GUI уже огромный шаг вперёд — им пришлось взять основы GUI от каждой ОС, под которую они делали JRE, и откинуть особенности. По крайней мере в Java Swing можно было уже создавать UI, который бы был достаточно одинаков под Windows, и под Linux (другие я не пробовал). Там же, кстати, я впервые столкнулся с layout'ом, до этого "окна" зачастую проектировали под определённые размеры экрана (благо разных размеров не так много было). А потом я ушёл в web-программирование — вот этот вот HTML/CSS/JS. Чтобы оценить насколько проще делать GUI при помощи web-технологий, достаточно попытаться реализовать аналогичный альтернативными способами.


                                                                                Никто и сейчас не мешает писать web-приложения на C++/Java/python/… Не нравится вам DOM и HTML? Реализуйте GUI для общения с пользователям с использованием тех же Delphi/QT/WPF/WinForms/JavaFX. Операционки позволяют делать это (как и пользовать сеть). Есть пакеты для создания GUI под различные ОС и для различных устройств — native apps. Тоже можно попробовать, чтобы оценить удобство связки HTML/CSS/JS.


                                                                                Более того, вы можете реализовать свою специализированную платформу внутри "браузерных технологий" — Wordpress, Magento, Vaadin, GWT, RoR, Django,… Браузер — это современная "операционная система" для класса приложений. Вы можете двигаться вглубь и сделать своё решение для некоторого подмножества приложений с использование браузерных технологий, или сделать то же самое, двигаясь наружу — с использованием нативных возможностей операционных систем или той же Java.


                                                                                Вы правильно сказали про "уже вложены миллионы человеко-часов. Это эффект наработанной базы." И про "Если попытаться с нуля сделать нормальный движок того же веб-магазина, то выяснится, что это ни разу не просто." тоже правильно. А теперь распространите это на вашу новую платформу, которая нам, типа как нужна, и вы увидите, что это тоже ни разу не просто, да и не очень-то нужно. Не даёт эта ваша новая платформа преимуществ, которые бы смогли побить эффект уже наработанной базы. А там, где даёт, там её уже делают. В игровой индустрии — Steam & Virtual Reality, например.

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


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

                                                                                  А там, где даёт, там её уже делают. В игровой индустрии — Steam & Virtual Reality, например.


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

                                                                                  С другой стороны — байткод? Возможность послать подальше DOM?
                                                                                  Как бы уже есть WebAssembly + WebGL. Да и раньше можно было Canvas использовать (вспоминаем тот же OnlyOffice еще со времен их бытия TeamLab, один из преимуществ которого была и есть возможно нормально отображать и редактировать офисные документы, более менее любых размеров, а не как у Google Docs. Как? А Canvas нормально использовать. Они даже не стеснялись это рекламировать — habr.com/ru/company/teamlab/blog/141434 и habr.com/ru/company/teamlab/blog/275471 )
                                                                                    0

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

                                                                                      +4
                                                                                      Не факт что не нужна. Приложения они разные бывают.
                                                                                      Пример — онлайн-библиотека (возможно совмещенная с магазином).
                                                                                      Реализации например: Bookmate, Сайт А(название условное), Флибуста, Самизадат (samlib.ru).
                                                                                      Самиздат — без проблем индексируются всеми желающими потому что это простой сайт на котором немного динамики и свой простой движок.
                                                                                      Флибуста — могла бы индексироваться если бы хотела, сделано на Drupal'е со спецмодом
                                                                                      Сайт А — индексируются описания и так далее, даже бесплатно доступные фрагменты не индексируются (притом что могли бы). Ну вот владелец сайта решил что так надо.
                                                                                      Сайт Ц — в отличии от сайта А — часть текста вообще рендерится сервером в картинки, еще и с шумом. Ну вот такая своебразная защита

                                                                                      Но технически все они (и все их аналоги — Bookmate например) это «web-читалка книг», приложение. Возможно — с уникальным контентом (вопрос копирайта тут не учитываем, как минимум для Сайтов А и Ц — это НЕ проблема если было бы желание).
                                                                                      У Сайта А есть мобильное приложение но сделано явно по веб-технологиям (почти весь внешний вид — сайта, добавлена только оффлайн-синхронизация)

                                                                                      Другой пример — да любой форум. Это приложение (с кучей контента) или сайт? А Хабр? С одной стороны это таки мобильное приложение (и вроде как работающее через закрытый API). Но одновременно это и сайт.

                                                                                      Или интернет-магазин чего-нибудь (без)полезного? С одной стороны весьма сложные движки а с другой стороны — весьма немалая потребность в индексации (и в найме специалистов по поисковой оптимизации)

                                                                                      +3

                                                                                      Вот и мне кажется что WebAssembly по сути и есть то самое что ищет автор. Жаль его подкосила вся эта история со Spectre (из-за этого оба основных движков отключили адекватную поддержку shared memory, которая нужна для нормальных тредов), но даже сейчас вполне можно этим пользоваться — тот же Blazor сейчас вполне интересная технология!


                                                                                      PS: и движка таки пока два. Не забывайте о Firefox — слава богу кроме Chrome жизнь ещё есть. Вот если он умрёт, тогда начнётся монополия. А монополия от корпорации — это будет весьма невесело...

                                                                                        0

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

                                                                                          0
                                                                                          Вы даже пошли дальше, и мне нравится то направление куда вы смотрите — а ведь действительно, если сделать просто legacy-supporting polyfills на wasm с поддержкой тех самых перегруженных спецификаций (можно даже автоматически загружаемые для старых сайтов), то это позволило и реализовать абсолютно новую спецификацию, и при этом не выбрасывать на свалку истории уже существующее.
                                                                                            0

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

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

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

                                                                                              0

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

                                                                                                +1

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

                                                                                                  0

                                                                                                  Я думаю это все решат разрабы браузеров. Все оно будет само тянутся.

                                                                                                    +1

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

                                                                                                      0

                                                                                                      Думаю тем, что слой совместимости со старьём выселят в отдельный независимый модуль. И он не будет захламлять ядро браузера. "Да, ваш старый сайт на HTML 0.00001 будет у нас работать, но чтобы обеспечить наилучшую работу, переходите на стильный-модный-молодёжный WASMWEB".

                                                                                                  0

                                                                                                  Вы не в курсе, прямое обращение из WASM во внешний мир таки сделали? Или по-прежнему через JS прокладки? Давненько правда, но я читал, что к примеру WebGL впрямую нельзя.

                                                                                                    0

                                                                                                    Есть WASI и interface types, они как раз про некоторую стандартную библиотеку, что-то в духе libc.
                                                                                                    https://github.com/WebAssembly/WASI/blob/master/phases/snapshot/docs.md


                                                                                                    Есть еще WebGPU, который как бы модерновая замена WebGL, и вроде есть планы напрямую присобачить его к WASI, чтобы не ходить через JS.

                                                                                            0
                                                                                            С новым подходом одна из проблем — если все делать «приложениями» — либо мы убиваем поисковые движки (гугло оно надо?) либо нужен новый способ индексации чтобы робот понял про что собственно этот сайт и как то получил достаточно информации чтобы понять как его ранжировать. И так то с SPA сложности в этом были.


                                                                                            И вот как раз гугл может продумать этот момент для новой среды. И ему это даже будет выгодно. SPA не укладывались в парадигму традиционного веба, но только потому что возникли уже после того как веб был спроектирован. Если продумать такие вещи заранее, то мы наоборот можем получить нечто лучшее, чего сегодняшний СЕО-мусор, которые засирают все подряд.
                                                                                            +3
                                                                                            Да ну, ерунда какая-то. Не нужен вам продвинутый CSS — не используйте. Не нужны API и фреймворки — не грузите. Какая проблема?

                                                                                            Проблема есть у производителей движка? Да. Ну и пусть. Нам-то что. На то она и Корпорация добра.

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

                                                                                            … И сразу бы на этом вырастет куча плагинов и фреймворков. Это будет ещё хуже, ибо сейчас худо-бедно есть стандарты W3C, а так каждый будет лепить, что захочет.

                                                                                            В итоге придём к тому, что мне вместо того, чтобы открыть страницу автосервиса в браузере придётся по сути загрузить отдельное приложение этого автосервиса. Ведь современные мобильные приложения с Котлином и Джавой — это ведь и есть то, что вы предлагаете. Разве вы сами не поняли?

                                                                                            Лет 15-20 назад был такие же проклятья в адрес x86. Но ничего, все смирились, живее всех живых.
                                                                                              +1

                                                                                              Ну насчет x86 немного не так. Сейчас много какого софта без мата спокойно переносится на arm mips и прочие архитектуры. Гвоздей держащих приложение на x86 все меньше.

                                                                                                0
                                                                                                Ведь современные мобильные приложения с Котлином и Джавой — это ведь и есть то, что вы предлагаете

                                                                                                А если еще вспомнить про Instant Apps (которые под лозунгом — вам не надо скачивать приложение! можно сразу запускать!)(реально жесткие ограничения на размер, в рамках современных тяжелых веб-страниц + возможность подгрузить потом модули)
                                                                                                Даешь в браузеры поддержку андроид'а а все сайты — в Instant Apps!
                                                                                                -:)
                                                                                                  0
                                                                                                  Да ну, ерунда какая-то. Не нужен вам продвинутый CSS — не используйте. Не нужны API и фреймворки — не грузите. Какая проблема?


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

                                                                                                  Такое везде, не только в языках программирования. Я например веду проект, который стартовал в 2010 году. Сейчас я бы много всего переписал по-другому. Но даже чёрт с ним с рефакторингом. Люди привыкли пользоваться проектом в таком виде, в котором он есть сейчас, и любые нововведения принимают со скрипом. Когда нужно ещё соблюдать обратную совместимость — вот и получаются тысячи страниц одной только спецификации.

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

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


                                                                                                    Будут, но люди тоже себе не враги и будут использовать чужие наработки, чтобы сэкономить время, так что через пару лет все устаканится. Будут в байткоде в кэше броузера лежать основные версии fontawesome, React, VueJS, jQuery и т.п. Сможете назвать хотя бы 50 общеупотребительных библиотек, которые нужны всем? Проверьте ради интереса сколько места занимает кэш в папке профиле гугл хрома.

                                                                                                    В итоге придём к тому, что мне вместо того, чтобы открыть страницу автосервиса в браузере придётся по сути загрузить отдельное приложение этого автосервиса. Ведь современные мобильные приложения с Котлином и Джавой — это ведь и есть то, что вы предлагаете. Разве вы сами не поняли?


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

                                                                                                    Лет 15-20 назад был такие же проклятья в адрес x86. Но ничего, все смирились, живее всех живых.


                                                                                                    Давайте я вам помогу подобрать еще более абстрактную аналогию — «Ни нужон нам этот ваш инторнет. Кричали и до сих пор кричат.
                                                                                                    +9
                                                                                                    Очень забавно, как хороня веб, автор заново придумывает… яву. А точнее, страшное слово «апплеты», для тех, кто еще его помнит.
                                                                                                      +1
                                                                                                      Метко подмечено.
                                                                                                        –1
                                                                                                        Чем принципиально плоха ява? Апплеты тормозили потому что тогда компьютеры были слабыми, потому что рантайм каждый раз загружался с нуля, потому что ява изначально не было создана для веба и ее туда прикостылили.
                                                                                                          0

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

                                                                                                            0
                                                                                                            потому что ява изначально не было создана для веба

                                                                                                            Именно для веба она и создавалась:
                                                                                                            In June and July 1994 – after three days of brainstorming with John Gage (the Director of Science for Sun), Gosling, Joy, Naughton, Wayne Rosing, and Eric Schmidt – the team re-targeted the platform for the World Wide Web. They felt that with the advent of graphical web browsers like Mosaic the Internet could evolve into the same highly interactive medium that they had envisioned for cable TV. <...> the first public release of Java, Java 1.0a2 with the HotJava browser, came on May 23, 1995
                                                                                                              +1
                                                                                                              От этого ява не стала основным языком на странице. Ее производительность и потребление памяти было неразумным для массы тогдашнего железа. Тогда ява была оверкилом для веба. И то что в итоге этот язык отъел огромную роль рынка где угодно, но только не на фронет говорит нам, что для под словами «создавался для веб» можно понимать, что у разработчиком Java представление о вебе было весьма своеоборазным.
                                                                                                                0
                                                                                                                Напомню, что в 1994, когда создавалась Java, веб был совсем непохожим на нынешний: сайтов во всём мире было меньше трёх тысяч, до выхода IE 1.0 оставалось больше года, до появления JS и CSS — ещё дольше.

                                                                                                                То, что в итоге этот язык отъел огромную долю рынка где угодно, но только не на фронте — говорит нам, что разработчики Java не смогли предугадать, в каких направлениях веб-экосистема будет развиваться. Точно так же и условный App Browser, созданный для решения проблем, актуальных для веба в 2020, рискует в 2030 восприниматься лишь как исторический курьёз.
                                                                                                          +1

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

                                                                                                            0
                                                                                                            А может проблемы не в вебе а в слишком разжиревших людях, которые слишком быстро бегут? Либо в этих классных дизайнерах, которые предлагают красивые «удобные» UI/UX.
                                                                                                              +2
                                                                                                              Да проблема абсолютно идетична той, когда люди пишут программы, которые жрут много ресурсов («а, вот, на асме бы было в 100 раз быстрее и в 100 раз меньше места бы занимало!»). И виноваты не программисты, а наше окружение, когда скорость и доступность интернета растёт, когда жесткие диски и оперативка дешевеют. Поэтому технологии «не парятся» (в лице разработчиков, которые их используют). И это ни хорошо, ни плохо, это эволюция.

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

                                                                                                              Так и с вебом и вообще с приложениями: спросят, а чего ты памятью разбрасываешься? А тебе ответят: а нафиг мне ее экономить, когда у всех по 64 гига и так стоит…
                                                                                                                0
                                                                                                                Так и с вебом и вообще с приложениями: спросят, а чего ты памятью разбрасываешься? А тебе ответят: а нафиг мне ее экономить, когда у всех по 64 гига и так стоит…
                                                                                                                Да-да, только вот через год надо будет уже 128 гигов, а ещё через год — 256. А память прибита гвоздями к материнке, так что изольте заплатить раз в год за новый ноутбук, и Вам сильно повезёт, если он будет не глючнее старого.
                                                                                                              +1

                                                                                                              Вы как и 20 лет назад, можете написать


                                                                                                              <title>Супер-сайт</title>
                                                                                                              <h1>Это мой замечательный сайт</h1>

                                                                                                              и всё будет работать.


                                                                                                              Если вам нужно, что-то более сложное — готовьтесь к сложностям, на чём бы вы не писали.


                                                                                                              P.S. вы бы погуглили, что такое «веб 2.0». Тег неуместен

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

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

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


                                                                                                                  Про войны браузеров да закончились.и начались войны медиа стандартов. Yuotube платят миллиарды apple все потому что в браузер удалось протащить стандарт едиа патент на ко орый принадлежит apple.


                                                                                                                  Так как в любую отдельно взятую точку времени обьем легаситкоторый приносит доход бизнесу будет составлять 100%. Никакие кардинальные изменения вкбу не грозят.


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

                                                                                                                    0
                                                                                                                    Если сложность разработки для браузера сравнится а по факту будет сложнее чем разработка нативного приложения мобильного или десктопного, то кто будет разрабатывать браузерные приложение erp?

                                                                                                                    Те, кто подозревают что клиентские рабочие места будут как минимум под Windows (и хорошо если это будут только Win10) и Linux(дешевле ж)(на тему в том числе desktop-приложений под линукс тут недавно была серия статей, один из самых оптимальных способов избежать проблем и поддерживать по возможности ВСЕ хоть как то актуальные дистрибутивы линукса — тащить за собой вообще все что может приложению потребоваться, используя Snap или Flatpak, возможно создавая проблемы уже с ними). Ну или Electron использовать для создания «нативного» приложения.
                                                                                                                    Да, доступ с мобильных устройств тоже бы неплохо иметь хоть в каком то виде. Веб-версия это даст. А если идем нативным путем — +еще андроид и iOS-приложение.

                                                                                                                    Вспоминается один проект (в деталях могу уже ошибаться — давно было). Там:
                                                                                                                    — два мобильных приложения (для двух ролей пользовательских, одна из ролей требует и iOS и Android, вторая только Android)
                                                                                                                    — сложный сервер
                                                                                                                    — операторские АРМы (изначально идея была что они запускаются в закрытой сети), там достаточно сложный интерфейс, карты (причем свои, на базе OSM, да — это было необходимо), IP-телефония, возможность быстро обновления выкатывать, так вот, оказалось значительно проще эти операторские АРМы сделать как веб-приложение, с поддержкой только Chrome(еще и обновление — с разрешения разработчиков системы) + необходимостью кастомной настройки небольшой (потому что WebRTC почему то не работал в стандартной, не помню точно что там за проблема). Зачем так? А у заказчиков использование Линукса серьезно рассматривалось в дополнение к Windows (а то что возится с настройкой придется — так все равно услуга по установке платная была)
                                                                                                                    +5

                                                                                                                    Ох уж эта молодежь, все бы им выкинуть и переписать, автор хотя бы историю вэба сначала почитал, ведь все уже было, и не один раз, и flash, и java applets, и silverlight, но корпорация добра сказала, только html5, и остальные вымерли.

                                                                                                                      0
                                                                                                                      И правильно сказала, между прочим. (Я кстати очень любила flash и Action Script. Было жаль расставаться, хоть и понимала, что это дорога в никуда).
                                                                                                                        +1
                                                                                                                        flash, и java applets, и silverlight


                                                                                                                        И все это было прикручено сбоку, половина была closed source.

                                                                                                                        корпорация добра сказала, только html5, и остальные вымерли.


                                                                                                                        Осталось дождаться когда корпорация добра устанет в одиночку поддерживать костыль для работы с html5. Кажется Adobe уже так поступила с flash.
                                                                                                                          0
                                                                                                                          Извините, но мне кажется, что самый жирный гвоздь был не от корпорации добра, а от корпорации Яблок: они сразу сказали, что на их устройствах не будет Flash.
                                                                                                                          А у Гугла в настольных браузерах Flash поддерживался очень долго, даже после того как стал маргинальной технологией. Да и в мобильных, его поддержка закончилась только в 2014 или в 2015, что ли.
                                                                                                                          +3
                                                                                                                          Кто похоронит современный веб?

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

                                                                                                                              +1
                                                                                                                              На эмоциональном уровне хочется в автором согласится — взять и все поделить переписать, но что-то мне подсказывает, что при этом может получиться тоже самое, только в профиль
                                                                                                                                –1
                                                                                                                                Не может. Платформа будет создаваться с нуля под сегодняшние реалии, а не 1995 года.
                                                                                                                                  0
                                                                                                                                  А через 20 лет опять переписывать?