Похоже вы описываете работу обычных SPA, упуская тот момент, что инструменты из статьи при первом запросе в теле документа возвращают всё, в том числе контент.
Да, я тоже там был и помню, когда Dreamweaver был какой-то магической штукой, которая за тебя много чего делала. Но сейчас всё немного по другому.
Предположим, есть сайт из 100 HTML файлов и везде нужно изменить какой-то блок. Сейчас этот блок — это один React компонент, который лежит в отдельном файле и включается в сборку с помощью описываемых инструментов. Кроме того они делают намного больше полезного чем просто сборка.
А вопрос скорости интернета актуален и сейчас. Доля мобильного трафика очень высока и местами его качество оставляет желать лучшего.
Для всего свой инструмент. Описываемые решения, как ни странно, больше нужны для удовлетворения требований поисковиков (SEO) и максимального улучшения пользовательского опыта, что в последнее время близко. Страницы статичны, быстро отдаются серверами, пользователи видят страницу мгновенно со всеми зависимостями в теле документа (разметка, critical CSS, минимизированные превьюшки изображений в виде base64). При навигации по сайту загружается тот минимум, который необходим для отображения следующей страницы. И даже при определенной настройке этот минимум загружается, когда пользователь только навел на ссылку. Похоже, что этот подход уже устаканился и его уже всё чаще и чаще используют большие компании.
Я предпочитаю использовать strapi.io в связке с Gatsby.js. Strapi предоставляет возможность гибкого формирования контента в довольно удобном интерфейсе и управлять доступом к нему через GraphQL API. А у Gatsby есть плагин для интеграции (gatsby-source-strapi). Всё это можно публиковать на Vercel или Git(Hu|La)b Pages. У Vercel есть что-то типа AWS Lambda. И всё это бесплатно.
А можно ли как-то перевести заголовок страницы, то есть тэг title? Хочется к нему просто добавить директиву i18n, но компилятор удаляет её (используется AoT). Хотя CLI включает эту строку в перевод…
Пример в статье больше для иллюстрации SRP и отсутствие надобности создавать экземпляр передаваемого сервиса с учётом всех его зависимостей внутри компонента, всё разрулит Angular DI. Вы считаете, этот момент нужно как-то подкорректировать?
Во-первых, вы приводите не всю фразу полностью, выдёргивая контекст. Там ещё говорилось про интерфейсы. А во-вторых, речь была про возможность удобной реализации этих принципов, используя фреймворк.
В коммерческих проектах фреймворк начали использовать сразу после выхода стабильной версии. До этого следили, изучали, писали тестовые приложения, устраивали внутренние митапы, делились, кто, что узнал нового.
Вот недавно начали 3-й проект на нём.
Фреймворк и его конечный размер, как мне кажется, больше подходят для средних и больших приложений. В нашем случае это:
система мониторинга за состоянием крупной системы в реальном времени,
большая база данных с возможностью просмотра всевозможных её срезов и агрегатов,
и что-то типа сетевой игры в реальном времени.
В таких проектах каждый компонент или элемент может быть сильно кастомизирован. Поэтому, по возможности, ради однородности кода пишем всё сами (если нет нативного аналога в браузере). Это не так уж и сложно, интересно и лишает боли в случае «неудобной» кастомизации. А такое случается часто, когда в календарь, например, необходимо встроить отображение различных событий, произошедших в системе с учётом их типов и интенсивности.
Поэтому, конечно, есть внутренние наработки некоторых типичных решений, но всё оно довольно частное, не заслуживает называться библиотекой и быть выложенной публично.
К тому же, у нас хорошая команда дизайнеров, по запросу рисуют и дорисовывают всё необходимое — замена поиска необходимого элемента в UI библиотеке :-) — конечно, если бюджет проекта позволяет.
А библиотеками пользуемся лишь базовыми moment.js, lodash, highcharts и подобными для удобства в различных ситуациях.
Похоже вы описываете работу обычных SPA, упуская тот момент, что инструменты из статьи при первом запросе в теле документа возвращают всё, в том числе контент.
Да, я тоже там был и помню, когда Dreamweaver был какой-то магической штукой, которая за тебя много чего делала. Но сейчас всё немного по другому.
Предположим, есть сайт из 100 HTML файлов и везде нужно изменить какой-то блок. Сейчас этот блок — это один React компонент, который лежит в отдельном файле и включается в сборку с помощью описываемых инструментов. Кроме того они делают намного больше полезного чем просто сборка.
А вопрос скорости интернета актуален и сейчас. Доля мобильного трафика очень высока и местами его качество оставляет желать лучшего.
Для всего свой инструмент. Описываемые решения, как ни странно, больше нужны для удовлетворения требований поисковиков (SEO) и максимального улучшения пользовательского опыта, что в последнее время близко. Страницы статичны, быстро отдаются серверами, пользователи видят страницу мгновенно со всеми зависимостями в теле документа (разметка, critical CSS, минимизированные превьюшки изображений в виде base64). При навигации по сайту загружается тот минимум, который необходим для отображения следующей страницы. И даже при определенной настройке этот минимум загружается, когда пользователь только навел на ссылку. Похоже, что этот подход уже устаканился и его уже всё чаще и чаще используют большие компании.
Ещё, как хороший вариант для бесплатного старта: Vercel Serverless Functions + MongoDB Atlas с бесплатными 500МБ.
Я предпочитаю использовать strapi.io в связке с Gatsby.js. Strapi предоставляет возможность гибкого формирования контента в довольно удобном интерфейсе и управлять доступом к нему через GraphQL API. А у Gatsby есть плагин для интеграции (gatsby-source-strapi). Всё это можно публиковать на Vercel или Git(Hu|La)b Pages. У Vercel есть что-то типа AWS Lambda. И всё это бесплатно.
Интересная мысль. Кстати, а в Индии ничего такого не планируется?
Вот недавно начали 3-й проект на нём.
Фреймворк и его конечный размер, как мне кажется, больше подходят для средних и больших приложений. В нашем случае это:
В таких проектах каждый компонент или элемент может быть сильно кастомизирован. Поэтому, по возможности, ради однородности кода пишем всё сами (если нет нативного аналога в браузере). Это не так уж и сложно, интересно и лишает боли в случае «неудобной» кастомизации. А такое случается часто, когда в календарь, например, необходимо встроить отображение различных событий, произошедших в системе с учётом их типов и интенсивности.
Поэтому, конечно, есть внутренние наработки некоторых типичных решений, но всё оно довольно частное, не заслуживает называться библиотекой и быть выложенной публично.
К тому же, у нас хорошая команда дизайнеров, по запросу рисуют и дорисовывают всё необходимое — замена поиска необходимого элемента в UI библиотеке :-) — конечно, если бюджет проекта позволяет.
А библиотеками пользуемся лишь базовыми moment.js, lodash, highcharts и подобными для удобства в различных ситуациях.