Django

Как там дела у Django, Ruby On Rails, Node.js?
Django

Гениальный ответ!

Perl + Mojolicious

После появления Servant все остальное стало резко ненужным.

это который для хаскеля?

hh.ru -> backend

/thread

Как там дела у Django

Прекрасно.

Чувак, веб - это днище, ниже только 1C.

Perl + Mojolicious

И сколько вакансий? 1 на всю РФ? За 70 тысяч рублей?

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

MVC и пачка REST-методов вполне уживаются вместе. Ты скорее всего имел ввиду что все клепают API.

MVC и пачка REST-методов вполне уживаются вместе.

Они-то уживаются, но с таким подходом MVC становится лишней сущностью на серверной стороне. Серверу, например, уже не нужно заботиться о рендеринге темплейтов, так что V полностью с него уходит. C тоже, если не считать частью контроллера сам REST-метод.

Это очень актуально. По этому сейчас, в кризисные времена неплохо бы уметь в актуальные способы заработать.

А можно пример того, о чем вы говорите?

пачки REST-методов

Надеюсь сэр не путает REST с RPC

Руби все, стула осталось два.

А сейчас где-то работаешь?

Что нынче актуально в серверных веб фреймворках?

PHP как всегда.

This

Golang!

А вот это действительно в тему. Спасибо.

Сейчас я делаю игори для андроидов и айос. Мне вообще норм, но неплохо бы уметь что-то еще.

А можно пример того, о чем вы говорите?

Вот хотя бы проект, в котором я участвую, соцсеточка для изучения языков в общении с носителями: https://demo.lingtwins.com (глубокая бета, могут быть косяки)

Серверная часть реализована на Akka HTTP, предоставляет исключительно REST-ы. Клиентская часть — одностраничное приложение на Angular, если я ничего не путаю. С точки зрения сервера весь фронтенд — просто статический контент, который отдаётся nginx-ом и работает уже на стороне клиента.

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

Что мешает V не заботиться о рендеринге и отдавать данные как есть? При этом тот же MVC с таким подходом в полном объеме реализуется на стороне клиента.

Что мешает V не заботиться о рендеринге и отдавать данные как есть?

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

Надеюсь сэр не путает REST с RPC

Не путаю. Просто сходу не нашёл лучшего термина, чем «метод».

Каждый раз, когда кто-то в 2016 году советует PHP, умирает один пингвинёнок.

Я не про отдачу статического контента, а про то, что серверу пофиг же, что он отдает, голые данные или отрендеренный html-контент, но и в том, и в другом случае этим занимается V. Тем более, что и json - это не обязательно внутреннее представление данных и преобразованием данных в json/xml/что_угодно занимается V.

4.2, пингвин не в последнюю очередь благодаря LAMP поднялся.

V — это то, что пользователь видит. А видит от не JSON/XML/что-угодно, а отрендеренную картинку.

Я просто сделал как тут предлагали:

hh.ru -> backend

смотри сам раньше лапти не склей

V — это то, что пользователь видит.

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

Для сервиса клиентом является клиентское приложение

Для которого понятие V не применимо. V — это исключительно для людей. А сервер возвращает данные предметной области, представленные каким-то из языков описания (XML/JSON/YAML/whatever). Данные в схеме MVC относятся к букве M.

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

M на клиенте тоже может быть. Иногда удобно построить свою модель на основании того, что отдал нам сервер. Как для кэширования, так и для удобства обработки.

А сервер возвращает данные предметной области, представленные каким-то из языков описания (XML/JSON/YAML/whatever).

А переводит данные в определенное представление V. Да, его ответственность сузилась по сравнению с классическим пониманием, но это как спор о том, каким должен быть контроллер, толстым или тонким.

Сейчас я делаю игори для андроидов и айос.

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

Я правда хз что сейчас в мобилах модно на бекенд вешать - какой-нибудь laravel, smartfox и прочие жава\пхп штуки. Хотя вон тут недавно одни крендели пилили на scala и хостили все это в amazon web services.

Короче там масса вариантов.

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

Это позволяет сделать говно вместо сайта и «перложение» для мобилок.

Чтобы склеить лапти раньше раби придется вернуться в прошлое.

Play на Scala.

Не вьюха, а адаптер (функция или DTO) меняет модель. Причем адаптеры могут (и должны) быть не только в слое MVC, но и выше и ниже. Ведь далеко не факт что модель, удобная для предметной области, хорошо уляжется в БД или в MVC. Надо адаптировать. Причем в обе стороны. man DDD

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

Фигасе у тебя слог. Слушай, а что такое функция? Ну, в математическом смысле.

Еще я термин функции не обсуждал). «функция» в том плане, что на входе одна модель, на выходе - измененная, адаптированная. В domain данные могут быть представленны так, в кэше - сяк, в бд - этак, по REST еще как-то, в ViewModel иначе. Данные одни, а представлений их может бытьмного. Но не называть же процесс преобразования - View. (хотя при желании можно генерить sql-запрос для бд джанговским шаблонизатором - тогда может оно и станет view))

Скорее наоборот, на V переходят, а именно react

Серверу, например, уже не нужно заботиться о рендеринге темплейтов

Ты не поверишь. Код клиента у меня получается в 3 раза короче, если часть темплейтов для ангуляра готовить на сервере. REST API всё то же, и также будет с мобильным приложением работать.

Битрикс?

И сколько вакансий?

Ты слишком стар: женилку отрастил, остепенился, обленился и далее по пунктам. А в ЮЗэй с Perl всё в порядке. Вообще, сейчас такое время, что хоть какая работа в Эрафии, и то хорошо.

а что такое функция? Ну, в математическом смысле.

Отображение множества X в множество Y

А что такое отображение? Это и есть функция. Тавтология, не находишь?

ТС, буду вторым в этом треде, кто скажет, что PHP живее всех живых.

Ты слишком стар

Да :(