JavaScript Framework & SEO A Заинтересованные стороны и руководство разработчика

1. Влияние фреймворков на пользовательский опыт и SEO
2. Что такое одностраничные приложения
3. Эволюция или распад фреймворков JavaScript
4. Способы, с помощью которых вы можете измерить производительность в сети без дополнительной инженерной...
5. Резюме

Вы заметили, что поисковая команда Google в последнее время «разбирает» фреймворки JavaScript?

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

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

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

Учитывая количество SEO-специалистов, которые хорошо разбираются в технической SEO для статического HTML, если вы хотите дифференцировать себя, понимаете, как работает JS, где он работает с SEO, где он блокирует SEO, как это влияет на другие поисковые системы и клиентов

Джон Мюллер на Reddit

Рамки предназначены для разработчиков, а не бизнес-целей.

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

Как маркетолог или заинтересованная сторона, что вы можете сделать?

Как вы можете сообщить свои требования или нанять подходящих разработчиков, чтобы помочь вам достичь этих целей?

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

Я планирую ответить на следующие вопросы и предоставить еще больше информации по смежным темам:

• Что такое JavaScript Framework? Почему разработчики используют их?
• Как они влияют на ваш поисковая оптимизация Результаты.
• Кроме того, как поговорить с вашими веб-разработчиками о достижении ваших бизнес-целей в Интернете.

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

Влияние фреймворков на пользовательский опыт и SEO

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

• Сложно сделать рендеринг с помощью JavaScript
• Одностраничные приложения имеют тенденцию не иметь хороших методов URL
• JavaScript создает узкие места производительности, задерживающие рендеринг страниц

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

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

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

Google, Microsoft и другие команды браузеров должны действовать осторожно, чтобы они не «разозлили» то, что считают разработчиками.

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

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

Я веб-разработчик, известный своей позицией против JavaScript-фреймворки "быстрого питания" потому что они негативно влияют на пользовательский опыт.

Раньше я был сторонником одностраничные веб-приложения Я даже написал книгу о том, как разработать СПА , Но SPA, которые я защищал, отличаются от SPA, популярных у разработчиков сегодня.

Моя версия SPA ориентирована на UX и быструю загрузку. Я даже следовал за сейчас устарела спецификация сканирования Google AJAX ,

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

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

Позвольте мне перевести сообщения из Маунтин-Вью в бизнес-термины:

Если вы используете JavaScript-фреймворк, ваш SEO не работает.

Вот лишь несколько анекдотов о JavaScript и SEO, чтобы подчеркнуть, почему все идет не так.

«Если вы будете искать какие-либо конкурентные ключевые слова, это всегда будут сайты, представленные сервером. И причина в том, что, хотя Google индексирует HTML-код, отображаемый клиентом, он еще не совершенен, и другие поисковые системы не делают этого также. Вы заботитесь о SEO, вам все еще нужно иметь контент, предоставляемый сервером ».

https://youtu.be/0wvZ7gakqV4

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

«Иногда при рендеринге дела идут плохо, что может негативно повлиять на результаты поиска по вашему сайту». «В декабре 2017 года Google деиндексировал несколько страниц Angular.io (официальный сайт Angular 2). Почему это случилось? Как вы уже догадались, единственная ошибка в их коде не позволила Google отобразить их страницу и вызвала массовую деиндексацию ».

https://www.elephate.com/blog/ultimate-guide-javascript-seo/

Страница CSR загружается браузерами и пауками без содержимого. Вот как типичный одностраничный сайт приложения выглядит для поисковой системы:

Вы видите, чего не хватает?

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

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

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

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

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

Но подождите, это еще не все!

Как работают ссылки SPA?

Как работают одностраничные приложения?

Я уже показал вам, как выглядит ваша разметка SPA. Теперь пришло время узнать, что такое одностраничное приложение и как оно развивалось.

Что такое одностраничные приложения

В начале десятилетия Интернет столкнулся с самым большим конкурентом - мобильными приложениями. В то время браузеры и веб-стандарты были очень фрагментированы. Около 10 лет назад большинство веб-разработчиков быстро приняли jQuery как способ создания современных веб-сайтов.

jQuery абстрагировал большинство различий в реализации API, с которыми мы столкнулись в то время, и сделал JavaScript доступным. Для большинства из нас это был первый приятный опыт JavaScript.

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

Мы (разработчики) сошли с ума.

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

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

В 2010 году я создал свое первое мобильное одностраничное приложение (SPA). В то время никто не называл их SPA, я был своего рода пионером. Я запустил приложение с более чем 400 просмотрами (страницами), которые загружались очень быстро через 3G.

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

