|
|
|
|
|
|
by ccachor
3024 days ago
|
|
|
Front-end frameworks are going to give you a few things: more control over routing, more "app" like behavior, instant state changes (easily done), and most of all: your front end isn't going to be DOM driven. Lets say you're tasked with redesigning an admin area and one really ugly area are forms. Rather than having the logic and styling bound to classes, that functionality is bound to a component. So, for large front-end applications the maintainability can be tremendous. I would say the big 3: maintainability, app like routing, and instantaneous state changes (across diff portions of your app) without doing much work. With Rails 5, you get the benefit of both. You're not doing your backend in javascript, but it plays nicely with modern front-end libraries and frameworks. |
|
|
I get this and all - but I also want to make a strong case for letting the traditional DOM manage application state.
Putting a "component" abstraction between what is being rendered on the front-end often feels like increasing complexity for perceived developer ergonomics and future-proofing your application. The only time I agree with this abstraction is when there is a clear need for insane complexity on the UI - something I actively try to hedge against during design phases. High UIX complexity generally means crap user experience/design.
Also - I would argue on how many different ways do we need to address a front-end component + tie data to it..? We've got ID's for singular selection, classes for group selection, HTML5 elements, name attributes, data attributes, etc etc. Yes, I understand that this conflates the UI DOM node's functionality (JS) and styling (CSS) but I've never felt the need to decouple that since they're both addressing/manipulating the same DOM; Which is what I consider the canonical state representation of the front-end.