QA Fest — конференция №1 по тестированию и автоматизации. Финальная программа уже на сайте >>
×Закрыть

Выбор JS фреймворка

Какой бы фреймворк вы выбрали для разработки приложеия SPA, учитывая, что ES2015 на подходе. Пока остановился на angular 2.0, ember 2, aurelia. Что можете посоветовать, учитывая что важно чтобы была хорошая модульность, менее нагрузочный data-binding, поддержка TS?

LinkedIn

Лучшие комментарии пропустить

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Мне Ember нравится. Хорошо ложится на ментальную модель Java backend девелопера

Мне тоже, только ember-data пока не очень. Например невозможность откатить изменения в отношениях печалит, так как при редактировании приходится создавать копию, работать с ней, потом изменения копировать в оригинальную модель.

мне кажется мы пересекались на stockoverflow по теме ember

Возможно, я иногда там бываю

Вопрос к адептам front-end разработки. Если нужно не SPA, а например типичный e-commerce проект с серверным рендерингом, что в таком случае на фронте будете использовать?

Сам использую Backbone, который подхватывает состояние того что выдал сервер. Но например Angular для такого не очень годится, хотя могу ошибаться.

Я бы все же не менял вопрос: а когда рендеринг на сервере плох, а когда хорош?

Смотрел недавно доклад про историю рефакторинга одного хайлоад приложения. Эпизод: убрали ноде джс для чата. В среднем в чате 30к посетителей, но пишут только пара тройка процентов. В итоге читателям посылается закешированные фрагменты хтмл кода. И чат стал летать без всяких вебсокетов.

Я бы в таком случае обошёлся классическим подходом с одним только jQuery и рендерингом страниц на php или что знает тот, кто будет реализовывать. Моё мнение такое, что если нужны 1-2 аякс-запроса (добавление товара в корзину, авторизация), то использование какого-либо из обсуждаемых здесь фреймворков напрасно усложнит разработку. Они (фреймворки) придуманы для SPA. А интернет-магазин (это же вы имеете в виду под «типичный e-commerce проект»?) — это никак не A (приложение), это на 99% S (сайт).
Но в общем случае нужно смотреть на конкретное ТЗ. Если оно предполагает, что нужно больше выводить статичной информации (каталог товаров), чем работать с пользовательскими данными — это проще реализовать обычным сайтом.

quick & dirty анализ:
Имеет ли смысл где либо между сервером и отображением информации — кешировать отображение?

Расшифровка: — как много потребителей у конкретного отображения информации, чтобы имело смысл — кешировать.
Примеры:

Корзина покупателя с заполненными позициями. В общем случае ее содержимое будет уникально для каждого посетителя. Значит — не имеет смысла кешировать ее отображение.

Карточка товара — она одинакова для «всех» посетителей, так зачем ее «рисовать» каждому, неважно где, на сервере, или в браузере?

Интерфейс ERPсистемы — у каждого оператора («бухгалтера», «менеджера», ...) будет свой набор отображений информации, причем каждый элемент-"виджет" имеет множество настроек (период выборки, отбор по значению дисконта, ..., ...) и поэтому скорее уникальный, чем как «всем». НЕ имеет смысл кешировать — значит SPA на ExtJS, ..., ...

«Лента Фейсбук»: состоит из элементов отображение которых всем одинаково, независимо от персональности самой ленты, ....

и т.п.

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

15тыс+ строк кода на JS, это без библиотек и шаблонов

Вполне можно обойтись, если нет нужды в активном использовании аякса. И даже проще, чем бороть разные «особенности» современных фреймворков (как известно, идеально всё работает только в документации, шаг в сторону может обернуться задачей на пару дней).

Это да, Angular или Ember будут большой проблемой в таком случае. В общем как я и думал, альтернатив пока нет

А вообще я б посмотрел бы на фронтэнда,
а я бы посмотрел сюды:
trends.builtwith.com/...script/javascript-library
обошелся бы классической лапшей на jQuery
а не надо всегда, безусловно, т.е. догматически выбирать jQuery
«Интернет магазины» тоже бывают разные.
— а вот я знаю случай...

случай не отменяет статистики. а по статистике — средний электронный магазин — это ...?

jQuery весит всего 84кб, не спорю там есть то что в принципе не будет использоваться. Все оттуда можно заменить на свои костыли, но зачем? Да и вопрос о упрощении разработки и поддерживаемости кода

И если на то пошло, люди активно Babel и прочие полифилы пихают для того чтобы быстрее заработали новые плюшки, а то что оно сгенерит лишнего кода никого ж не волнует?

И если на то пошло, люди активно Babel и прочие полифилы пихают для того чтобы быстрее заработали новые плюшки
статистика — есть? про «активно»?

