Блог компании RUVDS.com
Angular
JavaScript
ReactJS
VueJS
Комментарии 171
+30

К сожалению, приведённый пример с веб-компонентами не учитывает тот факт, что уже в небольшом приложении сразу же встанет вопрос об управлении состоянием, асинхронных операциях и т.п. Здесь нужны вспомогательные технологии, подобные redux, rxjs, mobx, vuex. В итоге получится некоторый глубоко кастомный фреймворк, для которого не будут существовать готовые рецепты и библиотеки (например, для обработки форм), а порог входа для новичков будет существенно выше, чем при разработке на популярном фреймворке. Придётся тратить дополнительное время на объяснение всех принципов, особенностей, best practices и соглашений. То есть собственно того, что делает фреймворк фреймворком.


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

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

Ну да это полбеды. Средний package.json для двух примерно одинаковых сайтов может представлять такую сборную солянку, что не угадаешь. Кто-то любит grunt, кто-то gulp, кто-то вебпак, кто-то не может жить без lodash, а кто-то считает что минимализм прежде всего. Не уверен, что выбранный фреймворк сильно повышает порог вхождения по сравнению со всем остальным. Разве что порог прохождения собеседования.
0
Ну всё же цель Framework'а не из голов разработчиков бардак убирать, а минимизировать его влияние. Без FWа простор для багов всегда больше. А бардак в головах нужно убирать ещё одним слоем соглашений внутри команды, просто меньшим (например, используем такой framework, такие инструменты и так располагаем файлы). Проще говоря определяем стек.
+6
Насколько я помню Jquery был популярным, потому что в те времена совместимость браузеров была ужасной. поддержка ie6 не давал возможность на реализацию любых фич без jquery. Сейчас js позволяет делать любую фичу jquery без jquery. Скорее всего будущие версии js будут нативно поддерживать функциональность фреймворков.
+6
Однако в js едва ли запихнут паттерны. Уже сейчас самое интересное, что даёт какой-нибудь реакт или даже ангуляр — это сокрытие солидной части «кишок» MVC. И это в js не появится. В то, что в js рано или поздно появится нативная хорошая поддержка шаблонизации — в это я, например, охотно верю. А вот то, что в него типичные паттерны проектирования интерфейсов впихнут в виде «синтаксического сахара» или еще как-то — неа.
0
Однако в js едва ли запихнут паттерны.

Мы в своё время запихнули. Но это было давно. Сейчас надо выбирать более подходящий фреймворк.
0
Уже сейчас самое интересное, что даёт какой-нибудь реакт или даже ангуляр — это сокрытие солидной части «кишок» MVC

Это каким образом реакт и ангуляр скрывают кишки mvc?

0
State management — это кишки MVC, да и в общем виде вопрос поддержки соответствия между M и V — это те самые кишки.
+2
State management — это кишки MVC, да и в общем виде вопрос поддержки соответствия между M и V — это те самые кишки.

Ну и весь стейт менеджмент что в ангуляре что в реакте лежит на плечах программиста. Где сокрытие кишок-то?


да и в общем виде вопрос поддержки соответствия между M и V — это те самые кишки

Это вобщем-то нерелевантный MVC вопрос, т.к. способ организации этого соответствия паттерном не регламетирован. Может у вас там подписки, может биндинги, может модель апи вида теребит — это все вполне mvc.

+1
Сегодня jquery-подобные библиотеки тоже имеют смысл. При всем прогрессе браузеров и стандартов, даже если вам не нужно поддерживать IE/Edge (что до сих пор редкость в серьезном проде) — всё равно нативная работа с домом очень многословная и неудобная.
Если приходится работать с домом, как правило, все равно используют какую-то вспомогательную библиотеку — будь то jQuery, или какой-то облегченный аналог, или самописный велосипед.
0

Это не совсем так работает. В стандарты JS вносят только фичи, которые могут быть полезны разным фреймворкам, например fetch. А такие штуки как Object.observe или HTML imports оказались полезны только отдельным фреймворкам, а не всему сообществу в целом, поэтому в финальный стандарт они так и не попали.

+2
А такие штуки как Object.observe или HTML imports оказались полезны только отдельным фреймворкам, а не всему сообществу в целом, поэтому в финальный стандарт они так и не попали.
Что вообще крайне странный подход. Супер полезные фичи не принимают только потому, что они вписываются не во все шаблоны проектирования разом, а только в 70%.
0

Откуда цифра в 70%? Эта фича была полезна только для Angular, а это далеко даже половина никогда не была. Вот здесь есть больше информации про это: https://esdiscuss.org/topic/an-update-on-object-observe


Кроме того, в стандарт внесли более полезный Proxy, который как оказался более удобным для применения в разных фреймворках: Vue, MobX

+1
Object.observe и RX.Observable — это вот вообще ни разу не одно и тоже, даже не близко. Object.observe — это примерно то, как оно реализовано в Vue.
Но в том-то как раз и дело, что Object.observe позволил бы в огромном количестве мест обходиться вообще без фреймворка и даже бойлерплейт-обвязок вокруг Proxy.
0
Object.observe был нацелен на оптимизацию $scope-объекта из AngularJS 1.x, а современный Angular как раз появился в 2015 году, когда стало понятно, что старый подход не прижился и порождает запутанный код.
0
стало понятно, что старый подход не прижился и порождает запутанный код.
Не прижился в Ангуляре, зато прижился в Vue и MobX, т.к. для маленьких систем и/или одностороннего биндинга более удобен. То есть сам архитектурный принцип никуда не делся и вполне распространён, но аргументировалось его принятие или не принятие исходя из потребностей одного фреймворка.
+1
Кроме того, в стандарт внесли более полезный Proxy, который как оказался более удобным для применения в разных фреймворках: Vue, MobX
Ну не знаю, реализация МобХ могла бы быть значительно изящнее с более простым Object.observe, чем с переусложнённым прокси.
0
C Object.observe проще выстрелить себе в ногу, устроив бесконечный цикл из обновлений самого себя. С Proxy такое сделать намного сложнее.

Насчет переусложненности нативного API – у него нет задачи быть изящным. Красота делается в userland-библиотеках, а платформа нужна для того чтобы дать техническую возможность реализации как можно большему числу разных библиотек, чтобы не пришлось переписывать стандарт с каждым новым веянием в стилях программирования.
0
Мне не нравится отображение прокси в дебагере, оно слегка усложнено
0
Красота делается в userland-библиотеках, а платформа нужна для того чтобы дать техническую возможность реализации

