Комментарии 171
Однако в js едва ли запихнут паттерны.
Мы в своё время запихнули. Но это было давно. Сейчас надо выбирать более подходящий фреймворк.
Уже сейчас самое интересное, что даёт какой-нибудь реакт или даже ангуляр — это сокрытие солидной части «кишок» MVC
Это каким образом реакт и ангуляр скрывают кишки mvc?
State management — это кишки MVC, да и в общем виде вопрос поддержки соответствия между M и V — это те самые кишки.
Ну и весь стейт менеджмент что в ангуляре что в реакте лежит на плечах программиста. Где сокрытие кишок-то?
да и в общем виде вопрос поддержки соответствия между M и V — это те самые кишки
Это вобщем-то нерелевантный MVC вопрос, т.к. способ организации этого соответствия паттерном не регламетирован. Может у вас там подписки, может биндинги, может модель апи вида теребит — это все вполне mvc.
Если приходится работать с домом, как правило, все равно используют какую-то вспомогательную библиотеку — будь то jQuery, или какой-то облегченный аналог, или самописный велосипед.
Это не совсем так работает. В стандарты JS вносят только фичи, которые могут быть полезны разным фреймворкам, например fetch. А такие штуки как Object.observe или HTML imports оказались полезны только отдельным фреймворкам, а не всему сообществу в целом, поэтому в финальный стандарт они так и не попали.
А такие штуки как Object.observe или HTML imports оказались полезны только отдельным фреймворкам, а не всему сообществу в целом, поэтому в финальный стандарт они так и не попали.Что вообще крайне странный подход. Супер полезные фичи не принимают только потому, что они вписываются не во все шаблоны проектирования разом, а только в 70%.
Откуда цифра в 70%? Эта фича была полезна только для Angular, а это далеко даже половина никогда не была. Вот здесь есть больше информации про это: https://esdiscuss.org/topic/an-update-on-object-observe
Кроме того, в стандарт внесли более полезный Proxy, который как оказался более удобным для применения в разных фреймворках: Vue, MobX
Но в том-то как раз и дело, что Object.observe позволил бы в огромном количестве мест обходиться вообще без фреймворка и даже бойлерплейт-обвязок вокруг Proxy.
стало понятно, что старый подход не прижился и порождает запутанный код.Не прижился в Ангуляре, зато прижился в Vue и MobX, т.к. для маленьких систем и/или одностороннего биндинга более удобен. То есть сам архитектурный принцип никуда не делся и вполне распространён, но аргументировалось его принятие или не принятие исходя из потребностей одного фреймворка.
Кроме того, в стандарт внесли более полезный Proxy, который как оказался более удобным для применения в разных фреймворках: Vue, MobXНу не знаю, реализация МобХ могла бы быть значительно изящнее с более простым Object.observe, чем с переусложнённым прокси.
Насчет переусложненности нативного API – у него нет задачи быть изящным. Красота делается в userland-библиотеках, а платформа нужна для того чтобы дать техническую возможность реализации как можно большему числу разных библиотек, чтобы не пришлось переписывать стандарт с каждым новым веянием в стилях программирования.
jquery и прочие, особенно с учетом cdn, это уже скорее стандарт де-факто на многих сайтах, чуть ли не больше стандарт, чем чистый js, отчасти это можно назвать языком более высокого уровня чем js.
Это смотря как собирать и использовать, например у меня есть проект на Vue который полностью весит 32мб но пользователю при работе с сайтом отдается 500кб-1.3мб js в зависимости от страницы, что позволяет работать с сайтом даже при 2G соединении, а учитывая кэш то можно работать вполне даже комфортно.
Да размер jquery меньше но по сравнению с кучей картинок и нестандартных шрифтов — размер не имеет существенной разницы.
Справедливо. Но речь идет не о том что js блокирует работу страницы и не о том что за счет распаковки и своего выполнения он есть больше памяти, а о том сколько приходит данных пользователю.
Плюс для таких любителей считать объем, которые думают что 1 мб js это много нужно учитывать что в SPA не только зашит собственно чистый js но и возможно css in js + довольно большая часть html кода компонентов и иногда например картинка в base64.
Так что вес страницы нужно мерить полностью. И да внезапно не оптимизированные шрифты которые затребовал заказчик в одном проекте составили 60% времени загрузки страницы и 30% рендера.
Да на Vue тоже можно сделать такую жуть что будет рендерится довольно долго, но это уже не проблема технологии как таковой.
На c++ тоже можно забыть затирать объект в куче и использовать костыли с O(n2) и потом ругаться что он медленный и жрет память.
Ну и в конце концов, многие крупные компании вообще уходят даже от JQuery, на чистый JS, пример тому github.
У меня есть знакомый, с которым мы расспорились на тему JQuery vs Vue. В итоге сошлись на мнении, что все таки лучше то использовать, что знает отлично вся команда разработчиков.
А вообще насколько используем подключаемый скрипт можно посмотреть в DevTools -> Coverage. Там же и определиться стоит ли шкурка выделки для переписания на чистый JS
Что-то как-то многовато.
Я не знаю, что курил автор, но у нового ангуляр приложения размер бандла 384KB, а не 6.5MB.
Часто такие авторы меряют размер того, что выдаст не сжатый dev bundle. А в самом запущенном случае — размер исходников в папках включая node_modules =)
Используя code splitting + gzip + сжатый bundle цифры совсем уже другие.
Я подозреваю, что автор взвешивал не-минифицированный вариант с учетом всего html и css. Хотя и в этом случае 2мб для заявленного функционала — многовато. Думаю, что пары сотен кб достаточно на всё.
П.С.: Я уже писал насчет качества ресурса-донора статьи — судя по увиденному там пишут в основном дилетанты для дилетантов.
UPD: Про дилетантизм — немного некорректно, вернее будет что-то вроде «льют воду для новичков под громкими заголовками».
Но блин, столько учить и знать…
Окей, основы нужны — html, css, js. Без вариантов. Немного интерактивномти — jquery. Больше динамики — ajax, http. Бекенд который отдаёт данные — php, python, ruby. Cookies и сессии тоже сюда. Немного красоты — bootstrap. База данных где хранить данные — mysql. Немного клея, чтобы всё это склеить — Linux, bash. Надо бы ещё нормальный инструмент, например толковая ide. Оказывается безопасность тоже надо — https, hsts, tls, let's encrypt, xss и прочие. Понадобилось работать с датами — добавляй moment.js, потом d3.js. Воспроизводимость и лёгкость деплоя — docker, ci/di. Ещё бы тесты и хуки для гита… Всё это я использую для простенького самописного crm как хобби.
На фреймворк недостаточно сил и времени сейчас, ибо надо работать и развиваться в профессиональной сфере.
И когда я смотрю на весь этот стёк, то я ужасаюсь, и хочу всё поменять на xcode, swift и iPhone :)))
Да, я понимаю что в идеале это разные сущности, разные отделы, разрабы, админы и так далее. Но блин, не слишком ли сложно?))
На самом деле не сложно, фреймворки очень похожи друг на друга. Сперва учить es6+ (месяц максимум) потом мне понадобилась на React 3 месяца а Vue уже освоил за 2 недели.
В сухом остатке — то что я бы делал на jquery + es5 пару месяцев я сделал на Vue за 2 недели.
Компонентный подход не прост — но правильное его использование существенно сокращает работу — тем более готовых компонентов куча и подключаются они проще чем плагины на jQuery.
В плагинах на jq разброд и шатание, каждый плагин это свои хуки, свои структуры данных и куча прочих велосипедов. В React/Vue все компоненты типовые и календарь и компонент перетаскивания файла — дают одно и тоже событие но с разным содержимым, при этом привязать нужный обработчик — это дело пары минут.
На самом деле не сложно, фреймворки очень похожи друг на друга.
Громкое заявление. Сравните React и $mol, например, и попробуйте найти хоть что-то общее. Впрочем, освоить $mol можно за те же 2 недели.
Если перейдёте на мобилки, то тесты будут ещё жёстче, IDE будет ещё жирнее, а безопасность уже будет обеспечиваться вами, а не технологиями вроде HTTPS или HSTS.
А так, добро пожаловать в разработку, у нас много интересных задач и много решений для этих задач.
Использование в собственных проектах чужого кода — это всегда риск.Если существует известный поддерживаемый фреймворк\библиотека, то писать собственный велосипед вместо него — это гораздо больший риск.
На самом деле цена каждой библиотеки-зависимости намного больше, чем принято думать. Вот здесь Russ Cox (один из авторов Go) это описал очень подробно: Our Software Dependency Problem.
Я понимаю, когда в браузере пользователь делает что-то по-настоящему эпичное (замена офисного пакета, полноценный почтовый клиент и т.п.), но ведь нет, большинство применений — это старые добрые фантазии на тему firstname, lastname и кнопочки Submit. Господа, в чём же профит?
К слову, заметил, что те действительно сложные и функциональные штуки делали в дофреймворковскую эпоху, сейчас смотрятся старомодно. Сейчас стараются не утомлять юзера лишними наворотами. Показать ему слоган, картинку, ну и эти… как их… firstname, lastname и кнопочку Submit.
(да, конечно, ещё не забываем про галочку согласия с условиями политики приватности с суперсложной логикой не давания нажимать Submit пока галочку не отметил)
Когда я делаю на VUE, то поля отправляют значения в store, оттуда скрипт повешенный на кнопку забирает значения и отправляет через AJAX.
Да, пушкой по воробьям. Но спам уже достал неимоверно. :(
npm install -g vue-cli
vue init webpack frontend
После этого замеряем размерчик папочки «frontend».Справедливости ради, аналогичная манипуляция с ReactJS даёт больше 200.
Так поставьте глобально пакеты. Будет один раз.
И что мешает реализовать эту невообразимо сложную логику на VanillaJS/JQuery?
И что, только ради этого надо вндерять в проект Vue? Не считая того, что его еще придется и изучать? Может про другие преимущества расскажете (в рамках предоставленного maslyaev примера)?
rails new PROJECT_NAME --skip-coffee --skip-test --skip-sprockets --webpack=vue
и затем
rails webpacker:install:vue
На этом я сразу получаю окружение, позволяющее сразу вести разработку приложения. Что такого сложного во «внедрении в проект VUE»?
как же быстро вы подтвердили контроверсионную точку зрения. теперь простой пример формочки firstaneme, lastname, email и кнопки submit требует рельсы...
Я просто упорно не могу понять. Есть три составляющие: сроки, функции, деньги. Если я уложился во все: какая разница, какие технологии и ресурсы я использовал?
А по-хорошему, всё могло бы обойтись стареньким пентиумом, засунутым с глаз долой куда-нибудь в кладовку.
Наличие ресурса, будь то AWS, или просто VPS (а его, поверьте, достаточно для Rails+Vue) — да, издержки этой практики. Но выбор Rails + Vue — это как ответственный подход с точки зрения будущей модернизации.
С другой стороны, мы не можем предвидеть развитие
Когда-то давно можно было уверенно говорить о том, что пилить систему на FoxPro — самое разумное решение, но сейчас все эти крутые начинания превратились в вонючее легаси, которое все мечтают срыть нахрен. Есть ли у нас гарантии, что поделия на Ангуляре, Вуе или Реакте не превратятся в такое же легаси в обозримой перспективе? Просто прикиньте, как сейчас искать спеца, который не только умеет, но и желает докручивать FoxPro, и примерьте ситуацию на наши прекрасные новомодные фреймворки.
Vue дает возможность полностью изолировать компоненты друг от друга. Что-то скрыть, что-то добавить — делается очень легко. Влияние на другие компоненты невозможно из-за scoped стилей. Не нужно думать о разделении стилей по namespace. Обмен — через Vuex. Если нужно — новый разработчик может даже не вникать в старый код — просто пишет новую компоненту, и общается со старыми через Vuex, ничего не зная: ни id компонентов других, ничего. Идеальная изоляция подсистем.
Я говорю только об этом, не замахиваясь на глобальность мироздания :)
Есть ли у нас гарантии, что поделия на Ангуляре, Вуе или Реакте не превратятся в такое же легаси в обозримой перспективе?
Да конечно превратятся! Просто ваша фигня под пентиум превратится быстрее.
Рассказывали байку про сервак, который при очередном ремонте случайно замуровали в простенок, и нашли только когда взялись делать перепланировку. А он себе спокойно всё эти годы работал и выполнял функцию.
1. Фигня — самоизобретённый велосипед. То есть не сильно заморачиваясь универсальностью сделали ровно то, что требовалось. Зависимости — только на стандартные библиотеки. Уровень перфекционизма — средненький.
2. Фигня сделана согласно полному комплекту веяний моды. Зависимости уходят в недра npm (как вариант, PyPI или чего ещё, без разницы), и там рекурсивно подхватывают существенный процент наработок сообщества.
Предположим, прошло 10 лет.
В первом случае после некоторого периода ознакомления с конструкцией пациента просто берём и докручиваем требуемое. И средство разработки, и стандартные библиотеки никуда не делись. Если нужно, на просторах Интернета можно найти что угодно, хоть 3-й турбо-паскаль.
Во втором случае оказывается, что используемые пакеты часть заброшены (и уже несовместимы со своими зависимыми), часть потерялись, часть развились так, что не узнать. Бубен в руки и вперёд, пытаемся восстановить состояние состояние инфраструктуры на тот момент, когда фигня создавалась.
В первом случае чтобы разобраться, нужно освежить знания по средству разработки и его стандартным библиотекам. Во втором — по той Джомолунгме барахла, от которого пациент зависим.
С чисто прагматической точки зрения лично я выбрал бы первое. Ну нафиг бегать с бубном вокруг Джомолунгмы.
1. Фигня — самоизобретённый велосипед. Нужно изучать весь код, чтобы понять что там происходит. Любой кусок функциональности потенциально может оказаться в любом файле.
2.1 Фигня использует заброшенный фреймворк. Приходится искать заброшенный учебник, но потом сразу становится понятно где что в проекте лежит.
2.2 Фигня использует старый, но еще актуальный фреймворк. Тут еще проще: достаточно найти правильного динозавра, и тот во всём разберется.
PS Ваши наезды на npm не вполне понятны. npm позволяет восстановить все зависимости именно в тех версиях, которые когда-то использовались. И даже если про npm все забудут, а центральный репозиторий выключат — где-то может остаться локальный кеш с нужными пакетами.
Но даже если и пакетов нигде не осталось — то можно взять за основу уже существующую и «жужжащую» сборку. Это всё равно на порядок проще, чем декопилировать бинарники, остающиеся от мейнстримовых языков.
Фигня под пентиум будет тихо себе жужжать в углу и есть не просить, пока уборщица провод из розетки не выдернет.
Сервак-то это хорошо все, но я про код говорил. Очень скоро найти человека, который будет поддерживать вашу ваниллужс, будет не проще, чем фокспрошника. Т.к. всем сейчас подавай реакт и смузи.
А вот если при изготовлении фигни её автор в порыве вдохновения изобретал свой ни на что не похожий реакт — да, труба дело. Только посочувствовать.
Github так не думает — https://habr.com/ru/post/418257/
Ну да, классика: https://bash.im/quote/394695
я вот чего-то не понял: как стор решает проблему капчи и спама?
Какое-то время можно их избегать вводя разные скрытые фиктивные поля, которые сбивают с толку скрипты. Например, сделать так: . В этом случае — скрипт будет в это поле вписывать почту, и на беке можно такую ситуацию отследить.
Но в последний год появились более умные скрипты, которые такую ситуацию просчитывают, видимо, путем анализа placeholder или label. Кол-во спама значительно выросло. Поэтому применить способ с полным отсуствием формы — сейчас для меня наиболее эффективный путь.
Вот пример, последнего спама:
Имя: 30857550
Phone fake: 79777777777
Местоположение: ()
Email: 333333@333.ru
Телефон: — Комментарий: Юридическое бюро предлагает услуги юридического сопровождения бизнес-процессов на всех этапах работы компании. тут была ссылка.
Обычно "отломать сайт для ботов" ещё по пути приводит к "отломать сайт для слепых людей со screenreader'ами".
Все говорят про какие-то крутые SPA
99% "крутых спа" — это проекты для внутреннего использования и б2б решения, то есть кровавый ынтырпрайз своего рода, с-но просто человек их не видит
А для того, чтобы ленту твиттера выводить — действительно, спа не нужны.
Чтобы выводить только для чтения, может, и не нужны, но вот для написания ответов, лайков и всего такого уже понадобится более менее толстая клиентская логика, а там уже и до SPA недалеко.
Чтобы выводить только для чтения, может, и не нужны, но вот для написания ответов, лайков и всего такого
уже понадобится более менее толстая клиентская логика
Не надо никакой толстой клиентской логики, чтобы поставить лайк и написать пост. Это функционал гостевухи с народа.
С точки зрения конкретно фронта твиттер — очень простое приложение.
Если перезагружать страницу целиком на каждое действие, то клиентского кода не надо, да.
Но если мы хотим делать без перезагрузки страницы, да еще и так, чтобы при переключении на просмотр одного твита и обратно позиция скролла не терялась, то тут уже надо писать клиентский код.
Сравните два примера:
- pikabu.ru – не-SPA, при переходе с поста на ленту показывается анимация подгрузки, страница ищет, куда вам перемотать
- mobile.twitter.com — SPA, переход со страницы твита на ленту мгновенный
Но если мы хотим делать без перезагрузки страницы, да еще и так, чтобы при переключении на просмотр одного твита и обратно позиция скролла не терялась, то тут уже надо писать клиентский код.
Подгружать отдельные виджеты аяксом научились за долгие годы до появления первых js-фреймворков.
И вы сильно преувеличиваете сложность реализации и издержки подобного подхода для простых интерфейсов.
А отпозиционировать скролл на пост можно вообще через хеш.
Если у вас есть контрпримеры, покажите, обсудим.
В теории оно наверное и могло бы где-то работать как вы описываете
А до реакта, я так понимаю, интернета не было?
В случае заметного количества интерактивного контента SPA оказываются отзывчивее и юзабельнее.
Вы в одну кучу смешали СПА и современные фреймворки.
- Можно делать СПА спокойно без каких-либо фреймворков на фронте, и оно не перестанет быть спа. В случае если у вас простое приложение вроде твиттера — такой подход, в сущности, не имеет каких-то особых проблем. С-но, большую часть существования интернетов именно такие спа и были. На каком фреймворке написан вк? А ведь он существенно сложнее твиттера будет.
- Если у вас сложное приложение — вы берете фреймворк. Там закатывать солнце руками — становится очень печально.
Я не топлю за ноду я за объективность.
С апачем может быть и все сложно (я его не видел последние лет 6, и слава богу). Связка php-fpm+nginx ставится одной командой, после этого достаточно немножко отредактировать конфиг nginx'а и в общем-то все будет работать сразу.
А если нужно локально повеселиться — apt/yum install php-cli && php -S localhost:8080
.
Между тем, минифицированный vue.js сейчас весит 86,5kb, и я готов платить эту цену за удобство и реактивность. И даже подтяну к нему компоненты для красивых селектов, дэйтпикера, и редактора. Ещё почти 100 kb, ужас прямо, особенно учитывая что всё это закешируется.
И да, возможно приложение будет тормозить, но не из за библиотек, а из за того что я на страницу подтянул несколько разнородных массивов данных из разных источников (на секундочку — несколько mb в gzip), отрисовываю их по разному, возможно работаю с ними, сравниваю, меняю… Эти проблемы решаются уже рефакторингом кода, нахождению узких мест, переписыванием алгоритмов — и они так же(а то и сильнее) тормозят на тех же данных на страницах на которых пока старый легаси код на jquery. А форма с простым submit где в селекте попытались отрисовать 10к элементов — вообще нормально не работает без автокомплита на стороне сервера.
Весело
безопасны, с документацией, по ним есть опыт у других разработчиков, на них не тратится бюджет
Это да.
В среднем они лучше написаны
А вот это — неа.
В лучшем случае они в среднем лучше написаны с т.з. сферического качества кода, а не решаемых проблем. Если только задачи не совсем непроходимо типовые без малейшего шага в сторону.
Сторонние велосипеды как правило решают задачу либо другого уровня обобщения, чем нужно, или кучу задач одной области, из которых в конкретном случае надо далеко не всё. Итого со сторонним велосипедом либо привносится «мусор», без которого можно было бы обойтись, либо же сторонний велосипед надо напильником и такой-то матерью слегка приспосабливать под имеющуюся задачу.
В среднем они лучше написаны
Анекдот про «В среднем они обе проститутки» знаете?
безопасны
Даааа? Возможно, если это велосипед написанный большой компанией, то код велосипеда проходит аудит безопасности. Возможно. А возможно и не проходит. А проходит ли аудит безопасности код, который используется этим велосипедом?
с документацией
Которой а) не хватает, потому приходится искать доклады, Best Practice и далее, далее б) Лучше бы не было, потому что она морально устарела или написана в стиле «вот переменная, вот класс, вот метод, вот так строится синхрофазатрон».
Я не говорю, что все фреймворки такие, но сам зачастую лезу в код очередной поделки, потому что в документации чушь.
по ним есть опыт у других разработчиков
Это не Rocker Science и не музыкальная теория, осилить фреймворк не составит труда любому более менее приличному разработчику. Вы не говорим о jQuery/Django/RoR программистах, которые просто не умеют ничего другого.
Учить надо алгоритмы и структуры, а не фреймворки. Не помню, кто сказал.
на них не тратится бюджет
Тратится. Фреймворк требует тестирования, проверки работы, исправления багов самого фреймворка, его обновления (и обновления вашего, кода который его использует).
Я не говорю, что нельзя использовать фреймворки. Конечно можно и нужно. Но стоит понимать, что фреймворк написан для решения конкретной задачи у конкретного человека (компании). Либо это монстр, который старается решить проблемы всех людей в мире и 99% его возможностей вы никогда не используете.
Что до рассматриваемой здесь ситуации с фреймворками, это всё же две немножко разные задачи — изобрести велосипед под конкретную потребность и условия эксплуатации, или средство изобретания велосипедов на любые случаи жизни.
вариации на тему: вы бы предпочли велосипед от giant / harley davidson или сваренный в гараже из остатков профиля и арматуры?
Если мне надо клетить девочек (ну или мальчиков) и я живу в городе, езжу по облагороженным паркам и имею доход для обслуживания — конечно giant / harley davidson.
Если я живу где-то в сельской жопе мира — я лучше сварю из арматуры, поставлю нормальные арматизаторы и буду гонять, не боясь сломать эту фигню.
В реальности я не куплю никакой, потому что живу на 5-м этаже в доме без лифта и имею проблемы со спиной, что выражается в отсутствии желания таскать на себе хоть что-то лишнее.
Систему нагружают ненужные операции по обновлению страниц, избыточные прослушиватели событий, глубокое сравнение объектов, без которого можно обойтись, неоправданно масштабные манипуляции с DOM. Избавиться от всего этого можно просто сделав всё своими силами.
Примечательно, что автор реализовал "своими силами" вызов полного ререндера в каждом сеттере. Во "фреймворках", наверно, что-то ещё более адское творится, раз он так "соптимизировал".
Для приложения такой сложности, как в статье — это абсолютно верный подход, потому что простой, надёжный, и с приемлемой производительностью. Что-то более оптимальное в данном случае это типичный пример premature optimization приводящей к излишнему усложнению кода и, возможно, багам.
приложения такой сложности
Какой такой? Как по мне тут слишком много кода для такой простой задачи. При этом данный код стыдно выпускать в прод, так как нет индикаторов ни на загрузку данных, ни на сохранение. Нет кнопки "повторить оборвавшуюся загрузку". В случае любой ошибки показывается белый экран. И тд, и тп.
простой
Ручной менеджмент состояний — это нифига не просто. Нужно каждый раз, что-то меняя, вручную проходиться и всё обновлять.
надёжный
Тут мы видим много дублирующейся логики, которая рано или поздно разъедется и привет ночи с дебаггером. Ручное обеспечение инвариантов — это источник чуть-ли не 90% всех багов.
с приемлемой производительностью
Ага, на тестовых данных с 3 рецептами. Как только пользователь внесёт несколько десятков всё начинает адски тупить.
premature optimization
А вы почитайте первоисточник этого выражения. Там речь про то, что нет смысла заниматься локальной низкоуровневой оптимизацией, пока не оптимизирована высокоуровневая работа кода, так как после высокоуровневой оптимизации низкоуровневый код либо летит в трубу, либо перестаёт быть узким местом.
излишнему усложнению кода
Использование правильных абстракций код, наоборот, упрощает. Так как за счёт накладываемых ими ограничений, библиотечный код может применять оптимизации, обеспечивать инварианты, реализовывать всю типичную рутину, на которую у человека никогда не хватит усидчивости.
А почему вы так считаете? У вас уже есть большое приложение на веб-компонентах и масштабируется нормально?
А я вот сейчас в сторону blazor смотрю, и то, что я вижу впечатляет
Связка web assembly + .net через некоторое время сделает ненужными вот эти тонны адских js-based фреймворков.
Реализуя концепцию .net everywhere разработка spa станет такой же комфортной, как и создание десктоп приложений.
знатный вброс получился
Что было бы если каждый человек писал без фреймворка, насколько увеличилось бы время до релиза? А имея основу, гораздо прозе и правильнее сфокусироваться на конкретной задаче, на конкретно своей идее и проекте.
За эти 60% процентов вы «покупаете» себе предсказуемость, документацию, фиксы безопасности и баг-фиксы, поддержку комьюнити, расширяемость.
Так же по мере роста проекта в него все реже добавляются новые пакеты и все больше пишется своего кода, соотвественно использовать фреймворки будет все выгоднее и выгоднее.
Вот и вся метрика. с определенной степени сложности/размера приложения/частоты обновления становится выгодно использовать фреймворки, до определенного — это неоправданно дорого.
Переслены три варианта любого проекта: из г**на и палок без фреймворка, по-простому с мини-фреймворком и по серьёзному с полнофункциональным фреймворком.
Все три варианта имеют право на существование, даже в крупных проектах. Ну понятно, что это сложно — поддерживать мега кода из г*а и палок, но они существуют.
1. Необходимо пилить много вспомогательных функций
2. Требуется хороший архитектор, чтобы «свой фреймворк» разросшись не погубил себя
3. Документирование его использования
4. Отторжение новыми программистами, которые заходят на проект (многие программисты предпочтут использовать общеизвестный фреймворк и развиваться в нем, получать опыт и соответственно повышать свою стоимость в случае перехода в другую организацию)
На самом деле в комментах много лукавства. Конечно хорошо профессионально овладеть каким-нибудь фреймворком и заточить под это дело воркфлоу. Особенно если работаешь на постоянке. Разворачивание проекта, вхождение в процесс — занимает очень мало времени. А вот переезжать на другую технологию, или, упаси бог, «даунгрейдиться» до ванильных html/css/js — брр… Поэтому сразу начинаются холивары о модных тенденциях во фронтэнде, об удобстве компонентного подхода по сравнению с семантическим и т.д.
Поработайте во фрилансе. Желательно не стартуя с новым проектом, а доделывая за кем-то. Ад и Израиль! Куча мала из смеси фреймворков и нативных сущностей. Зато на какой-то модной штуке. Которую, во-первых, надо умудриться запустить («А вы чем собираете? Грунтом? Попробуйте Ярн! Не работает? А у вас какая версия?»). А во-вторых, разобраться где там куда всё распихано… Хотя как там фреймворки позиционируют? Удобство и скорость?
С «устаревшим», но вменяемым «ванильным фронтэндом» эта проблема практически не всплывает.
Программистов куда не запусти — тут же начнут обмазываться какими-то «оптимизаторами рабочего процесса» и повышать порог вхождения. Вот и до фронтэнда добрались. Что там на очереди? Дизайн?
Это несправедливо. Конечно в идеальном мире можно было бы ожидать каких-то идеальных решений, созданных на идеальном API. Но в реальном мире приходится чем-то жертвовать.
Если под фронтендом имеется ввиду полторы анимации выпадающего меню на статичной странице-лэндинге тогда да, вполне возможно.
Идеальный ванильный фронтенд с обходом всех косяков всех браузеров (точно всех? и тесты есть?) и имеющий хоть сколько-нибудь интересный функционал — ну вот например банальный date-picker — но не тот про который вы скажете "ну используйте нативный type="date"
, а посложнее чуть — с подсветкой доступных для вылета дат (реальный кейс, помните у всех были сайты авиабилетов в 2011-2012 году?) или выбором внутри диапазона дат (тоже реальный кейс, уже из отельного бизнеса) будет писаться долго, муторно, а после ухода программиста его написавшего — еще и крайней неохотно поддерживаться.
Как только появляется необходимость управлять состоянием, синхронизацией с сервером, более-менее сложных асинхронных вариаций форм — все, привет. На ванильном коде далеко не уедешь (ну или уедешь но добираться будешь крайней долго)
Конвейер это быстрее и лучше во многих отношениях, хотя бы на примере автомобилей. Но, как ни странно, существую автомобили и мотоциклы собранные в ручную. С каждым подходом вы получаете определённые плюсы и минусы. Замечу(мне так кажеться), что результат зависит не от использования фрейморка(конвейера) или его не использования(руки). Есть прекрасные образцы как ручного труда, так и сделанного на фрейворке таком-то. И весь хайп не из за подхода (каждый хвалит свою капусту), а из за людей, которые крафтили плохой код на конвейере или самоделку.
Поддерживать говнокод всегда сложно и там и там. Хороший код всегда хорошо поддерживать и ручной и не ручной.
Если Вам удобно писать с использованием фреймворк(ов)(а), отлично! Но это не значит, что Вы выдаёте максимальную эффективность (иногда, неожиданно, даже по показателем времени). Чёткий пруф с графиками я не готов предоставить. Мой опыт, я даже допускаю, что он, не совсем мал не идёт ни в какое сравнение с тысячами разработчиков. Но я замечу, что, обычно, фреймворки решают определённый круг задач, и как только Вы выходите за пределы фреймвор — это уже нагрузка, а не помощь.
Я не против фрейморков, они решают типовые задачи, и делают это хорошо. Но это всего-лишь инструмент. И в заголовок можно написать что-то типа «Когда наконец исчезнут отбойные Молотки». Ответ очевиден =)
Однако в случае фронтенд-фреймворков почему-то аргумент про 99% типичных ситуаций уже не подходит, и всегда получается длинное обсуждение, о том как здорово делать все самому. Видимо, DIY-специфика Хабра влияет.
Все таки нужно уметь находить баланс между VanillaJS и FW.
Как многие сказали — фреймворки упрощают разработку, но в то же время они увеличивают размер страницы и влияют на производительность. Для каких-либо личных (читать как простых) или очень сложных проектов (например, панели управления чем-то, полноценные приложения) использование фреймворков оправдано. В первых случаях они ускоряют разработку, во вторых — упрощают поддерживание и наращивание функциональности.
Для проектов средней сложности (думаю что хабр можно отнести к таким), и проектов с которыми регулярно взаимодействуют я бы предпочел использовать как можно меньше сторонних библиотек/фреймворков. В таких проектах, как мне кажется, сложная логика на клиенте требуется чуть больше чем никогда, и цеплять всякие vue/react/angular для того чтобы отрендерить формочку для отправки комментария или цеплять jQuery чтобы просто выбрать элемент по селектору и добавить к нему класс — ну такое себе...
1) Берем React и делаем свой продукт
2) Продукт разрастается, начинает тормозить, пилим свой велосипед
3) Выкладываем в опенсорс и получаем очередной публичный FW
4) Другие разработчики… Возвращаемся к пункту №1
Когда исчезнут JavaScript-фреймворки?