Backend vs Frontend

[hell0w0rd]

@stalxed, нет. Основное преимущество, что у тебя на сервере есть js и на клиенте есть js. То есть ты можешь написать код 1 раз, а исполнить и там и там. В случае с выше обсуждаемым реактом, есть так скажем ядро, а есть несколько движков для рендринга: в строку, в DOM (с использованием virtual dom), есть еще react-native, то есть рендер нативными компонентами ios/android, а еще react-canvas, react-art и вероятно другие рендеры.

 

[artoodetoo]

> То есть ты можешь написать код 1 раз, а исполнить и там и там
Какой именно код нужен и там и там? Он составляет заметную долю?

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

 

[hell0w0rd]

@artoodetoo, настоящие программисты - это которые делают что?)
По поводу кода, самое простое - это view часть и валидация. В meteor реализована работа с моделью, пишешь код один раз, работает и там и там. Реализаций работы с моделью вне метеора не видел.
Я вот собираюсь в приложении вокруг чатика использовать константы совместно, и на клиенте и на сервере. В Flux все на событиях, так скажем, можно эти события спокойно прокидывать по веб-сокетам и обрабатывать и на клиенте и на сервере. В таком случае сервер/клиент понимают друг друга без дополнительных слоев, тк данные внутри ходят одинаково.

 

[artoodetoo]

Про настоящих программистов была изрядная доля шутки. А имел в виду унылых традиционных программистов )))

То есть фактически только валидация. И то с оговорками "какая именно валидация" — недавно обсуждалось. Про остальное я вроде слова понимаю, но не вижу позывов что-то выполнять на обеих сторонах.
Опять же имхо: Модель на клиенте это имеет смысл только в пределах сессионых данных. Видимо они либо тут, либо там, повторно использовать код не получится.

 

[Вурдалак]

По поводу кода, самое простое - это view часть и валидация. В meteor реализована работа с моделью, пишешь код один раз, работает и там и там.

Речь про domain model и модель для отображения? Иметь одну модель и одну валидацию?

 

[grigori]

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

авторизацию, storage и resize фоток, биллинг, geo, рассылки, конвертация в pdf и печать, failover - это одновременно и на клиенте, и на сервере писать?
если все это выносится в сервисы и пишется на других языках - что остается? формы, скроллинг, модальные окошки - то есть UX.
фронт - и есть фронт, рассылку на ангуляре мы не сделаем.
общего кода для фронта и сервера будет 5%. за что агитация?

 

[hell0w0rd]

@grigori, рассылку ты не сделаешь на фронте. Но оно и не надо. Но вместо создания rest endpoint POST /emails, ты просто вызовешь функцию, которую напишешь один раз.
@Вурдалак, вот у тебя есть метод для создания пользователя, который что-то делает с базой. Ты его пишешь один раз, а затем исполняешь либо на клиенте, либо на сервере.
https://github.com/meteor/simple-todos/blob/master/simple-todos.js - ну вот вам пример.

 

[weregod]

@hell0w0rd,
за такие вилки