давайте я вам пример приведу, наглядный.
У некого чела Ч в фейсбуке 300 «друзей».
3ое из них сходив на фильм Ф, написали — какой здоровский фильм! Всем смотреть!
1 написал — гуано полное.

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

но чел по имени Ч делает вывод — а классный видать фильм, большинство же друзей написало.

Эм.... Даже не буду пытаться сравнивать с количеством инсталляций какого нить престашоп.

Это то что я писал в теме разработчик не инженер
Неумение оперировать количественной информацией. Извините.

О чем тогда эта статистика? trends.builtwith.com/...script/javascript-library

Не хочу обидеть чьи-то чувства, но Prototype, YUI, script.aculo.us, MooTools как часто вы сталкивались с этим всем? Упоминания о них остались либо в книжках вроде Стоян Стефанова в качестве примеров шаблонов, либо в каких-нибудь уж совсем старых проектах. Нужна по ним статистика — откройте вакансии по фронтэндам и посмотрите какие технологии требуются.

На самом деле по приведенной ссылка вообще лютая каша во всем. Как-будто авторы от балды сгруппировали все что знали.
Ну вот как можно в одну категорию засунуть бекбон и моментджс? что во фремворках делают хендлбарс и мусташ? какой вообще смысл в категории node.js и почему туда опять засунули бекбон?

а я бы посмотрел сюды:
trends.builtwith.com/...script/javascript-library

и что там видать?

И я не совсем понял основную идею ответа. Ну есть тонна ресурсов которые используют джейквери. И что?

Конечно ничего. Он уже умер. Вчера ещё.

*остроумное замечание про Кобол*

Навешивать компоненты поверх отрендеренной страницы?

Ну как бы вариантов несколько, 1 реакт будет рендерить, ты ему только данные скармливай, 2 выдавай html который совпадает в виртуальным домом реакта, реакт увидет что все идентично и просто навесит свои ивенты. 3 самый идеальный react на сервере отдает html сразу, и тот же код реакта потом подхватывает работу на фронте. По 3 варианту кстати будет хорошый доклад на конференции Angular&React Framework days

Т.е шаблоны в любом случае дублировать придется для корректной работы реакта?

ну в первом варианте не надо. Из недостатков только то что страница отрендерится когда js загрузится а не сразу. Поисковикам это не помешает проиндексировать, все го то увеличится время отображения страницы ровно на время загрузки js скрипта

В чем профит тогда от реакта?

скорость написания интерактивной части страницы (работа с DOM), скорость изменения DOM, чистота кода, возможность писать на es6. Вобщем дофига

а если не надо менять DOM для каждого посетителя сайта.

То в чем профит?

писать на es6.
прикольный аргумент, выбирать фреймворк, из-за фич языка, которые через год два будут штатными...

где вы видели WEB2.0 без изменения DOM? Сейчас даже для select не используют стандартный браузерный. А это тоже манипуляция с DOM деревом.

прикольный аргумент, выбирать фреймворк, из-за фич языка, которые через год два будут штатными...
Конечно прикольно. Через год два все будут переписывать а у тебя уже все готово. Не зря же Twitter уже сейчас использует css4
где вы видели WEB2.0 без изменения DOM?
я не падаю ниц перед технологиями.

а DOM менять можно по разному — разным.

Чем славен Backbone ?

не проверял, но встречал много где о том же цитата:

Из того, что мы можем хорошего сказать про Backbone — он быстр. Вот такой простой шаблон, сговняканый на коленке при помощи underscore.js, будучи развернут 100 раз в один и тот же узел DOM при помощи присваивания в innerHTML...

<% for( var i = 0; i < 1000; i++ ){ %>
<div class="row">
<div class="col"> a </div>
<div class="col"> b </div>
<div class="col«> c </div>
</div>
<% } %>

...берет на свой разворот примерно 1,5-2 секунды. Полностью идентичный разворот HTML на ультрасовременном ReactJS с элементами искусственного интеллекта обновления DOM занимает 12 секунд. Это с учетом того, что React разворачивает его только один раз, а остальные 99 — вообще пытается не трогать DOM. Из соображений тонкой оптимизации.

gaperton.livejournal.com/65989.html

Пост ценен тем что называется:
Backbone Sucks

Через год два все будут переписывать а у тебя уже все готово.
другими словами инвестиция даст выигрыш через год-два.
или не даст.

мало того — например в провокационной книге «Блеск и нищета ИТ» на многочисленных примерах показывается, что пионеры чаще всего — пролетают :)

Не зря же Twitter уже сейчас пишет на css4
ну, если вы пишите новый Twitter, то да.

оно конечно и на лисапед можно прикрутить турбину от Пратт Уитни. Выигрыш перед остальными будет — огромный :)

