Какой JS фреймворк выбрать для full-stack?

Question

[ChibiZ]

Какой фреймворк на данный момент самый развивающийся для full-stack разработки на javascript?

Есть опыт разработки в React+redux, Angular, Vue, JQ, но это скорее о клиенте,
На Node.js я пользовал только ORM + Express, для простых каких то микро сервисов (чат, лендинг, хост API и подобное).
От экспресса ощущение конструктора лего, и вся архитектура на тебе, да и дозволяет изрядное количество говнокода.
Свела меня судьба в symphony и laravel, и было очень комфортно, но это php, чего не хотелось бы.
Я ярый фанат JS, сайты, игры, приложения на нем делаю.

Интересуют следующие вещи:

• Строгая архитектура (Цель: пресечь говнокод, много разработчиков, мало времени делать код ревью за ними)
  
• Богатый набор встроенных дебаг инструментов
  
• Генерация документации
  
• Наличие тестов, unit, end-to-end
  
• Независимость от конкретной бд. Может и в Mongo и в SQL
  
• Менеджер пакетов npm
  
• Гибкость в сборке fronend (возможность использования и gulp и webpack)
  
• Удобный рендеринг React/Angular/Vue на сервере
  
• Легкость хоста API
  
• Работа с авторизацией, куками и подобное
  
• Websocket, или альтернатива
  
• Своевременность обновлений
  
• Кросплатформенность (Win/Mac/Lin)?
  
• Шаблонизация? Pug?
  
• Динамические имена фалов, пути
  

Из претендентов
koa.js
total.js
sails.js
meteor.js
derby.js
По репозиториям и поддержке выходит метеор, но возможно я чего то не знаю.
Бытует мнение что метеор будет скорее мертв чем жив. Пишут метеор мертв, популярен реакт, но блин, это же совсем разные вещи. Все, статьи "Метеор это будующее" из 2014 года.
Опыта ни с одним из перечисленных фреймворков нет, так что особо не ругайте за наивные вопросы.

Answer 1

[Alexander Litvinenko]

В свое время работал и с React\Redux, и Vue, и Angular.

Зависит от задачь, наиболее удобным являеться React\Redux, при наличии человека что может вам настроить кастомный webpack, это просто сказка а не разработка.

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

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

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

Comments

[merss]

а что должен уметь кастомный вебпак для реакта?

[Антон Спирин]

Вы бы хоть вопрос прочитали, пред тем как лонгрид не по теме писать.

[Alexander Litvinenko]

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

[Alexander Litvinenko]

merss, ну Артём Петренков уже ответил, можно добавить к этому кучу мелочей вроде путей от корня или глобальных scss стилей, но целом настраиваеть хватает, у нас есть билд что нарабатывался не один год, если будет интересно, в личку, можем в деталях разобрать.

[Kir ---]

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

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

Как же я горю от таких советчиков, особенно с описанием "team lead".
Вы не понимаете какие 2 основные задачи должен решать программист. Вы не понимаете, как организовать архитектуру приложения. Вы не понимаете даже что такое архитектура.
Вы не используете рефакторинг. Скорее всего вы разрабатываете либо в Notepad++ или Sublime Text.

[Alexander Litvinenko]

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

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

Работаю в редакторе VS Code, мне также очень нравяться продукты JetBrains но сейчас нахожу их избыточными под текущие задачи. Ничего не имею против Sublime Text, с определенным уровнем кастомизации он сполне себе мошьный инструмент, а в тренинг центре при нашей команде, на первых этапах принудительно заставляю работать только в редакторах уровня базового Notepad++, чтобы запоминали лучше а не пользовались подсказками редактора.

Вобще стоит ли продолжать, вам не кажеться что пост "Вы не понимаете....", "Вы не используете" и "Скорее всего вы..." составляют личные эмоции и просто недостаточно информативны чтобы адекватно вам ответить.

[PxlFxr]

Я даже авторизовался, чтобы на этот бред ответить.
1. Автор спросил совсем не про то, что вы написали. Ему нужно бэкэнд на js писать.
2. Даже в контексте выбора фрэймворка для SPA, все написанное - бред, особенно про VueJS.
3. По уровню ответа - вы максимум мидл, а безграмотность делает все еще хуже.

[Alexander Litvinenko]

PxlFxr, охтыж господи
1. На этот вопрос было отвечено уже
2. Подтвердите обоснование, я свое могу и как минимум 6 человек со мной согласны. Или дайте расширеное объяснение если неправильно вас понял.
3. Мы кажеться неговорили с вами на технические темы и собеседование не проводили, вы пророк? также я могу оценить когото, но не оцениваю. Свой личный уровень я оцениваю как мидл+ по шкале нашей компании, хотите попробовать пройти собеседование?