То есть пользователи без библиотек должны страдать?
0
А как вы хотите? Чтобы браузерное API было заточено под ваш вариант использования? Тогда пользователи с другими хотелками расстроятся, что угодили вам, а не им
0
Конечно нет, мои хотелки тут ни причём. Да и что там варианты использования, достаточно названий. Все эти document.getElementById(), document.getElementsByTagName(), document.getElementsByName(), document.getElementsByTagName(), document.getElementsByClassName(). Не сразу появился универсальный querySelectorAll(), да и тот весьма длинный и хочет себе обязательно какой-нибудь контекст, тот же document, хотя на тот момент уже был пример удобного $('').
+3
Да нет, это именно ваша хотелка. Мне вот querySelectorAll даром не нужен, а от от document.evaluate с человеческим лицом не отказался бы. Кого будем переименовывать в $? Но вообще, я гораздо чаще употребляю декоратор реактивной мемоизации, если что и переименовывать в $ то именно его. Вот тогда будет удобно. Для меня.
+3

Чтобы использовать не-React компоненты в React и наоборот, подключать React-компоненты в другие фреймворки.

+5
Половина статьи об отказе от jquery весящий меньше 100кб, а потом вдруг внезапно аргумент с angular с 8мб-ной папкой.
jquery и прочие, особенно с учетом cdn, это уже скорее стандарт де-факто на многих сайтах, чуть ли не больше стандарт, чем чистый js, отчасти это можно назвать языком более высокого уровня чем js.
-8

Это смотря как собирать и использовать, например у меня есть проект на Vue который полностью весит 32мб но пользователю при работе с сайтом отдается 500кб-1.3мб js в зависимости от страницы, что позволяет работать с сайтом даже при 2G соединении, а учитывая кэш то можно работать вполне даже комфортно.


Да размер jquery меньше но по сравнению с кучей картинок и нестандартных шрифтов — размер не имеет существенной разницы.

+7
Js, с точки зрения вычислений, стоит на порядок-два дороже картинок, так что даже 500 кб — это ужасно много.
+1

Справедливо. Но речь идет не о том что js блокирует работу страницы и не о том что за счет распаковки и своего выполнения он есть больше памяти, а о том сколько приходит данных пользователю.


Плюс для таких любителей считать объем, которые думают что 1 мб js это много нужно учитывать что в SPA не только зашит собственно чистый js но и возможно css in js + довольно большая часть html кода компонентов и иногда например картинка в base64.


Так что вес страницы нужно мерить полностью. И да внезапно не оптимизированные шрифты которые затребовал заказчик в одном проекте составили 60% времени загрузки страницы и 30% рендера.


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


На c++ тоже можно забыть затирать объект в куче и использовать костыли с O(n2) и потом ругаться что он медленный и жрет память.

0
А статья как раз и говорит о том, что просто измерять суммарный объем — это слишком упрощенная метрика. Потому что условные 100 кб скриптов сожрут ресурсов намного больше, чем равного объема картинка.
+1
C jQuery бывает сложно остановиться. Да, сам он маленький, но вот мы подключили его расширение для таблиц (grid), вот для модальных и диалоговых окон, для пользовательского интерфейса (ui)… Сколько в итоге будет весить папочка с jQuery скриптами?
0
Смотря какой функционал вы преследуете. Если подключать расширения от которых вам реально требуется только 10% его способностей, то тут ошибка ваша. Опять же если взять фреймворки, в них так же нужно подключать компоненты.
Ну и в конце концов, многие крупные компании вообще уходят даже от JQuery, на чистый JS, пример тому github.
У меня есть знакомый, с которым мы расспорились на тему JQuery vs Vue. В итоге сошлись на мнении, что все таки лучше то использовать, что знает отлично вся команда разработчиков.
-1
Логичный вопрос возникает: а когда нужно подключать jQuery (просто голый), когда сколько процентов его возможностей собираешься использовать?
0
Речь шла о подключаемых расширениях — «но вот мы подключили его расширение… таблиц (grid)… модальных и диалоговых окон… пользовательского интерфейса (ui)...»

А вообще насколько используем подключаемый скрипт можно посмотреть в DevTools -> Coverage. Там же и определиться стоит ли шкурка выделки для переписания на чистый JS
+5
Два мегабайта для практически пустого приложения?
Что-то как-то многовато.
Я не знаю, что курил автор, но у нового ангуляр приложения размер бандла 384KB, а не 6.5MB.
+2

Часто такие авторы меряют размер того, что выдаст не сжатый dev bundle. А в самом запущенном случае — размер исходников в папках включая node_modules =)


Используя code splitting + gzip + сжатый bundle цифры совсем уже другие.

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

Я подозреваю, что автор взвешивал не-минифицированный вариант с учетом всего html и css. Хотя и в этом случае 2мб для заявленного функционала — многовато. Думаю, что пары сотен кб достаточно на всё.

П.С.: Я уже писал насчет качества ресурса-донора статьи — судя по увиденному там пишут в основном дилетанты для дилетантов.

UPD: Про дилетантизм — немного некорректно, вернее будет что-то вроде «льют воду для новичков под громкими заголовками».
+3
Мне очень импонирует идея веба и простых приложений в них- вики, pdf-генератор, простенькая база с парой форм, доступ отовсюду…

Но блин, столько учить и знать…

Окей, основы нужны — 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 :)))

Да, я понимаю что в идеале это разные сущности, разные отделы, разрабы, админы и так далее. Но блин, не слишком ли сложно?))
+1

На самом деле не сложно, фреймворки очень похожи друг на друга. Сперва учить es6+ (месяц максимум) потом мне понадобилась на React 3 месяца а Vue уже освоил за 2 недели.


В сухом остатке — то что я бы делал на jquery + es5 пару месяцев я сделал на Vue за 2 недели.


Компонентный подход не прост — но правильное его использование существенно сокращает работу — тем более готовых компонентов куча и подключаются они проще чем плагины на jQuery.


В плагинах на jq разброд и шатание, каждый плагин это свои хуки, свои структуры данных и куча прочих велосипедов. В React/Vue все компоненты типовые и календарь и компонент перетаскивания файла — дают одно и тоже событие но с разным содержимым, при этом привязать нужный обработчик — это дело пары минут.

0
На самом деле не сложно, фреймворки очень похожи друг на друга.

Громкое заявление. Сравните React и $mol, например, и попробуйте найти хоть что-то общее. Впрочем, освоить $mol можно за те же 2 недели.

+2
> Впрочем, освоить $mol можно за те же 2 недели

Громкое заявление от разработчика этого фреймворка :D
+2
И когда я смотрю на весь этот стёк, то я ужасаюсь, и хочу всё поменять на xcode, swift и iPhone :)))

Большая часть из того, что вы перечислили — это бэкенд. Если у вас мобильное приложение будет взаимодействовать с сервером, то будет и бэкенд. А там снова и базы данных, и очереди, и серверные языки, и линукс, и безопасность. Не слишком сложно?

+5
А для «xcode, swift и iPhone» не нужны базы, безопасность, бекенд, тесты, ci/cd, хуки гита?
0
А вы взяли и смешали в кучу людей и коней. Всё, что относится к Web закончилось на cookies и тем, что оканчивается на .js. Всё остальное — общие инструменты и практики, которые не только в вебе работают.

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

А так, добро пожаловать в разработку, у нас много интересных задач и много решений для этих задач.
+2
Ты забыл добавить еще один минус, человеку который не с нуля начинает разработку проекта ему будет очень тяжело разобраться в работе кода.
+7
Использование в собственных проектах чужого кода — это всегда риск.
Если существует известный поддерживаемый фреймворк\библиотека, то писать собственный велосипед вместо него — это гораздо больший риск.
0

На самом деле цена каждой библиотеки-зависимости намного больше, чем принято думать. Вот здесь Russ Cox (один из авторов Go) это описал очень подробно: Our Software Dependency Problem.

+24
Все говорят про какие-то крутые SPA, но реальность в подавляющем большинстве случаев выглядит ошеломляюще примитивной. То есть спросить пользователя firstname, lastname, email и предложить нажать кнопочку Submit. Это можно было сделать на заре WWW через банальный CGI, и можно сделать сейчас через сложнейшую связку NodeJS с <Ваш любимый фреймворк>. В первом случае это простенький скрипт на пыхе, а во втором эпичная конструкция.

Я понимаю, когда в браузере пользователь делает что-то по-настоящему эпичное (замена офисного пакета, полноценный почтовый клиент и т.п.), но ведь нет, большинство применений — это старые добрые фантазии на тему firstname, lastname и кнопочки Submit. Господа, в чём же профит?

К слову, заметил, что те действительно сложные и функциональные штуки делали в дофреймворковскую эпоху, сейчас смотрятся старомодно. Сейчас стараются не утомлять юзера лишними наворотами. Показать ему слоган, картинку, ну и эти… как их… firstname, lastname и кнопочку Submit.

(да, конечно, ещё не забываем про галочку согласия с условиями политики приватности с суперсложной логикой не давания нажимать Submit пока галочку не отметил)
+3
большинство применений — это старые добрые фантазии на тему firstname, lastname и кнопочки Submit. Господа, в чём же профит?

Чтобы точно ответить на этот вопрос, нужно знать конкретный пример. Иначе для одной формочки действительно фреймворки не нужны.

+3
Как минимум — когда делаешь form/submit — сразу получишь кучу спама. Можно извращаться с фейковыми полями и прочим — но все это не работает. Либо капча (неудобно для пользователя), либо терпеть спам.

Когда я делаю на VUE, то поля отправляют значения в store, оттуда скрипт повешенный на кнопку забирает значения и отправляет через AJAX.

Да, пушкой по воробьям. Но спам уже достал неимоверно. :(
-1
Банальная отправка данных через POST, имхо, не повод затаскивать к себе в проект 100 с лишним мегабайт чужого кода, суть и конструктивные особенности которого уже давно ни одна живая душа во всей полноте осмыслить не может.
-4
На самом деле 120 с чем-то.
npm install -g vue-cli
vue init webpack frontend
После этого замеряем размерчик папочки «frontend».

Справедливости ради, аналогичная манипуляция с ReactJS даёт больше 200.
+5

А компилятор C++ сколько весит? Или он лежит в другой папочке, а потому не считается? А джавовский Gradle считается? Он себя может локально развернуть. А ведь там тоже мегабайты "чужого кода, суть и конструктивные особенности которого уже давно ни одна живая душа во всей полноте осмыслить не может".

-1
Не подумайте, мне не жалко 120 метров. Особенно если для действительно для чего-то достойного. Но в данном случае эта штука не помогает даже с дизайном. То есть по-любому весь HTML и CSS всё равно придётся своими руками написать. А вся эта жуть, вокруг которой столько шума — это про то, как подружить M c V через P. Вот в этих трёх соснах вся толпа и бродит, наворачивая всё новые и новые навороты поверх существующих уже и так изрядно навёрнутых наворотов.
+2
Я вас сильно удивлю, но для староверов которые не любят npm, сборщики и прочее из мира фронтенда(я сам такой, не бейте палками — основная профессия всё же бэк) — можно просто подключить vue на страницу через тег script и вместо 120mb вы в свой проект загрузите 85kb. И даже компоненты можно так же подключать. Современный фронтенд не любит такой подход, но vue к счастью предоставляет выбор.
-2
Ну наверное, это лучше, чем мог бы быть гигабайт, и хуже, чем, скажем, 15 мегабайт. А о чем говорит размер? Большой размер — это хорошо, или плохо? Или вообще ни на что не влияет? Мне кажется, последнее.
+1

И что мешает реализовать эту невообразимо сложную логику на VanillaJS/JQuery?

0
Для меня на VUE это быстрее написать. Плюс — получаю еще кучу других преимуществ.
0

И что, только ради этого надо вндерять в проект Vue? Не считая того, что его еще придется и изучать? Может про другие преимущества расскажете (в рамках предоставленного maslyaev примера)?

0
А почему нет? Что такого есть в VUE, что делает его «сложным для внедрения»? Создание проекта делается в две команды:
rails new PROJECT_NAME --skip-coffee --skip-test --skip-sprockets --webpack=vue

и затем
rails webpacker:install:vue

На этом я сразу получаю окружение, позволяющее сразу вести разработку приложения. Что такого сложного во «внедрении в проект VUE»?
+1

как же быстро вы подтвердили контроверсионную точку зрения. теперь простой пример формочки firstaneme, lastname, email и кнопки submit требует рельсы...

+1
Я и не скрывал. А рельсы для такого — это плохо? Почему? У них есть какие-то недостатки, не позволяющие эффективно решить задачу формочки?
0
Согласен :) Я просто из обычной своей строки иницииации стер все лишнее :)
0
Вот это «почему нет?» конкретно расслабляет. Туда-сюда сотню-другую мегабайт — фигня вопрос. А потом смотрим, вдруг внезапно начинает цвести тема «девопс», позволяющая лёгким движением руки развернуть тысячу виртуалок. Народ, а что у нас за такие крутые вычислительные задачи, для которых нам может понадобиться тысяча stateless вычислительных серверов? Крипту майним? Лекарство от рака ищем? Навороченные нейросетки тренируем? Да нет же, пытаемся сделать так, чтобы firstname и lastname сабмитились гладко через врождённо-однопоточную Ноду.
+1
Хм… Вот опять не понимаю. Стоит бизнес-задача — гладкий сабмит firstname и lastname. Задача решена, быстро, заказчик доволен. В чем проблема, даже если это и требует «тысячи серверов»?