Ну и причем здесь backbone? давайте не путать шаблонизатор с фреймворком. Можно взять тот же lodash или underscore и обойтись только им, можно по старинке на jQuery. Но сейчас в тренде React и не просто так.

P.S. Я даже и подумать не мог что из поста из двух слов может вырасти такое дерево :)

авайте не путать шаблонизатор с фреймворком
еще раз — давайте не путать задачу, условия ее и решения — и применение чего-то моднего ради применения моднего.
Но сейчас в тренде React и не просто так.
кто вам сказал? ;)
dou.ua/...orums/topic/14905/#773006

вы знаете что такое Hype cycle?
думаю знаете.

так что разницу между трендом:
говорят на каждом углу
и
применяют в каждом десятом (хотя бы) проекте
пояснять думаю не нужно

я просто оставлю это тут github.com/...ct/wiki/Sites-Using-React
The New York Times
По «React» находит в коде ресурсов только beforeactivate._change
По «Backbone» — кучу всего. :)
Reddit — аналогичная история.
Третий раз я не искал, чтобы не портить статистику :)
.
Если более серьезно, то таки не надо путать хайп и тренд. Про тренд можно будет говорить через 1-2 года.

Как часто на практике Вам приходилось развернуть список на 1000 элементов и потом при каждом чихе обновлять все эти элементы? О чем это вообще?)

И Backbone рендерингом не занимается. Хотите используйте Underscore, хотите React или нативный API

Речь я вёл о том, что если не надо манипулировать дум деревом, то зачем им оперировать? См мой пост с пример quick & dirty анализом

Ember тоже умеет es6. Вернее, ember-cli умеет, рекомендованая утилита для сборки

Простите но звучит как в той шутке: JAVA говорит: я такие вещи делал что ни одному языку и не снились. .NET отвечает: Да я такие вещи в банковском секторе рулил что те в жизнь не смочь. И PHP рядом: я тоже что то делал!!!!

Ну, если констатацию того факта, что поддержка es6 не является уникальной фичей реакта вы видите именно так — ваше право.

про поддержку es6 реактом я написал самым последним пунктом не просто так. Это просто как маленький плюс.

Angularjs. То, что в обозримом будущем уже маячит angular2, не должно смущать — обещают обратную совместимость и плавный переход

Не задалось как-то с обратной совместимостью.

я аж заплакал

Попробовал бы использовать React с различными ништяками (Flux, например, Webpack, ES6 само собой). Пока не пробовал, нет свободного времени, так что ничего сказать не могу.

Всем привет
Хочу спросить у программистов, которые пишут на JavaScript

Какие фреймворки Вы используете на работе?
Для BackEnd-а и FrontEnd-а.

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

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

Спасибо

Angular на 2х проектах. Хоть ему и пророчат скорую смерть, умирать он не собирается. Он везде сейчас и будет востребован в ближайшее время.

... посмотрел на требования по вакансиям JS-разработчика, понял что их очень много существует, разных, для разных целей, но я хочу знать, именно стек фреймворков, которые используются в большинстве всех случаев
По фронт-энду.
Нету «стека фремворков». Есть (в порядке новизны, и немного популярности): react, angular, backbone; для задач не архитектурных, а как разумный набор утилит jquery и в некоторой мере underscore/lodash.
Учитывая «хипстовость» направления, все может поменяться в любой момент. Если цель найти работу, то лучше ее сначала найти и потом просто изучить «стек» который будет на вашем месте работы.
Но в общем, думаю, стоит почитать статью о Дяди Боба bit.ly/1UGqgc9
статью Дяди Боба
К таким статьям тоже нужно критично относиться, а то можно удариться в велосипедостроительство :)

ну-у-у-у... на самом деле практически любой популярный фреймворк является скорее компромиссным решением чем наилучшим. вы только не подумайте, что я всех призываю писать свои фреймворки.

. посоветую подумать на фига вообще нужен SPA. С точки зрения пользователя сайта — ему пофиг он идет на сайт за информацией и не восхищатся крутизной разработчика (скорее наоборот — яваскриптовые фреймворки будут жутко тупить на мобильных платформах) а разработка подобных приложений гораздо более трудоемка.
Иными словами SPA не имеют никаких преимуществ — одни проблемы. И вообще в эпоху облачных вычислений таскать бизнес логику на клиента как минимум глупо.

а вы не задумывались почему все хотят SPA? единственное что лучше SPA — это гибриды, но их разработка еще более трудоемка

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

так же есть куча сервисов которые без SPA подхода вообще невозможно создать

то есть аргументы — «все хотят» и «тренд». Попросту говоря — это модно в этом сезоне, все такое носят.. Собственно других аргументов я и не ожидал.
и какие такие сервисы нельзя реализовать без SPA?
и кто эти "все хотят? уверен что не пользователи сайтов.