if (Meteor.isServer) {

if (Meteor.isClient) {

в серьёзном проекте, а не примере 2do какого-то, поубивал бы.

не знаю, что там у вас творится, но мы клиент/сервер-сайд разделяем.

 

[Вурдалак]

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

Это забивание гвоздей в крышку гроба проекта. Но это нужно почувствовать.

Чашечка латте, интерфейсы, красивая анимация, кнопочки, всплывающие нотификации, сервер-сайд. What could possibly go wrong?

 

[флоппик]

Это забивание гвоздей в крышку гроба проекта. Но это нужно почувствовать.

Чашечка латте, интерфейсы, красивая анимация, кнопочки, всплывающие нотификации, сервер-сайд. What could possibly go wrong?

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

 

[grigori]

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

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

Общий код для фронта и бекенда хорош для прототипов, быстро набросать вывод каталога-ленты, а в проектах, где 95% работы - это обработка данных и бизнес-логика, все задачи по выводу решает фронтэндщик, это его сфера ответственности, и верстка - незначительная часть из общего объема работы.
У меня так.

Я не понимаю в каких проектах единый код на сервере и фронте даст какое-то преимущество, приведи реальные примеры.

 

[fixxxer]

What could possibly go wrong?

Мухахаха.

Не, я могу понять, если чистые domain models работают где угодно (что им помешает?), а инфраструктурные слои реализованы отдельно на клиенте и на сервере.

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

 

[hell0w0rd]

@grigori, аналоги trello, github, slack, форумы, соц-сети. И блин, вот где я сказал все так делать? Биллинг - это кусок приложения, его можно написать вообще на других технологиях, это отдельный сервис.

 

[grigori]

да что вы говорите? вот это полет фантазии!
http://stackoverflow.com/questions/14753615/trellos-graphical-user-interface
https://www.quora.com/What-technologies-and-tools-were-used-to-build-GitHubs-front-end
п;%:ть - не мешки ворочать

 

[hell0w0rd]

ну с трелло ты прямо сильно промахнулся. http://wekan.io - опенсорс копия трелло, на метеоре. Сейчас переделали, переименовались и вернулись. И да, фронтенд гитхаба - старье. Там толи pjax, толи его аналог используется.
Я не говорю, что вот сейчас надо все бросить и переходить на подобные технологии разработки. Но не посматривать на их развитие, возможно даже попробовать в сайд-проектиках - глупо.
PS оригинальный trello, кстати, использует node.js

 

[grigori]

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

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

аналоги trello, github, slack, форумы, соц-сети. И блин, вот где я сказал все так делать?

фронтенд гитхаба - старье.
trello использует node.js
Я не говорю, что вот сейчас надо все бросить и переходить на подобные технологии разработки. Но не посматривать на их развитие, возможно даже попробовать в сайд-проектиках - глупо.

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

 

[fixxxer]

Я могу сформулировать за него

Есть такие сайты, которые по сути являются аналогами десктопных приложений. Веб-интерфейс почты, например, или мессенджеры. Подход с генерацией страницы на сервере там неудобен и использовался только когда других вариантов вообще не было. Потом в IE 5.5 появился XHR, и постепенно, через промежуточный этап "генерим на сервере куски HTML", с развитием JS и его производительности в браузерах (тот же компилирующийся V8) произошел плавный переход к классической "трехзвенке" и "толстому" клиентскому приложению в браузере. С появлением фреймворков типа angular такие приложения стало делать настолько удобно, что программирование ручками на jquery в сколь-либо сложной вьюхе уже видится примерно как программирование приложения для windows на голом win32 API - сложно, муторно и ни к чему. Далее, с трендом "каждому надо свое мобильное приложение", стало очень заманчиво делать на сервере единый REST-бэкенд, а для веба и для мобилок делать приложения, в которые унесена вся вьюха. Но остается проблема с поисковыми системами - JSON-LD в гугле хоть и есть, но непонятно в каком виде, а в яндексах с бингами появится неизвестно когда, если вообще появится. И тут на сцену выходит фейсбуковский react, который оперирует своим собственным виртуальным DOM, что отлично подходит и для сервера, и для браузера, и для мобилок. Пока что все это в довольно примитивном состоянии, с кучей проблем и нюансов, и суют это везде только молодые увлеченные хипстеры , но это уже четкий тренд, в перспективе сулящий множество плюшек - и если его игнорировать и пропустить, года через 3 можно оказаться никому не нужным динозавром типа программистов на перле

 

[MiksIr]

Веб-интерфейс почты, например, или мессенджеры

Почему так узко. Весь екоммерс более-менее сложный вполне подходит под это определение. Везде, где сложные фильтры, выборки и т.п. и при этом заботятся об удобстве интерфейса, а SPA этому очень помогает. Ни разу не хипстер никто у нас, но запускаем сейчас один такой проект, хотя скорее всего без реакта. Ибо поддержка двух версий сайта - SPA+статика - ад.

 

[WMix]

года через 3 можно оказаться никому не нужным динозавром типа программистов на перле

зря ты так о перле, очень требуются

начал за здравие ну а дальше мысль ушла в неизвестность )

 

[fixxxer]

Почему так узко

Потому что с этого начиналось. Щас намного шире, ога.

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

Ну я уже два таких запустил, вроде со смузи и маффинами тоже не был замечен

Ибо поддержка двух версий сайта - SPA+статика - ад.

Именно, адов ад. Я вот задолбался делать две версии там, где это действительно надо. Хорошо хоть мало таких мест.

Реакт тут должен от дублировния спасти. Теоретически, сам еще не пробовал

зря ты так о перле, очень требуются

Поддерживать легаси - да. Чот не видел проектов на перле, которым меньше 10 лет. Что там, кстати, с perl 6?