Я просто упорно не могу понять. Есть три составляющие: сроки, функции, деньги. Если я уложился во все: какая разница, какие технологии и ресурсы я использовал?
+1
Безответственный хищнический подход. Задачу сделали, деньги получили, а там хоть трава не расти. Сейчас Заказчик доволен, желаемая им магия работает. А через месяц окажется, что для его фигни нужно во-первых не забывать регулярно башлять Амазону за AWS, а во-вторых желательно нанять загадочного, редкого и чрезвычайно дорогого зверя, который называется «девопс-инженер».
А по-хорошему, всё могло бы обойтись стареньким пентиумом, засунутым с глаз долой куда-нибудь в кладовку.
0
Картина апокалипстическая, но реальная жизнь все же другая. Старенький пентиум в кладовке — это не бизнес, а стагнация. Создавая любую систему нужно исходить из того — что она должна быть расширяема. И фрейморвки, в данном случае — Rails, Vue, React и пр. задают очень удобные рамки. Уровень вхождения в проект любого нового разработчика, знакомого с Rails и Vue — очень низкий, понять, что делал предыдущий человек — можно довольно быстро.

Наличие ресурса, будь то AWS, или просто VPS (а его, поверьте, достаточно для Rails+Vue) — да, издержки этой практики. Но выбор Rails + Vue — это как ответственный подход с точки зрения будущей модернизации.
0
С одной стороны, мы не можем в полной мере предвидеть модернизации, которые могут потребоваться в будущем. Ведь вполне может случиться так, что та потребность, о которой сейчас вообще никто догадаться не может, вывалится за рамки любимого фреймворка.
С другой стороны, мы не можем предвидеть развитие безумия наших прекрасных технологий.

Когда-то давно можно было уверенно говорить о том, что пилить систему на FoxPro — самое разумное решение, но сейчас все эти крутые начинания превратились в вонючее легаси, которое все мечтают срыть нахрен. Есть ли у нас гарантии, что поделия на Ангуляре, Вуе или Реакте не превратятся в такое же легаси в обозримой перспективе? Просто прикиньте, как сейчас искать спеца, который не только умеет, но и желает докручивать FoxPro, и примерьте ситуацию на наши прекрасные новомодные фреймворки.
0
Это все слишком глобально. Я мыслю проще. Рельсы обеспечивают обвязку для проекта, где любой рельсовик знает: где найти маршруты, контроллеры, модели и миграции. Это настолько жестко забито — что я ни разу не видел проектов, где было бы не так, как везде. :)

Vue дает возможность полностью изолировать компоненты друг от друга. Что-то скрыть, что-то добавить — делается очень легко. Влияние на другие компоненты невозможно из-за scoped стилей. Не нужно думать о разделении стилей по namespace. Обмен — через Vuex. Если нужно — новый разработчик может даже не вникать в старый код — просто пишет новую компоненту, и общается со старыми через Vuex, ничего не зная: ни id компонентов других, ничего. Идеальная изоляция подсистем.

Я говорю только об этом, не замахиваясь на глобальность мироздания :)
0
Да никакой глобальности мироздания. Просто нужно думать на шаг вперёд и понимать, что решаемая задача всегда в каком-то контексте. Что есть понятие жизненного цикла даже для маленькой скромной поделки. И что жизненный цикл не заканчивается получением денег от Заказчика, а по-хорошему только начинается.
+1
Есть ли у нас гарантии, что поделия на Ангуляре, Вуе или Реакте не превратятся в такое же легаси в обозримой перспективе?

Да конечно превратятся! Просто ваша фигня под пентиум превратится быстрее.

0
Фигня под пентиум будет тихо себе жужжать в углу и есть не просить, пока уборщица провод из розетки не выдернет.
Рассказывали байку про сервак, который при очередном ремонте случайно замуровали в простенок, и нашли только когда взялись делать перепланировку. А он себе спокойно всё эти годы работал и выполнял функцию.
0
Тихо жужжать в углу может что угодно. Вопрос легаси-кода поднимается в тот момент, когда жужжать в углу уже недостаточно, и «фигню» приходится дорабатывать.
0
Теперь представьте себе две ситуации:
1. Фигня — самоизобретённый велосипед. То есть не сильно заморачиваясь универсальностью сделали ровно то, что требовалось. Зависимости — только на стандартные библиотеки. Уровень перфекционизма — средненький.
2. Фигня сделана согласно полному комплекту веяний моды. Зависимости уходят в недра npm (как вариант, PyPI или чего ещё, без разницы), и там рекурсивно подхватывают существенный процент наработок сообщества.

Предположим, прошло 10 лет.

В первом случае после некоторого периода ознакомления с конструкцией пациента просто берём и докручиваем требуемое. И средство разработки, и стандартные библиотеки никуда не делись. Если нужно, на просторах Интернета можно найти что угодно, хоть 3-й турбо-паскаль.
Во втором случае оказывается, что используемые пакеты часть заброшены (и уже несовместимы со своими зависимыми), часть потерялись, часть развились так, что не узнать. Бубен в руки и вперёд, пытаемся восстановить состояние состояние инфраструктуры на тот момент, когда фигня создавалась.
В первом случае чтобы разобраться, нужно освежить знания по средству разработки и его стандартным библиотекам. Во втором — по той Джомолунгме барахла, от которого пациент зависим.

С чисто прагматической точки зрения лично я выбрал бы первое. Ну нафиг бегать с бубном вокруг Джомолунгмы.
0
Нее, ситуации выглядят по-другому.

1. Фигня — самоизобретённый велосипед. Нужно изучать весь код, чтобы понять что там происходит. Любой кусок функциональности потенциально может оказаться в любом файле.

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

2.2 Фигня использует старый, но еще актуальный фреймворк. Тут еще проще: достаточно найти правильного динозавра, и тот во всём разберется.

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

Но даже если и пакетов нигде не осталось — то можно взять за основу уже существующую и «жужжащую» сборку. Это всё равно на порядок проще, чем декопилировать бинарники, остающиеся от мейнстримовых языков.
-2
Если задачу можно решить просто и дубово, без лишних наворотов и зависимостей от всей необъятной Вселенной, её нужно решать просто и дубово. Решение новичка, накрутившего глупостей и корявостей по незнанию — это, конечно, зло, но и код гения, решившего на простенькой задачке про засабмичивание firstname и lastname продемонстрировать свою невероятную крутизну — зло ни разу не меньшее. И пусть он не тешит себя мыслью про то, что потом его формочку можно будет превратить в полноценный фейсбук. Никто в фейсбук её превращать не захочет. А во что её захотят превратить, он всё равно не угадает. Потому что никто не знает будущего. А кто думает, что знает, у того просто мало опыта.
0
Фигня под пентиум будет тихо себе жужжать в углу и есть не просить, пока уборщица провод из розетки не выдернет.

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

