Комментарии 43
Мне кажется, тут смотря что с чем сравнивать. В данном посте нет сравнения, конечно, но в одну кучу запихано как сладкое так и зеленое, и создается впечатление, что все эти фреймворки/библиотеки про одно и тоже. Если конкретно про Meteor, то все вышеперечисленное можно использовать вместе с ним. И, мне кажется, искать корреляцию между популярностью Meteor и, например, React, будет не верно. Есть даже и подобные решения, а можно и что-то свое сделать, но в любом случае Meteor занял свою нишу, и чувствует себя там комфортно.
Слежу за Meteor постоянно и мне нравится как развивается проект в последнее время, становится более взрослым что ли. Также интересно будет посмотреть на Apollo. И какого-то прекращения разработки Meteor, отказа от поддержки или вообще умирания тоже не вижу в ближайшем будущем.
В плане функциональности, собственно про что и говорил, сейчас они делают Apollo, который будет использоваться в метеоре. Да и в целом они движутся по поставленным задачам, которые предполагают большие изменения и параллельно улучшают качество продукта: изменяются в лучшую сторону стабильность, производительность, документация, появляются какие-то дочерние проекты и т. д. И все это с какой-то проработкой делается, с учетом предыдущих ошибок.
По крайней у меня есть некоторая уверенность в этом проекте и текущий путь развития мне нравится. А я именно на нем пишу уже в течение пары лет, наверное, различные внутренние решения для компании, с возможностью совместной работы. Начинал еще с версии 0.8.3 вроде и собственно отслеживал путь развития проекта, с тех времен. Возможно я ошибаюсь, конечно, но достойных аналогов в этой нише пока не вижу.
Возможно вы и правы, что сейчас они сосредоточились на стабильности и стремятся к enterprise ready. Я сам жду какой-нибудь 2.0. Если до него и в нем будут такие же мелкие изменения, то придется уходить
Polymer как-бы не фреймворк и даже не близко.
Polymer is a lightweight library built on top of the web standards-based Web Components API's, and makes it easier to build your very own custom HTML elements
Да, есть наборы компонентов, с их помощью можно практически приложения собирать декларативно, но это НЕ фреймворк в том смысле, в котором им являются другие представленные проекты.
То же самое о React — он только view слой, и ничего больше, он сам по себе вообще достаточно скуден без экосистемы и точно не является фреймворком.
A declarative, efficient, and flexible JavaScript library for building user interfaces
Он нормальный. Остальное — реклама. Как и везде.
По фичам не хуже, чем остальные и проще для освоения (в случае с ангуляром — намного проще). Активно развивается: на подходе мажорный релиз (версия 2.0). Еще к нему vuex есть — архитектурный каркас для построения приложений
Aurelia — вроде когда-то мелькало, но видно не взлетело
Meteor — взлетело, но уже падает
Webix — аналогично Aurelia
React — не фреймворк
Хотя бы опрос добавьте с болеее широким выбором, посмотрим кто чем пользуется на хабре. Только не называйте фреймворком все и вся.
- Angular 1
- Angular 2
- Polymer
- React
- Ember
- Aurelia
Choosing a JavaScript Framework — Rob Eisenberg
Однозначно в закладки...
А компонентов для ExtJS побольше, да и мобильная версия есть (Sencha Touch).
Да и в 6-й версии ExtJS есть двухсторонний биндинг, (ViewModel, ViewController ) и так далее.
Хотите что-то задекларировать?
Да! С Aurelia больше никогда не работать!
а riot кто-нибудь пробовал?
Дело-то не в производительности движка/фреймворка, а в производительности программиста при работе с ними.
Но проблема останется в медленной работе с DOM и прочими интерфейсами, предоставляемыми браузером, которые никуда не денутся с приходом WebAssembly, или я чего-то не понимаю? Если, например, нужно отобразить 10 000 строк таблицы, данные для которых были получены по сети, а потом их изменять, перерисовывать и все такое, как тут поможет WebAssembly? В данный момент я вижу области применения этой технологии, там где нужны вычисления, например: обработка изображений, видео, звука, игровая физика и т. д. На счет не быстрого js, у меня тоже есть сомнения как ни странно.
Не пишите чушь. DOM невероятно, фантастически быстр!
А то, что вместо изменение одной маленькой ноды где-то глубоко народ вызывает element.innerHTML += 'xyz'; это никакой WebAssembly не исправит.
Те же Polymer и React ускоряют работу страницы именно аккуратным обращением к DOM (хотя и используют разные подходы).
Но в целом — да, WebAssembly может и сделает меньше нагрузку на CPU в рантайме, но больше чем на пару процентов прироста я бы не рассчитывал в общем случае. Вот для 3D графики, где много CPU времени использует именно JS код — там будет прирост.
Возможно я не совсем ясно выразился про DOM, поэтому пример конкретный привел, где мало что будет зависеть от производительности непосредственно js, по моему мнению.
И вы сами же написали:
Те же Polymer и React ускоряют работу страницы именно аккуратным обращением к DOM
Я собственно про обращения к API движка и говорил, и про то, что производительность зачастую упирается именно в это, по крайней мере в этих библиотеках.
5 наиболее перспективных JavaScript фреймворков в 2016-м году