Выбор JS фреймворка
Какой бы фреймворк вы выбрали для разработки приложеия SPA, учитывая, что ES2015 на подходе. Пока остановился на angular 2.0, ember 2, aurelia. Что можете посоветовать, учитывая что важно чтобы была хорошая модульность, менее нагрузочный data-binding, поддержка TS?
143 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівМне 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 весит всего 84кб, не спорю там есть то что в принципе не будет использоваться. Все оттуда можно заменить на свои костыли, но зачем? Да и вопрос о упрощении разработки и поддерживаемости кода
И если на то пошло, люди активно Babel и прочие полифилы пихают для того чтобы быстрее заработали новые плюшки, а то что оно сгенерит лишнего кода никого ж не волнует?
давайте я вам пример приведу, наглядный.
У некого чела Ч в фейсбуке 300 «друзей».
3ое из них сходив на фильм Ф, написали — какой здоровский фильм! Всем смотреть!
1 написал — гуано полное.
остальные — не ходили. кого жанр не заинтересовал, кто кино вообще не любит и т.д. а те кто ходили, ушли с полфильма и забыли даже что ходили смотреть.
но чел по имени Ч делает вывод — а классный видать фильм, большинство же друзей написало.
babeljs.io/users пойдет?
Эм.... Даже не буду пытаться сравнивать с количеством инсталляций какого нить престашоп.
Это то что я писал в теме разработчик не инженер
Неумение оперировать количественной информацией. Извините.
О чем тогда эта статистика? trends.builtwith.com/...script/javascript-library
Не хочу обидеть чьи-то чувства, но Prototype, YUI, script.aculo.us, MooTools как часто вы сталкивались с этим всем? Упоминания о них остались либо в книжках вроде Стоян Стефанова в качестве примеров шаблонов, либо в каких-нибудь уж совсем старых проектах. Нужна по ним статистика — откройте вакансии по фронтэндам и посмотрите какие технологии требуются.
На самом деле по приведенной ссылка вообще лютая каша во всем. Как-будто авторы от балды сгруппировали все что знали.
Ну вот как можно в одну категорию засунуть бекбон и моментджс? что во фремворках делают хендлбарс и мусташ? какой вообще смысл в категории node.js и почему туда опять засунули бекбон?
и что там видать?
Выше и вам ответил
И я не совсем понял основную идею ответа. Ну есть тонна ресурсов которые используют джейквери. И что?
Конечно ничего. Он уже умер. Вчера ещё.
*остроумное замечание про Кобол*
Возьми React
Навешивать компоненты поверх отрендеренной страницы?
Ну как бы вариантов несколько, 1 реакт будет рендерить, ты ему только данные скармливай, 2 выдавай html который совпадает в виртуальным домом реакта, реакт увидет что все идентично и просто навесит свои ивенты. 3 самый идеальный react на сервере отдает html сразу, и тот же код реакта потом подхватывает работу на фронте. По 3 варианту кстати будет хорошый доклад на конференции Angular&React Framework days
Т.е шаблоны в любом случае дублировать придется для корректной работы реакта?
ну в первом варианте не надо. Из недостатков только то что страница отрендерится когда js загрузится а не сразу. Поисковикам это не помешает проиндексировать, все го то увеличится время отображения страницы ровно на время загрузки js скрипта
В чем профит тогда от реакта?
скорость написания интерактивной части страницы (работа с DOM), скорость изменения DOM, чистота кода, возможность писать на es6. Вобщем дофига
а если не надо менять DOM для каждого посетителя сайта.
То в чем профит?
прикольный аргумент, выбирать фреймворк, из-за фич языка, которые через год два будут штатными...где вы видели WEB2.0 без изменения DOM? Сейчас даже для select не используют стандартный браузерный. А это тоже манипуляция с DOM деревом.
Конечно прикольно. Через год два все будут переписывать а у тебя уже все готово. Не зря же Twitter уже сейчас использует css4а 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, то да.оно конечно и на лисапед можно прикрутить турбину от Пратт Уитни. Выигрыш перед остальными будет — огромный :)
Ну и причем здесь backbone? давайте не путать шаблонизатор с фреймворком. Можно взять тот же lodash или underscore и обойтись только им, можно по старинке на jQuery. Но сейчас в тренде React и не просто так.
P.S. Я даже и подумать не мог что из поста из двух слов может вырасти такое дерево :)
dou.ua/...orums/topic/14905/#773006
вы знаете что такое Hype cycle?
думаю знаете.
так что разницу между трендом:
говорят на каждом углу
и
применяют в каждом десятом (хотя бы) проекте
пояснять думаю не нужно
я просто оставлю это тут github.com/...ct/wiki/Sites-Using-React
По «Backbone» — кучу всего. :)
Reddit — аналогичная история.
Третий раз я не искал, чтобы не портить статистику :)
.
Если более серьезно, то таки не надо путать хайп и тренд. Про тренд можно будет говорить через
Как часто на практике Вам приходилось развернуть список на 1000 элементов и потом при каждом чихе обновлять все эти элементы? О чем это вообще?)
И Backbone рендерингом не занимается. Хотите используйте Underscore, хотите React или нативный API
Речь я вёл о том, что если не надо манипулировать дум деревом, то зачем им оперировать? См мой пост с пример quick & dirty анализом
Ember тоже умеет es6. Вернее, ember-cli умеет, рекомендованая утилита для сборки
Простите но звучит как в той шутке: JAVA говорит: я такие вещи делал что ни одному языку и не снились. .NET отвечает: Да я такие вещи в банковском секторе рулил что те в жизнь не смочь. И PHP рядом: я тоже что то делал!!!!
Ну, если констатацию того факта, что поддержка es6 не является уникальной фичей реакта вы видите именно так — ваше право.
про поддержку es6 реактом я написал самым последним пунктом не просто так. Это просто как маленький плюс.
Angularjs. То, что в обозримом будущем уже маячит angular2, не должно смущать — обещают обратную совместимость и плавный переход
Не задалось как-то с обратной совместимостью.
я аж заплакал
AngularJS
Нету «стека фремворков». Есть (в порядке новизны, и немного популярности): react, angular, backbone; для задач не архитектурных, а как разумный набор утилит jquery и в некоторой мере underscore/lodash.
Учитывая «хипстовость» направления, все может поменяться в любой момент. Если цель найти работу, то лучше ее сначала найти и потом просто изучить «стек» который будет на вашем месте работы.
Но в общем, думаю, стоит почитать статью о Дяди Боба bit.ly/1UGqgc9
ну-у-у-у... на самом деле практически любой популярный фреймворк является скорее компромиссным решением чем наилучшим. вы только не подумайте, что я всех призываю писать свои фреймворки.
Берите MeteorJS.
. посоветую подумать на фига вообще нужен SPA. С точки зрения пользователя сайта — ему пофиг он идет на сайт за информацией и не восхищатся крутизной разработчика (скорее наоборот — яваскриптовые фреймворки будут жутко тупить на мобильных платформах) а разработка подобных приложений гораздо более трудоемка.
Иными словами SPA не имеют никаких преимуществ — одни проблемы. И вообще в эпоху облачных вычислений таскать бизнес логику на клиента как минимум глупо.
а вы не задумывались почему все хотят SPA? единственное что лучше SPA — это гибриды, но их разработка еще более трудоемка
открою вам секрет этот тренд популярен благодаря томуч что хочет бизнес — предоставлять более качественный сервис в продуктах, инженеры тут не причем.
так же есть куча сервисов которые без SPA подхода вообще невозможно создать
то есть аргументы — «все хотят» и «тренд». Попросту говоря — это модно в этом сезоне, все такое носят.. Собственно других аргументов я и не ожидал.
и какие такие сервисы нельзя реализовать без SPA?
и кто эти "все хотят? уверен что не пользователи сайтов.
я написал
это не было аргументацией, это было предложение включить мозгигугл докс и ему подобные
бизнес
пользователи вообще не могут знать чего они хотят, они на то и пользователи
сразу видно что вы в бизнесе ничего не понимаете
в бизнесе , к которому вы апелируете, всегда знают что хотят. Иначе вылетают с бизнеса.
Отмазка «пользователь тупой лох» типична для доморощеных програмеров с юношескими понтами. В странах где есть Кремниевые долины считают что надо делать как требует пользователь а не умничать. Уж поверьте — не один год на аутсорсе сижу. Когда пытаюсь говорить их программерам — давайте убедим пользователя сделать по другому — на меня смотрят квадратными глазами.
Работает только ТЕХНИЧЕСКАЯ аргументация и не «погуглите» или «включите мозги» а ссылка на оф. сайт или саппорт продукта где четко сказано что есть те или иные проблемы.
вы первых мы обсуждаем не бизнес. а во вторых, предьявите свой многомиллионный бизнес, senjor developer лабающий на яваскрипте.
ну ясен пень что я не могу вам раскрывать детали — все под НДА
небольшой, мной такого плана сделан один — линк на сервис не дам, так как не имею права
вы не мой клиент, я вам не должен разжевывать
бизнеса у меня нет, но я хорошо понимаю как он мыслит, ибо проталкивал очень много ченджей, на которые клиент соглашался
ладно, так и быть. по сути SPA решают проблемы UX, не более того, в первую очередь при помощи более быстрого отзыва приложения (валидация форм на клиенте, AJAX намного быстрее чем ререндеринг целой страницы, путем хранения данных на клиенте часто можно вообще избежать некоторых запросов на сервер, то есть все сводится к тому что все действия производимые пользоввателем происходят быстрее, а ему можно показать няшный лоадинг в это время). по факту, это самое главное преимущество, его можно дробить на мелкие, ибо там куча факторов, но в итоге все сводится к UX improvment
ну, вот, смешались в кучу кони, люди...
jQuery с этим поспорит. или это джкверя «делала SPA, когда это еще не было мейнстримом»? :)cookie
по-моему, вы спутали «логику на клиенте» и «SPA как подход».
SPA оно про навигацию. экономим на оверхеде по запросам большого количества элементов(потому что даже для 304 Not Modified надо послать запрос), а в итоге должны самостоятельно реализовать инициализацию(в зависимости от URL — т.е. навигация ж) и запрос данных.
хранение данных на клиенте подразумевает — cookie, localStorage, sessionStorage, IndexedDB, App Cache, 304 & Expired header, js inmemory
навигация не обязательный аттрибут, но очень полезный
Wiki:
Single page application (SPA) — это веб-приложение, которое выполняется непосредственно на стороне клиента в Web-браузере, обычно написанное на комбинации из HTML, JavaScript и CSS[1]. Приложение может получать доступ к структурам веб-страницы как к объектам дерева DOM.
Вы вообще проектированием веб приложений хоть раз в жизни занимались?
в чем его single-page’ность в таком случае? ну, раз «навигация не обязательный аттрибут». а?
беру URL, делаю на нем контейнер с несколькими компонентами(карта, форма с клиентской валидацией, данные отправляются по AJAX) — у меня уже SPA, выходит?
если вы замыкаете весь функционал приложения на одной странице — это и есть SPA. навигацию не обязательно использовать, можно без нее спокойно обойтись, но тогда невозможно (не то чтобы совсем, но по нормальному не выйдет) передавать состояние приложения, однако можно по прежнему его сохранять для одного взятого пользователя через куки и локал стореджи, по сути path от URL это некое глобальное состояние приложение, удобное для передачи, то есть часть модели приложения.
любая JS игра — SPA, чатик — SPA, если у гугл мапс отобрать изменения линки — это на функционал повлияет? — нет, но все равно будет SPA.
кстати MPA по факту набор многих SPA :)
ajaх не быстрее — при нынешних скоростях инета и стоимости трафика — это экономия на спичках.зато нехило грузится браузер что приводит к тормозам на мобильных платформах.
экономия обращений на сервер не настолько велика чтобы оправдать трудоемкость разработки. Вы все равно не сможете загрузить с сервера все нужные данные — максимум какие нибудь настройки или короткие списки иначе браузер( особенно на мобиле ) надует всю память.. Плюс все равно надо сразу сохранять измененные данные в персистентное хранилище на сервер иначе в любой момент могут пропасть.
А теперь обратная сторона — вам надо сходить на сервер — получить данные и в зависимости от них подучить следующие. Типичная задача сложной бизнес логики
на сервере — это просто последовательное обращение к БД. на асинхронке - обращение к серверу ожидание колбека с ответом — затем еще одно обращение.
И что мы сэкономили? учитывая то что все равно надо писать серверную часть так или иначе.
Реальная экономия если это какая нибудь браузерная игра.
Еще раз — нет никаких внятных аргументов в сторону SPA.
это действительно тренд, по просту говоря мода которая завтра сменится на что то другое.
на самом деле ноги у ajax растут с одной проблемы — сохранение персистентности состояния элементов страницы которую приходится обеспечивать во время переагрузки.
Теоретически выглядит красиво — не перегружаем страницу не заботися как восстанвить состояние элементов формы, списков и прочее. и люди начинают искать эту волщебную таблетку. Но в реальность выливается в реальный головняк.
Реально, самый разумный подход -компонентный как например в WebForms - там фреймворк сам восстанавливает страницу — програмист заимается тем чем ему положено реализует бизнес-логику и не заботится как передать данные на клиента и прочитать оттуда — он работает с бэкендом.
Впрочем спорить с вами нет смысла — когда эта мода пройдет (а она пройдет я за многолетний опыт програмирования уже не одну проходил) вы к тому времени повзрослеете и начнете думать объективно а не с помощью «трендов» раскручиваемых в первую очередь производителями тех же фреймворков.
Удачи.
.
Вы себе просто не представляете, насколько вы заблуждаетесь.
Единственное в чем вы правы, что понятие СПА когда-то канет в лету.
Но вместе с ним и канет понятие МПА, за которое вы так цепляетесь.
Не утруждайтесь я это уже пробовал пациенту объяснить. Пациент кроме себя ничего не слышит.
не дадите расшифровку?
речь о сингл пейдж приложениях. гугл докс попадают более чем под это определение.
А зачем вам голова? Она нужна только чтобы в неё есть, так иногда она ещё и болит.
то есть по делу возращить не можете? Что и следовало ожидать?
По делу я говорю с теми, кто это дело знает. Вы, судя по всему, не знаете что такое SPA и зачем они нужны, и просто хотите поспорить на пустом месте. Мне это неинтересно. Хотите аргументов за и против — погуглите, это общедоступная информация.
во первых вы не знаете что я знаю а что нет. В частости как раз с матюками доделываю страницу на Flex за такими же эвангелистами как вы, которых выгнал заказчик. А во вторых. — «погуглите» это типичный аргумент тех кому нечего сказать, то есть привести ТЕХНИЧЕСКИЕ " аргументы.
как и с любыми эвангелистами — как можно возражать ведь в эвангелии написано.
У вас пригорает
слив защитан.
Сами себе ещё и сливы засчитываете? Похвально, не каждый способен.
Снять часть нагрузки с сервера и перенести её на клиента — в условиях высоких нагрузок может дать хорошую экономию на услугах облачных сервисов.
Щодо Angular 2.0 або React я б ой як задумався... Для мене в цьому сенсі більш приємний Angular 1.x або Riot. Не так давно написав пост у себе в блогу про кілька фреймворків
Да, Riot симпатишный и как мне показалось довольно простой в изучении (смотрел пару обучалок по нему на ютубе)
React.js + Redux + React Router
Посмотри в сторону Backbone + Marionette
опыт у команды с чем из указанного?
есть ИМХО симпатичный фреймворк vue.js — vuejs.org
из всех фреймворков (не считая jQuery, который как бы не совсем фреймворк), что я смотрел мне он больше всего понравился и был более понятен, чем другие фреймворки. Хотя и ангуляр в принципе неплох.
Лично мы юзаем CanJS просто по дефолту :)
Все проекты с его использованием построены по полностью модульной системе.
Есть двусторонний дата-биндинг
Открою тайну. Чтобы написать действительно хорошее SPA достаточно jQuery и Javascript. Современные джаваскрипт фреймворки это жалкие недопилки, которые угробят любое SPA сложнее тудулиста.
скажите сколько SPA вы проектировали и разрабатывали? и какой сложности?
4
если вы грамотно выбираете фреймворк, и ГРАМОТНО ЕГО ИСПОЛЬЗУЕТЕ, то ничего тормозить не будет
С введением людей в проект все в норме, если использовать принципы Solid и KISS, а «люди» — не студенты с второго курса политеха — проверено на опыте. Насчет багов — тоже самое.
А в сторону react не хотите посмотреть?
react по сути компоненты, а мне необходимо SPA приложение
да и не люблю я когда мешается js и html
-
ну как бы хорошая модульность по умолчанию идет в ES6, тут больше вопрос что за приложение вы ожидаете?? насколько большое? какие задачи?? если чтото примитивное типа просто запросы к серверу, без модели на клиенте, то ангуляр очень хорошо подойдет. если нужна модель на клиенте, приложение более сложное, то смотрите в сторону ембер, а вообще очень сложный вопрос, надо учитывать множество факторов.
так же одни из ключевых, есть ли у вас уже команда, то их знания играют огромную роль в принятии решения
проблема ангуляра в том, что вторая версия не будет совместима с первой
вы не на то смотрите, вам решение делать надо, а не самую свежую технологию выбирать
Важно чтобы потом поддержка была как можно проще, по этому надо именно TS
я сейчас пишу на ангуляре, но бывают проблемы с перформансом если много данных. А эмбер лучше в этом плане?
вы знаете, я вам с радостью помогу, честно, но опишете что должно делать приложения — именно хай-левел, и опишите опыт команды. я вам смогу дать совет тогда с аргументацией, хотите пользуйтесь, хотите нет. но пока мало данных
Приложение хочу разрабатывать пока сам, в качестве pet project, но со временем может быть и переход в нормальный проект с монетизацией. Приложение типа ведения домашнего бюджета с множеством различных статистических возможностей, рассчетов на будующее, на скринах могут отображаться данные за месяц в виде календаря и т д. И что лучше выбрать с бекенда, parse.com сервис или писать свой на asp.net web api?
а по поводу производительности Angular, рекомендуется ознакомиться минимум с
blog.scalyr.com/...angularjs-1200ms-to-35ms
tech.small-improvements.com/...ormance-with-large-lists
а этим
пренебречь, так как человеку с вашим то опытом и знанием такого кол-ва терминов осилить какой-то там ng2 не составит проблемой... ящитаюосвоить то не проблема, проблема в том, что понадобится время на переписывание всего приложения
ну думаю, это тоже не проблема... ucoz.net обладает достаточно большой коллекцией жеквери скриптов... основная проблема: разобраться с админкой, но думаю, что у вас всё получится... и тогда, хочешь — новый счётчик прямо на странице, хочешь — совершенно новый шаблон для всего сайта!
возможно это поможет angularjs.blogspot.com/...ngular-2-coexistence.html
а как там кастомные схемы данных реализовывать?
Что-то мне подсказывает, что это было написано с целью обосрать, а не в русле конструктива.
тогда мой вам совет — angular, судя по всему у вас будет простенькое приложение (то есть слегка продвинутый ЮАй, будете директивы юзать, и отсутствие бизнес логики на клиенте), ангуляр для таких целей отличным.
юзайте только первый, ибо пока вторая версия не стабилизируется, может усугубить сильно разработку, введение различных брейкинг ченджей.
бекенд — на том что знаете, ибо весь ваш бекенд сведется к проксированию запросов к БД
ну а вдруг ng1, пока данный ТСер проЭкт свой пилить будет таки реально устареет? что делать в таком случае? непонятно...
да ты понял мой вопрос!!!1 что делать, если ng1 устрареет, а ng2, как известно — не совместим с первым! что это по вашему, как не проблема angular, о которой ТС прекрасно осведомлён, а вы, оказывается нет!
вот из-за таких как вы у ТСеров подобных данному и возникают проблемы, и вместо того, что бы решать конкретно, вы продолжаете гнуть свою линию!
как бы недавно вышла версия 1.4, сейчас идет работа над 1.5
в реальности понятие устаревание технологии весьма субъективно, никто сбрасывать суппорт не будет первого ангуляра, а сегодняшний код как выполнялся так и будет выполнятся.
может это не будет самим «свежим» и «крутым», но если вы за этим гонитесь, то у меня для вас плохие новости. ничего не выйдет. это ИТ. завтра будет новая технология
теперь понимаешь, почему ты до сих пор девственник ?)
думаю, по
уже можно было понять, что человек не всерьез.PS ну, или белка-истеричка. но скорее всего — просто троллит.
да-да, полностью с вами согласен! Очевидно же, что ТС — тролль!
ловко вы Евгений его раскусили!
к сожалению, много таких кто всерьез в это верит
насчет «устаревания»? ну, да.
а еще есть те, кто уверен, что можно сделать «правильный выбор инструментов» и потом все пойдет как по маслу.
предположу, раз автор темы спрашивает, опыта у его/команды ни с чем из вышеперечисленных особо нет.
react жестко определяет подход к построению приложения, эмбер тоже декларирует определенные ограничения.
ангуляр дает достаточно разнотиповых подходов, чтоб без опыта можно было «наворотить делов».
Я тоже начинаю делать свой pet-project и тема мне интересна. А опыт есть только с Knockout. Aurelia выглядит намного понятнее, что ли. Но планы по реализации server-prerendering у них только в далекой перспективе. А React предполагает использование immutable структур данных и я не уверен, что это то, что мне нравится. Думаю начать ковырять Angular 2.
angular 2 имеет смысл, только если вам просто технология интересна
Конечно, чтобы делать более осознанный выбор нужно хотя бы по небольшому проекту сделать с использованием каждого фреймворка. Angular 2 звучит многообещающе. Но не исключено, что попробую сделать тоже и на других Фреймворках чтобы понять что удобнее.
Начинать изучать Angular 1.5 не хочется, так как он не будет так стремительно развиваться в виду Angular 2.
не обязательно, почитай техникал овервью каждого фреймворка, если у вас достаточно опыта, то сможете проанализировать то что вам надо, и понять какие проблемы решить та или иная технология, а где возможно надо будет совмещать
Да, как раз этим и занимаюсь. Как всегда, хочется крутой фреймворк, который помогает решить любую задачу, быстрый и понятный :).
Я слышал про phantomjs. Тут идея в том, что бы сервер сгенерил страничку, которую потом сможет подхватить клиент и дальше работать с ней, как будто она сгенерена на клиенте. Вот вчера посмотрел
насколько такое актуально в вашем проекте? ускорение отображения за счет усложнения инициализации(как пример: в видео по ссылке на серьезных щах предлагают «записывать» клики и прочие действия пользователя, а потом «воспроизводить» уже после инициализации).
а server-side rendering игнорирует одну удобную вещь: кеширование.
шаблоны на клиенты кешируются и потом, гоняя только данные(JSON/XML/etc), мы реально можем экономить на трафике.
мне думается, через link[type=prefecth/prerender/dns-prefetch] и разделением шаблона на небольшие фрагменты можно добиться большего, чем рендерингом на стороне сервера.
а для SEO достаточно и prerender на phantomjs
просто уменьшая оверхед в одном месте, получаем его в другом. а вместе с задачей — даже если за нас делает фреймворк — новые баги и нюансы. лучше знать — зачем это всё надо. только тогда понятно, сто́ит или не сто́ит.
я к тому, что(IMHO ясень пень) сервер сайд рендеринг — оно для роботов, которые не умеют Javascript, и которые вполне обойдутся без интерактивности. а под «обычных клиентов» это дает неочевидное ускорение и очевидное усложнение системы.
просто не рассчитывайте на серебряную пулю. как и у всего есть свои нюансы и ограничения.
А иначе может легко получиться, что ради разницы между 3мя и 2мя секундами первичной загрузки, вы добавите себе сложностей при разработке. И будуте думать, как обойти эти сложности вместо того, чтобы разрабатывать приложение.
не, ну, а чо, есть резон.
если мы не про соцсети говорим, где как раз действия пользователя — это ядро.
всякие там статьи и прочие опросники важны контентом, а не полосой комментов, например.
Если действия пользователя — не главное, то тогда это и не приложение получается, а обыкновенный веб-сайт, для которого применение SPA-фреймворка вряд ли оправдано.
Конечно, согласен, что это может быть более трудоемким занятием, поэтому сначала и пробую на pet-project.2-3 секунды ждать пока хоть что-то отобразится. Тот же VK, Twitter, GitHub и т.п. они же SPA/RIA, действия пользователя там на первом месте, и контент отображается очень быстро.
Но если можно отобразить контент за 700ms, например, и, пока пользователь будет думать, что ему делать дальше подгрузить все остальное и, если нужно, показать лоадер — то для пользователя это будет лучше опыт, чем
я не понимаю.
если у нас SPA, то время первой загрузки не критично: 0,5 или 3 секунлы.
если у нас не SPA, то зачем нам такой тяжелый фреймворк, который требует еще сервер-рендеринга, чтоб пользователь не бесился после каждого действия, ожидая перезагрузки + рендеринга страницы.
если хотитет попробовать — это ваше дело.
но вот с аргументацией рациональности не согласен, нет.
Часто приложение можно условно разделить на модули. Каждый модуль может рендериться на сервере, а на клиенте вести себя как SPA не требуя постоянных перезагрузок. Так количество asset’ов необходимых для загрузки модуля будет меньше и сам он будет загружаться быстрее. Под модулем я скорее понимаю раздел сайта. В GitHub это, например, репозиторий. Может, модуль тут не совсем правильный термин.
-
разве ng-upgrade даже в текущей реализации не достаточно облегчает переход?