-1
Даже самый ярый поклонник реакта всё равно хоть один раз в своём проекте, да вписывает гетЭлементБайИД. То есть он по-любому знаком и с ваниллой, и с ХТМЛ, и с ЦСС.
А вот если при изготовлении фигни её автор в порыве вдохновения изобретал свой ни на что не похожий реакт — да, труба дело. Только посочувствовать.
+1

Тысячу stateless серверов вы только что сами придумали. А сотня-другая мегабайт будут только на компьютере разработчика и CI-сервере.


Что касается "врождённо однопоточной" ноды, то реактивный подход сейчас стал популярен и на многопоточных платформах.

0
Справедливости ради, реактивный подход мне самому понравился. Зачётная идея. Очень не хватало.
0
только гента после этого работает, а приложение на vue еще писать надо.
-1
Ну собственно ускорение разработки в целом и порождает библиотеки, фреймворки и прочее повторное использование кода. И скорость разработки одна из основных метрик, можно даже сказать главная «хард-метрика» по которой бизнес решает сколько этому разработчику платить и платить ли вообще.
+2
Скорее всего, делается упор на то, что у спамботов скрипты не исполняются
0
Верно. Как я понял, они сканируют сайты, и если видят стандартные формы — начинают спамить разными предложениями путем прямой отправки сообщений в форму, мимо сайта. Это хорошо видно на малопосещаемых b2b сайтах, где видно, что спама больше, чем посещений по метрике. Рекламируют всякую фигню — от металлостанков до скупки деревянных палетт.

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

Но в последний год появились более умные скрипты, которые такую ситуацию просчитывают, видимо, путем анализа placeholder или label. Кол-во спама значительно выросло. Поэтому применить способ с полным отсуствием формы — сейчас для меня наиболее эффективный путь.

Вот пример, последнего спама:
Имя: 30857550
Phone fake: 79777777777
Местоположение: ()
Email: 333333@333.ru
Телефон: — Комментарий: Юридическое бюро предлагает услуги юридического сопровождения бизнес-процессов на всех этапах работы компании. тут была ссылка.
0
Кажется, у вас парсер сожрал пример формы. Но это тема весьма примитивная и старая и по-моему описывалась даже ещё в тогда бумажном выпуске ][акер-а год так за 2008, по крайней мере я увидел первый раз именно там.
0
Ну да, тема старая. Я же не говорил, что использую VUE только для этого. Просто для меня это как «антимпам из коробки» :) Уже готовый.
+2

Обычно "отломать сайт для ботов" ещё по пути приводит к "отломать сайт для слепых людей со screenreader'ами".

+4
Все говорят про какие-то крутые SPA

99% "крутых спа" — это проекты для внутреннего использования и б2б решения, то есть кровавый ынтырпрайз своего рода, с-но просто человек их не видит
А для того, чтобы ленту твиттера выводить — действительно, спа не нужны.

0

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

0
Чтобы выводить только для чтения, может, и не нужны, но вот для написания ответов, лайков и всего такого
уже понадобится более менее толстая клиентская логика

Не надо никакой толстой клиентской логики, чтобы поставить лайк и написать пост. Это функционал гостевухи с народа.
С точки зрения конкретно фронта твиттер — очень простое приложение.

0

Если перезагружать страницу целиком на каждое действие, то клиентского кода не надо, да.


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


Сравните два примера:


  • pikabu.ru – не-SPA, при переходе с поста на ленту показывается анимация подгрузки, страница ищет, куда вам перемотать
  • mobile.twitter.com — SPA, переход со страницы твита на ленту мгновенный
0
Но если мы хотим делать без перезагрузки страницы, да еще и так, чтобы при переключении на просмотр одного твита и обратно позиция скролла не терялась, то тут уже надо писать клиентский код.

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


А отпозиционировать скролл на пост можно вообще через хеш.

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

А до реакта, я так понимаю, интернета не было?


В случае заметного количества интерактивного контента SPA оказываются отзывчивее и юзабельнее.

Вы в одну кучу смешали СПА и современные фреймворки.


  1. Можно делать СПА спокойно без каких-либо фреймворков на фронте, и оно не перестанет быть спа. В случае если у вас простое приложение вроде твиттера — такой подход, в сущности, не имеет каких-то особых проблем. С-но, большую часть существования интернетов именно такие спа и были. На каком фреймворке написан вк? А ведь он существенно сложнее твиттера будет.
  2. Если у вас сложное приложение — вы берете фреймворк. Там закатывать солнце руками — становится очень печально.
+1
А почему для вас пхп это простенький скрипт, а nodejs это сложнейшая связка. Попробуйте вручную поставить отдельно пхп и апатч и настроить их конфиги чтобы вместе работали, а потом в ноде сделаете тоже самое за 3 строчки кода.
Я не топлю за ноду я за объективность.
-1
Попробуйте вручную поставить отдельно пхп и апатч и настроить их конфиги чтобы вместе работали

Всё это есть на любом копеечном хостинге, а для ноды, в большинстве своём, нужен VPS, где кроме самой ноды придётся сервер содержать.
+1

С апачем может быть и все сложно (я его не видел последние лет 6, и слава богу). Связка php-fpm+nginx ставится одной командой, после этого достаточно немножко отредактировать конфиг nginx'а и в общем-то все будет работать сразу.
А если нужно локально повеселиться — apt/yum install php-cli && php -S localhost:8080.

0
Я экспериментировал с чистым js, когда думал что мне не нужно тянуть за собой кучу библиотек вроде jquery для того, чтобы просто отправить форму. Это было давно, ES6 ещё не было, а я верил, что тащить лишний код в маленькое приложение глупость, когда можно написать пару функций. Потом я захотел отобразить список. Потом мне потребовалось чтобы список динамически обновлялся. Периодически я страдал, пытаясь сделать что-то что без библиотек писалось в десять строк вместо одной. Это был интересный опыт с чистым js. Повторять я его, конечно, не буду.

Между тем, минифицированный vue.js сейчас весит 86,5kb, и я готов платить эту цену за удобство и реактивность. И даже подтяну к нему компоненты для красивых селектов, дэйтпикера, и редактора. Ещё почти 100 kb, ужас прямо, особенно учитывая что всё это закешируется.

И да, возможно приложение будет тормозить, но не из за библиотек, а из за того что я на страницу подтянул несколько разнородных массивов данных из разных источников (на секундочку — несколько mb в gzip), отрисовываю их по разному, возможно работаю с ними, сравниваю, меняю… Эти проблемы решаются уже рефакторингом кода, нахождению узких мест, переписыванием алгоритмов — и они так же(а то и сильнее) тормозят на тех же данных на страницах на которых пока старый легаси код на jquery. А форма с простым submit где в селекте попытались отрисовать 10к элементов — вообще нормально не работает без автокомплита на стороне сервера.
+3
Фреймворки в JS исчезнут примерно тогда же, когда в Java. Иными словами — вряд ли вообще исчезнут. Потому что альтернатива — конструирование велосипедов.
+1
Либо куча велосипедов сделанных другими людьми, либо куча велосипедов сделанными самим.