Перенесемся через год или два, и мы начали видеть, что термин SPA используется все больше и больше. JQuery не очень подходит для этого нового типа веб-приложений.

Кроме того, большинство «веб-разработчиков» на самом деле не являются веб-разработчиками, они являются внутренними разработчиками.

Таким образом, фреймворки начали появляться из умов бэкэнд-разработчиков ... подробнее об этом в следующем разделе.

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

Этот метод был изначально разработан в первые дни Интернета, чтобы обеспечить возможность перехода к различным частям веб-страницы из оглавления.

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

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

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

Перенесемся в современную сеть. Браузеры добавили событие hashchange, когда изменился фрагмент хеша URL.

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

Твиттеру даже приписывают изобретение 'hashbang', #, который большинство SPA используют, чтобы отличить традиционный якорь от якоря SPA.

https://yoursite.com/#!route-to-page-content

Пауки поисковых систем обычно не выполняют JavaScript для «поиска» ссылок и контента. Google неоднократно заявлял, что использует прямые ссылки, а не хеш-фрагменты для прямого доступа к вашему контенту.

Одностраничные приложения обычно используют модель App Shell. Это где основной макет страницы отображается в первую очередь. Затем каждый вид или содержимое страницы отображается в основной области содержимого. Возможно, некоторые основные макеты будут изменены по мере того, как приложение живет в браузере, но по большей части оно статично.

Когда пользователь «перемещается», выполняется JavaScript, чтобы создать обновленный HTML и заменить основной контент.

К сожалению, для SEO паук должен «выяснить» все URL на стороне клиента.

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

Google рекомендует вам использовать рендеринг на стороне сервера и реальные теги привязки с реальными URL.

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

Новое руководство на самом деле является упрощенной версией спецификации AJAX Crawling, которую они устарели несколько лет назад. Эта политика была нацелена на то, чтобы вы преобразовали слаг SPA (значение фрагмента хэша) в параметр queryString и сконфигурировали свой сервер для поиска этого значения queryString.

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

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

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

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

Я был прав.

Если ваши разработчики говорят с вами об изоморфном JavaScript, просто скажите «нет». Скажите им, чтобы они просто визуализировали контент на сервере и забыли церемонию на стороне клиента.

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

Сегодня я использую серию nodejs Lambdas в AWS для отображения моих страниц на статическом веб-сайте. Я использую некоторый клиентский JavaScript, но это лишь малая часть того, что загружает большинство сайтов. Появление работники сферы обслуживания позволили удалить большую часть моего клиентского скрипта, вы должны рассмотреть это как вариант.

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

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

Это большая часть того, что AMP делается.

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

Эволюция или распад фреймворков JavaScript

Вернуться к временной шкале JavaScript.

Мы стали свидетелями появления новых фреймворков, которые понравились этим первоклассным разработчикам. Angular был первым популярным фреймворком. Вскоре последовал React. Другие пришли вместе, но не смогли добиться такой же тяги, как эти двое. Я даже слабо назвал свою коллекцию небольших библиотек и архитектуры «Love2SPA».

Примечание: Angular и Polymer были созданы в Google. Это не означает, что поисковые или браузерные команды являются поклонниками этих фреймворков. На любом крупном предприятии есть «внутренние раздоры», руководители которых, как правило, замалчивают.

Делай, как я говорю, а не как команда в другом здании

К сожалению, эти фреймворки были разработаны без учета целей бизнеса (UX) и работы браузеров. Вместо этого они сосредоточились на создании «отличного» опыта разработчика.

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

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

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

Технический термин для этого 'Jankiness' ,

Каждая из этих платформ опирается на сотни килобайт JavaScript. Но это не останавливаться на достигнутом.

Часто эти фреймворки дополняются дополнительными, плохо оптимизированными библиотеками и компонентами. jQuery страдает от подобных явлений с экосистемой плагинов. Эти компоненты составляют вес, необходимый для этих каркасов.

Расширения увеличивают полезную нагрузку JavaScript до мегабайт.

Разработчики ленивы и страдают от синдрома дефицита внимания в массе. Это означает, что они, как правило, размещают несколько фреймворков на веб-странице. Я нахожу все более и более привычным видеть 2-4 фреймворка, наложенных поверх jQuery и других вспомогательных библиотек.

Результат - 3-6 МБ JavaScript, большинство из которых никогда не используется, но задерживает превращение страницы в интерактивную.

Но это не останавливаться на достигнутом. Я открываю для себя все больше и больше сайтов с файлами JavaScript объемом 10-50 МБ, не только всего, но и большими файлами.