я написал

а вы не задумывались почему все хотят SPA?
это не было аргументацией, это было предложение включить мозги
и какие такие сервисы нельзя реализовать без SPA?
гугл докс и ему подобные
и кто эти "все хотят?
бизнес
уверен что не пользователи сайтов.
пользователи вообще не могут знать чего они хотят, они на то и пользователи
Попросту говоря — это модно в этом сезоне, все такое носят..
сразу видно что вы в бизнесе ничего не понимаете
это не было аргументацией, это было предложение включить мозги
предпочел бы агрументацию а не отмазки
бизнес
ничем не подтвержденное вранье.
гугл докс и ему подобные
какой процент таких сервисов? Лично сделаный вами сервис типа гугдедокс в студию.
пользователи вообще не могут знать чего они хотят, они на то и пользователи
в бизнесе , к которому вы апелируете, всегда знают что хотят. Иначе вылетают с бизнеса.
Отмазка «пользователь тупой лох» типична для доморощеных програмеров с юношескими понтами. В странах где есть Кремниевые долины считают что надо делать как требует пользователь а не умничать. Уж поверьте — не один год на аутсорсе сижу. Когда пытаюсь говорить их программерам — давайте убедим пользователя сделать по другому — на меня смотрят квадратными глазами.
Работает только ТЕХНИЧЕСКАЯ аргументация и не «погуглите» или «включите мозги» а ссылка на оф. сайт или саппорт продукта где четко сказано что есть те или иные проблемы.
сразу видно что вы в бизнесе ничего не понимаете
вы первых мы обсуждаем не бизнес. а во вторых, предьявите свой многомиллионный бизнес, senjor developer лабающий на яваскрипте.
предпочел бы агрументацию а не отмазки
написал ниже
ничем не подтвержденное вранье.
ну ясен пень что я не могу вам раскрывать детали — все под НДА
какой процент таких сервисов? Лично сделаный вами сервис типа гугдедокс в студию.
небольшой, мной такого плана сделан один — линк на сервис не дам, так как не имею права
Работает только ТЕХНИЧЕСКАЯ аргументация и не «погуглите» или «включите мозги» а ссылка на оф. сайт или саппорт продукта где четко сказано что есть те или иные проблемы.
вы не мой клиент, я вам не должен разжевывать
а во вторых, предьявите свой многомиллионный бизнес, senjor developer лабающий на яваскрипте.
бизнеса у меня нет, но я хорошо понимаю как он мыслит, ибо проталкивал очень много ченджей, на которые клиент соглашался

ладно, так и быть. по сути SPA решают проблемы UX, не более того, в первую очередь при помощи более быстрого отзыва приложения (валидация форм на клиенте, AJAX намного быстрее чем ререндеринг целой страницы, путем хранения данных на клиенте часто можно вообще избежать некоторых запросов на сервер, то есть все сводится к тому что все действия производимые пользоввателем происходят быстрее, а ему можно показать няшный лоадинг в это время). по факту, это самое главное преимущество, его можно дробить на мелкие, ибо там куча факторов, но в итоге все сводится к UX improvment

ну, вот, смешались в кучу кони, люди...

валидация форм на клиенте, AJAX намного быстрее чем ререндеринг целой страницы
jQuery с этим поспорит. или это джкверя «делала SPA, когда это еще не было мейнстримом»? :)
путем хранения данных на клиенте
cookie

по-моему, вы спутали «логику на клиенте» и «SPA как подход».
SPA оно про навигацию. экономим на оверхеде по запросам большого количества элементов(потому что даже для 304 Not Modified надо послать запрос), а в итоге должны самостоятельно реализовать инициализацию(в зависимости от URL — т.е. навигация ж) и запрос данных.

jQuery с этим поспорит. или это джкверя «делала SPA, когда это еще не было мейнстримом»? :)
это было до. собственно активное использование и привело к созданию более активного использования логики на клиенте, что и привело к формированию термина SPA
cookie
хранение данных на клиенте подразумевает — cookie, localStorage, sessionStorage, IndexedDB, App Cache, 304 & Expired header, js inmemory
SPA оно про навигацию.
навигация не обязательный аттрибут, но очень полезный

Wiki:
Single page application (SPA) — это веб-приложение, которое выполняется непосредственно на стороне клиента в Web-браузере, обычно написанное на комбинации из HTML, JavaScript и CSS[1]. Приложение может получать доступ к структурам веб-страницы как к объектам дерева DOM.

