мне нравится, что по сравнению с react, где flux / redux не является чем-то коробочным, или тот же react-router с адскими вселомающими обновлениями, вместе с vue.js идут пусть и отдельные, но разрабатываемые core team инструменты vuex, vue-router

т.е. сами разработчики vue за этим следят. Это не разные люди и не разные проекты

я пишу SPA на vue.js как pet-project

Ты бы видел меня когда я сел за реакт.

Первая мысль, где мой сахар.

Я привык к нему, а тут прикручивай, откладывай, еще этот конфиг сиди переделывай.

React отпугивает тем, что 1. Насильно навязывает Redux. 2. Первое время никто не может объяснить, зачем нужен Redux. Все говорят, что со временем поймешь, зачем. Это со временем наступает через месяц-два разработки

и доки redux-а жесть

Хорошо, что я еще с java xml не встречался, там бы еще жоще было бы.

vuex в этом плане выигрывает, как по мне

Redux нужен, чтобы не было всех этой херни с прокидыванием пропсов.

Мне надоело прокидывать через 3 компонента.

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

хотелось изменять напрямую

без однонаправленного флоу

весь кайф этого флоу я прочувствовал, когда проект подрос

и пришлось что-то дебажить

потом ещё раз

и ещё раз

потом я полюбил редакс )

но первое время я хейтил его наверное даже больше, чем js

Тоже самое. При этом я быстро въехал в сам Redux, но не понимал как его правильно готовить. А самое ужасное, многие хорошие фронтендеры готовили весь этот стэк по-разному, и друг друга дерьмом поливали за иные способы. Кто-то юзал Saga, или redux middlewares, а кто-то в экшенах ajax отправлял

во vuex это лучше регламентировано и все понятно

хотя мб я просто глубоко не копал еще

https://github.com/paralect/koa-react-starter

а ещё минус и плюс во vue.js - это зачастую одна популярная либа на задачу

минус - нет конкуренции

плюс - единообразие и либа одна развивается по максимуму

в реакте, если не ошибаюсь, три популярных варианта роутеров

четыре варианта либ для валидации форм + 50% реактеров хотят писать валидации с нуля

и.т.д.

Ну как бэ история та же, что и с рельсой.

Что есть у нас кроме синатры и недавно вышедшей на продакшн сцену ханами?

ну синатра плохой пример

синатра не диктует архитектуру

ты с ней чё хочешь можешь собрать )

но да, мессадж я уловил

та же история

есть ещё grape

хотя я не видел онли-grape проектов

в комбе с рельсой только

а, ну и Trailblazer для гиков же

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

а вообще есть что-то типа синатры, но с архитектурой уже?кроме кастомных синатр

рельсы?

рельсы?

+

ну хотелось бы всё же из микрофреймвёрков что-то

микрофреймворк == конструктор "собери сам"

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

или что имеется в виду?

ну хотелось бы всё же из микрофреймвёрков что-то

почти все, на чем строится http стек в Ruby - это Rack, для микрофреймворков можно использовать чистый Rack с небольшими обвязками. Для этого стоит просто разок написать свой wrapper. Но если лениво, вот есть. http://cuba.is/

имелось ввиду синатра, например, но с MVC. Понятно ,что можно и на синатре написать ,что собно и делал ,но это всё выглядит как костыль, вот и подумал может уже есть готовые лёгкие фреймвёрки с MVC

MVC - это уже не совсем микрофреймворк)

хм

берешь синатру

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

решаешь что у тебя является View (HTML, JSON, etc)

решаешь, что у тебя Model

ActiveRecord, rom-rb, sequel etc.

Вуаля

фреймворк собран )

и получается рельса :D

ну да )

;)))

а как иначе, если из микрофреймворка нужно сделать MVC )

ActiveRecord::Base в рельсах 5.2 уже не имеет delegate метод? NoMethodError: undefined method `delegate' for #<Product:0x00007fa503dc6630> Did you mean? delete app/models/product.rb:21:in `block in <class:Product>'

А кто сказал, что нужно MVC ?)

так выше ж сказали

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

это не я придумал )

это был риторический вопрос)

но, кстати, свой MVC имеет смысл

ибо рельса без ActiveRecord-а - вообще не рельса

так что если Model не ActiveRecord - то почему бы не собрать всё с нуля? )

Да можно собрать, конечно. Но как правило, потом выясняется что нужно письма отправлять - прикручиваем actionmailer. Ах, вот еще классно юзать constantize, present? и т.п, а давай-те воткнем тогда ActiveSupport...весь!

потом растут требования и фичи

ActiveSupport грозились же на несколько гемов разбить

система начинает обрастать REST API

Или мне приснилось?

там и сейчас можно подгружать то, что необходимо

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

ActiveRecord::Base в рельсах 5.2 уже не имеет delegate метод? NoMethodError: undefined method `delegate' for #<Product:0x00007fa503dc6630> Did you mean? delete app/models/product.rb:21:in `block in <class:Product>'

умеет

Да можно собрать, конечно. Но как правило, потом выясняется что нужно письма отправлять - прикручиваем actionmailer. Ах, вот еще классно юзать constantize, present? и т.п, а давай-те воткнем тогда ActiveSupport...весь!

письма отправляются зачастую через сторонние сервисы сейчас, actionmailer в минусах. activesupport - да, захочется добавить полюбе. и почему бы и нет?

REST API - вообще не понял поинта

как рельса помогает делать REST API?

в том смысле, почему это тяжело должно быть делать без неё? )

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

А вы попробуйте на Sinatra написать API на 100 каких-нибудь базовых ресурсов, с дополнительными HTTP endpoints

другой вопрос - будет ли это многое большей частью от всей рельсы? )

даже если изначально их было 10, где гарантия, что количество endpoints не дорастет до 300 ?

будет несколько неудобно)

не вижу кореляции между колличеством эндпоинтов и синатрой

будет несколько неудобно)

почему?

думаю, потому, что начнется каша. Каждый эндпоинт обрабатывать в отдельном блоке. В рельсах довольно грамотный роутер. Не без проблем, но все же. Я конечно не спец в синатре и наверное там есть решения, но вот всякие routes constraints, action_filters в контроллерах и т.п. не плохо помогают

подобное используется в grape и мне не очень нравится

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

по поводу грейп, сейчас на проекте в комбе с рельсой грейп

тоже казалоьс, что сложно будет ориентироваться

особенно когда в одном файле допустим 15 эндпоинтов

по итогу - Ctrl + F в редакторе