Как определиться с фреймворком?

Question

[Dmitrii Solovev]

Нужна помощь с выбором дальнейшего пути развития в веб разработке. За плечами пока только HTML/CSS/JS.
Выбрать я его смогу, но для этого мне не хватает понимания "полной картины, как все устроено".

Вообщем пока варианты такие:

1. Клиентская часть с Angular || React || Ember
   
2. Серверная часть с ruby и рельсами || node.js с sails и подобные || питон с Django…?
   

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

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

Comments

[CapeRatel]

Могу предположить что вы начинающий кодер, и выбираете технологию с какой завоюете мир(ну или понтоваться можно)). В корне неверный вопрос. Все есть в гугле. Если вы задаете такие вопросы, то вам нужно попрактиковаться а не книжки читать.

[Dmitrii Solovev]

В корне не правильно. Я не выбираю среди Angular || React || Ember или sails || Rails…
Я не могу выбрать среди 1 и 2 пункта. Фронтэнд и бекэнд, так как плохо понимаю какие захачи они решают и разницу (в основном про бэкэнд речь идет)

Answer 1

[index0h]

Мне не понятно, это разделение фреймворков на группы, что они делают и для каких задач предназначены фреймворки из первой группы и из второй?

1-я группа работает на клиенте (в браузере)
2-я группа работает на сервере

Почему они так разделены?

Разные платформы выполнения

Используют ли их вместе, или только один?

Зависит от проекта.

Какие задачи решают фреймворки из первой и второй группы?

1-я БЛ (бизнес логика) отображения и взаимодействия с пользователем
2-я БЛ обработки данных и взаимодействия с клиентом (браузером)

Для какое задачи достаточно будет знать только ангуляр, а для какой только рельсы?

Только Angular - задачи frontend
Только Rails - задачи backend

Comments

[Dmitrii Solovev]

Если первое более менее понятно, взаимодействие с пользователем, оживление ДОМа. То второе не очень. Что будет реальными примерами?

[index0h]

Простейший пример: регистрация пользователей, переписка между пользователями. Это все серверная часть.

Answer 2

[Сергей Протько]

Нужна помощь с выбором дальнейшего пути развития в веб разработке.

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

Мне не понятно, это разделение фреймворков на группы

разделение по языку программирования и задачах, которые решает этот фреймворк. Допустим RoR, Sails, Laravel, Symfony, Drango - это фреймворки для организации WEB интерфейса к вашему приложению. И не более.

Angular, Ember, React, etc - это фреймворки для организации интерактивных WEB приложений на клиенте, на сервере им делать нечего (если не учитывать server-side рендринг для укорения отображения страницы).

Используют ли их вместе, или только один?

если вам надо написать интерактивное приложение и API к нему, то логично взять два фреймворка, которые реализуют то что нужно. Так что да.

Как большое море, в котором видны островки, но целой карты нету

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

Comments

[HoHsi]

Забавная идея на счет карты, надо будет реально запилить (вспоминается аналогичная карта c++)

[Dmitrii Solovev]

"это фреймворки для организации WEB интерфейса к вашему приложению. И не более."
Что под этим подразумевается? Я не понял.
Есть ли пара каких то реальных примеров, задач, которые решаются с помощью этого?

[HoHsi]

Dmitrii Solovev: т.е. на них пишется только клиентская часть, а сервер (что генерит и отдает информацию), на них не пишется (и не может писаться).

[Сергей Протько]

HoHsi: нет не так.

[HoHsi]

Сергей Протько: уже есть серверный ангуляр?

[Сергей Протько]

Dmitrii Solovev: почитайте на вики про клиент-серверную архитектуру.

Почитали? Далее... у нас есть две типичные ситуации:

- обычные сайтики, как например тостер, где сервер отвечает за формирование интерфейса пользователя (html) и отдает его на клиент. в этом случае на клиенте практически нет бизнес логики, только UI составляющая. Например когда вы добавляете комментарий тут, срабатывает ajax запрос на сервер, страница не перезагружается, но это просто улучшение UX. То есть у нас тут ситуация с толстым сервером и тонким клиентом, так как часть ответственности клиента ложится на сервер.

