Vanilla javascript что это
Vanilla JS vs jQuery 2.0
Статья навеяна фреймворком Vanilla.js.
Эпоха старых браузеров уходит в небытие, вряд ли сейчас найдется сознательный человек, использующий ie6,7,8, на зло разработчикам и вопреки техническому прогрессу. Возможно, только по необходимости, например корпоративная система написана под IE6, или лентяи админы издеваются над пользователями и не хотят обновлять/устанавливать новые версии. Тем не менее, статистика использования этих браузеров неумолимо стремится к нулю. Собственно и новая версия jQuery 2.0, отказалась поддерживать устаревшие браузеры(IE 6-8). И тут с релизом jQuery возник вопрос, а для чего же тогда нужен jQuery?
Мое мнение заключается в том, что люди используют jQuery лишь по привычке, или просто не знают базовых вещей javascript и API браузера, который он предоставляет. Чего таить, сам писал на jQuery до того, как освоил javascript…
Но в итоге vanilla одержал верх, на то было много причин, но о некоторых подробнее ниже.
Разберем основные возможности jQuery:
Движок кроссбраузерных CSS-селекторов Sizzle
Что же в этом случае предлагает vanilla?
Для javascript разработчиков знакомо document.querySelectorAll, встроенный в браузер и появившийся даже в IE8. can i use
Но тут кому-то может стать жалко символов, чтобы писать это каждый раз, благо javascript гибкий язык и позволяет писать различные конструкции, чем можно и воспользоваться.
Манипуляции и переход по дереву DOM
Я думаю, что многим знакома картина в проектах:
Конечно, многие скажут, что этому коду прямая дорога на одноименный сайт, и будут правы. В идеале, конечно, next(selector). Но следует задуматься, почему кто-то написал его именно так? А ведь это, типичное поведение для jQuery объектов. Но если не придираться к самому коду, ведь вместо next могли быть различные манипуляции с DOM (css,attr,find. ), записанные в цепочку вызовов, напрашивается вопрос: для чего такая обфускация кода?
Видимо, некоторые пишут код для машины… а не для людей, которым этот код достанется.
Подобно поведение существует и для методов работы с объектами jQuery (node list, array), методы: each, map и др. Необходимость в этих методах была, когда jQuery реализовывал их для старых IE. Во всех современные браузерах есть нативные методы работы с массивами, forEach, map…
Что касательно самого jQuery, пример кода:
Сразу несколько замечаний, элемент массива передается вторым аргументом, что в итерации по списку глупо и нелогично, потому как сам итератор нужен чаще чем индекс, а индекс и вовсе не нужен, но есть this который ссылается на текущий элемент, причем в данном случае, создавая новый экземпляр переменной Number… что показано во 2 примере, очевидно что this и атрибут — не одно и то же. При попытке сравнить this с числом, без преобразования, получится false.
javascript, позволяет, но если каждый будет делать так, как ему того хочется, мир от этого явно лучше не станет.
Параметры в логичном порядке, есть возможность задать контекст исполнения (this), не делая лишних замыканий.
Для манипуляции над DOM объектами существует довольно обширное API, почитать можно на MDN.
События
В случае отсутствия элемента на странице произойдет ровным счетом ничего, в процессе разработки можно ошибиться в названии класса, и jQuery успешно отработает этот случай, а вы будете дальше искать, почему же не работает событие на кнопке/линке, пока не заметите опечатку. Или аналогичная ситуация, когда элемент присутствует на разных страницах, но на первой нужно событие, а на второй нет. Вот тут уже приходится импровизировать, менять имена классов или делать условные селекты.
jQuery здесь всего лишь синтаксический сахар, не более.
В ранних версиях IE, эвенты прикреплялись с помощью attachEvent, что затрудняло работу, а jQuery в свою очередь, делал все автомагически, но теперь все браузеры поддерживают EventListener
что всегда можно переопределить, написав короткий метод или удобную обертку над эвентами(на строк 20), если хватит знаний javascript.
Визуальные эффекты
Набор простеньких утилит для эффектов которые не всегда нужны… Альтернатива? написать самостоятельно, лишь то, что Вам нужно, об этом в статье про vanilla. Конечно не повод городить велосипеды, но не тянуть же ради 1 метода всю библиотеку.
Трудно сейчас представить сайт без ajax. Но что же делает jQuery таким особенным в данном случае?
В предыдущих версиях было очевидно, что ajax запрос должен быть кроссбраузерным и реализовываться по разному, в зависимости от браузера пользователя. Но это в прошлом, теперь jQuery лишь добавляет синтаксический сахар для тех, кто в действительности просто не знает, как создать объект XMLHttpRequest. Спорить трудно, намного короче записать:
без учета самой jQuery вроде коротко, но современные браузеры поддерживают нативный XMLHttpRequest:
что само по себе не сильно выходит за рамки jQuery.ajax.
JavaScript-плагины
Обширная библиотека плагинов на jQuery, слайдеры, скролеры и тд… Клоны библиотек на любой вкус, по запросу в поиске можно найти десятки, а то и сотни идентичных плагинов, отличающихся ничемреализацией и/или автором.
$(‘selector’).сделать_все_как_надо() решает много вопросов, но кто из авторов библиотек может вам дать 100% гарантии, и если что-то пойдет не так, заказчику явно будет не интересно слушать, что виноват Вася Пупкин, зарелизивший баг.
Конечно, Vanilla это не фреймворк, а самый что ни на есть javascript, позволяющий делать все, что необходимо.
Трудно представить, чем поможет jQuery, если вам необходимо написать какой-нибудь класс на javascript или не найдется нужной либы, а вы, возможно, даже и не слышали, что такое prototype(не фреймворк) и для чего он нужен.
Резюме
В итоге нельзя сказать, что jQuery тяжелый фреймворк (33.6 KB сжатый) в наш цифровой век безлимитных интернетов и мобильных устройств с памятью большей 1Гб. Но в большинстве случаев абсолютно бесполезный довесок, замедляющий работу страницы во много раз(как показывают бенчи примерно 50), без которого можно обойтись. Совсем другая ситуация с плагинами. Складывается впечатление, что разработчики вовсе не хотят сами думать, новый таск — новый плагин в проекте. В итоге кол-во плагинов jQuery (которые могут тянуть разные версии jQuery), раздувает js до 0.5 Мб, а то и больше…
jQuery предоставляет синтаксический сахар, ко многим конструкциям клиентского javascript, но ценой производительности, видимо, каждому решать самому, чем жертвовать, временем на разработку или качеством продукта.
Известна точка зрения Никлауса Вирта, которую разделяет часть программистского сообщества: согласно ей, любое расширение языка, не вызванное необходимостью, ухудшает его, так как приводит к усложнению транслятора и, соответственно, к понижению его надёжности и производительности. Одновременно возрастает сложность изучения языка и сложность сопровождения программ. Кроме того, сам факт наличия дополнительных синтаксических средств часто играет провоцирующую роль: он побуждает программиста прибегать к различным синтаксическим трюкам вместо того, чтобы глубже анализировать задачу и реализовывать более эффективные алгоритмы.[wiki]
Порой необходимо задумываться над тем, что вы делаете, работа у программиста такая — думать, вот и постарайтесь.
Речь не идет о том чтобы отказаться от jQuery и писать на vanilla, просто не переоценивать его возможности, бездумно используя, где надо и не надо, думаю все помнят про «как сложить два числа в javascript».
Для чего вам отдельно изучать vanilla JavaScript
Дата публикации: 2019-04-29
От автора: многие люди часто смотрят на vanilla JavaScript и фыркают. Для чего изучать vanilla JavaScript, если у нас есть Angular, React и Node.js? Но именно в этом многие разработчики, особенно новички, ошибаются. Чего они не понимают, так это того, что все это и многое другое построено на JavaScript. Вот несколько веских причин, почему вы должны изучать vanilla JavaScript, даже если вы думаете, что вам это не нужно.
Понимание
Изучение vanilla JavaScript — это все равно что учиться строить дом с нуля. Вы не зависите от комплектов и моделей, которые в долгосрочной перспективе могут не соответствовать требованиям вашей мечты. Хотя это решает краткосрочную проблему необходимости быстрого производства чего-либо, ваша способность создавать собственные конфигурации ограничена тем, что доступно в выбранной вами среде или библиотеке.
И это еще одна вещь, которую многие разработчики не признают — что существуют фреймворки и библиотеки, помогающие создавать код JavaScript. Без этого вы не сможете создавать то, что вам нужно, на лету. Вы привязываетесь к фреймворкам и библиотекам, которые не будут работать вечно.
Кто-нибудь помнит старые добрые времена jQuery? Никто больше не говорит о когда-то популярной библиотеке JavaScript. Всем нужны React и Angular.
Лучший код
Если вы лучше поймете, как работает JavaScript, у вас будет больше шансов создать более качественный код.
Суть JavaScript в том, что он был создан, чтобы каждый мог писать код. Однако со временем приложения и требования стали более сложными, и JavaScript изменился, чтобы приспособиться к ним.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Это означает, что шаблоны и парадигмы программирования, наряду с идеями других языков, внедряются в природу JavaScript, чтобы предотвратить коллапс приложений.
Большинство основных проблем в программном обеспечении — это проблемы неправильного представления — Рич Хики, дизайнер Clojure.
Когда вы изучите vanilla JavaScript, вы освоите его преимуществам и нюансы. Вы сможете увидеть и понять вещи, которые не видят 90% начинающих разработчиков. С этими новыми знаниями вы начнете воспринимать набор кода по-разному и увидите, где можно улучшить вещи, чтобы уменьшить сложность.
Ускоренное внедрение фреймворков и библиотек
Когда вы изучаете vanilla JavaScript, ваша способность внедрять новые фреймворки и библиотеки увеличивается в три раза. Это потому, что вы сможете посмотреть на фрагмент кода и понять, что он значит.
Разница между теми, кто знает и понимает JavaScript, и теми, кто не знает — это разница между механиком и водителем. Если ваша машина сломается, у механика будет больше шансов починить машину самостоятельно, чем у водителя.
Чтобы стать фантастическим профессиональным разработчиком, вы должны выйти за пределы мышления пользователя JavaScript и войти в пространство создателя. Фреймворки и библиотеки, такие как Angular и React, являются просто инструментами, которые помогают обрабатывать и организовывать JavaScript.
Одно дело научиться пользоваться своими инструментами. Другое дело знать, как эффективно использовать инструменты для достижения ваших целей.
Когда вы изучаете vanilla JavaScript, вы больше понимаете, что делаете. Вы не пишете код, просто потому что в руководстве сказано так.
Долговечность
Фреймворки и библиотеки меняются, но JavaScript — это навсегда.
Ну, на добрую половину десятилетия, по крайней мере, до выхода следующей версии. Но в отличие от фреймворков и библиотек, где нет 100% гарантии обратной совместимости, JavaScript должен быть обратно совместимым. Это единственный язык во время исполнения в Интернете, и если он сломается, у нас у всех будут большие проблемы.
Помните, когда Facebook изменил свою лицензию с BSD + Patents на MIT, и каждый стартап теперь хочет, чтобы их материалы были написаны на React? А как насчет Angular? Я помню.
Помните, когда вышел Angular 2 и все на Angular 1 рухнуло? Я помню. Помните, когда вышел Angular 1, и все перестали говорить о jQuery? Я помню. Но это все еще всего лишь JavaScript — написанный и структурированный по-другому.
Заключение
Когда вы изучаете vanilla JavaScript, вы также учитесь разрабатывать код и способы уменьшения сложности. В то время как учебные пособия по Angular и React сейчас в моде, FreeCodeCamp приложил усилия, чтобы включить vanilla JavaScript в качестве одной из своих сертификаций — и не без причины. Поэтому если вы потратите время на самостоятельное изучение JavaScript, оно безусловно будет того стоить.
Автор: Aphinya Dechalert
Редакция: Команда webformyself.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
JavaScript. Полное руководство
Изучите самый популярный язык разработки и станьте высокооплачиваемым профи
Учите ванильный JavaScript, прежде чем браться за фреймворки
Что такое «ванильный JavaScript»?
VanillaJS – это использование простого JavaScript без каких-либо дополнительных библиотек, таких как jQuery. Люди используют этот термин как шутку, чтобы напомнить другим разработчикам, что многое можно сделать в наши дни без дополнительных библиотек JavaScript.
Или, в нашем случае, без новых, причудливых фреймворков.
Фреймворк Vanilla JS
История сайта Vanilla JS, выдающего себя за сайт очередного JS фреймворка, коротка, но забавна. Эрик Вастл создал его в 2012 году, чтобы с щепоткой троллинга и путаницы объяснить: зачастую можно использовать простой JavaScript без дополнительных фреймворков или библиотек.
Хотя Эрик не использовал термин как таковой, его сайт, безусловно, способствовал его популярности.
Состояние современного «обычного» JavaScript
Исторически сложилось так, что разработчики должны были обходить нативный JavaScript для решения многих задач, например, кроссбраузерности, или просто для выхода за пределы возможностей языка. Речь идет о далеких днях IE 6-7. Очень часто им в этом помогала jQuery. Но сейчас этот продолжительный условный рефлекс опоры на внешние библиотеки уже не нужен, благодаря эволюции спецификации ECMAScript, и современным браузерам, поддерживающим большинство новых возможностей.
Сегодня выбор Vanilla JS вместо jQuery чаще всего является самым разумным, не раздувая кодовую базу ненужными зависимостями. Очевидный пример с великолепного сайта Возможно вам не нужна jQuery:
На этом сайте полно примеров ванильного JS, обязательно посмотрите!
Если вам нужно больше доказательств:
We’re finally finished removing jQuery from https://t.co/r2QL2aHBfa frontend. What did we replace it with? No framework whatsoever:
• querySelectorAll,
• fetch for ajax,
• delegated-events for event handling,
• polyfills for standard DOM stuff,
• CustomElements on the rise.
О JS фреймворках: за и против
Прежде всего, что мы имеем ввиду под термином «JS фреймворки»?
Речь идет о всех этих Angular, Vue, React, Backbone, Ember, Knockout, Ext, jQuery, Meteor, Express, Koa, Total, Socket.io и им подобных. Да, безусловно, они все разные. Да, некоторые из них на самом деле не фреймворки, а скорее библиотеки. Но в рамках этой статьи мы обобщим их, потому что все они имеют общую цель.
За: JavaScript-фреймворки великолепны
Все это упоминается при каждом обсуждении популярных фреймворков. Но это по большей части маркетинг.
Самая большая ценность здесь – это сотрудничество. Последовательный интерфейс и методы позволяют разработчикам из разных стран понимать друг друга и работать вместе.
Если вы создаете приложение с помощью [ваш любимый фреймворк], то когда придет время, вы сможете найти опытного разработчика, который сможет быстро разобраться с кодовой базой проекта и начать работу без объяснений каждой детали вашей архитектуры.
Другой ключевой причиной использования фреймворков является практика. Они заставляют тебя тренироваться снова и снова. И это замечательно! Практика всегда приводит к мастерству, чего бы вы ни пытались достичь.
Против: JavaScript-фреймворки ужасны
Люди, которые работают над реализацией фреймворков, очень талантливы – по крайней мере, большинство из них. Они делают огромную работу по упрощению сложностей. Но все эти уровни абстракции могут быстро стать злом.
В любом проекте наступает день, когда что-то работает не так, как ожидалось, и вы не знаете, почему. Вот тогда и надо начинать копать. Когда вы пробираетесь через плохо документированный, сложный код, вам понадобится глубокое понимание JS, чтобы понять, в чем дело. В противном случае вы потеряете все драгоценное время, которое сохранили, используя свой причудливый фреймворк. Возможно, Вам просто придется купить новую эспрессо-машину, чтобы уложиться в сроки.
Ты не React-разработчик и не Vue-разработчик. Ты просто разработчик.
Конечно, фреймворки полезны для небольших команд, работающих над одним приложением. Да, они сэкономят вам некоторое время (если вы не наркоман рефакторинга). Но что делать, если у вас несколько команд и несколько проектов? Как вы думаете, все руководители групп согласятся на единую платформу для всего набора приложений? А что, если в 2019 появится новый суперфреймворк?
Проблема в том, что в тот момент, когда вы выбираете фреймворк, вы влияете на каждое предстоящее инженерное решение. Кроме того, вы приковываете свою команду к технологии, которая, вероятно, скоро будет устаревшей. Эта ужасно.
Почему сначала нужно учить ванильный JavaScript?
Если вы освоите основы JavaScript, то вашей единственной проблемой при изучении новых фреймворков будет их синтаксис.
JavaScript сейчас – это язык веб-программирования. Понимание его основных инженерных принципов имеет первостепенное значение, если вы хотите построить себе достойную карьеру в этой области.
За последние 5 лет появилось больше 10 фронтенд-фреймворков. Угадайте, сколько будет в ближайшие 5-10 лет? Если вы просто притворяетесь, что знаете JavaScript, этот движок, питающий веб-революцию, как вы будете идти с ним в ногу?
Просто подумайте о том, что сегодня делают «разработчики jQuery»: пытаются догнать Angular. Завтра они будут пытаться догнать React / Vue. И этот грустный цикл продолжается.
Знание ванильного JavaScript позволит вам понять или даже внести свой вклад в JS фреймворки, и поможет выбрать правильный, когда вам это потребуется.
Где и как учить ванильный JavaScript?
Надеюсь, вы готовы запачкать руки простым старым JavaScript. Вот вам суперсовет:
Всегда будьте любопытны, всегда читайте исходники и всегда пробуйте сами.
И еще несколько конкретных рекомендаций:
Для начинающих: вот отличный материал для старта. И еще немного:
А здесь огромный список ресурсов для обучения.
Еще парочка статей:
Заключение
Использование фреймворка, безусловно, даст вам быстрые результаты. Но если Вы не понимаете основные понятия, стоящие за ним, то далеко не уйдете. Научиться играть Wonderwall на гитаре не значит научиться сочинять музыку, но это даст вам повод для практики.
Принцип «сначала изучи основы» применим практически ко всему в жизни. От изучения нового языка программирования до нового вида спорта. Это требует много практики, но когда вы освоите основы, начнется самое интересное.
Ванильный JavaScript и HTML. Никаких фреймворков. Никаких библиотек. Никаких проблем
Используете для создания приложений Vue, React, Angular или Svelte? Я использую, и если вы тоже, и уверен, что вам уже давно не приходилось писать приложение, которое выводит информацию без этих прекрасных инструментов.
Когда-то многие из нас писали веб-приложения только с помощью тех средств, что были встроены в браузер. И хотя современные инструменты помогают нам абстрагироваться от этого (и имеют много других преимуществ), всё ещё полезно знать, что происходит у них под капотом.
При выводе небольшого количества информации вам может потребоваться использовать HTML, JavaScript и DOM без каких-либо инструментов. Недавно я написал несколько базовых примеров, которые иллюстрируют основы веб-разработки и помогают в изучении DOM, HTML, JavaScript и принципов работы браузера. Этот опыт позволил мне понять, что другие разработчики — возможно, вы, — будут рады вспомнить, как выводить информацию без использования библиотек.
Кроме того, это забавно, полезно и помогает понять ценность современных библиотек и фреймворков, которые делают за нас так много работы.
Давайте рассмотрим разные способы вывода информации. И держите под рукой эту документацию!
Образец приложения
Вот приложение, которое я продемонстрировал в своей статье. Оно извлекает список персонажей и выводит их при нажатии на кнопку. Также приложение отображает индикатор выполнения при извлечении списка.
Инструменты
Важно выбрать правильные инструменты. В этом упражнении нам нужно отобразить в браузере информацию с помощью конкретных инструментов, доступных всем нам. Никаких фреймворков. Никаких библиотек. Никаких проблем.
Мы будем использовать только HTML, TypeScript/JavaScript, CSS и браузерную DOM (объектную модель документа). Давайте посмотрим, как можно отобразить HTML.
Как вы могли заметить, я использую TypeScript. Особенности его набора прекрасно помогают избегать багов, и я пользуюсь его возможностью транспилирования в любой формат JavaScript. Если хотите, можете использовать чистый JavaScript. В будущем я напишу статью о том, как транспилировать TypeScript.
Подход
Наше приложение отображает индикатор выполнения и список персонажей. Начнём с самого простого — индикатора, — и рассмотрим разные способы его отображения. Затем перейдём к списку и разберёмся, как меняется ситуация, если нужно выводить больше информации.
Отображение индикатора выполнения
Индикатор должен отображаться, пока приложение решает, какие персонажи должны попасть в список. То есть сначала индикатор невидим, затем пользователь нажимает кнопку обновления, индикатор появляется, и снова исчезает после отображения списка.
Все нижеописанные методики требуют размещения элементов по мере их создания. Например, индикатор и список персонажей где-то должны располагаться. Одним из решений является ссылка на существующий элемент, уже содержащий их. Или можно ссылаться на элемент и заменять его новыми данными.
Отображение индикатора с помощью внутреннего HTML
Просто. Легко. Почему так нельзя сказать про любой код? Ну посмотрите, как быстро этот фрагмент решает проблему!
Вероятно, вы уже заметили, насколько уязвим этот код. Одна ошибка в HTML — и всё! У нас проблема. И действительно ли он удобочитаем? Да, это так, но что будет, когда HTML станет слишком сложным? Когда у вас 20 строк кода с классами, атрибутами и значениями… ну, вы поняли. Да, решение не идеальное. Но при небольшом количестве HTML вполне работает, и я рекомендую присмотреться к нему любителям всё писать в одну строку.
И последнее: innerHTML может влиять на скорость отображения. Я не увлекаюсь избыточной оптимизацией, но лучше проверяйте производительность, потому что innerHTML может быть причиной возникновения циклов отрисовки и вывода макетов в браузере. Имейте в виду.
Индикатор выполнения с помощью DOM API
Уменьшить громоздкость длинных строк можно с помощью DOM API. Создаём элемент, добавляем необходимые классы и атрибуты, задаём значения, а потом добавляем его в DOM.
Преимущество в том, что нужно писать больше кода и полагаться на API. То есть по сравнению с innerHTML при опечатках повышается вероятность, что система сообщит об ошибке, которая поможет найти причину проблемы и придумать решение.
Отрисовка индикатора с помощью шаблонов
Ещё один способ заключается в создании тега и использовании его для упрощения вывода информации.
Создадим и присвоим ему ID. Шаблон не будет отображён на HTML-странице, но позднее вы можете ссылаться на его содержимое и использовать его. Это очень полезно, вы можете писать HTML везде, где это целесообразно: на HTML-странице, с применением всех полезных возможностей HTML-редактора.
Затем код может взять шаблон с помощью метода document.importNode() из DOM API. По мере необходимости код может манипулировать содержимым шаблона. Теперь добавьте это содержимое в DOM, чтобы отобразить индикатор.
Шаблоны — хороший способ сборки HTML; мне он нравится, потому что позволяет писать HTML там, где это имеет смысл, и можно меньше делать с помощью кода на TypeScript/JavaScript.
Можно ли импортировать шаблоны из других файлов? Да, но с помощью других библиотек. Однако сейчас мы от них сознательно отказались. Импорт HTML обсуждается годами, но, как видно из материалов сайта «Can I Use», даже не все современные браузеры поддерживают эту возможность.
Отображение списка персонажей
и списка персонажей заключается в том, что теперь мы:
Отображение персонажей с помощью внутреннего HTML
Это работает. И возможно, это более удобочитаемо. Что насчёт производительности? Трудно ли выявить (или вообще возможно?) опечатки при наборе кода? Судить вам. Но давайте не будем делать выводов, пока не разберёмся с другими методиками.
Отображение персонажей с помощью DOM API
Отображение персонажей с помощью шаблонов
. Сначала на HTML-странице создаём шаблон. Этот HTML-код будет чуть сложнее, чем в случае с
. Но это не проблема. Это просто HTML внутри HTML-страницы, так что мы можем легко исправлять ошибки и форматирование с помощью прекрасного редактора VS Code.
Этот шаблон проще других методик? Я считаю, что относительно проще. С моей точки зрения, код построен по шаблону, который упрощает воспроизведение и читабельность, а также лучше защищает от ошибок.
Итоги
Я не упомянул о том, как отображают информацию популярные фреймворки и библиотеки. Vue, React, Angular и Svelte существенно облегчают задачу и требуют писать меньше кода. Также у них есть и другие преимущества. В этой статье мы рассмотрели лишь относительно простые методики вывода информации с помощью DOM и чистого HTML, а также TypeScript/JavaScript.
Надеюсь, вы теперь представляете, как выводить информацию без использования библиотек. Есть ли другие способы? Конечно. Можно написать функции, которые упростят код и позволят использовать его многократно? Конечно. Но однажды вам захочется поэкспериментировать с одним из таких прекрасных инструментов, как Vue, React, Angular или Svelte.
Эти фреймворки делают за нас много работы. Вы можете помнить, как выводить информацию с помощью чистого DOM-кода с JavaScript или jQuery. Или как делать это с помощью инструментов вроде handlebars или mustache. А может быть, вы никогда не выводили информацию в DOM без помощи фреймворка. Можете сами представить, какие процессы протекают под капотом современных библиотек и фреймворков, когда они выводят для вас информацию на экран.
Полезно знать, что можно сделать с помощью чистого HTML, TypeScript/JavaScript и CSS, даже если вы используете фреймворк, который избавляет вас от всего этого.
Вне зависимости от вашего опыта, я надеюсь, что вам был полезен этот краткий экскурс в некоторые методики отображения информации.