Comments 25
jQuery лучший пока приложение небольшое, а потом, как в сказке «Золушка», после 12 часов карета … )))
Какой смысл делать все это, не сравнив, в итоге, размер бандлов, скорость рендера или потребление памяти? Где ссылка на результат? Где ссылка на исходник в удобоваримом виде? Читатель должен все это скомпилировать и отрендерить сам у себя в голове? Пример с jQuery - особенно шикарен: тащим в проект зависимость, которая, по сути, не делает вообще ничего кроме дублирования ванилы... Ну и общий стиль: "я хотел использовать такой-то фреймворк, но не хотел. Я буду использовать то-то, но может и не буду...". Что автор сказать то хотел? Что на всех этих либах можно сделать туду-лист? А мы и не подозревали.
Преждевременная оптимизация - известный антипаттерн, а Дональд Кнут вообще назвал ее корнем всех зол. Если размер бандла, скорость рендеринга и потребление памяти удовлетворительные, т.е. не вызывает проблем у пользователя, то эти цифры не имеют значения. А я вас уверяю, в приведенном примере todo листа эти все показатели будут удовлетворительными. Чистота и количество кода здесь более интересный показатель, другое дело что опять таки, показанный пример совершенно недостаточен для того, чтобы сделать вывод, todo лист без проблем можно реализовать даже на jQuery, что автор и показал, но для более сложных случаев, jQuery превращает код в императивный ад.
Если размер бандла, скорость рендеринга и потребление памяти удовлетворительные, т.е. не вызывает проблем у пользователя, то эти цифры не имеют значения.
Да, особенно это хорошо видно, когда страница комментариев у хабра загружается минуту. Ведь у разработчиков такой проблемы не было, а значит её нет
Лично я с такой проблемой не сталкивался, но даже если страница загружается долго, уверены ли вы что это именно веб браузер долго не может отобразить вашу страницу? Или это ответ с сервера долго не приходит? Или еще в чем проблема? И да, повторюсь, если вы достоверно знаете, что, скажем, из-за размера бандла страдает user experience, то да, эта проблема, которую нужно решать, если нет - есть другие важные вещи, которые необходимо учитывать
Про тормоза хабра я тут писал: https://habhub.hyoo.ru/#!author=nin-jin/repo=HabHub/article=34
Преждевременная оптимизация — известный антипаттерн
Любители приводить этот тезис так же любят забывать, что речь идёт именно про преждевременную оптимизацию. И что "преждевременная" — это не одно и то же, что "пока не тормозит, но будет". Преждевременная — это когда вы вообще не знаете, где у вас bottleneck, и имеет ли он какое-то практическое значение. Когда вы заведомо знаете, что, где, и как именно у вас будет тормозить, и такие тормоза для вас неприемлемы — это уже не "преждевременная". Даже если вы этот код еще не написали и вам еще пока не прилетели письма счастья от ваших клиентов.
И в вебе тормоза и риски очень неплохо просчитываются вперед.
Размер бандла - это крайне важно - с самого начала разработки, когда до реальных проблем еще далеко и все летает, и да самого конца. Веб-пользователи со всем их зоопарком устройств очень активно реагируют даже на легкие тормоза в UI. Когда наступают реальные проблемы, никакие антипаттерны и теоретические доводы вас не спасут, кем бы они ни были произнесены (и в каком контексте).
Если Автор берется сравнивать фреймворки, то размер бандла для сравнения очень важно указывать, так как этот бандл - это render-blocking resources, то, что будет грузиться в первую очередь и блокировать рендеринг.
Размер бандла важен только если вы пишите B2C, если какое-нибудь B2B, которое пользователь один раз загрузил и работает весь день, то это уже совсем не важно. Например CRM, ERP, торговый терминал и тому подобное. Загрузил однажды, закэшировал и пользуйся. А вот удобство разработки сложной логики тут вылазит на приоритетные позиции
Преждевременная оптимизация - известный антипаттерн
Кроме "преждевременной" есть еще "своевременная" и та, которая была необходима еще вчера. Выбор фреймворка - это далеко не то-же самое, что попытка экономии на циклах из трех элементов. Поменять стек "потом", когда гугл вас понизит в выдаче из за конского бандла, будет несравнимо дороже, чем в начале пути.
Я в js фреймворках особо не разбираюсь (на текущий момент), так, на jQuery и Vue формочки и прочее иногда леплю. Но почему то мне интуиция подсказывает, что человек с React переборщил. Или там действительно надо всё так детализировать?
Максимально простой и читабельный же из этих примеров тут Svelte.
Можно еще TodoMVC посмотреть.
Статья (врятли ее так можно назвать) перевод которого не следовало бы делать
Заголовок и заключение , аля смотри как накалякать.
Где тесты?
согласитесь как ангуляр и реакт соснули у vue по чистоте понятности минимализму ?
А вот о чем такое сравнение сложно сказать. Типа "Смотри, мама, я cli такого-то фреймворка запустил"? Мне вот во Vue нравится плагин к хрому мониторить состояние, и то что стор это по сути просто большой объект, который к тому же легко завязать к локал стораджу плагином. Отсутствие этого в самой философии ангуляра не находит принятия во мне. Если делаешь что-то вроде виджетов чата, нужно во всех фреймворках велосипедить проброс ивентов между табами, из коробки такого не находил нигде. И стоит упомянуть вещь, которая будет стопить разработку, это интеграция с сервисами вроде рекапчи, Гугл мапс и чего-то менее популярного. Не все хорошо с этим даже у Vue, совсем бледно у svelte. Лучше всего экосистема в этом плане у Реакта. Хорошо если у вас продукт, и вам можно взять несколько спринтов для интеграции стороннего сервиса как фреймворк плагина. На аутсорсе такой роскоши нет и выбор фреймворка выбирается исходя из богатства экосистемы.
Стоит ли говорить про такую вещь как нейтив которой нет в jQuery и svelte? Справедливости ради weex для Vue можно описать одним словом - боль. В Android Studio это даже не стартанет не выплюнув с десяток ошибок, от которых у не андроид разработчика волосы встают дыбом.
Добавить сюда бэк с ворохом SQL и noSQL и окажется что фуллстек синоним слова ноулайфер :)
Svelte - все не так. Что не так? Все не так. Ну, хотя бы пример не работает и не должен.
https://svelte.dev/repl/b84291af78cf49ba9aaa0a1e1774e482?version=3.42.4
Этот вариант должен работать. Стили в вашем примере не могут работать, они в скоупе компонента и .container main .note form не будет работать из App.svelte для компонента Note
Сабмит формы должен быть on:submit|preventDefault
Для меня все выглядит многословно и... избыточно. Да, я переписал не на TS, но речь не про это. Свелте в переводе - тощий, стройный. Это так, если его не велосепедировать.
В целом, подход людей, знакомых с другими фрейворками которые пробуют пользоваться свелте - удручает. Свелте не про JS. Он - компилятор, поэтому, человек, хорошо знакомый с JS\TS будет говорить - это не возможно в JS и сознательно построит велосипеды.
Он модульный до тошноты. И да, на выхлопе это удобно и он заставляет делать все модульным. Хотя бы - стилями per module.
Его реактивность и store выглядят как детский сад - и это прекрасно. Поставить $storyName.title, и забыть об обновлениях на странице.
Просто пройдитесь по https://svelte.dev/examples#hello-world и посмотрите на то, как авторы видят подход к програмированию на этом фреймворке. Полчаса времени для знакомого с реактом, vue. Для тех, кто не любит перелопачивать сотни строк и не берет денег за кол-во строк - самое то.
PS: Зачем парсить json? localStorage умеет объекты. (в своем переписанном примере использовал svelte/store, это svelte-way, гибко и ....в REPL не работает local storage из за iframe, как понимаю ). В проекте тоже использовал бы store, а к нему уже прикручивать - куда писать данные и от куда читать)
Создаём одинаковое приложение 5 раз