Весело
+4
У распространённых велосипедов от других людей есть существенные преимущества по сравнению со своими. В среднем они лучше написаны, безопасны, с документацией, по ним есть опыт у других разработчиков, на них не тратится бюджет и так далее. Так что да, не исчезнут никогда.
+2
безопасны, с документацией, по ним есть опыт у других разработчиков, на них не тратится бюджет

Это да.

В среднем они лучше написаны

А вот это — неа.
В лучшем случае они в среднем лучше написаны с т.з. сферического качества кода, а не решаемых проблем. Если только задачи не совсем непроходимо типовые без малейшего шага в сторону.

Сторонние велосипеды как правило решают задачу либо другого уровня обобщения, чем нужно, или кучу задач одной области, из которых в конкретном случае надо далеко не всё. Итого со сторонним велосипедом либо привносится «мусор», без которого можно было бы обойтись, либо же сторонний велосипед надо напильником и такой-то матерью слегка приспосабливать под имеющуюся задачу.
0
Эх, мечты, мечты…

В среднем они лучше написаны

Анекдот про «В среднем они обе проститутки» знаете?

безопасны

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

с документацией

Которой а) не хватает, потому приходится искать доклады, Best Practice и далее, далее б) Лучше бы не было, потому что она морально устарела или написана в стиле «вот переменная, вот класс, вот метод, вот так строится синхрофазатрон».
Я не говорю, что все фреймворки такие, но сам зачастую лезу в код очередной поделки, потому что в документации чушь.

по ним есть опыт у других разработчиков

Это не Rocker Science и не музыкальная теория, осилить фреймворк не составит труда любому более менее приличному разработчику. Вы не говорим о jQuery/Django/RoR программистах, которые просто не умеют ничего другого.
Учить надо алгоритмы и структуры, а не фреймворки. Не помню, кто сказал.

на них не тратится бюджет

Тратится. Фреймворк требует тестирования, проверки работы, исправления багов самого фреймворка, его обновления (и обновления вашего, кода который его использует).

Я не говорю, что нельзя использовать фреймворки. Конечно можно и нужно. Но стоит понимать, что фреймворк написан для решения конкретной задачи у конкретного человека (компании). Либо это монстр, который старается решить проблемы всех людей в мире и 99% его возможностей вы никогда не используете.
+2
Это не Rocker Science и не музыкальная теория, осилить фреймворк не составит труда любому более менее приличному разработчику. Вы не говорим о jQuery/Django/RoR программистах, которые просто не умеют ничего другого.
Учить надо алгоритмы и структуры, а не фреймворки. Не помню, кто сказал.

Совершенно верно. Но чтобы правильно написать бизнес-логику, нужно знать нюансы работы фреймворка, иначе вместо O(1) где-то получится O(n), а вместо O(n) — O(n^2). В туториалах не всегда эти моменты освещены.

+1
Это не нюансы работы фреймворка, это алгоритмы и структуры. Которые не имеют никакого отношения к фреймворку. И если знать их, разобраться в тонкостях конкретного фрейворка — вообще не проблема.

+1

Они имеют прямое отношение к фреймворку как раз потому, что используются в этом самом фреймворке. Нюансы как раз и заключаются в том, чтобы знать, какие алгоритмы и особенности их поведения используются в конкретном фреймворке. Например, какой ключ использовать для атрибутов key в элементах react и angular — когда можно брать его из счётчика цикла, а когда лучше использовать что-то из поля данных; почему в компонент react лучше передавать два атрибута по отдельности, а не объединять их в объект с двумя полями и т.д.

-1
Открыл код, посмотрел. Если я знаю структуры данных и алгоритмы, это вопрос часов. А то и минут, если это react. Зачем указывать это в требованиях? :)
-1

Вы об этих кейсах узнали только что, а компания желает, чтобы особенности работы фреймворка вам были известны заранее, а не разбирались в нём в рабочее время.

+2
Ну да. Мы, инженеры-велосипедостроители, обречены изобретать велосипеды. Как только мы перестаём изобретать велосипеды, мы сразу же обнаруживаем себя продавцами-консультантами в велосипедном отделе. В принципе, там тоже не так уж и плохо, но у нас веселее.

Что до рассматриваемой здесь ситуации с фреймворками, это всё же две немножко разные задачи — изобрести велосипед под конкретную потребность и условия эксплуатации, или средство изобретания велосипедов на любые случаи жизни.
0

вариации на тему: вы бы предпочли велосипед от giant / harley davidson или сваренный в гараже из остатков профиля и арматуры?

+1
Если денег нет, то пусть будет собственноручносваренный, чем пешком ходить.
0
Обсуждение инструмента без области применения — переливание из пустого в порожнее.
Если мне надо клетить девочек (ну или мальчиков) и я живу в городе, езжу по облагороженным паркам и имею доход для обслуживания — конечно giant / harley davidson.
Если я живу где-то в сельской жопе мира — я лучше сварю из арматуры, поставлю нормальные арматизаторы и буду гонять, не боясь сломать эту фигню.

В реальности я не куплю никакой, потому что живу на 5-м этаже в доме без лифта и имею проблемы со спиной, что выражается в отсутствии желания таскать на себе хоть что-то лишнее.
+4
Систему нагружают ненужные операции по обновлению страниц, избыточные прослушиватели событий, глубокое сравнение объектов, без которого можно обойтись, неоправданно масштабные манипуляции с DOM. Избавиться от всего этого можно просто сделав всё своими силами.

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

0

Для приложения такой сложности, как в статье — это абсолютно верный подход, потому что простой, надёжный, и с приемлемой производительностью. Что-то более оптимальное в данном случае это типичный пример premature optimization приводящей к излишнему усложнению кода и, возможно, багам.

+6
приложения такой сложности

Какой такой? Как по мне тут слишком много кода для такой простой задачи. При этом данный код стыдно выпускать в прод, так как нет индикаторов ни на загрузку данных, ни на сохранение. Нет кнопки "повторить оборвавшуюся загрузку". В случае любой ошибки показывается белый экран. И тд, и тп.


простой

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


надёжный

Тут мы видим много дублирующейся логики, которая рано или поздно разъедется и привет ночи с дебаггером. Ручное обеспечение инвариантов — это источник чуть-ли не 90% всех багов.


с приемлемой производительностью

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


premature optimization

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


излишнему усложнению кода

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

0

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

+2