Answer 2

[Дмитрий Кузнецов]

Если вам важен js как на фронте, так и на бэке, то попробуйте Adonis JS. Это что-то типо Laravel, только на Node.JS. Вот статейка на хабре: https://habrahabr.ru/post/324220/

Comments

[Igor Koch]

https://github.com/nuxt-community/adonuxt-template

Есть еще темплейт со связкой с nuxt

Answer 3

[Coder321]

Если выберете Angular для фронта то можно посмотреть в сторону nestjs, это ангулароподобный node фреймворк.
Еще мне понравился Loopback.

Comments

[Coder321]

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

Answer 4

[xfg]

Лучшее что сейчас есть это koa или express для http протокола и socket.io для websocket протокола. PHP тоже от full-stack фреймворков движется в сторону микрофреймворков. Сегодня современный фреймворк это роутинг запросов реализованный на концепции мидлваров.

Проблема спагетти-кода решается не фреймворком, а архитектурой. На сервере это обычно multilayered architecture. Бьете приложение на 4 слоя presentation, application, domain и infrastructure (еще могут называть data access layer или persistence layer). Контроллеры фреймворка куда попадает запрос пользователя это будет ваш самый верхний presentation слой. Слой инфраструктуры лучше собирать из отдельных библиотек, чем завязывать его на фреймворк. В таком случае не придется переписывать весь слой инфраструктуры из-за того, что фреймворк больше не развивается. Application и Domain слои используют Infrastructure слой через интерфейсы, тем самым абстрагируясь от конкретных реализаций. Таким образом вы всегда сможете заменить одну реализацию другой (паттерн Strategy) без изменения вышестоящих слоев. Presentation слой просто вызывает сервисы из application слоя и возвращает результат в html/json/xml/etc клиенту.

Иногда упрощают до 3 или даже 2 слоев. Например если у вас CRUD приложение, тогда application и domain слои не нужны и вы можете оставить только presentation и infrastructure. Также если ваш application слой не делает ничего, кроме вызова domain слоя, то от него также можно избавиться оставив 3 слоя presentation, domain и infrastructure.

Примеры реализации можно найти здесь и здесь. Они на Java. На javascript пока не встречал.

Более подробно тему можно изучить взяв любую книгу на эту тему.

Meteor не советую. Это не будущее. Это костыль. Они хотели сделать фреймворк для real-time приложений. Но фактически получилась просто платформа для стриминга произошедших изменений в mongo прямо на клиент.

Sails это попытка сделать full-stack фреймворк. Но весь мир движется в обратном направлении.

Comments

[Антон Спирин]

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

[xfg]

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

[Михаил]

xfg, по моему, когда говорят о реализации без зависимости от фреймворка то имеют ввиду просто хорошее проектирование. Рассматривать все эти случаи когда нужно поменять фреймворк? Может быть 1 из 1000 раз, когда не нужно будет будет переписывать проект целиком, и понадобится пересесть на что-то другое.

Answer 5

[Виталий]

метеор мне понравился , но его заточенность под монго не совсем привлекла, вроде как есть кастылизация под другие бд, но мне не по душе орм
по тому мой выбор koa.js jwt socket.io pg-promise (бек), постгрес как бд, на фронт два варианта реакт / реакт редакс либо через CRA с eject конфигурации и ее коррекцией с последующим проксированием через нгинкс либо если требуется SSR то подключение next.js.
В любом случае каркас проекта и требования к тому что пишут разрабы нужно устанавливать сразу, но если проект без особых заморочек, не думаю что это проблемой может быть.

Answer 6

[itexams]

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

Как итог - 100% загрузка памяти и адские тормоза. В итоге с метеором пришлось расстаться.

Answer 7

[Виктор]

Angular это полноценный фреймворк а не только для клиента, там есть всё что Вам нужно

Comments

[ZoomLS]

Как давно бэкэнд завезли в Ангуляр?

Answer 8

[Дмитрий Слепнёв]

node.js не для этого придумали, там всё на микросервисах работает.

Comments

[Джавараст Скриптович]

Виагру тоже не для этого придумывали...

Answer 9

[PxlFxr]

Свела меня судьба в symphony и laravel, и было очень комфортно

Ну вот.

но это php

И что? Современный php очень неплох. Сложившееся мнение о php не отражает текущей ситуации.

Недавно попробовал laravel, понравилось. Весь требуемый вами функционал там есть.