3 ms·
Agree in principle, but any technique is frigthening at first. Clearly for the authors this is a usual workflow - they're productive with it, and they only had
by vemv 9y ago
Agree in principle, but any technique is frigthening at first.
Clearly for the authors this is a usual workflow - they're productive with it, and they only had to pay the complexity cost once (when figuring out things).
Once you get an integrated frontend-backend system and codebase, you start to get unique benefits:
- Server-rendered data, for avoiding superfluous ajax requests
- Simpler deployments (fewer moving pieces)
- Single codebase, less knowledge segregation
and so on.
- jtmarmon 9y agoTo your first point, you can still server side render if you use an API by serving your frontend through a server that fetches data from the API before rendering
- hamandcheese 9y agoAnd at that point is the added complexity worth not just rendering with rails?
- laverick 9y agoI'm in the middle of converting a small production Rails API + Ember app to Rails Views + Vue.js using webpacker and a lot of the techniques discussed. It's certainly been a learning curve, but I'm definitely happier with the new setup for all of the reasons you mentioned. It's not a one-size-fits-all solution, but for a single dev / small team working on a web-only application it can make a lot of sense. For anyone interested, Gorails has a series on Vue + Rails that's been very helpful. https://gorails.com/series/using-vuejs-with-rails https://gorails.com/series/using-vuejs-with-rails