Комментарии 17
Спасибо за статью! Достаточно актуальная тема, я считаю.
Нужно просто реализовать web-компоненты не в виде html, а в виде JS-модулей. И вообще отказаться от html и css. И создать 2 вида загрузки модуля: со всеми рекурсивными зависимостями и без. Кэширование, CDN, возможность использовать многократно npm-пакеты и что угодно. Один язык (пусть не JS, пусть будет webassembly). Возможно разделять отображение, стили и подгружать все это динамично, жду, когда же возьмется кто-то из крупняков.
А следующий шаг — вообще нативная поддержка таких модулей браузерами, т.е. браузер будет поддерживать не только html, txt и xml, но и JS-компонент.
В общем-то webpack мелкими шагами что-то частично делает, но нужна масштабная работа всех крупных вендоров и стандартизация, а все эти bundle — это костыли.
А следующий шаг — вообще нативная поддержка таких модулей браузерами, т.е. браузер будет поддерживать не только html, txt и xml, но и JS-компонент.
В общем-то webpack мелкими шагами что-то частично делает, но нужна масштабная работа всех крупных вендоров и стандартизация, а все эти bundle — это костыли.
Ага, а вместо вебсайтов качать экзешники, где всё то, что вы предлагаете уже может быть реализовано на java/c#/c++/100500 других языков программирования.
НЛО прилетело и опубликовало эту надпись здесь
Если вам так не нравится html/css делайте интерфейсы через js, кто ж запрещает? Элементы через createElement, стили через element.style. Будет получаться очень многословно, так ведь можете это все обернуть во фреймверк и будет вам счастье)))
Никто не запрещает, и никто уже давно не использует HTML, шаблонизаторы это не HTML, они базируются на его синтаксисе. Просто нужен новый стандарт для браузеров для динамичной разметки, пока самый подходящий JSX.
Та же самая ситуация с CSS, мы легко решаем вопрос через JS (любые программные возможности), но речь о том, что нужен стандарт. В данном случае JSX опять же решает этот вопрос inline-стилями.
Ну и кроме стандартизации, вопрос встроенной поддержки этого стандарта всеми браузерами (чтобы каждый сайт не грузил свой react или angular).
Та же самая ситуация с CSS, мы легко решаем вопрос через JS (любые программные возможности), но речь о том, что нужен стандарт. В данном случае JSX опять же решает этот вопрос inline-стилями.
Ну и кроме стандартизации, вопрос встроенной поддержки этого стандарта всеми браузерами (чтобы каждый сайт не грузил свой react или angular).
Ну лично я бы не стал все стандартны валить в одну кучу под названием Javascript. Но спорить с вами не буду, потому что есть смысл в ваших словах. Писал я к тому, что вы и сейчас можете все делать из JS, при большом желании и я даже знаю людей, которые так и работают. Минусы имхо очевидны, плюсы кстати тоже есть и не малые.
Одно только плохо — никакого нормального способа это делать в «родном» синтаксисе js почему-то не придумали.
Такая необходимая фича, и ни намека про нее в стандарте :(
Как будто не видели придумыватели стандартов решения на AMD и аналогах. Не знали что сервер по другую сторону WiFi, браузеры не резиновые, трава не зеленая.
Такая необходимая фича, и ни намека про нее в стандарте :(
Как будто не видели придумыватели стандартов решения на AMD и аналогах. Не знали что сервер по другую сторону WiFi, браузеры не резиновые, трава не зеленая.
Во-первых всё видели. Во-вторых, ES Modules ещё не стандартизированы окончательно, как раз в этом месте, а именно SystemJS.
Да знаю что видели. Говорят просто о чем-то другом, о возвышенном, думали когда мысли свои на бумагу переносили.
Что «старый» importScripts невозможно использовать, что новый import/require почему-то думает что все исходники лежат в разных файлах и доступны надежно и с нулевым латенси.
В ES6 Modules есть только один плюс — возможность статического анализа. Все остальное как-то не о том.
А все эти webpack, browserify, requirejs, systemjs — это не от жизни хорошей. У нас вот тоже «своя» модульная система есть — ymb/yms.
Что «старый» importScripts невозможно использовать, что новый import/require почему-то думает что все исходники лежат в разных файлах и доступны надежно и с нулевым латенси.
В ES6 Modules есть только один плюс — возможность статического анализа. Все остальное как-то не о том.
А все эти webpack, browserify, requirejs, systemjs — это не от жизни хорошей. У нас вот тоже «своя» модульная система есть — ymb/yms.
НЛО прилетело и опубликовало эту надпись здесь
HTTP/2 не решает это. Проблема в иерархической структуре зависимостей. Мы не можем параллельно загружать все модули (требующиеся, например, стартовому) одновременно. Загружаем один, считываем его зависимости, их грузим параллельно, у каждого из них опять считываем зависимости, либо подгружаем модули во время исполнения, но это рождаем зависимость интерфейса от их загрузки, нам придется как-то договариваться об этом с пользователем (бесконечными лоадерами) или иметь сверх-скоростной. надежный в 99% случаях, интернет (возможно, в будущем так и будет).
Железная воля и неудержимая решимость требуется для того, чтобы озвученную технику внедрить в готовое приложение. Являюсь сторонником упаковки в большой файл, уповая на кэш и в ожидании мифического HTTP/2, который магически решит все мои проблемы (останется только поменять один конфиг и приложение пойдёт грузиться по зависимостям, а не пачкой)
Я то думал, что-то новенькое придумали :)
Не в обиду автору, подход нормальный и в чём-то правильный, но я бы ещё раз подумал, а точно ли хуже, когда мы один раз грузим bundle, зато потом приложение работает отзывчиво? А то таких «1.bundle» со временем накопятся десятки, и все они будут грузиться не сразу, а только после действия юзера, тем самым снижая отзывчивость вашего приложения. И получится, пожалуй, даже хуже, чем загружать сразу N файлов при первоначальной загрузке страницы.
Не в обиду автору, подход нормальный и в чём-то правильный, но я бы ещё раз подумал, а точно ли хуже, когда мы один раз грузим bundle, зато потом приложение работает отзывчиво? А то таких «1.bundle» со временем накопятся десятки, и все они будут грузиться не сразу, а только после действия юзера, тем самым снижая отзывчивость вашего приложения. И получится, пожалуй, даже хуже, чем загружать сразу N файлов при первоначальной загрузке страницы.
Большое человеческое спасибо! — Именно то, над чем сам думал )
Дополнительный вопрос: Для уменьшения объёма продакшен-кода не пробовали использовать что-нибудь типа react-lite?:
https://www.npmjs.com/package/react-lite
Как-то очень фантастично звучит: +25Kb и React на борту — неужели правда?
Дополнительный вопрос: Для уменьшения объёма продакшен-кода не пробовали использовать что-нибудь типа react-lite?:
https://www.npmjs.com/package/react-lite
Как-то очень фантастично звучит: +25Kb и React на борту — неужели правда?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Прогрессивная загрузка web-приложения с помощью разделения кода