Comments 12
Фреймворки типа React
React — это не фреймворк. Впрочем, это не претензия к переводу.
Мне кажется, что нет смысла сравнивать чисто фреймворки/библиотеки. Возьмем Angular и Ember. Ребята из Эмбера сразу начнут нахваливать свой крутой раутер. А мы добавим в проект на Angular их UI-router, и разница с Эмбером будет уже меньше (Эмбер-раутер все равно круче, но не намного).
Но чтобы вот так стеки сравнивать, нужно быть очень осведомленным обо всем, что вокруг того или иного фреймворка иди библиотеки делается — это гораздо сложнее, чем пойти на официальные сайты и сравнить по документации и примерам.
Но чтобы вот так стеки сравнивать, нужно быть очень осведомленным обо всем, что вокруг того или иного фреймворка иди библиотеки делается — это гораздо сложнее, чем пойти на официальные сайты и сравнить по документации и примерам.
И эмбер и ангуляр — фреймворки. Библиотеки вам не навязывают какой-то mv-паттерн для вашего сайта/приложения. Это ключевая разница. Можно использовать фреймворк и библиотеку вместе, но не два фреймворка.
Мне кажется, в теории, критерии можно выделить. Количество сущностей на один и тот же функционал, количество кода, количество сложных конструкций и т.д. Другое дело, что никто этого не делает, только поверхностные «интуитивные» обзоры.
Не впервые вижу такое замечание и не могу согласиться. Реакт может быть использован, как DOM шаблонизатор, но, в то же время, он может работать и как фреймворк, навязывая собственную структуру кода. jQuery, например — это набор функций, не навязывающий ничего, поэтому его называют баблиотекой.
В общем, да: спустя 2 недели после публикации статьи, там же появился хороший перевод.
то-то у меня дежавю…
бросил читать после фразы
Программистом нужно понимать, что как работает – иначе они чувствуют себя неуверенно.
p.s.
(на самом деле нет, дочитаю :) )
Никак не могу отделаться от ощущения, что что-то в этом мире все время идет не так. Вот зачем изобретать какое-то API, если потом нужно изобрести еще 100500 фреймворков, что бы можно стало нормально работать? Почему бы сразу не делать фреймворк элементом архитектуры, как была спроектирована например BeOS? Понятно что кому-то покажется что фреймворк неправильный и надо делать по другому, но вдруг таких будет меньшинство?
Или может быть правы считающие излишним переусложнение программ в попытках сделать их компоненты сверхуниверсальными на все случаи жизни и надо решать только конкретную проблему стоящую перед задачей, на что вполне хватает и API?
Или может быть правы считающие излишним переусложнение программ в попытках сделать их компоненты сверхуниверсальными на все случаи жизни и надо решать только конкретную проблему стоящую перед задачей, на что вполне хватает и API?
Вот зачем изобретать какое-то API, если потом нужно изобрести еще 100500 фреймворков, что бы можно стало нормально работать?
Это состояние дел в индустрии. Сначала делаем, потом смотрим, как получилось, потом корректируем. 100500 фреймворков получается из-за того, что у всех своё мнение, как должен выглядеть идеал, плюс программисты таки решают разные задачи.
Так и работает коллективный разум. До появления Энштейнов в рамках конкретной науки, разрывающий замкнутый круг и расширяющих горизоны.
Sign up to leave a comment.
В поисках идеального фреймворка для JavaScript