Как стать автором
Обновить

Комментарии 25

Жду когда появится гений и создаст фреймворк где без лишних абстракций получится писать чистый и ясный код, решающий задачу, а не очередную проблему совместимости библиотеки А с языком B…
Возможно, через 10 лет нынешние фреймворки будут напоминать каменные топоры, но, как мне показалось, самый удобный каменный топор это Dart+Angular2. Только что читал про React и про то как круто, что расширяется JS, а не HTML, и что теперь html внутри JS, может чего-то и не понял, но всё же, думаю, что котлетки надо класть отдельно, а супчик отдельно. А задачку надо решать тем, что есть, на крайний случай создавать самому, мечтать лучше на отдыхе. Первый Angular действительно сложноват и местами запутан, Angular2 решает эту проблему, остальное дело вкуса, мне нравится сесть в машину и ехать, другим нравится тюнинг и собственные колёса. Почему Angular2 — потому, что он даёт почти всё, что нужно для фронтенда, что один проект на этой библиотеке будет похож на любой другой и прочитать код будет проще и втянуться в разработку тоже. Почему Dart — ответ в статье, настолько всё в нём просто делается, от создания проекта и до его релиза и если приходится с чем-то бороться, то это собственные ошибки, а не упущенная строчка в документации на пару томов.
В той теме я то же отписался… мне кажется вы во мне разбудили бунтаря.
Интересны были бы рекомендации при каком размере приложения имеет смысл связываться с каким либо фреймворком? А то для меня всё это выглядит как огромный блоатваре почти на пол мегабайта одного кода!!!
т.е. все эти фреймворки явно излишни для ToDoMVC примера (хотя я видел и гораздо проще примеры куда вкорчивали Angular).
Надеюсь понятно моё недоумение…

ЗЫ Dart конечно по приятнее чем JS но вся эта возня с трансляцией конечно отпугивает так же как и от TypeScript.
В отличие от TS, в процессе разработки на Dart ничего транслировать не надо. Dart код нативно исполняется и отлаживается в Dartium. Транслируем в JS только перед выкладыванием клиентской части в продакшен.

И при современной веб-разработке скорость разработки, в подавляющем количестве приложений(>95% по моим ощущениям), намного важнее чем +-3..4 сотни килобайт. Т.е. большинство «бунтарей» которые пекутся за размер и планируют участвовать в разработках сложнее чем ToDoMVC никогда не столкнутся с проектами в которых это будет критически важно. Скорость доступа она как бы растет…
Скорость доступа она как бы растет…

1. Задержка особо не уменьшается, а CDN не всегда получается использовать.
2. Не надо забывать, что это 3-4 сотни килобайт ещё надо распарсить браузером… возьмём мобильный веб к примеру. :) (у меня там от jQuery были проблемы то)

И я правильно вас понял: вы предлагаете даже для приложений уровня ToDoMVC всегда использовать фреймворки?
Я предлагаю понять, что на текущий момент есть возможность разработки и хорошо оплачиваемый спрос на разработку полноценных/полнофункциональных приложений на веб технологиях. А куча людей умеющих решать задачи только уровня ToDoMVC на jQuery для этих разработок не особенно пригодны. Приоритеты у них при разработке не те.
При публикации в веб Dart отпиливает вообще всё, что не нужно, именно поэтому я процитировал автора поста "#Angular2 для #dartlang 11.7 KB меньше чем JS версия. Я выжал что мог из обоих."
Не знаю что именно сделал автор, но результат на лицо, любой может повторить, ToDoMVC будет чуть больше, но не думаю, что уйдёт за 100кб.

Рекомендации не по размеру приложения, а по сути его работы, если нужно сделать игру, то Angular не подходит, если нужно сделать сайт со множеством страниц, то очень даже. Одностраничники вроде ToDoMVC писать только в качестве тренировки и для понимания основ работы.
В кругу коллег и в беседах просто на тему фреймворки\не_фреймворки сформировалась очень простая мысль. В текущем виде фреймворки нужны по сути только для проброса зависимостей + бутстрап. Всё остальное (даже событийная шина, кстати) — это задача приложения и\или его компонентов. Причем это справедливо и для фронта и для бэка.

Сам пишу давно на symfony (1*, 2* версии) + ангуляр 1 последние полгода.

