Backend vs Frontend

[Sender]

Есть мысль, что модные языки и технологии оттянули на себя разработчиков, который в PHP могли придти. Скоро будем динозаврами. С одной стороны плохо, с другой хорошо Ждем выхода PHP7 и всплеска интереса.

Условия плюс-минус нормальные, с учетом кризиса к тому же.

 

[AmdY]

Есть мысль, что модные языки и технологии оттянули на себя разработчиков, который в PHP могли придти. Скоро будем динозаврами. С одной стороны плохо, с другой хорошо Ждем выхода PHP7 и всплеска интереса.

Скорее модные технологии убивают PHP, symfony и doctrine начали, а типизация в php7 добьёт. входной порог повышается, кода писать нужно больше, в итоге проще писать сразу на java-.net, а не на костылях php, а для хипстеров есть nodejs. Потому приток новой крови сократился, джуники предпочитают учить js, а не php.

 

[Sender]

Ты рассуждаешь как синьор, рассуждай как джуниор, для которого твои слова как какое-то заклинание.

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

Ну и акцент в вебе сместился ближе к клиенту, чем к серверу, отсюда модность frontend'а.

 

[hell0w0rd]

Да при чем тут модность фронтенда. Сейчас сайт с генерацией html на сервере - динозавр. Современные технологии позволяют делать все на клиенте (начиная с 10 IE, и с оговорками для 9), общаясь исключительно с rest-api сервера. А на мой взгляд, для большинства сайтов технология, на которой написано rest-api - вообще не важно.
А node.js еще ко всему прочему позволяет шарить код между клиентом/сервером (валидация, шаблоны) и делать universal приложения. Это когда вместо пустого index.html по запросу отдается весь контент, а дальше работает как обычное SPA. Такого без node.js либо невозможно, либо сложно, а значит дорого, сделать.

И, кстати, как я смотрю, большинство хотелок по php 7.x удовлетворяется typescript 1.6.

 

[MiksIr]

А на мой взгляд, для большинства сайтов технология, на которой написано rest-api - вообще не важно.

Есть и не большинство, когда бизнес-логика много сложнее, чем логика отображения. TypeScript интересен, но у него нет инфраструктуры, что мешает созданию сложных приложений. PHP c тем же Symfony пока на голову выше ноды с тайпскриптом. По-этому, то, что "за рестом" - скорее всего будет PHP.

 

[hell0w0rd]

@MiksIr, ну по этой причине нода обычно как прокси к более умным сервисам. Базе, микросервису с сложной логикой, кешам и прочему.

А еще я просто уверен что про ноду до сих пор думают, как про ужас с callback-hell. Но это давно не так.

// callback-hell
app.get('/some-file', function(req, res, next) {
  fs.readFile(filename, function (err, content) {
    if (err) return next(err);
    doSomethingWithFile(function (err, (data) {
      if (err) return next(err);
      res.send(data);
    }))
  });
});

// ES7, async-await stage 3
app.get('/some-file', async (req, res) => {
  const content = await fs.readFileAsync(filename);
  const data = await doSomethingWithFile(content);
  res.send(data);
});

 

[fixxxer]

А node.js еще ко всему прочему позволяет шарить код между клиентом/сервером (валидация, шаблоны) и делать universal приложения. Это когда вместо пустого index.html по запросу отдается весь контент, а дальше работает как обычное SPA.

К сожалению, только в теории. Вопрос изоморфной вьюхи реакт решает, а дальше - ничего, одни хипстерские поделки. Так что все равно в итоге за нодой будет какой-нибудь php.

 

[hell0w0rd]

Угу, в yahoo, airbnb, flipboard, whatsapp и atlassian одни хипсеры сидят
По поводу валидации, на пример, есть библиотека Joi.
Хотя я согласен, качественных решений вокруг реакта и ноды маловато.

 

[fixxxer]

Есть 1% нормальных библиотек на фоне 99% ерунды, и полтора вменяемых микрофреймворка. Фулл-стек фреймворков не видел, одно дерьмо хипстерское.

 