хранение данных на клиенте подразумевает — cookie, localStorage, sessionStorage, IndexedDB, App Cache, 304 & Expired header, js inmemory
ваш менеджер будет в восторге что инвойс или заказ поставщику вы сохранили у себя в мабиле а не на сервере. Вы ж к бизнесу апелировали? Или к браузерным игрушкам?
Wiki:
Single page application (SPA) — это
все знают что это. Вопрос не «что это» а «зачем это»

Вы вообще проектированием веб приложений хоть раз в жизни занимались?

все знают что это.
а что это, по-вашему?
хранение данных на клиенте подразумевает — cookie, localStorage, sessionStorage, IndexedDB, App Cache, 304 & Expired header, js inmemory
я о другом. то, что вы выделяете как «аттрибуты SPA» было задолго до появления этого термина. и любого другого. «веб-приложение» === «SPA»? че-то мне думается, что SPA — это лишь подмножество, подход к реализации веб-приложения. и если у нас в некие моменты будет происходить перезагрузка страницы — приложение не перестанет содержать в себе сложную логику.
Single page application (SPA) — это веб-приложение, которое выполняется непосредственно на стороне клиента в Web-браузере, обычно написанное на комбинации из HTML, JavaScript и CSS[1]. Приложение может получать доступ к структурам веб-страницы как к объектам дерева DOM.
в чем его single-page’ность в таком случае? ну, раз «навигация не обязательный аттрибут». а?

беру URL, делаю на нем контейнер с несколькими компонентами(карта, форма с клиентской валидацией, данные отправляются по AJAX) — у меня уже SPA, выходит?

че-то мне думается, что SPA — это лишь подмножество, подход к реализации веб-приложени
вам очень правильно думается))
в чем его single-page’ность в таком случае?
если вы замыкаете весь функционал приложения на одной странице — это и есть SPA. навигацию не обязательно использовать, можно без нее спокойно обойтись, но тогда невозможно (не то чтобы совсем, но по нормальному не выйдет) передавать состояние приложения, однако можно по прежнему его сохранять для одного взятого пользователя через куки и локал стореджи, по сути path от URL это некое глобальное состояние приложение, удобное для передачи, то есть часть модели приложения.

любая JS игра — SPA, чатик — SPA, если у гугл мапс отобрать изменения линки — это на функционал повлияет? — нет, но все равно будет SPA.

кстати MPA по факту набор многих SPA :)

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

А теперь обратная сторона — вам надо сходить на сервер — получить данные и в зависимости от них подучить следующие. Типичная задача сложной бизнес логики

на сервере — это просто последовательное обращение к БД. на асинхронке - обращение к серверу ожидание колбека с ответом — затем еще одно обращение.
И что мы сэкономили? учитывая то что все равно надо писать серверную часть так или иначе.
Реальная экономия если это какая нибудь браузерная игра.

Еще раз — нет никаких внятных аргументов в сторону SPA.
это действительно тренд, по просту говоря мода которая завтра сменится на что то другое.

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

Реально, самый разумный подход -компонентный как например в WebForms - там фреймворк сам восстанавливает страницу — програмист заимается тем чем ему положено реализует бизнес-логику и не заботится как передать данные на клиента и прочитать оттуда — он работает с бэкендом.

Впрочем спорить с вами нет смысла — когда эта мода пройдет (а она пройдет я за многолетний опыт програмирования уже не одну проходил) вы к тому времени повзрослеете и начнете думать объективно а не с помощью «трендов» раскручиваемых в первую очередь производителями тех же фреймворков.

Удачи.

.

Вы себе просто не представляете, насколько вы заблуждаетесь.
Единственное в чем вы правы, что понятие СПА когда-то канет в лету.
Но вместе с ним и канет понятие МПА, за которое вы так цепляетесь.

на сервере — это просто последовательное обращение к БД. на асинхронке — обращение к серверу ожидание колбека с ответом — затем еще одно обращение.
Кхм, база данных может тоже находиться на удаленном сервере и к ней тоже очень полезно обращаться асинхронно. Про async/await, слышали? Помогает писать асинхронный код, будь то C# или JS, если в этом проблема.
WebForms
многолетний опыт
Может, вам просто неинтересно/лень изучать/искать более эффективные решения? И поэтому вы доказываете, что ископаемыми технологиями тоже можно решать задачи?
Еще раз — нет никаких внятных аргументов в сторону SPA.
А как же юзер экспириенс, СПА делается в первую очередь для пользователя, и если пользователь хочет этого все аргументы против его не волнуют

Не утруждайтесь я это уже пробовал пациенту объяснить. Пациент кроме себя ничего не слышит.

так же есть куча сервисов которые без SPA подхода вообще невозможно создать
я уже сомневаюсь, что речь о single page application
не дадите расшифровку?

речь о сингл пейдж приложениях. гугл докс попадают более чем под это определение.

А зачем вам голова? Она нужна только чтобы в неё есть, так иногда она ещё и болит.

