На чем делать сервис / SAAS в 2018 году?

Цитата:

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

Это верно. Если один разработчик делает сайт-визитку о пяти страницах, то MVC жутко тормозной по сравнению с  шутсрым PHP скриптом разработчика и жутко затрантый по ресурсам.

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

Цитата (jack31):

Если один разработчик делает сайт-визитку о пяти страницах, то MVC жутко тормозной

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

Цитата (jack31):

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

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

Интересно... другое... так ли часто рождаются такие проекты над которыми работают 10 разработчиков, как часто используют эти фреймворки сегодня!?).... вопрос, конечно риторический.

а про визитку это вы конечно мимо - как раз на визитке побоку чем она обвешана, все равно летать будет.

П.с. а сугубо по теме.

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

vovka-morkovka, Ппц тут серьезные дядки обсуждают.

Я делаю бложики на Вордпрессе. Сам счастлив, клиенты счастливы. В команде 2 человека - я и мой одногруппник. Сайты быстро загружаются так что пипец. Не загружаются, а летают просто.

vovka-morkovka, да что тут обсуждать, последний проект под пару лямов с перспективой увеличения еще на три умер благодаря таким самопивцам, любители короче вокруг.

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

Так что фигня эти ваши самописы - уже не одним годом практики доказано - 1 делом\проектом\задачей человек может заниматься ровно столько (даже при большой оплате) - пока его это не запарит. А самопис - ускоряет процес запаривания.

Цитата:

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

Классика.. Ключевой проект, один программист, с которым нет возможности/желания договариваться,  непонимание (полное) того как он работает плюс enterprise технологии (читай "не найдешь голодного студента". Гремучая смесь..
В этом случае да, выходить за рамки собственных навыков не получится.
Дружить нужно с разработчиками..
А что разные подрядчики отказывают, так это нормально. Браться за доработки незнакомой системы (пусть даже на знакомой технологии), можно либо на условиях, которые покажутся заказчику драконовскими, либо "набраться практики".