- single page приложения, например google music или яндекс музыка, или любое другое сложное приложение. В этом случае у нас сервер ничего не знает о клиенте, а клиент ничего не знает о сервере кроме того, что тот предоставляем ему какой-то интерфейс (как правило поверх HTTP) для работы с оным. То есть каждое действие обрабатывается javascript-ом и что бы достать/сохранить данные шлет http запросы на сервер, но все это может происходить не видимо для пользователя.

так вот, возвращаясь к фреймворкам. Если мы берем приложение, то у него есть та часть которая общается с клиентом через web - его WEB интерфейс. В первом случае у нас это будут шаблонизаторы, формы и прочая чушь. Во втором это будут какие-то HTTP API, например, выплевывающие JSON, который уже обрабатывается на клиенте как ему там хочется. В этом случае на сервере для реализации WEB интерфейса применяют сериализаторы и прочее.

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

Еще может быть CLI интерфейс (командная строка), или например интерфейс для работы с очередями... бизнес логику все эти интерфейсы будут запускать одну и туже а ей, бизнес логике, глубого плевать каким образом клиент попросил нас что-то сделать. Запросил он страничку, сделал HTTP запрос или же инициировал цепочку команд... у нас будет какой-то слой который все это обработает, бизнес логика обычно не зависит от этого всего, ей побоку. Потому то и важно что бы бизнес логика была минимально завязана на фреймворк (чего обычно непроисходит, люди мнят фреймворки самым главным в приложении, как когда-то - базу данных).

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

Но это все относительно задачь бэкэнда. Для фронтэнда же есть интересные особенности. В частности, в большинстве случаев за HTML отвечает сервер, а не клиент. То есть нам выплевывают кусок HTML с сервера а мы уже подключаем скрипты и прочее. В этом случае ни о каких фреймворках говорить особо не приходится, нам он не нужен что бы подключить какой-нибудь слайдер на jQuery. А с учетом того что скоро придут web-компоненты, все будет еще проще.

Но WEB развивался, требования пользователей росли. Скажем тут на тостере есть пара мелочей облегчающих жизнь, например добавление комментариев без перезагрузки страниц. Это то место, где чуть чуть бизнес логики вытекло на клиент, мы можем создать комментарий и сделать его отображение целиком на клиенте, общаясь с сервером через HTTP интерфейс и забрав у него данные в JSON формате, можем просто попросить что-то сделать и вставить HTML присланный сервером... тут короче вариантов масса. Тут уже в зависимости от задачи приходят на помощь различные библиотеки (заметте, пока не фреймворки), аля knockoutjs, understore, reactjs и т.д.

И вот мы дошли до полноценных приложений, которые целиком рендрятся на клиенте (мы сейчас не будем говорить о оптимизация аля server-side рендринг и т.д.), и сервер о клиенте не знает ровным счетом ничего. В этом случае помимо того что нам надо работать с UI (DOM), и мутить примитивную бизнес логику, нам еще нужна определенная инфраструктура для того что бы не превратить все в ад. Задача весьма себе обычная, реализовать структуру. Скажем angular предоставляет вам MVC подход (как впрочем и ember и react и т.д.), когда все разбито на малюсенькие UI компоненты со своей моделью, представлением и контроллером.

То есть у нас на клиенте появляется необходимость маршрутизации состояний, управление бизнес логикой, HTTP запросами (что-то посложнее $.ajax), очередями задачь и т.д. И тут на помощь приходят фреймворки, так как, как мы уже выяснили ранее, писать велосипеды это весело а вот поддерживать их в одиночку не особо.

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

- модульность, разбиение на отдельные компоненты
- отказ от двустороннего датабиндинга как идеи, данные должны идти только в одну сторону.
- абстракция от DOM (virtual-dom в reactjs), позволяющая ускорить тестирование, организовать server-side рендринг и прочие оптимизации.
- изоляция и web-компоненты