А потому что завтра добавляем в это приложение ещё компонентов и страниц. Внезапно оказывается, что оно почему-то начало подтормаживать. Чтобы внедрить оптимизацию рендеринга потребуется довольно много времени на рефакторинг и регрессионное тестирование. А в бэклоге задачи только увеличиваются. В фазе MVP проекта никто времени на рефакторинг не даст, а тем временем техдолг растёт, как растёт и сложность спагетти-кода, которая всё более тормозит нормальный процесс разработки.

0
Кажется, когда люди вспомнят про события и научатся пользоваться веб-компонентами, люди поймут, что никуда не упал ни redux ни react
+3
Как только вы напишете что-то нетиповое на несколько десятков веб-компонент в несколько уровней глубиной, так потом обнаружите, что для управления этим всем вы уже где-то там сбоку наколхозили или state management, или гору тестов, или еще чего-то в таком же духе, что не сильно отличается от подхода реактов с редаксами.
0

А почему вы так считаете? У вас уже есть большое приложение на веб-компонентах и масштабируется нормально?

0

А я вот сейчас в сторону blazor смотрю, и то, что я вижу впечатляет
Связка web assembly + .net через некоторое время сделает ненужными вот эти тонны адских js-based фреймворков.
Реализуя концепцию .net everywhere разработка spa станет такой же комфортной, как и создание десктоп приложений.

+2
Какая разница на .net или js писать, если модели, API и т. д. браузеров те же? Ну и насчёт комфорта очень субъективно.
+1

Но ведь Blazor больше похож на ASP.NET MVC, чем на десктопные технологии.

0

Если Blazor больше похож на ASP.NET MVC, чем на WPF, то и удобство программирования будет таким же, не так ли?


И да, не забывайте, что вместо этой "тонны адских js-based фреймворков" у вас будет виртуальная машина .NET, запущенная в виртуальной машине WASM, а интеграция с браузерным API всё равно будет проходить через JavaScript.

0
Что не говори, фреймфорки значительно упрощают жизнь разработчику. Автор правильно упомянул что за все нужно платить, в данном случае производительностью, но хочу обратить внимание и на экономию самого важного ресурса — экономию времени. Зачем изобретать колесо второй раз? Если можно объединить усилия, и так сказать с миру по нитке собрать интересные идеи вместе, комбинируя работы разных людей.

Что было бы если каждый человек писал без фреймворка, насколько увеличилось бы время до релиза? А имея основу, гораздо прозе и правильнее сфокусироваться на конкретной задаче, на конкретно своей идее и проекте.
-1
И на счёт производительности ещё не факт. Свой велосипед легко может показать производительность меньшую, чем фреймворки, только над производительностью которых куча людей работает.
0
Ждём продолжения «Когда исчезнут Java-фреймворки?», «Когда исчезнут C++ фреймворки?»
0
В минусах отказа от фреймворка не указано повышение порога вхождения в проект для человека знакомого с фреймворком или набором библиотек а-ля react+redux.
+2
Создавая приложение на чистом js, вы невольно будете создавать очередной фреймворк. И чем больше приложений вы будете продолжать писать, тем больше он будет обрастать функционалом и расти в объеме.
+1
Никогда не исчезнут. И это не зависит от языка. Потому как они антагонистичны.
Цель любого языка программирования стать как можно более универсальным.
Цель любого фреймворка стать как можно более специализированным.
Цель любого микрофреймворка стать еще более специализированным, ибо эти фреймворки сильно разожрались.
Есть ФВ для фронта, есть для бэкенда, есть для микроконтроллеров, есть для десктопа, есть для мобилок, есть для 3D, есть для VR.
И так было всегда, даже когда еще не было компов. Топором можно и избу срубить и часы починить. Но ведь зачем-то сделали часовые отверточки…
0
Первый фреймворк, который я изучал, назывался TurboVision. Крутая штука, на которой можно было сделать всё, о чём только можно было помыслить. Потом оказалось, что таки не всё. А потом он умер и был навеки забыт.
+3
окей. давайте так. у среднего реального проекта на react соотношение бандлов с вендоским кодом (все что в node_modules) и банда кода из src составляет 181кб/99кб. Только 60% кода реально попадающего клиенту (ну мы же не будем сравнивать размер папок с исходным кодом, право) — это код из node_modules (+ к этому tree shaking у вебпака работает так себе, я думаю можно снизить еще — было бы желание)

За эти 60% процентов вы «покупаете» себе предсказуемость, документацию, фиксы безопасности и баг-фиксы, поддержку комьюнити, расширяемость.
Так же по мере роста проекта в него все реже добавляются новые пакеты и все больше пишется своего кода, соотвественно использовать фреймворки будет все выгоднее и выгоднее.

Вот и вся метрика. с определенной степени сложности/размера приложения/частоты обновления становится выгодно использовать фреймворки, до определенного — это неоправданно дорого.
0
Как бы да. Но во всю эту формулу еще стоит внести стоимость переноса проекта на любой из фреймворков и склонность проектов к разрастанию. Заимев опыт разгребания многотонных монстров, начинающихся с «нам нужна одна страничка с информацией о компании», Вы в какой-то момент замечаете, что лепите на фреймворках все, что сложнее лендинга, а лендинги проектируете так, чтобы переносить их на фреймворк было не сильно больно.
0
Раньше были времена цикла jquery vs vanila, теперь когда jq меньше используют, нужно найти новый объект хейта.
0
Какие задачи возникают в результате отказа от использования веб-фреймворков?

Переслены три варианта любого проекта: из г**на и палок без фреймворка, по-простому с мини-фреймворком и по серьёзному с полнофункциональным фреймворком.

