|
|
|
|
|
by peterangular
3024 days ago
|
|
> most of all: your front end isn't going to be DOM driven 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. |
|