[MiksIr]

А мне это даже нравится - провоцирует архитектурную развязку на независимые части.

 

[Вурдалак]

Сейчас сайт с генерацией html на сервере - динозавр.

Ты из в темы в темы повторяешь про какую-то генерацию HTML, а я, в свою очередь, из темы в темы тебе напоминаю, что ты говоришь лишь про частный случай presentation, в то время как основную часть приложения составляет domain, application, инфраструктура.

Для меня client-side — это всего лишь деталь представления. Это может быть веб, может быть iOS-приложение, Android. Скучные, неинтересные детали. Анимации, иконки, блоки, кнопки, etc. Я не считаю это приложением.

А node.js еще ко всему прочему позволяет шарить код между клиентом/сервером (валидация, шаблоны) и делать universal приложения

Context is king, не нужно пытаться сделать что-то универсальное. Не нужно смешивать валидацию domain с валидацией на уровне представления; не нужно смешивать модель для записи и для чтения, etc.

Client-side наплевать на детали сервера. Серверу наплевать на представление. Это нормально, каждому своё. Это лишний раз доказывает, что всё-таки frontend/backend разделение очень полезное. И то и другое усложняется с годами. Если пытаться совместить в себе оба качества, то скорее всего ты не будешь хорошо делать ни то, ни другое.

 

[hell0w0rd]

@Вурдалак, угу, meteor идиоты придумали Может для банковской системы нужно все, что ты каждый раз упоминаешь, но это не нужно для большинства проектов, а где нужно - берут JVM.
Всякие чатики (сюда же маленькие соц-сети), контентые сайты, бэкенды для небольших игр - это спокойно можно писать на node и пользоваться тем, что у тебя фронтенд и бэкенд могут иметь общий код.

 

[WMix]

я уверен что под общим кодом подразумеваются сущности и шаблонизация первое делается json_encode второе не решает всех задач

 

[Вурдалак]

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

Меня не волнует на чём проект можно написать. Меня волнует как потом его поддерживать.

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

Да это всё простые концепции. Аналогично я иногда не понимаю и половины слов в ваших разговорах на тему AngularJS и ко, потому что я не в теме, но я не думаю, что это rocket science. Когда ты уже знаком с подходом/технологией, то тебе это уже кажется простым и ты можешь применять это в проекте почти любого масштаба, даже если кажется, что проект не очень большой.

Простота — это относительная штука. Для кого-то просто — это когда ты пишешь на голом JS + jQuery, а стили вставляешь прямо в теги, не вынося это в CSS (провожу аналогию, как умею ). Но я, наверное, не ошибусь, если ты скажешь, что для нормального проекта — это боль в заднице и за это нужно бить в морду? Ну вот примерно также для меня выглядят и твои попытки отказаться от ООП.

Иными словами, мне кажется твой подход наивным.

 

[AmdY]

Для кого-то просто — это когда ты пишешь на голом JS + jQuery, а стили вставляешь прямо в теги, не вынося это в CSS (провожу аналогию, как умею ). Но я, наверное, не ошибусь, если ты скажешь, что для нормального проекта — это боль в заднице и за это нужно бить в морду?

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

p.s. Кстати, laravel как раз из фреймворков, которые делают бэкэнд простым, что большой плюс к вакансии.

 

[hell0w0rd]

@Вурдалак, ну вот я скажу просто - не прав ты
Во-первых да, началось это все с angular. Всю жизнь по руками били за onclick=..., а тут ng-click и прочие аналоги. Все понимают что это работает по другому.
Во-вторых, среди фанатов реакта есть идея, что надо css писать прямо внутри JS. Мне такой подход не нравится, но он имеет право на жизнь, и в некоторых проектах даже необходим.

Ты считаешь, что если ООП может помочь в 5% случаев внутри проекта - его необходимо внедрить. Я сколько видел OOП-кода, все возможности к расширению сводятся к минимуму и почти никогда не используются. Давай банально вспомним Symfony и как сделано наследование в бандлах. А сделано оно через костыль:

class UserBundle extends Bundle
{
    public function getParent()
    {
        return 'FOSUserBundle';
    }
}

И нахрена такой ООП? А все дело в том, что какие-то простые области на самом деле можно покрыть с помощью ООП - драйверы для базы данных, обертки вокруг кешей, авторизации, файловой системы и прочих аналогичных штук.
Единственное что нужно в коде бизнес-логики - это интерфейс. Интерфейс можно описать на любом языке, и не обязательно явно. В JS сейчас появился Iterable, работающий по принципу утиной типизации.
http://passportjs.org - вот библиотека для авторизации, для нее написано 300+ провайдеров для различных соц-сетей, методов авторизации и тому подобному.

 

[MiksIr]

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

Всякие "чатики" - это вообще далеко не "большинство проектов". А простым сайтам это не нужно как раз. Вернее, простые сайты аля "контентные" - им вообще не все плевать. JS там больше презентационный - всякие анимашки. Для них в общем глубоко пофиг, нода там, или пхп, или руби. На них и пасутся всякие недопрограммисты фронтенда, знающие технологии, но не знающие программирование.
Все плюсы SPA проявляются как раз на более сложных сайтах. И на них же проявляются проблемы хреновой архитектуры, неверного разделения слоев. По-этому, нода остается как слой отображения. И это хорошо. И не обязательно это "банки". Более-менее крупный магазин уже содержит в себе прилично бизнес логики.

 

[MiksIr]

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

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

То, что появляется в том или ином фремворке, и особо то, что это начинают использовать тысячи леммингов - еще не значит, что оно правильно. История циклична, можно посмотреть вообще начало веб-разработки, зачем появился PHP и чем в итоге он стал.

 

[Вурдалак]

Давай банально вспомним Symfony и как сделано наследование в бандлах.

Это технический код, деталь реализации Symfony. Это glue code, детали конфигурации, назови как хочешь. Это скучный и неинтересный код, тот факт, что там будет «неправильный ООП» или что-то такое меня не особо волнует.

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

В конечном счёте, ты меня не услышишь, потому что у тебя нет достаточного опыта в работе именно с server side. Я в свою очередь, вряд ли тебя услышу, когда ты приводишь в качестве примера client-side технологии и рассказываешь, что там есть крутые библиотеки, сотни провайдеров. И чо?

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

Ребят, да вы просто не умеете писать код, вот и всё.

UPD: Что до фреймворков на JS, там другая история. Я сейчас про server-side. На клиенте там могут быть другие проблемы.

 

[Adelf]

Кстати приведу отрывок из своей статейки. Имхо в тему.

Но начну я с того, что расскажу чем мне не нравятся некоторые аббревиатуры на букву M: MVC, MVP, MVVM и другие. У неофита, читающего свои первые книги и статьи о том, как проектировать приложения, эти аббревиатуры всплывают одними из первых. У него создаётся ложное впечатление, что программа — это некая триада состоящая, например, из модели, контроллера и представления, и, что самое опасное, члены этой триады равны по важности! Многие из этих статей и видео-уроков подкрепляют эту опасную ложь примерами приложений из серии: «ну пусть за представление у нас отвечает такой-то шаблонизатор, контроллеры — это контроллеры нашего фреймворка, а модель — это какой-нибудь ActiveRecord ORM». После такого могут понадобиться годы Толстых Тупых Уродливых Контроллеров, чтобы неофит осознал, что что-то он делает не так. Что Модель в этих триадах занимает главное место и чем сложнее приложение, тем более это выражено.

Главный принцип деления программы на части высокого уровня не меняется уже несколько десятилетий: Data access layer, Business (logic) layer и Presentation layer. Причем, очевидно, что слой отражающий суть и всю ценность нашего приложения это Business layer, а DAL и PL являются некого рода обслуживающими слоями. А все эти аббревиатуры на букву M представляют собой архитектурные паттерны, описывающие как организовать Presentation layer в программах, не более того.