Все три варианта имеют право на существование, даже в крупных проектах. Ну понятно, что это сложно — поддерживать мега кода из г*а и палок, но они существуют.
0
Минусы «своего фреймфорка»:
1. Необходимо пилить много вспомогательных функций
2. Требуется хороший архитектор, чтобы «свой фреймворк» разросшись не погубил себя
3. Документирование его использования
4. Отторжение новыми программистами, которые заходят на проект (многие программисты предпочтут использовать общеизвестный фреймворк и развиваться в нем, получать опыт и соответственно повышать свою стоимость в случае перехода в другую организацию)
0
Какой наброс!
На самом деле в комментах много лукавства. Конечно хорошо профессионально овладеть каким-нибудь фреймворком и заточить под это дело воркфлоу. Особенно если работаешь на постоянке. Разворачивание проекта, вхождение в процесс — занимает очень мало времени. А вот переезжать на другую технологию, или, упаси бог, «даунгрейдиться» до ванильных html/css/js — брр… Поэтому сразу начинаются холивары о модных тенденциях во фронтэнде, об удобстве компонентного подхода по сравнению с семантическим и т.д.
Поработайте во фрилансе. Желательно не стартуя с новым проектом, а доделывая за кем-то. Ад и Израиль! Куча мала из смеси фреймворков и нативных сущностей. Зато на какой-то модной штуке. Которую, во-первых, надо умудриться запустить («А вы чем собираете? Грунтом? Попробуйте Ярн! Не работает? А у вас какая версия?»). А во-вторых, разобраться где там куда всё распихано… Хотя как там фреймворки позиционируют? Удобство и скорость?
С «устаревшим», но вменяемым «ванильным фронтэндом» эта проблема практически не всплывает.
Программистов куда не запусти — тут же начнут обмазываться какими-то «оптимизаторами рабочего процесса» и повышать порог вхождения. Вот и до фронтэнда добрались. Что там на очереди? Дизайн?
0
Чтоб увидеть самому, видимо. В корпоративном мире всё примерно так же, только снаружи не видно. Потому что сор из избы и всё такое. Зато о корпоративном мире можно иногда судить по внешним проявлениям, как например когда гуглопочта для показа ваших писем вдруг начинает прогружать 6.7 мегабайт яваскрипта.
0
Ну так автор заглавного коммента вроде так и написал, что фреймворки тут ни разу не являются «серебрянной пулей». В том смысле, что конечно они не виноваты в кривых руках и дедлайнах «вчера», но они и не сильно-то помогают делу поддерживаемого кода в условиях кривых рук и дедлайнов. А то и скорее наоборот: то, с чем на голом жс просто бы не справились, с фреймворками — всё-таки как-то взлетает на костыльной тяге, и потом доставляет миллионы радости и оптимизма тому, кому это потом поддерживать приходится.
0

Его коммент был вроде как о том, что без этих ваших фреймворков говнокодить проще, как и потом поддерживать этот говнокод.

0

Это несправедливо. Конечно в идеальном мире можно было бы ожидать каких-то идеальных решений, созданных на идеальном API. Но в реальном мире приходится чем-то жертвовать.


Если под фронтендом имеется ввиду полторы анимации выпадающего меню на статичной странице-лэндинге тогда да, вполне возможно.


Идеальный ванильный фронтенд с обходом всех косяков всех браузеров (точно всех? и тесты есть?) и имеющий хоть сколько-нибудь интересный функционал — ну вот например банальный date-picker — но не тот про который вы скажете "ну используйте нативный type="date", а посложнее чуть — с подсветкой доступных для вылета дат (реальный кейс, помните у всех были сайты авиабилетов в 2011-2012 году?) или выбором внутри диапазона дат (тоже реальный кейс, уже из отельного бизнеса) будет писаться долго, муторно, а после ухода программиста его написавшего — еще и крайней неохотно поддерживаться.


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

+1
Давайте смотреть на фреймворке проще.
Конвейер это быстрее и лучше во многих отношениях, хотя бы на примере автомобилей. Но, как ни странно, существую автомобили и мотоциклы собранные в ручную. С каждым подходом вы получаете определённые плюсы и минусы. Замечу(мне так кажеться), что результат зависит не от использования фрейморка(конвейера) или его не использования(руки). Есть прекрасные образцы как ручного труда, так и сделанного на фрейворке таком-то. И весь хайп не из за подхода (каждый хвалит свою капусту), а из за людей, которые крафтили плохой код на конвейере или самоделку.

Поддерживать говнокод всегда сложно и там и там. Хороший код всегда хорошо поддерживать и ручной и не ручной.

Если Вам удобно писать с использованием фреймворк(ов)(а), отлично! Но это не значит, что Вы выдаёте максимальную эффективность (иногда, неожиданно, даже по показателем времени). Чёткий пруф с графиками я не готов предоставить. Мой опыт, я даже допускаю, что он, не совсем мал не идёт ни в какое сравнение с тысячами разработчиков. Но я замечу, что, обычно, фреймворки решают определённый круг задач, и как только Вы выходите за пределы фреймвор — это уже нагрузка, а не помощь.

Я не против фрейморков, они решают типовые задачи, и делают это хорошо. Но это всего-лишь инструмент. И в заголовок можно написать что-то типа «Когда наконец исчезнут отбойные Молотки». Ответ очевиден =)
+1
Хорошая аналогия. 99% людей купили свой автомобиль в салоне и никто не пристает к ним с вопросами, почему они не собрали свой, который ездит быстрее и ест меньше топлива.

Однако в случае фронтенд-фреймворков почему-то аргумент про 99% типичных ситуаций уже не подходит, и всегда получается длинное обсуждение, о том как здорово делать все самому. Видимо, DIY-специфика Хабра влияет.
0

Все таки нужно уметь находить баланс между VanillaJS и FW.
Как многие сказали — фреймворки упрощают разработку, но в то же время они увеличивают размер страницы и влияют на производительность. Для каких-либо личных (читать как простых) или очень сложных проектов (например, панели управления чем-то, полноценные приложения) использование фреймворков оправдано. В первых случаях они ускоряют разработку, во вторых — упрощают поддерживание и наращивание функциональности.
Для проектов средней сложности (думаю что хабр можно отнести к таким), и проектов с которыми регулярно взаимодействуют я бы предпочел использовать как можно меньше сторонних библиотек/фреймворков. В таких проектах, как мне кажется, сложная логика на клиенте требуется чуть больше чем никогда, и цеплять всякие vue/react/angular для того чтобы отрендерить формочку для отправки комментария или цеплять jQuery чтобы просто выбрать элемент по селектору и добавить к нему класс — ну такое себе...

-1
Формочка и выбор по селектору — это как раз примеры простых проектов. Примеры проектов средней сложности для меня: рабочие места каких-то операторов, фронт- и бэк-офисы, личные кабинеты постоянных клиентов и «корзины» обычных покупателей, и т.д, и т. п. И как раз в них использование сторонних фреймворков или мощных библиотек оправдано (если возможно следовать идеологии этих фреймворков и библиотек, а не бороться с ними). А вот для очень сложных проектов оправдано «изобретение велосипедов» и, как вариант, выкладывание их в опенсорс для частичной поддержки силами комьюнити с одной стороны и бесплатной подготовки специалистов под себя. Собственно как тот же Фейсбук поступил с Реактом.
0
Вот так и получается:
1) Берем React и делаем свой продукт
2) Продукт разрастается, начинает тормозить, пилим свой велосипед
3) Выкладываем в опенсорс и получаем очередной публичный FW
4) Другие разработчики… Возвращаемся к пункту №1
+1
Все правильно, примерно так и есть, за исключением того, что подавляющее большинство проектов на пункт 2 так никогда и не переходят
0
Мне кажется, что из пункта 2 почти все успешно выполняют часть «начинаем тормозить».
Только полноправные пользователи могут оставлять комментарии. , пожалуйста.