Привет, Хабр!
Хочу представить вниманию хабровчан генератор статических сайтов с открытым исходным кодом, написанный на Node.JS, в основе которого лежит Webpack.
Проект вдохновлён тем же Jekyll, но в основе своей использует современный технологический стек. Например, предоставляет возможность «горячей подгрузки» (без перезагрузки страницы) изменённых скриптов и стилей.
Проект ориентирован на международную аудиторию, поэтому официальный сайт, документация и видеоролики — на английском языке.
Особенности
- Современный технологический стек
Создавайте современные сайты, с хорошо упакованными (минифицированными, сжатыми, в т.ч. gzip) скриптами и стилями.
Можно быстро разработать прототип сайта и задеплоить его на сервер.
Используйте любой современный фронтэнд фреймворк (Webpack внутри) – Vue.JS, React, Angular, Ember и т.д. - Супер быстрый и надёжный
Обрабатывает ~1000 страниц в секунду (зависит от содержимого страницы, а также мощности процессора).
Ясное дело, что процесс отдачи статического HTML в разы быстрее любого интерпретируемого языка. - Подойдёт любой хостинг
Не требует базы данных (информация хранится в файлах) и работает на любом хостинге (поскольку на выходе — статические html-файлы и ассеты). - Встроенный деплой
Создайте пресет и разверните сайт на сервере через FTP, SFTP или дажеrsync.
Недавно вышел материал, как бесплатно задеплоить сайт на now.sh. - Безопасный. Никаких обновлений
Можно забыть про необходимость регулярных обновлений, как, например, в том же WordPress.
Безопасноcть на уровне 100%, т.к. никому ещё не удавалось взломать статический HTML (фича). - Бесплатный. Open Source
Пользуйтесь на здоровье. Ни копейки не платите.
Для каких целей подойдёт:
- Быстрое прототипирование (сделали шаблон, показали рабочий прототип, а потом уже натянули на движок)
- Портфолио
- Сайт компании
- Сайт продукта
- Персональный блог
Подойдёт для любого сайта, где нет контента, генерируемого пользователем.
Можно сделать даже коллективный блог, при помощи Pull Requests на Github.
При помощи Firebase или любого другого API, написанного на любом языке (PHP, Ruby, Python, Node.JS) или даже с помощью WordPress (JSON-API), и современного фронтэнд фреймворка типа Vue.JS или React, можно сделать динамический сайт под более сложные задачи: интернет-магазин, каталог продукции и так далее.
Для чего не подойдёт:
- Форум
- Социальная сеть
- Чат
В общем, для проекта, где много контента, генерируемого пользователями, где много работы с базой данных и страницы генерируются на лету.
Требования
Надобно иметь установленные Node.JS (9.x или выше) и NPM (обычно идут вместе).
Скачать и установить (если ещё этого не сделали).
Рекомендуется последняя (v10.12.0) верися Node.JS.
С Node.JS < v9.x не работает, потому как из коробки идёт компиляция SASS, Less, Stylus, а node-sass требует 9 версии.
Также можно использовать Yarn вместо NPM.
Cogear.JS работает на:
- Mac
- Linux
- Windows
Можете использовать модный нынче VSCode для разработки.
Установка
Простая, без ухищрений:
$ npm install cogear -g
# or
$ yarn global add cogearВот и всё. Установка прошла успешно.
Cogear.JS после установки доступен через консольную команду cogear.
Теперь можно сгенерировать первый сайт.
Использование
Перейдите в директорию, где хранятся Ваши веб-сайты.
$ cd ~/SitesВызовите комнаду на генерацию нового сайта:
$ cogear new site.io # где "site.io" – это имя папки нового сайта
После чего проследуйте в данную директорию:
$ cd ~/Sites/site.ioЗапустите Cogear.JS в режиме development (разработка) или production(подготовка к продакшену) (больше о режимах работы).
$ cogear # по-умолчанию запускает режим разработки с «горячей подгрузкой» обновленных ассетов и страниц
$ cogear production # построить сайт и запустить локальный сервер — посмотреть как сайт будет выглядеть в продакшнеОпции
Увидеть список опций командной строки можно путём добавления флага --help.
Полезные ссылки
Если тема вызовет интерес хабровчан, могу сделать серию туториалов, что да как.
- Официальный сайт https://cogearjs.org
- Документация https://cogearjs.org/docs
- Блог https://cogearjs.org/blog
- Репозиторий https://github.com/codemotion/cogear.js
- Туториалы на YouTube
- Список плагинов и тем
P.S. Не стал размещать в Я пиарюсь, т.к. open source.
Задавайте вопросы, постараюсь ответить.
Комментарии (60)
Alex_ME
13.10.2018 14:50А зачем статическому сайту React/Angular/Vue/etc?
Супер быстрый и надёжный
Обрабатывает ~1000 страниц в секунду (зависит от содержимого страницы, а также мощности процессора).Так он же, как я понял, на выходе дает набор статических бандлов, html, картинок и т.п., которые могут потом отдаваться любым http сервером, будь то ngnix или apache. Как Cogear.JS влияет на скорость обработки страниц?
ZoomLS
13.10.2018 15:02Скорее всего имелось ввиду, что если на сайте 1000 страниц, то примерно за секунду он создаст их.
CuamckuyKot Автор
13.10.2018 15:50Речь идёт о компиляции страниц самой системой. Для чего и приводится бенчамарк. Он есть отдельно в репозитории, можно на любом ПК прогнать и проверить.
CuamckuyKot Автор
13.10.2018 15:51А надежный, потому что в HTML нечего ломать + будет работать в любом окружении, на любом хостинге.
PerlPower
13.10.2018 18:34Jekyll отвратителен, но на фоне тех сотен генераторов, что появились в последние годы он просто жемчужина. Почему-то никто из создателей этих генераторов не думает, что автор блога может быть не-программистом. И если одна из десятка зависимостей не установится, или версия языка установленная по-умолчанию в большей части популярных дистров окажется слишком низкой для генератора, то это будет легко починить.
Хороший генератор сайтов должен иметь минимум зависимостей. Никто не думает, что блог можно вести 5-10 лет, а то и всю жизнь. По ощущениям у меня jekyll на debian stable и testing ломался примерно каждый год-два. Половина новодельных генераторов без колдовства с кастомной версией языка и отдельной папкой для либ вообще не заводится. ИМХО, идеальный генератор должен иметь возможность при минимуме зависимостей выдавать HTML4 без js и всего, а все остальное доделывать плагинами.CuamckuyKot Автор
13.10.2018 19:34Пожалуйста, посмотрите процесс установки, описанный выше.
Одна команда. Любое обновление также затруднений не вызовет:
$ npm upgrade -g cogear@latest # или $ yarn global upgrade cogear@latest
В наше время уйти от зависимостей нельзя. Иначе каждый бы писал свой Webpack, придумывал бы свой SASS и мастерил свой Markdown.
Тогда идеальный генератор, если рассуждать по-вашему, это написание чистого HTML руками, без использования каких-либо генераторов.
PerlPower
14.10.2018 01:22Когда версия ноды в основных дистрах более-менее догонит используемую авторами генераторов, можно будет говорить о простой установке. А в остальном — просто вернитесь к этому вопросу через N лет, когда вам после полугодового перерыва захочется что-то опубликовать, а те изменения безопасности, которые вы накатили за эти полгода, сломали вам генератор. Это надоедает, и jekyll подкупает тем, что есть в стандартных репах даже debian stable.
CuamckuyKot Автор
14.10.2018 12:25Cogear.JS работает на актуальной версии Node.JS, а также на предыдущей (9.x).
Изменений безопасности в статических генераторах нет, т.к. в генерируемом HTML охранять нечего.
У Jekyll большой путь и компания Github за плечами. Всё ещё впереди.
CuamckuyKot Автор
14.10.2018 12:33А в остальном — просто вернитесь к этому вопросу через N лет, когда вам после полугодового перерыва захочется что-то опубликовать, а те изменения безопасности, которые вы накатили за эти полгода, сломали вам генератор.
На минутку представьте, что создатели WordPress перестали бы его обновлять лет 5 назад.
Ваши слова применимы к абсолютно любому программному продукту. В наши дни практический любой программный продукт для веба имеет зависимости.
Hellcore
13.10.2018 19:34Недавно увидел генератор vuepress.vuejs.org
Он пока в альфе, но уже функционал довольно большой, и очень удобно.
Вот тут автор VUE его показывает:
www.youtube.com/watch?v=lIv1ItUzktcCuamckuyKot Автор
13.10.2018 19:37Достаточно давно с ним знаком.
Он тоже классный, как и Gatsby.
VuePress создан для публикации документации к Vue-проектам.
И он, опять-таки, завязан на Vue.
А что делать, например, если я изначально не хочу завязываться на фронтенд-фреймворки, а просто хочу статический сайт с современными возможностями в плане JS/CSS?
kranid
13.10.2018 20:37+1Использую hexo, куча готовых тем и плагинов, очень просто и удобно.
CuamckuyKot Автор
13.10.2018 20:56Отличный продукт. Он только под блоги заточен? На главной написано.
Только не нашёл в нем поддержки Webpack из коробки.
Подскажите, как он компилирует ассеты? Есть ли «горячая» перезагрузка?Leopotam
15.10.2018 00:53Умеет запускаться в режиме сервера и мониторит изменения файлов, перегенерируя результат не лету. Умеет сжимать картинки, stylus, ejs и т.п.
baxxter
13.10.2018 22:26Подскажите кейс использования подобных генераторов в продакшене, или не проще настроить Webpack для конкретной задачи (конвертации md в html например), без лишних инструментов и необходимости их изучать? Ведь по большому счету это универсальный сборщик из «чего-то-там» в HTML, который собирает все это хозяйство по команде?
Как движок блога использовать подобное станет только садомазохист или гик — почему не использовать любую популярную CMS? Да, нужна база, да, возможно придется иногда обновляться — зато это решение в 1000 раз более гибкое, проще и дешевле в поддержке.
С CMS вам не придется искать дорогого программиста на Vue.js или React, чтобы встроить функционал интернет-магазина в ваш блог, или обучать какую нибудь девочку контент-менеджера как через вот этот вот богомерзкий *.md написать новый пост (а еще картинки надо по ftp залить в нужную директорию и не забыть их имя вставить в документ!).
С другой стороны если у вас не такой большой блог и вы ведете его сами для себя, то что вы получите от этих плюсов со скоростью работы статичного HTML, насколько вообще критично использовать подобныевелосипедыгенераторы?CuamckuyKot Автор
13.10.2018 22:35Подскажу. В самой первой версии генерация страниц шла целиком через HTMLWebpackPlugin. Когда на тесте было 10 страниц, всё шло более менее нормально. Но как только скармливал ему 100-1000 и более страниц, время компиляции увеличивалось драматическим образом.
Да, сборщик. В т.ч. можно продукт подлежит рассмотрению как готовая конфигурация Webpack с более быстро сборкой (в десятки раз) страниц и самых разных форматов, с использованием темизации и шаблонов. С современным рабочим процессом, поддержкой ES6, TypeScript, CoffeeScript, SASS, LESS, Stylus из коробки.
Как движок блога использовать подобное станет только садомазохист или гик — почему не использовать любую популярную CMS? Да, нужна база, да, возможно придется иногда обновляться — зато это решение в 1000 раз более гибкое, проще и дешевле в поддержке.
Скажите, почему все проекты в мире не делаются на Wordpress? Он хорош для новичков, когда неохота разбираться. Но на выходе, с чем стакливался достаточно часто, он даёт очень тяжелые сайты, которые трудно оптимизировать в силу того, что кодовая база WP тянется с 2003 года.
Я не против WP, сам на нём более 10 лет делаю проекты, но для каждой задачи — свой инструмент.
Иногда в тысячу раз проще на статическом генераторе свой уникальный дизайн со всеми современными плюшками собрать за пару часов, чем пытаться оптимизировать какую-нибудь «красивую» тему для WP.
С CMS вам не придется искать дорогого программиста на Vue.js или React, чтобы встроить функционал интернет-магазина в ваш блог, или обучать какую нибудь девочку контент-менеджера как через вот этот вот богомерзкий *.md написать новый пост (а еще картинки надо по ftp залить в нужную директорию и не забыть их имя вставить в документ!).
Не надо обижать Markdown, это отличный язык разметки, созданный программистами для программистов.
Здесь тоже не нужно знает Vue или React – это по желанию.
Что касается плюсов — они большие. Сегодня поисковые системы смотрят не только на содержимое сайтов, но и на качество их кода, скорость загрузки.
Понимаю, что вы более веб-мастер, чем программист, это нормально. Каждому своё: отдавайте Богу — богово, а Кесарю — кесарево. Но не стоит всех по собственным предпочтениям судить.
Одни нравится одно, другим другое. Иначе бы не придумывали бы Webpack, React, Vue и иже с ними, а все сайты делали бы только на WordPress'е и Drupal'е.
Просто поверьте в конкуренцию идей. Именно она является двигателем мира веб-разработки.
baxxter
14.10.2018 01:01Я не против WP, сам на нём более 10 лет делаю проекты, но для каждой задачи — свой инструмент.
Согласен. Только это не повод становиться рабом лампы. Преждевременная оптимизация только ради оптимизации и в ущерб удобству.
Скажите, почему все проекты в мире не делаются на Wordpress? Он хорош для новичков, когда неохота разбираться. Но на выходе, с чем стакливался достаточно часто, он даёт очень тяжелые сайты, которые трудно оптимизировать в силу того, что кодовая база WP тянется с 2003 года.
Wordpress по статистике — самая популярная CMS. И в целом сам факт того, что из версии к версии используются API и решения из самых первых версий, доказывает что изначально был использован правильный подход к архитектуре WP. И WP — полноценная CMS, в отличие от сборщиков и генераторов, соответсвенно и спектр задач отличается. Так вот для задачи по ведению небольшого блога любая CMS подойдет лучше любого генератора. Задачи оптимизации (в т.ч. поисковой) — это задачи на вырост и они тоже решаемы, это не повод изначально выбирать неудобный инструмент.
Не надо обижать Markdown, это отличный язык разметки, созданный программистами для программистов.
Это я привел в пример потенциальную точку зрения контент-менеджера.
Понимаю, что вы более веб-мастер, чем программист, это нормально.
Да я вообще админ, поэтому и задаю такие вопросы. Возьмем средний бизнес в вакууме. Нужен этому бизнесу например сайт в котором раз в неделю девочка из PR-отдела будет публиковать новости, типичный блог. Вы серьезно предложите использовать генератор для этой задачи?
Насколько я вижу у генераторов могут быть 2 узкоспециализированные задачи:
1) Публикация в html из другого формата большого обьема документов (например документация к проекту пишется в md разработчиками, а для пользователей автоматически генерируется в html)
2) Очень жесткий хайлоад, если вообще возможно перевести сайт на статику. В любом случае такую задачу нужно решать комплексно(балансировка, кеширование, тюнинг nginx и т.д.) и генератор тут поможет только с подготовкой контента из другого формата(если это вообще будет необходимо).
P.S.: Я посмотрел документацию проекта и стало понятно откуда вообще это упоминание про блоги — Вы просто перевели как есть.
theuser
14.10.2018 11:45+1А кому сейчас вообще статика нужна? Дорвеи генерить? Лэндинги-хуэндинги?
CuamckuyKot Автор
14.10.2018 12:29Странный вопрос.
Прочтите данный материал:
https://www.smashingmagazine.com/2015/11/modern-static-website-generators-next-big-thing/
Посмотрите на количество звёзд в репозиториях статических генераторов сайтов.
Может быть эта информация подскажет Вам правильный ответ.
To4KaXD
14.10.2018 12:29+1Начинающим веб-разработчикам нужно ли это?
CuamckuyKot Автор
14.10.2018 12:30Всё зависит от самих разработчиков.
Кто-то считает, что изучать HTML/CSS/JS не надо, а можно довольствоваться настройкой плагинов и тем для WordPress. Другие считают иначе. Каждому своё. Нельзя ответить за всех сразу.
0whitewolf0
14.10.2018 13:24+1Лично я не вижу такой необходимости, Так как начинающему front-end разработчику лучше сконцентрировать внимание на html+css, и ванильному js. Ну и какую нибудь Либу или фреймворк.
CuamckuyKot Автор
14.10.2018 13:25В данном случае можно расценивать Сogear.JS как сборщик HTML, CSS и ванильного JS с возможностью шаблонизации и подключения любых сторонних библиотек.
0whitewolf0
14.10.2018 23:41Я то понимаю) Инструмент интересный, и нужен под конкретные задачи. Я имел ввиду, что человеку который только недавно начал свой путь web-разработчика, им лучше голову не забивать. У меня как раз близкий товарищ начал обучение, и довольно таки активно, я вижу как он напрягается чтобы понять казалось бы элементарные основы, поэтому я стараюсь пока не рассказывать ему даже про css препроцессоры.
Сogear.JS нужен тем кто понимает, что это такое, и понимает какие задачи он поможет решить.CuamckuyKot Автор
15.10.2018 00:40Согласен. Однако и с таким инструментом можно хорошо поизучать VanillaJS, ES6 и препроцессоры.
Zoolander
15.10.2018 07:05Уважаю людей, которые делают полноценные open-source проекты и понимаю, что полноценный генератор статических сайтов — это большой и удобный инструмент.
Но… разве ни разу в голове ни у кого не мелькнула мысль, что рекурсивно обойти дерево исходников и запихать их в размеченный шаблон в указанной папке — это даже для начинающего программиста задача на 1, ну максимум, 2 дня.
Нужно больше информации, чем статические генераторы лучше таких быстрых наколенных поделок. При том, что такие поделки можно лепить на любом удобном для тебя языке, который (если ты программер), уже стоит на твоей системе, и не нужно ставить ноду (это уже не мой случай, нода стоит, но N лет назад не стояла и я делал для таких случаев генераторы на PHP или дажe Java)
Можете ответить, какой функционал в статическом генераторе явно превосходит то, что я описал, его киллер, а точнее — seller-функции? :)
CuamckuyKot Автор
15.10.2018 10:19На основании чего вы позволили себе такое суждение о «неполноценности»?
Да ещё бросили камень в виде «быстрой наколенной поделки».
Начнём с того, что в Open Source понятие «seller» отсутствует. Здесь ничего не покупается и не продаётся.
- Асинхронная сборка страниц.
- Горячая перезагрузка ассетов.
- Поддержка «из коробки» ES6, TypeScript, CoffeeScript, SASS, LESS, Stylus.
- Модульность, плагины.
- Встроенный деплой.
Zoolander
15.10.2018 20:32+1Здравствуйте, приехали.
Ваш проект я как раз и назвал полноценным опен-сорсным генератором.
Под поделкой подразумевается то, что каждый начинающий программист может написать за 1-2 дня.
collectFiles(srzPath).forEach(fillPatternAndCopyToOut) — примерный алгоритм такой поделки на любом языке.
Вопрос стоял так — вот я пишу такое за 1 день, если не беру предыдущий генератор. Зачем мне нужно тратить 1 день на изучение чужих генераторов? Что в них такого? Поддержка фреймворков? Это закладывается на уровне шаблона?
Удачи вам в вашем проекте в любом случае. Я может неясно выразился, но никогда не спешите принимать мутные слова именно на свой счет. Я не хотел вас обидеть и никак не оценивал ваше детище.CuamckuyKot Автор
15.10.2018 20:42Спасибо, я вас действительно, не так понял. Возможно, и вправду построение текста было таковым.
Я вам ответил достаточно ясно по пунктам.
Ещё раз спасибо за пояснение. Я не обижался, слова принял, действительно, на свой счёт.
und88
15.10.2018 10:11+1Очень интересно. Знаком с jekyll. Хотелось бы прочитать туториал от вас. ждем продолжения
CuamckuyKot Автор
15.10.2018 10:21Спасибо.
Если по-английски читаете, можете посмотреть здесь:
https://dev.to/cogear/creating-a-blog-with-cogearjs-21afund88
15.10.2018 15:51+1Благодарю. А если по — русски так ещё перевода нет нигде, правильно?)
CuamckuyKot Автор
15.10.2018 16:39Правильно. Пока нет. Намеревался закончить серию видеороликов, после чего перевести сайт и видео на русский.
jehy
А в чём отличие от Gatsby? Сейчас вроде модно через него статика генерировать.
Правла, мне оказалось проще целиком написать самому свой генератор статики, чем ковыряться в Гэтсби.
Уже не говорю о том, что Гэтсби с нужными плагинами и темой чуть ли не под гигабайт занял.
CuamckuyKot Автор
Вы, по-большей части, сами ответили на вопрос.
Gatsby классный, но он полностью завязан на React.
Данный проект проповедует агностицизм в отношении фронтенд-фреймворков.
Их можно не использовать вообще. А можной и любой из них — надо только знать, как в конфиг Webpack-а добавить соответствующий загрузчик и посмотреть туториал, как плагины писать к Cogear.JS.
Вот, как пример, плагин, который подключает обработку Vue с его концепцией Single File Component:
github.com/codemotion/cogear-plugin-vue
Всего 31 строка кода.
Sabubu
Читаю и ужасаюсь. Зачем статическому сайту фронтенд-фреймворк, если у него все равно нет бекенда с АПИ? Это какой-то нездоровый оверинжиниринг.
Люди, ну не будьте такими глупыми, подумайте хоть секунду головой. Фронтенд-фреймворки сделаны для высокоинтерактивных приложений — вроде редактора электрических схем или сложных форм. Для сайта-блога или сайта-книги они не нужны и являются бессмысленным усложнением.
CuamckuyKot Автор
Фронтенд-фреймворка созданы далеко не только для работы с API.
Вариантов их применения множество.
Вот поэтому в данном контексте система не требует их наличия вообще.
CuamckuyKot Автор
Приведу пару примеров.
1. Поиск по сайту.
При помощи плагина Pages-JSON генерируется список страниц с содержимым. Минифицированная и зажатая в GZip информация всего официального сайта (документация, блог) весят порядка 20Кб.
При помощи Vue.JS делается один запрос (т.к. потом этот файл кешируется браузером), и при помощио Vue делаются подсказки в виде выпадающего меню в поисковой строке.
2. Форма обратной связи.
Клиент, например, хочет иметь статический сайт. Чтобы его никто не взломал, что хостинг был бесплатный, чтобы его не надо было обслуживать и обновлять каждый день плагины и темы (как с WP).
Пишется крохотное API (или берётся сервис) и на том же Vue.JS создаётся форма, которая без перезагрузки страницы, без перебрасывания GET/POST-запроса в новом окне, позволяет отправить письмо, и даёт обратную связь, чтобы пользователь сайта понимал, что всё в порядке.
Alex_ME
Но форму обратной связи можно сделать на jQuery или даже без него. Взять данные с нескольких полей и отправить их AJAX-запросом не особо сложное занятие, чтобы городить ради него целый фреймворк.
Мне кажется, что смысл фронтенд-фреймворков начинается, когда в приложении есть большое количество динамически изменяемых элементов. Тогда да, без фреймворка получается каша кусков html кода в строках для добавления новых элементов, генерация id-шников итп итд.
CuamckuyKot Автор
jQuery давно ушёл из трендов по объективным причинам. С расширением нативного браузерного API нужда в костылях, во многом, отпала.
Сравните вес jQuery и Vue.JS. А в плане скорости перерисовки DOM разница будет значительная, не в пользу старичка.
Sabubu
Тренды для меня ничего не значат. Технические аргументы — пожалуйста.
jQuery и Vue для разных целей. Сравнивать их между собой — то же самое, что сранивать молоток и дрель.
> А в плане скорости перерисовки DOM разница будет значительная, не в пользу старичка
Я не верю. В jQuery вы явно указываете, что обновить. Во Vue — перерисовываете все и ищете отличия.
Alex_ME
Ну хорошо, для формы обратной связи можно обойтись и вовсе без jQuery.
document.getElementById(), все дела.Много ли интеркактива в форме обратной связи или в чем-то аналогичном по сложности? Там считать значение, там добавить/скрыть элемент, поменять стиль, disable/enable и т.п. Хоть тресни, но напрямую сделать какую-нибудь кнопку enable будет быстрее, чем построить весь виртуальный DOM, найти различия, а потом ровно так же изменить ровно один атрибут.
CuamckuyKot Автор
Если работать с ShadowDOM самому, то можно, конечно, и быстрее фремворков.
Форму обратной связи тоже можно сделать по-разному. Можно с валидацией, обработкой событий, реакцией на действия пользователей. А можно, конечно, по-простому. Всё зависит от потребностей и предпочтений.
Sabubu
То, что вы описали, легче сделать на jQUery. Чем превращать каждую страницу в приложение, утяжелять сайт, замедлять загрузку и показ данных.
CuamckuyKot Автор
Давайте обратимся к фактам.
Размеры пакетов (несжатый/сжатый)
jQuery 3.0 – 250Кб/83Кб
Vue.JS 2.4.2 – 58Кб/21Кб
Если более глубоко изучите тему, узнаете, что работа с ShadowDOM (как у Vue, React) в разы быстрее манипуляций в самом DOM, как это делает по-старинке jQuery.
Sabubu
Во-первых, Vue работает не с Shadow, а с Virtual DOM. Во-вторых, мне кажется, вас ввели в заблуждение маркетологи.
Когда маркетологи React или Vue пишут про то, что они используют Virtual DOM, который «быстрее» «обычного» DOM, это надо читать не как «реакт быстрее любых других бибиотек для работы с DOM», а «реакт быстрее библиотек с аналогичным принципом работы, которые создают при рендеринге дерево из обычных элементов DOM вместо виртуальных». Я, кстати, ни одной такой не знаю :)
Увы, вы видимо не понимаете, как они работают.
Вот в jQuery обновление элемента: $('#something').text('hello'). Элементарно — нашли элемент и заменили содержимое.
А как работает реакт или Vue? Он рендерит всю страницу, все компоненты с помощью Virtual DOM. Затем сравнивает новый Virtual DOM со старой сохраненной копией. Находит отличия и применяет их к обычному DOM. То есть на самом последнем шаге он делает то же, что код выше на jQuery, но перед этим делает очень тяжелую вычислительную работу для поиска, что именно надо изменить на странице. Быстрее это быть никак не может.
То есть в jQuery мы указываем, какой элемент изменить, в реакте/vue мы перерисовываем целиком всю страницу только чтобы понять, что на ней изменилось. Это не быстро. Не верьте маркетологам.
CuamckuyKot Автор
Речь не про замену текста в элементе. А про операции типа appendChild.
Не всю страницу, а только лишь тот блок, который Vue обрабатывает, который задаёт как el при инициализации.
Почитайте тут:
medium.com/js-dojo/whats-the-deal-with-vue-s-virtual-dom-3ed4fc0dbb20
+ к тому jQuery, как было указано выше, в несколько раз тяжелее Vue.
Полагаюсь не на маркетологов, а на разработчиков данных технологий, на первоисточник.
Поймите одну простую вещь, jQuery не просто так стремительно теряет свою популярность.
Google Trends
Sabubu
> Поймите одну простую вещь, jQuery не просто так стремительно теряет свою популярность.
Это аргумент маркетолога, а не инженера.
> Не всю страницу, а только лишь тот блок, который Vue обрабатывает, который задаёт как el при инициализации.
В сложном приложении это и есть вся страница.
CuamckuyKot Автор
Это факт, который измеряется по числу загрузок в промежуток времени.
С точки зрения инженера работа с VirtualDOM вдвое быстрее дедовского метода jQuery:
https://github.com/jonmiles/react-performance-tests
Совершенно непредвзятое тестирование, которое каждый может проделать самостоятельно.
Думаю, что переведёте сами:
Sabubu
У вас нет ощущения, что тест специально подогнан под случай, с которым лучше работает реакт? Давайте сделаем другой тест, сложный интерфейс с 1000 контролов и надо обновить единственный.
Или же код с JQuery можно было бы переписать так, чтобы он обновлял только изменившиеся значения и тогда бы он работал быстрее. В добавок, в тесте он написан максимально неэффективно, например, там на каждом шаге подключается парсер DOM (в этой строке: github.com/jonmiles/react-performance-tests/blob/master/public/js/jquery/dashboard.js#L40 ). Автор, видимо, не очень его знает или специально хотел сделать медленный код.
Запускать тесты с открытым devtools плохая идея. Тесты сделаны плохо и непрофессионально, и сравнивают непонятно что.
Реакт выбирают не потому, что он быстрее jQuery (во многих случаях он медленнее). А за совсем другие достоинства.
Не shadow, а virtual DOM.
CuamckuyKot Автор
Правильно! Сделайте другой тест, чтобы доказать обратное.
Тем более, что у Вас более глубокое понимание процессов, чем у автора теста.
Ладно, не моё дело — Вас убеждать в чём-либо.
jQuery и фронтент-фреймворки хоть и пересекаются по части вопросов, но из разных плоскостей.
Статистика и тренды — их не отнять. Но пусть каждый пишет на том, на чём душе угодно. И давайте закончим уже. А то какой-то холивар получается уже.
YemSalat
По вашему на статическом сайте нe может быть какого-нибудь редактора или сложных форм?
К тому же бэкенд не обязательно свой дергается, может какие-то публичные апи просто.
CuamckuyKot Автор
Полностью согласен.
Тем более, когда фронтенд-фреймворки весят в разы меньше jQuery.
Sabubu
> По вашему на статическом сайте нe может быть какого-нибудь редактора или сложных форм?
Когда будет, тогда и подключите. Зачем весь сайт по такой архитектуре делать? Не надо бежать за модой, нужно использовать инженерное мышление.
CuamckuyKot Автор
Напомню, что в данном случае вообще можно не использовать фронтенд-фреймворк. Они — просто как дополнение.
babylon
Мне понравилось. еще бы универсальный лейаут сделали на JSON используя localToGlobal
https://www.bennadel.com/blog/1871-translating-global-jquery-event-coordinates-to-a-local-context.htm
ФРОНТЕНДИТЬ ТАК ВО ВСЁМ!
CuamckuyKot Автор
Отрисовка DOM на jQuery в разы больше ресурсов требует, чем у React/Vue и иже с ними.