Comments 14
Я никогда не занимался вебом профессионально. Но представление разумеется имею, html/css/js и несколько языков для бэкенда знаю, что-то по мелочи иногда делал. Вот сейчас делаю пет-проект - локальную систему для изучения социальных графов соцсети VK. Серверная часть на Go, интерфейс - простой сайт на локалхосте.
И вот что меня интересует: а что дают фронтенд-фреймворки по сравнению с чистым Javascript? Да, поскольку я не профессионал в вебе, то возникают вот такие странные вопросы. Я явно что-то не понимаю, но хочется понять:) Допустим, какой нибудь одностраничный сайт - там и js как таковой вообще не нужен, все можно написать на чистом html. Или взять с другой стороны - какой нибудь монстр типа Google Docs. Сложнейший программный комплекс. Но часто ли вы пишете что-то подобное? Можно взять середину - сайт типа Хабра. Солидный сайт, но что здесь есть такого, что требует сложного кода на JS? Пожалуй только редактор статей/комментариев. Остальное - ну лайк поставить, это же просто. И требуется ли для этого фреймворк (кстати, если да то интересно какой используется)?
В общем я для своего личного проекта пока спокойно обхожусь чистым JS (даже не jQuery). Пока один файл на 8Кб, и в основном там однотипные обработчики нажатий кнопок для запаковки отправляемой информации.
То есть лично для меня на Хабре не хватает статей на тему "введения в веб-фреймворки", где рассказывается что это такое и показываются преимущества работы с ними по сравнению с чистым JS. Статей по самому JS полно, в том числе для новичков. И иногда появляются профессиональные (на мой взгляд со стороны) статьи по фреймворкам, где разбираются какие-то сложные частные кейсы. А вот таких вводных статей нет.
Без Single Page Application можно и без фреймворков. А с SPA ещё придётся повозиться, если фронтенд аналитики переусложнили и на проекте есть фанаты SPA. Хабр няшечка, он поисковиками хорошо индексируется и SPA не использует. SPA индексируется намного хуже. Если пишем очередной аналог Skype, то SPA + Electron. А если хотим, чтобы были индексируемые каналы в нашем мессенджере, то забываем про SPA.
Если нужно чтобы данные подгружались на лету, то без фреймворков будет тяжеловато. Ну и сам jQuery тоже можно считать за фреймворк
Вот и как объяснить такому человеку, зачем нужен Alpine.js?
Привет!
а что дают фронтенд-фреймворки по сравнению с чистым Javascript?
К преимуществам фреймворков я бы отнес:
1. Встроенную, в некоторые из них архитектуру, например, тот же Angular
2. Поддержка из коробки компонентного подхода, который достаточно удобно применять на проекте. Это также можно реализовать и на чистом JS, но в фреймворке это сделать намного легче. Пример конкретной реализации - React Component
3. Встроенные оптимизации рендеринга. Манипуляции с DOM-деревом достаточно медленные. Хотелось бы как можно меньше трогать DOM-дерево. Фреймворки в том числе занимаются и этими оптимизациями. Примером конкретной реализации является Virtual DOM в React
4. Удобный функционал, который поставляется вместе с фреймворком:
4.1. Типизация, во многих фреймворках из коробки, если нет, то существуют готовые инструменты для сетапа всего проекта: vite, cra
4.2. Удобная работа со стилями. В статье писал о минусах использования чистого css, так вот в фреймворках эти проблемы тоже решены
5. Удобство при работе с SPA, когда рендеринг происходит на клиенте. Также каждый популярный фреймворк имеет свою реализацию SSR/SSG. Это все полезно, когда возникают вопросы с SEO/скоростью загрузки страниц.
Ну и есть еще много всяких мелочей, например, экранирование вставленного контента, чтобы предотвратить XSS и тд.
Соглашусь с вами, что для маленьких проектов достаточно и реализации на чистом js. Но на более крупных проектах, я советую посмотреть в сторону фреймворка.
Вы также можете воспользоваться каким-то vite и буквально за одну команду засетапить себе проект, используя любой популярный фреймворк.
Также считаю, что опыт с реализацией на чистом js очень важен для понимания работы фреймворков, ведь любой фреймворк в конечном счете использует какой-то document.createElement для вставки =)
Серверная часть на Go
Зачем? Есть же ассемблер или Си, к чему вся эта новомодная фигня? Что там вообще такого в серверной части, джейсоны туда сюда перекладывают и всё. Я для своего личного проекта джейсоны на Си перекладываю. Вот взять хабр. Зачем там хипстерский Go, что там такого? Улетел комментарий, прилетел комментарий...
Есть же ассемблер или Си
Зачем эта новомодная фигня? Что там такого в серверной части, просто нули и единички гоняются. Я для своего проекта просто нанял индуса, которому комментарии на почту приходят, он их в бинарники переводит, и затворы транзисторов сам щелкает. Где надо 0 - там 0, где 1 - там 1. Вот взять хабр. Зачем там хипстерский Си, что там такого? Улетел комментарий, прилетел комментарий...
react/vue/angular/etc дают тебе обертку над DOM для простоты манипуляций "на лету" (то что про SPA уже писали). Плюсом к этому стандарт написания кода под конкретное api, что позволяет и код переиспользовать (ui-kit например) и разрабов "переиспользовать" в других проектах.
Для сравнения представьте, что таких как вы 10 человек и все свои пет проекты пишут на чистом js, а потом вы захотите объединиться в один суперапп. Пример, конечно, фантастический, но если бы вы писали на одном фреймворке, то объединить код было бы куда проще, не говоря уже про переиспользование его в других проектах
Несколько раз пытался понять, что такое менеджеры состояния. Пока остановился на том, что это такие штуки, которые менеждерят состояние. Как бы вы объяснили маме, что это такое?
Недавно пет так разросся что пришлось смотреть в их сторону. Боже, какие сложности на пустом месте там накручивают. Как по мне абстракция, ради абстракции. Если нужен простой менеджер состояний (вернее его аналог), лучше смотреть в сторону dexiejs. Не технология а сказка. Кстати может ли кто то объяснить почему так сильно любят mobx на Хабре и так хейтят redux?
может ли кто то объяснить почему так сильно любят mobx на Хабре и так хейтят redux?
Выбор стейт-манагера делается на основе вкусовых предпочтений и удобства (субъективного, разумеется). А выбор между мобх и редукс - это ещё и ООП vs. ФП, что, безусловно, обостряет холивар. Редукс хейтят все, кто видит там сложности, на пустом месте накрученные, о которых вы же и говорили.
Пульт от телевизора - менеджер состояния (телевизор включен\выключен, канал какой-то выбран и т.д., и можно этими состояниями управлять)
Менеджер состояния - это регистратура в поликлинике. В ней лежат данные, доступные на чтение и на запись во всей поликлинике, притом в определённых местах и определенными методами. Вы прошли обследование у лора, он пишет какие-то данные в вашу карту, потом вы идете к хирургу, он смотрит в карту (читает данные), анализирует, пишет в карту свои выводы (пишет данные). Так вот регистратура - это менеджер состояния, а карточка - модуль менеджера состояний. Может быть одна, а может быть много, не важно.
Зачем? Когда вырастает довольно большой проект, в котором много компонентов, им бывают нужны одинаковые, синхронизированные данные. Например, какие-то данные с бекенда, для этого их получают в менеджере состояний в экшонах, пишут в стейт и получают в любом компоненте.
P.S. Если еще проще - менеджер состояний - это NAS в вашей сети. Любое устройство может оттуда читать данные, любое может писать, главное - что у всех данные одинаковые.
Роадмэп по современному фронтенду от KTS