Пока отстает только Angular, но уже зимой вроде как релизится Angular2 который соответствует всем перечисленным пунктам. И когда выйдет Angular2, то идеологически различий между этими фреймворками не останется, в общем и целом все будет одним и тем же, различия будут только в реализации этих идей, и тут уже все субъективно. Мне вот с идеологической точки зрения нравится react но его инфраструктура убога, как-будто рубисты понабежали.

Словом... что бы не заплутать в этом море, просто стоит перестать зацикливаться на том что каждую неделю выходит по фреймворку и све такое. Во фронтэнд мире есть 3 основных лидера, которые идут к примерно одному и тому же, что говорит о верности направления развития. В бэкэнд мире разница между фреймворками только в количестве предоставляемых абстракций и ORM (извечный холивар active record vs data mapper). Все... больше различий нет. Со временем вы увидите общую картину и успокоитесь.

[Сергей Протько]

HoHsi: нет, под web интерфейсом я подразумевал именно интерфейс по которому клиент общается с сервером. Обычно это HTTP запросы и HTML или JSON в ответ. Так же связанное с этим необходимость валидации данных, маршрутизация и т.д. К бизнес логике приложения это имеет весьма и весьма поверхностное отношение.

Ну и да, angular2 будет поддерживать server-side рендринг, если что. Так что "серверный angular" это не так уж и странно, просто заменить на бэкэнде базу данных на rest api и получится именно это, серверный angular, view прослойка, service-layer прослойка и контроллеры с маршрутизацией.

[Сергей Протько]

HoHsi: ну и да, "карта" это зовется mind maps. Удобная штука для визуализации информации.

[Dmitrii Solovev]

Сергей Протько: спасибо, так по понятнее стало.
То есть по сути backed это мозги приложения, и к примеру если пишется spa по удалению слов из трека, то здесь большой backend на сервере и просто небольшой заглушки на фронте, будет достаточно.
А к примеру блог, имеет большой фронт, с админкой и кучей страниц, а backend делает только связь фронта с базой данных и выдает страницы из шаблонов, под конкретный пост/юзера/тэг.
Правильно понимаю?

[Сергей Протько]

Dmitrii Solovev: нууу не совсем пожалуй, в той части где вы говорите про толщину бэкэндов и фронтэндов.

Админка, где сервер генерирует формы и прочее обладает весьма скудным фронтэндом. Вы можете вообще без js все сделать и все будет работать. Если брать SPA то на сервере API а весь UI на клиенте.

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

Answer 3

[Максим Тимофеев]

можно разделить по технологиям php фремворки, javascript фремворки и css фреймворки и т.д. Традиционно серверная часть пишется на php, а клиентская на javascript, украшено все это css.
Но можно обойтись одним, можно использовать несколько. Выбор кол-ва и типов зависит от проекта. Я например большую часть проектов делаю php фреймворке yii2 и css фремворке bootstrap3, который там подключен из коробки. Вполне самодостаточная связка. И хотя yii2- это php, bootstrap3- это css , они одержат кучу фишек на javascript (на jquery, если быть точным). Так что четких правил и границ тут нет. Лучший способ понять - начать делать. Возьмите yii2 и попробуйте.

Comments

[Ivan Palamarchuk]

Традиционно на php пишется серверная часть? С чего это?

[Максим Тимофеев]

Ivan Palamarchuk: Статистика

[Ivan Palamarchuk]

Максим Тимофеев: статистика исходит из того, что большинство "php проггеров" больше ничего не знают..

[HoHsi]

Ivan Palamarchuk: да ладно, все мы когда-то были им заляпаны :)

[Максим Тимофеев]

Ivan Palamarchuk: Как это относится ко мне и к тексту который я написал? Вы просто хотите написать, что Вы супер чел, который не использует php на серверной части, потому что суперчелы не используют php?

[Максим Тимофеев]

HoHsi: Вы нашли себя в другом, я рад за Вас, но чем Вам php не угодил? И что по Вашему в миллион раз лучше? По Вашей интонации, понятно, что Вы овладели како-то чудо технологией, которая ушла на много лет вперед. И какова была последняя знакомая Вам версия php?