то есть по делу возращить не можете? Что и следовало ожидать?

По делу я говорю с теми, кто это дело знает. Вы, судя по всему, не знаете что такое SPA и зачем они нужны, и просто хотите поспорить на пустом месте. Мне это неинтересно. Хотите аргументов за и против — погуглите, это общедоступная информация.

во первых вы не знаете что я знаю а что нет. В частости как раз с матюками доделываю страницу на Flex за такими же эвангелистами как вы, которых выгнал заказчик. А во вторых. — «погуглите» это типичный аргумент тех кому нечего сказать, то есть привести ТЕХНИЧЕСКИЕ " аргументы.
как и с любыми эвангелистами — как можно возражать ведь в эвангелии написано.

У вас пригорает

Сами себе ещё и сливы засчитываете? Похвально, не каждый способен.

скорее наоборот — яваскриптовые фреймворки будут жутко тупить на мобильных платформах
Бинго
И вообще в эпоху облачных вычислений таскать бизнес логику на клиента как минимум глупо.

Снять часть нагрузки с сервера и перенести её на клиента — в условиях высоких нагрузок может дать хорошую экономию на услугах облачных сервисов.

Щодо Angular 2.0 або React я б ой як задумався... Для мене в цьому сенсі більш приємний Angular 1.x або Riot. Не так давно написав пост у себе в блогу про кілька фреймворків

Да, Riot симпатишный и как мне показалось довольно простой в изучении (смотрел пару обучалок по нему на ютубе)

Посмотри в сторону Backbone + Marionette

опыт у команды с чем из указанного?

есть ИМХО симпатичный фреймворк vue.js — vuejs.org

из всех фреймворков (не считая jQuery, который как бы не совсем фреймворк), что я смотрел мне он больше всего понравился и был более понятен, чем другие фреймворки. Хотя и ангуляр в принципе неплох.

Лично мы юзаем CanJS просто по дефолту :)
Все проекты с его использованием построены по полностью модульной системе.
Есть двусторонний дата-биндинг

Открою тайну. Чтобы написать действительно хорошее SPA достаточно jQuery и Javascript. Современные джаваскрипт фреймворки это жалкие недопилки, которые угробят любое SPA сложнее тудулиста.

Чтобы написать действительно хорошее SPA достаточно jQuery и Javascript.
все закончится написанием своего недофреймворка.
скажите сколько SPA вы проектировали и разрабатывали? и какой сложности?
все закончится написанием своего недофреймворка.
да. но оно не будет тормозить карл.
скажите сколько SPA вы проектировали и разрабатывали? и какой сложности?
4
да. но оно не будет тормозить карл.
только багов будет вагон, и введение людей в проект зашкаливать.
если вы грамотно выбираете фреймворк, и ГРАМОТНО ЕГО ИСПОЛЬЗУЕТЕ, то ничего тормозить не будет

С введением людей в проект все в норме, если использовать принципы Solid и KISS, а «люди» — не студенты с второго курса политеха — проверено на опыте. Насчет багов — тоже самое.

А в сторону react не хотите посмотреть?

react по сути компоненты, а мне необходимо SPA приложение
да и не люблю я когда мешается js и html

да и не люблю я когда мешается js и html
как это уживается с вариантами angular и aurelia?

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

проблема ангуляра в том, что вторая версия не будет совместима с первой

вы не на то смотрите, вам решение делать надо, а не самую свежую технологию выбирать

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

вы знаете, я вам с радостью помогу, честно, но опишете что должно делать приложения — именно хай-левел, и опишите опыт команды. я вам смогу дать совет тогда с аргументацией, хотите пользуйтесь, хотите нет. но пока мало данных

Приложение хочу разрабатывать пока сам, в качестве pet project, но со временем может быть и переход в нормальный проект с монетизацией. Приложение типа ведения домашнего бюджета с множеством различных статистических возможностей, рассчетов на будующее, на скринах могут отображаться данные за месяц в виде календаря и т д. И что лучше выбрать с бекенда, parse.com сервис или писать свой на asp.net web api?

И что лучше выбрать с бекенда, parse.com сервис или писать свой на asp.net web api?
думаю www.ucoz.net для вас самый вариант

а по поводу производительности Angular, рекомендуется ознакомиться минимум с
blog.scalyr.com/...angularjs-1200ms-to-35ms
tech.small-improvements.com/...ormance-with-large-lists

а этим

проблема ангуляра в том, что вторая версия не будет совместима с первой
пренебречь, так как человеку с вашим то опытом и знанием такого кол-ва терминов осилить какой-то там ng2 не составит проблемой... ящитаю

освоить то не проблема, проблема в том, что понадобится время на переписывание всего приложения