Отсюда ответ на вопрос «при каком размере приложения имеет смысл связываться с каким либо фреймворком» — как только самостоятельная поддержка и бутстрап начинают вызывать проблемы — надо использовать фреймворк. Конечно же, желательно это «как только» предсказать, чтобы не выполнять мартышкин труд — не переписывать инфраструктурный код.
Если Dart+Angular2 это каменный топор, то Redstone.dart и Polymer это наверно будут просто камни )) Но они по степени простоты освоения и удобству использования в сравнении Angular2 как небо и земля. И при помощи этих камушков можно сложить full-stack вплоть до enterprise очень легко.
Не сказал бы, что Angular2 намного сложнее Polymer. по удобству использования — в течение пары часов приввыкаешь при переходе с Polymer на Angular2. Ну, мне так кажется. Polymer — хорошая штука, но очень уж тормозная. Angular2 вроде как побыстрее.
Вы точно сверяли Polymer 1.0 c Angular2 на схожих задачах?
Вот, например, в первом видео декларируется, что выбрали Polymer потому что он быстрее Angular 1.0. Наверняка они это про некоторую ситуацию в прошлом когда и Polymer был потормозней.
Что понимать под схожимим задачами?
Например, я разрабатывал 2 достаточо больших приложения, на Polymer 0.5.x и Polymer 1.0.x. И в обоих случаях производительность была приемлемая только в Chrome. В остальных браузерах, тк используются полифиллы — жесть просто. Ради интереса делал такое же приложение на последнем Angular 1.4 — все гораздо быстрее и стабильнее. И предсказуемо. Хотя я Angular 1 вообще не люблю.

И что еще не понравилось очень — Polymer 1.0.x очень уж сильно отличается от 0.5.x, причем в худшую сторону — столько они там всего переделали, убрали (а потом добавили все-таки по запросам пользователей). Так что переход с 0.5 на 1.0 — не такое уж и простое дело. Да и столько глюков и багов в нем, что диву даешься — они его хоть сами-то тестируют?

А ребят с этого видео знаю, работаю там же. Сейчас планируется переход на Angular 2, т.к. Polymer очень тормозной.

Angular2 это фреймворк, когда Polymer это библиотека для создания компонентов и не более того, т.е. в Angular2 приложении можно использовать Polymer компоненты, ничего плохого не произойдёт. Angular создан так чтобы подгружать контент не перезагружая всю страницу, и сайт превращается из набора html страничек в приложение, где можно обеспечить плавный переход и экраны загрузки если захочется. А какой у вас опыт создания серверной части? Я фронтендер и сделал себе на сайте сервер на Dart, запихнул туда Redstone и еще Shelf для статики, через пару недель после запуска это чудо убивается системой из-за нехватки памяти, сервер самый дешевый, который только смог найти. Вот не пойму что сделал не так.
В Polymer компонент нельзя подгружать контент не перезагружая всю страницу?

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

А сервер примитивный: codeshare.io/ubI9Y
Ну так в этом и суть полимера и веб-компонентов — строй приложение из разных независимых кирпичников, какие больше подходят для твоей задачи.
Angular создан так чтобы подгружать контент не перезагружая всю страницу, и сайт превращается из набора html страничек в приложение, где можно обеспечить плавный переход и экраны загрузки если захочется.

В Polymer это тоже возможно.
В Polymer это тоже возможно.

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

Простите, но где тут сказано про то, что в полимере невозможна подгрузка контента?
Я про предыдущий комментарий. Там вы это преподносили прямо как одно из основных достоинств.
Привет, Миш. Про котлетки и супчик хотел написать.
Jsx в React описывает компоненты, шаблоны которых небольшие (иначе стоит подумать о декомпозиции). Так что, иметь html внутри js реально удобно и уместно. И, думаю, React полюбили не за то, что у него есть виртуальный Dom, а как раз за jsx, то есть, за супчик с котлетами в одной тарелке. И ни дай Бог их разделить.
Я просто не понимаю зачем html пихать внутрь js. Давай лучше в скайпе обсудим, ты объяснишь мне в чем я не прав.
Вот и всё. Вы можете тестировать работающее приложение.

Тема апдейтов в pubspec.yaml и работа dart pub не раскрыта, ибо отсутствуют:
— хладные басни про настройку PUB_HOSTED_URL, когда основная репа дарта, висящая на одном (!) заокеанском сервере, упала;
— хладные басни про pub get vs pub upgrade при работе с git, когда непонятно с какой версией собирается и почему нужная версия не выкачивается;
— хладные басни про PUB_CACHE, когда pub upgrade говорит: «ок», но ничего не выкачивает вообще.

Много тем осталось за кадром, не всё же в одну статью.
Рома, хватит зудеть. Все эти проблемы возникают когда мы на одной машине, с одним кэшем пытаемся собрать 2 ветки одного приложения «одновремменно». Если говорить про локальные машины разработчиков то такой проблемы нет. А то что у вас на билдовой машине твориться, надо разбираться:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории