Comments 22
Быстрая адаптация новых сотрудников оборачивается тем, что когда фреймворк теряет популярность, люди не хотят с ним разбираться.
Так если технология с более сложным входом потеряет популярность, то будет еще сложнее найти желающих в них разобраться. Да и сам сложный вход может повлиять на потерю популярности, так что это вообще аргумент в минус.
Тут дело не в сложности освоения технологии, а в поиске сотрудников, которые хотят с нею работать.
Точнее в том, что подготовленных людей (которые хотя бы немного с ней работали) крайне мало на рынке. А изучать технологию (пускай даже довольно простую) не все потенциальные кандидаты хотят. Особенно, если по применимости они видят только правки легаси.
Довольно странно судить обо всех фреймворках по одному устаревшему их представителю, не находите?
Они все рано или поздно устареют. Есть какой-нибудь контр-пример?
Конечно, $mol.
Как Вы сами пишете в 2020 году:
Прошло уже 4 года, а $mol всё ещё не современен. Он из будущего.
Давайте посмотрим уже после того, как он преодолеет отметку "современности", и мы посмотрим на крупные поддерживаемые проекты на нем? Какими темпами они будут развиваться, какие сложности появятся?
И еще я не уверен, что он FullStack. Но тут Вы, наверно, расскажите.
$mol всегда будет обгонять современные решения на пару голов.
Тут можете глянуть вики на $mol с синхронизацией в реальном времени.
Если же вы попадете на проект, где используется старый фреймворк, то он может блокировать обновление версий. С Meteor, например, не получится использовать Node.js выше 14 версии.
Раньше это была настоящая боль, но, по-моему, сейчас Метеор запускает ноду в ноде. То есть на машине может быть установлена последняя версия, а под капотом при запуске Метеора заведётся четырнадцатая.
Вообще, я разделяю чувства по поводу двуликости таких фреймворков. Я использую Метеор, чтобы показать студентам, как быстро и с минимальными усилиями поднять готовый полноценный проект, но каждый раз испытываю сомнения из-за того, что это просто набор решений, которые кто-то принял за них.
Как старый дед, сидевший на Метеоре кажется с того самого 2012 года пока не потребовалось расти дальше, скажу, что выделил бы совсем другие вещи.
В первую очередь, в чем собственно фреймворк. Это же не только реализация, не только код, что идет в библиотеке NPM, это идеи и принципы дизайна кода и разработки.
Для метеора можно привести в пример Optimistic UI, метеор учит вас работать с данными так, будто их мутации оптимистичны(уже произведены), что возможно благодаря подходу с изоморфным хранилищем и DDP, все, что происходит полагается на сокеты и реалтайм, а код обращается к данным так, будто они хранятся локально и актуализируются немедленно, автоматически, в момент возникновения события.
Эти кейсы не универсальны и причина, по которой метеор дает стартовыми приложениями чаты, а не одностраничник-маркетплейса именно в особом подходе к разработке.
Вы получаете особые инструменты, как playground для Graphql, или Redux-devtools, без которых разработка может превратиться в кошмар, а с ними, в дивный и необычный мир. Где например вполне нормально для изменений из devtool немедленно отражаться в базе, которой кстати вовсе не обязательно быть Mongo.
С фреймворком вы так же привыкаете, что не все можно сделать его возможностями, когда-то поддержку SSR, 10-кратного прироста скорости сборки пакетов новеньким вебпаком с HMR, и даже NPM-модулей приходилось реализовывать самому, потому, что все на свете хотелось делать на Meteor. Но по честному, конечно, мир меняется вы и сами должны расти и перерастать фреймворки.
Метеоровская команда подарила нам многие возможности фреймворка уже в виде Apollo, библиотеки вроде Grapher или Accounts перестали быть чем-то уникальным, пользователей стало привычно хранить в JWT, Mongo давно справляется с ACID, optimistic UI больше не захватывает сердца дизайнеров, а serverless давно и прочно вошел в жизнь, подружившись даже с enterprise и миллионами nginxов.
Но вот захочется написать чат, первое, что проверю, — как там дела у Метеора.
Очень странное сравнение - full stack framework против.. отсутствия фреймворков вообще? А что мешает нынче взять отдельно фронт, отдельно бэк, и скрестить их по GraphQL? Получатся практически все плюсы и почти никаких минусов из статьи?
Всё же я сравниваю с разделением фронта и бэка. На самом деле, с точки зрения разработки, это правда получается дольше. Как минимум, в плане фиксации договоренностей.
GraphQL - отличная альтернатива традиционному подходу с REST запросами. Но придется решать что делать с вебсокетами.
В плане запуска - тоже придется что-то придумывать. Монорепозиторий? Кстати, он решит проблему шаринга интерфейсов. Но потребует дополнительного контроля в плане смешивания кода.
если из названия и текста убрать fullstack то все станет на свои места.
в случае с fullstack проблема осложняется только тем что они могут быть чуть более сложные и зависят от большего кол-во библиотек и технологий, каждая из которых развивается своей жизнью или вообще умирает.
чем больше готового кода - тем меньше надо писать самому, но и меньше гибкости.
В целом, Вы правы.
Как я и писал, fullstack принимает решения за вас. В том числе, архитектурные:
Принципы построения api
Принципы роутинга
Доступность тех или иных вещей на разных этапах
Это делается, в том числе, за счет большего количества зависимостей, которые и реализуют фунционал на более «узком» наборе технологий.
Проблема в том, что рано или поздно технологию придется менять. И в случае fullstack это будет намного больнее, чем для частей по отдельности.
тут еще вопрос что понимать под fullstack.
я например часто использую два стека которые подходят под это описание.
laravel + livewire. Обработка событий с фронтенда (реактивных) в php коде на сервере, протокол передачи данных свой внутренний. JS код писать полностью (или почти) не требуется, но можно делать очень интерактивные страницы.
laravel + inertciajs + vue. По сути 2 фреймворка и небольшой мост, но ставится все в пару строк из laravel и из коробки уже готовая заготовка админки с авторизацией: формы и бд). inertciajs добавляет свой протокол для связи, но большая часть связи реализуется самостоятельно (axios).
это можно считать fullstack ? или вы под этим понимаете приложения где сервер и клиент на одном языке, то есть только JS ?
Не хочется ввязываться в спор.
В данном случае, вопрос в том, насколько больно будет переводить ваши проекты на другой стек, если это потребуется.
Если это в меру больно - то очень рад за вас. Если внутренний протокол для передачи данных придется реализовывать с костылями - то сочувствую. Если при переходе на другие технологии придется переписывать половину или больше эндпоинтов - сочувствую еще больше.
тоже не хочется начинать холивар.
ну вот "попроще" задачка. а например если надо переписать с react на vue (или наоборот) насколько это больно? вроде бы 2 фреймворка, не фуллстек, самые популярные и идеалогия одна и та же, экосистема каждого включает практически те же модули.
а переписывать все равно придется почти полностью.
Если есть хоть небольшой тренд что один растет односительно другого, то рано или поздно он перетянет одеяло на себя и станет основным мейнстримом. Или появится еще чтото более перспективное вследствие появления новых технологий. например на уровне JS появится средство для создания реактивных переменных и фреймворки будут выглядеть по другому.
Мы всегда выбираем: сделать быстрый старт или сразу планировать долгий путь не экономя ни на чем.
Сэкономил, купил дешевое авто, а оно через пару лет сломалось (а вдруг не сломалось? ведь не у всех ломается). Понятно что дороже в теории должно быть лучше, долговечнее. Но у кого то выбора нет, иначе он тогда вообще без авто останется.
Фуллстек фреймворки в какой то степени то же дешевый продукт для масс. Но без этой экономии и ускорения многие стартапы могут до релиза вообще не дойти.
По сути, в статье вы про это и написали, немного другими словами. У каждой медали 2 стороны.
Рассказываем о пользе и вреде FullStack-фреймворков на примере Meteor.js