ну думаю, это тоже не проблема... ucoz.net обладает достаточно большой коллекцией жеквери скриптов... основная проблема: разобраться с админкой, но думаю, что у вас всё получится... и тогда, хочешь — новый счётчик прямо на странице, хочешь — совершенно новый шаблон для всего сайта!

думаю www.ucoz.net для вас самый вариант
брать платформу ради использования в качестве бекенда для пет-проджекта?
а как там кастомные схемы данных реализовывать?

Что-то мне подсказывает, что это было написано с целью обосрать, а не в русле конструктива.

тогда мой вам совет — angular, судя по всему у вас будет простенькое приложение (то есть слегка продвинутый ЮАй, будете директивы юзать, и отсутствие бизнес логики на клиенте), ангуляр для таких целей отличным.
юзайте только первый, ибо пока вторая версия не стабилизируется, может усугубить сильно разработку, введение различных брейкинг ченджей.
бекенд — на том что знаете, ибо весь ваш бекенд сведется к проксированию запросов к БД

ну а вдруг ng1, пока данный ТСер проЭкт свой пилить будет таки реально устареет? что делать в таком случае? непонятно...

таки реально устареет?
поясните этот вопрос пожалуйста, что вы вкладываете в понятие «устаревания технологии»

да ты понял мой вопрос!!!1 что делать, если ng1 устрареет, а ng2, как известно — не совместим с первым! что это по вашему, как не проблема angular, о которой ТС прекрасно осведомлён, а вы, оказывается нет!
вот из-за таких как вы у ТСеров подобных данному и возникают проблемы, и вместо того, что бы решать конкретно, вы продолжаете гнуть свою линию!

ng2, как известно — не совместим с первым
вы уверены? angularjs.blogspot.com/...ngular-2-coexistence.html
ng1 устрареет
как бы недавно вышла версия 1.4, сейчас идет работа над 1.5

в реальности понятие устаревание технологии весьма субъективно, никто сбрасывать суппорт не будет первого ангуляра, а сегодняшний код как выполнялся так и будет выполнятся.

может это не будет самим «свежим» и «крутым», но если вы за этим гонитесь, то у меня для вас плохие новости. ничего не выйдет. это ИТ. завтра будет новая технология

теперь понимаешь, почему ты до сих пор девственник ?)

думаю, по

!!!1
уже можно было понять, что человек не всерьез.
PS ну, или белка-истеричка. но скорее всего — просто троллит.

да-да, полностью с вами согласен! Очевидно же, что ТС — тролль!
ловко вы Евгений его раскусили!

к сожалению, много таких кто всерьез в это верит

насчет «устаревания»? ну, да.
а еще есть те, кто уверен, что можно сделать «правильный выбор инструментов» и потом все пойдет как по маслу.

отсутствие бизнес логики на клиенте), ангуляр для таких целей отличным.
Почему angular плох если на клиенте более сложная логика? И если не angular, то что вы предпочитаете: ember, aurelia или react?
Почему angular плох если на клиенте более сложная логика?
не «плох», а «проще выстрелить себе в ногу».
предположу, раз автор темы спрашивает, опыта у его/команды ни с чем из вышеперечисленных особо нет.
react жестко определяет подход к построению приложения, эмбер тоже декларирует определенные ограничения.
ангуляр дает достаточно разнотиповых подходов, чтоб без опыта можно было «наворотить делов».

Я тоже начинаю делать свой pet-project и тема мне интересна. А опыт есть только с Knockout. Aurelia выглядит намного понятнее, что ли. Но планы по реализации server-prerendering у них только в далекой перспективе. А React предполагает использование immutable структур данных и я не уверен, что это то, что мне нравится. Думаю начать ковырять Angular 2.

angular 2 имеет смысл, только если вам просто технология интересна

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

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

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

крутой фреймворк, который помогает решить любую задачу, быстрый и понятный
к сожалению, или к счастью, такого не существует
планы по реализации server-prerendering у них только в далекой перспективе
типа такой перспективы: github.com/prerender/prerender ?

Я слышал про phantomjs. Тут идея в том, что бы сервер сгенерил страничку, которую потом сможет подхватить клиент и дальше работать с ней, как будто она сгенерена на клиенте. Вот вчера посмотрел www.youtube.com/watch?v=0wvZ7gakqV4. Такое уже есть у ember и react. У Aurelia только в планах github.com/...relia/framework/issues/72.

насколько такое актуально в вашем проекте? ускорение отображения за счет усложнения инициализации(как пример: в видео по ссылке на серьезных щах предлагают «записывать» клики и прочие действия пользователя, а потом «воспроизводить» уже после инициализации).

а server-side rendering игнорирует одну удобную вещь: кеширование.
шаблоны на клиенты кешируются и потом, гоняя только данные(JSON/XML/etc), мы реально можем экономить на трафике.