[Ivan Palamarchuk]

HoHsi: тут согласен)

[HoHsi]

Максим Тимофеев: в нем нет ни чего плохого. Это как памперс, ты из него вырастаешь, и нужно переходить к чему-то более крутому

[HoHsi]

Максим Тимофеев: семерки мануал полистал. А так переодически на 5+ пишу. Повторюсь плохого ничего, но сковывает

[Ivan Palamarchuk]

Максим Тимофеев: Нет, просто не пишите о традициях в разработке, это очень не правильно. Я могу сказать, что традиционно, на серверной стороне web-socket'ы реализовываются с помощью socket.io, но был бы прав, да?

[Максим Тимофеев]

Ivan Palamarchuk: Мы отвечаем человеку, который говорит, что знает HTML/CSS/JS и никогда не сталкивался с фремворками. Какой web-socket? Вы хотите помочь человеку или самоутвердиться?

[Максим Тимофеев]

HoHsi: Сковывает -да. Но для большинства проектов, это просто, быстро и работает. Поэтому и популярно, поэтому и традиционно.

[HoHsi]

Максим Тимофеев: ну, ок. Чего вы так пригорели то? Я же сказал, что сам ингда пишу, но он далеко не серебряная пуля

Answer 4

[HoHsi]

Мне не понятно, это разделение фреймворков на группы, что они делают и для каких задач предназначены фреймворки из первой группы и из второй?

Какие задачи решают фреймворки из первой и второй группы?

Первая группа - фронтэнд - фреймворки работающие на стороне клиента. Т.е. в браузере
Вторая группа - языки + фреймворки для бекэнда - серверной стороны.
Общего между ними 0, это абсолютно разные вещи для разных задач.

Используют ли их вместе, или только один?

Если вы имеете ввиду, использовать ли Angular и Ember (или Ruby on Rails + node.js), то ответ 100% нет. Это взаимозаменяемые вещи.

Какие задачи решают фреймворки из первой и второй группы?

Первая группа занимается пользовательской частью. Рендарит Dom, выполняет клиентские вычисления, Ajax
Вторая - серверные фреймы. На их основе пишется сам сайт, его основа. Или же REST.

Для какое задачи достаточно будет знать только ангуляр, а для какой только рельсы?

Это не взаимоисключающие вещи. Ангуляр рендарит клиента, обновляет поля, html, сортирует таблицы. RoR отвечает на post/get, выступает в роли REST.

Подведя итог, если знаний 0, начните либо с фронтэнда (1 группа) или с бекэнда (2 группа). За частую это разный подход к мышлению.

Если нет знаний даже в JQ, но сайтик хочется берите для начала JS+PHP (но быстро бросайте, как только появятся скиллы). После этого переключайтесь на Coffee (замена JS) + Node.js

Ссыли в Сибире:
PHP
node.js
jquery.com
coffeescript

Comments

[HoHsi]

Владислав Турчинский: Кто сказал про фреймворки? Вы ответ читали, я описал человеку роадмап

[Илья]

HoHsi: Переезжать с пхп на nodejs. Спасибо, посмеялся.

[HoHsi]

FireGM: над чем?

[Илья]

HoHsi:Переезжать с языка, который предрасположен к говнокоду, на ад из колбеков. И не надо говорить, что сейчас идёт над этим работа. Подвижки есть, но гайдов мало. В итоге выйдет говнокод.

[HoHsi]

FireGM: вся соль в руках

Answer 5

[Алексей П]

К в одном циничном и непристойном анекдоте про официанта: "возьмите 'старый мельник'...".
Перефразирую - метеор жс - ваш выбор.

Answer 6

[CapeRatel]

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

Фронтэнд фреймы примерно равны разделять их не нужно. Любой подойдет.
Насчет бекенда можно делить на 2 группы:
- Обычный сайт или спа(Тут подойдет все, и руби и питон и нода и чехотите.)
- Там где нужна жесткая реальная многопоточность(для стриминга всякой фигни в стиле видео или музыки) - здесь вопрос к мастерам эрланга или го и прочих "танков".