Хороший пример — Cassandra. Написана на Java, кушает себе память и кушает. Конечно, гиганты типа Facebook держат in-house патчи или что-то такое для их объемов, но для большинства — оно работает.
И с каждым улучшением GC Java (вплоть до специально для Cassandra написанного) все пользователи
будут получать улучшение производительности или репортить баг и получать улучшение производительности.
И есть scylladb (не умаляю труда разработчиков), которая год назад только и умела, что сыпать краш дампы.
Для меня лично плюс GC в том, что я уже получаю тысячи часов работы умных людей и могу решать задачу.
А если мне понадобится оптимизировать какое-то место, то есть умные коллеги, которые сделают выбор
free vs delete или, что скорее, скажут заменить O(n^3) на O(n)
Разные проекты, требования, подходы и сроки. Где NASA может тратить 1000$ на строчку кода, обычно тратится в разы меньше. Этим и вызван взрывной рост интернета. Если бы все писали, считая delete vs delete[] vs free, то непонятно где бы мы были. Все как всегда — «каждой задача по технологии»
Routable Components, которые никак не доедут, уберут понятие Controller, а с ним и доступ напрямую через model. Будет или attrs как в React, или что-то подобное
На счет первого, в дальнейшем не будет доступа через model, так что имеет смысл уже не писать через него, а делать напрямую через setupController, который тоже должен уйти.
— Не очевидно как передавать данные между разными элиментами приложения. Я так и не понял, как я могу иницировать запрос новых данных для одного контроллера из другого.
Сейчас переходят на компоненты, a-la React. Но в целом, конструкций вида this.controllerFor хватало. Опишите детальней пример, подумаю, как можно решить, потому что сам много раз бодался.
GWT еще легок по сравнению с Vaadin. Был с последним опыт — это что-то для тех, кто не хочет писать под веб, но их заставили и они пишут как под десктоп.
Ember хорош, но в тоже время «магия» иногда приводит к значительным остановкам, а некоторые вещи нельзя сделать до определенной версии Ember.
ember-cli прикольная штука, благодаря тому, что:
* унифицирует структуру приложения еще жестче и облегчает работу новичкам
* будет частью 2.0+ и поддерживается core разработчиками
* предоставляет инфраструктуру и для тестов сразу
но:
* скорость (по итогу вынес tmp на RAM disk)
* разные дополнения разного уровня «деталей реализации», что может вылиться в необходимость или делать свой похожий или патчить чужой
* необходимость прописывать, что именно мы складываем из bower_components после brunch выглядит излишним
В целом, это отличный фреймворк, но надо быть готовым столкнуться с различными подводными камнями, источник которых не сразу будет явно виден.
Пишу на Ember. По началу — все радужно. Потом всплывают разные косяки, которые обещают починить в 2.0
Основное, что считаю поломанным сейчас:
1. собственно EmberData. Да, оно в бете, и грех жаловаться, но готовьтесь к тому, что: rollback не работает на one-to-one, one-to-many, DataBoundPromise никак не доедут до релиза
2. документация отличная, но не покрывает все моменты (некоторые вещи приходится смотреть прямо в коде)
3. многострадальные queryParams. Они вроде как есть, но некоторые вещи в них не работают и на них заведено много issue
4. синглтон контроллеры настолько всем не нравятся, что их убирают в 2.0
5. сложно писать сложные компоненты, где требуется обновление большого кол-ва property и не хватает one-way binding property. Новый подход к компонентам обещают в 2.0 (больше похоже на React)
Что действительно радует — роутер, к нему претензий нет.
Судя поrfc для 2.0, они хотят с помощью HTMLBars + one-way binding сделать компоненты похожими на React, но при этом использовать всю мощь роутера и EmberData для моделей
У вас их сколько? 10-20-100? Если много, то скорее всего вы используете или какой-то шаблон их создания/запоминания или просто разделяете на важно/не сильно важно/вообще не важно и для каждой группы делаете пароль. Если же вы реально помните кучу уникальных, сложных паролей, то снимаю шляпу.
И с каждым улучшением GC Java (вплоть до специально для Cassandra написанного) все пользователи
будут получать улучшение производительности или репортить баг и получать улучшение производительности.
И есть scylladb (не умаляю труда разработчиков), которая год назад только и умела, что сыпать краш дампы.
Для меня лично плюс GC в том, что я уже получаю тысячи часов работы умных людей и могу решать задачу.
А если мне понадобится оптимизировать какое-то место, то есть умные коллеги, которые сделают выбор
free vs delete или, что скорее, скажут заменить O(n^3) на O(n)
Вижу бенчмарки в Java, вспоминаю @shipilev
model
. Будет илиattrs
как в React, или что-то подобноеhttps://github.com/ef4/rfcs/blob/routeable-components/active/0000-routeable-components.md
https://gist.github.com/samselikoff/1d7300ce59d216fdaf97
model
, так что имеет смысл уже не писать через него, а делать напрямую черезsetupController
, который тоже должен уйти.В идеале, в вашем примере нужно:
чтобы перестать использовать
model.
в шаблонах (deprecated
)input
использовать согласноDDAU
(ох уж эти любители акронимов) и с<>
скобкамиrollbackAttributes
пока что не умеет работать сbelongsTo
/hasMany
А так, куча вещей помечено
deprecated
, но при этом замены пока нет.Спасибо
Сейчас переходят на компоненты, a-la React. Но в целом, конструкций вида this.controllerFor хватало. Опишите детальней пример, подумаю, как можно решить, потому что сам много раз бодался.
К примеру, ваш код на ES6:
ember-cli прикольная штука, благодаря тому, что:
* унифицирует структуру приложения еще жестче и облегчает работу новичкам
* будет частью 2.0+ и поддерживается core разработчиками
* предоставляет инфраструктуру и для тестов сразу
но:
* скорость (по итогу вынес tmp на RAM disk)
* разные дополнения разного уровня «деталей реализации», что может вылиться в необходимость или делать свой похожий или патчить чужой
* необходимость прописывать, что именно мы складываем из bower_components после brunch выглядит излишним
В целом, это отличный фреймворк, но надо быть готовым столкнуться с различными подводными камнями, источник которых не сразу будет явно виден.
Основное, что считаю поломанным сейчас:
1. собственно EmberData. Да, оно в бете, и грех жаловаться, но готовьтесь к тому, что: rollback не работает на one-to-one, one-to-many, DataBoundPromise никак не доедут до релиза
2. документация отличная, но не покрывает все моменты (некоторые вещи приходится смотреть прямо в коде)
3. многострадальные queryParams. Они вроде как есть, но некоторые вещи в них не работают и на них заведено много issue
4. синглтон контроллеры настолько всем не нравятся, что их убирают в 2.0
5. сложно писать сложные компоненты, где требуется обновление большого кол-ва property и не хватает one-way binding property. Новый подход к компонентам обещают в 2.0 (больше похоже на React)
Что действительно радует — роутер, к нему претензий нет.
Судя поrfc для 2.0, они хотят с помощью HTMLBars + one-way binding сделать компоненты похожими на React, но при этом использовать всю мощь роутера и EmberData для моделей