мне думается, через link[type=prefecth/prerender/dns-prefetch] и разделением шаблона на небольшие фрагменты можно добиться большего, чем рендерингом на стороне сервера.

а для SEO достаточно и prerender на phantomjs

насколько такое актуально в вашем проекте?
Не думаю, что это сколько-нибудь актуально, просто мне идея очень нравится, я дЖва года ждал фреймворк, который помогает это реализовать. И хочу попробовать. Идея отличная.
«записывать» клики и прочие действия пользователя, а потом «воспроизводить» уже после инициализации
Это будет реализовано Фреймворком, на сколько я понял.
кеширование
Нужно наверное разобрать какой-то конкретный пример. И я не знаю деталей реализации пока. Ведь страница, которая придет с сервера, возможно, уже будет содержать все шаблоны — тогда производительность только улучшится. А если шаблоны будут подгружаться на лету — то они тоже будут кешироваться. Просто повторюсь, я не утверждаю, что это оптимальное решение, но хочу попробовать. Это то, чего мне очень не хватало в ASP.NET MVC с knockoutjs и приходилось делать костыли (которые, впрочем, вполне сносно работают).
Это будет реализовано Фреймворком,
я и не писал, что именно вам это делать вручную.
просто уменьшая оверхед в одном месте, получаем его в другом. а вместе с задачей — даже если за нас делает фреймворк — новые баги и нюансы. лучше знать — зачем это всё надо. только тогда понятно, сто́ит или не сто́ит.
Нужно наверное разобрать какой-то конкретный пример.
я к тому, что(IMHO ясень пень) сервер сайд рендеринг — оно для роботов, которые не умеют Javascript, и которые вполне обойдутся без интерактивности. а под «обычных клиентов» это дает неочевидное ускорение и очевидное усложнение системы.
сервер сайд рендеринг — оно для роботов
Помимо того, что мне нравится идея, что сервер возвращает готовую страницу, а клиент ее оживляет, мне, как пользователю, кажется очень удобным что можно сразу увидеть контент и не ждать пока фреймфорк все это соберет вместе.
что мне нравится идея
та я ж не отговариваю.
просто не рассчитывайте на серебряную пулю. как и у всего есть свои нюансы и ограничения.
мне, как пользователю, кажется очень удобным что можно сразу увидеть контент и не ждать пока фреймфорк все это соберет вместе
Вам кажется. Во-первых, для работы всё равно должны будут загрузиться скрипты. Во-вторых, когда Вы думаете или читаете где-то о чём-либо «это долго» — всегда задавайте себе вопросы «насколько долго?» и «насколько это критично». И только после того, как сможете на них ответить, решайте что делать дальше.
А иначе может легко получиться, что ради разницы между 3мя и 2мя секундами первичной загрузки, вы добавите себе сложностей при разработке. И будуте думать, как обойти эти сложности вместо того, чтобы разрабатывать приложение.

не, ну, а чо, есть резон.
если мы не про соцсети говорим, где как раз действия пользователя — это ядро.
всякие там статьи и прочие опросники важны контентом, а не полосой комментов, например.

Если действия пользователя — не главное, то тогда это и не приложение получается, а обыкновенный веб-сайт, для которого применение SPA-фреймворка вряд ли оправдано.

Конечно, согласен, что это может быть более трудоемким занятием, поэтому сначала и пробую на pet-project.
Но если можно отобразить контент за 700ms, например, и, пока пользователь будет думать, что ему делать дальше подгрузить все остальное и, если нужно, показать лоадер — то для пользователя это будет лучше опыт, чем 2-3 секунды ждать пока хоть что-то отобразится. Тот же VK, Twitter, GitHub и т.п. они же SPA/RIA, действия пользователя там на первом месте, и контент отображается очень быстро.

я не понимаю.
если у нас SPA, то время первой загрузки не критично: 0,5 или 3 секунлы.
если у нас не SPA, то зачем нам такой тяжелый фреймворк, который требует еще сервер-рендеринга, чтоб пользователь не бесился после каждого действия, ожидая перезагрузки + рендеринга страницы.
если хотитет попробовать — это ваше дело.
но вот с аргументацией рациональности не согласен, нет.

Часто приложение можно условно разделить на модули. Каждый модуль может рендериться на сервере, а на клиенте вести себя как SPA не требуя постоянных перезагрузок. Так количество asset’ов необходимых для загрузки модуля будет меньше и сам он будет загружаться быстрее. Под модулем я скорее понимаю раздел сайта. В GitHub это, например, репозиторий. Может, модуль тут не совсем правильный термин.

разве ng-upgrade даже в текущей реализации не достаточно облегчает переход?

Подписаться на комментарии