Не говоря уже о том, что стоимость разработки и обслуживания этих Франкенштейнов огромна.

Как SEO, специалист по цифровому маркетингу и т. Д. Вы, вероятно, слышали, что вам нужен быстрый веб-сервер, оптимизация изображений и т. Д. В то время как вы должны делать это, проверяйте JavaScript вашего сайта. Окупаемость намного выше.

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

Если скрипт изменяет DOM (структуру HTML), он перезапускает критический путь рендеринга, вызывая дальнейшие задержки. Эти структуры почти всегда вызывают этот дорогой перезапуск.

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

Они почти всегда работают на высокоскоростных компьютерах с процессорами i7 и 16 ГБ оперативной памяти. Потребители, как правило, используют мобильные телефоны с гораздо менее мощными процессорами и ограничениями памяти. Потребительский опыт усиливает любой налог на производительность в геометрической прогрессии.

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

Я покажу вам, как вы можете сделать это, не покупая телефон позже!

У тебя есть 3 секунды, чтобы произвести впечатление , С научной точки зрения у вас действительно есть 1 секунда, потому что именно здесь ум начинает воспринимать латентность от ожиданий.

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

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

Это не верно.

Типичный профиль загрузки и рендеринга веб-страницы имеет около 5% времени для выделения первого байта. Это означает, что 95% времени, необходимого для рендеринга веб-страницы, - это время, необходимое для обработки всех сетевых ответов, рисования содержимого на экране и удаления с пути.

«80-90% времени отклика конечного пользователя тратится на интерфейс. Начните с него».

Стив Соудерс

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

Когда скрипт встречается, браузер запрашивает его с сервера, что должно занять 200-1000 мс по хорошей широкополосной сети. Но большинство пользователей не имеют широкополосного доступа, они сегодня пользуются сотовой связью. Это означает, что для загрузки файла сценария вам необходимо выделить 1-3 секунды.

Умножьте это на 5-10, если у вас есть один из этих 50 МБ сценариев!

Вы не сделали, даже не близко.

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

Эта обработка включает в себя парсинг скрипта и выполнение всего скрипта , Это требует времени. Большие фреймворки обычно составляют 100-500 Кбайт JavaScript. В среднем на мобильных телефонах это занимает несколько секунд.

Если у вас несколько сценариев, а на большинстве страниц - десятки, этот процесс повторяется.

Даже если разметка и CSS отобразили некоторые элементы на странице, они будут казаться замороженными. Вы даже не можете прокрутить страницу.

Для потребителя это означает, что страница не работает. Они не ждут, они уходят.

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

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

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

Способы, с помощью которых вы можете измерить производительность в сети без дополнительной инженерной степени

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

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

Есть два бесплатных инструмента, которые я рекомендую всем, кто участвует в веб-сайте, научиться использовать, WebPagetest и инструменты разработчика браузера.

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

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

• Табель успеваемости (стрелять для А)
• Время до первого интерактивного (документ завершен)
• Сетевой водопад (меньше запросов и лучше - лучше)
• Индекс скорости (1000 или менее идеально)
• Просмотр киноленты (смотрите, когда ваш контент рендерится)

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

Когда вы запускаете тест, я рекомендую выбрать вкладку «Chrome» и включить тест Lighthouse. Это даст вам дополнительные данные, в том числе, насколько хорошо вы набрали как прогрессивное веб-приложение ,

Pro Совет: перейти к https://www.webpagetest.org/easy.php иметь предварительно настроенную среду для тестирования вашей страницы.

Вы можете запустить тест Lighthouse прямо из локального браузера Chrome.

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

Lighthouse отлично справляется с выводом значимых данных так, чтобы любой мог их понять. Инструмент сообщает о многих показателях взаимодействия с пользователем и разбивает их на такие категории, как Progressive Web App, Best Practices, Accessibility и даже раздел с токенами SEO.

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

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

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

Это всего лишь два из моих любимых инструментов. Есть и другие, как WebHint и детальные инструменты аудита, встроенные в инструменты браузера.

Некоторые из наиболее рекомендуемых инструментов в SEO-пространстве, такие как Pingdom, GTMetrix и даже инструмент Google Speed ​​Test, бесполезны.

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

Pingdom и GTMetrix действительно просто измеряют время до первого байта, что важно, но составляет примерно 5% от среднего времени рендеринга страницы.

Резюме

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

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

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

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

Поверьте мне, ваш сайт не нуждается в фреймворке JavaScript, HTML и CSS могут удовлетворить большинство ваших потребностей без помощи JavaScript.