4 ms·
I don't understand how people claim this is hiding huge levels of complexity. It's trivial syntactic sugar. If stylistically, you don't like it, oppose it on th
by JMTQp8lwXL 7y ago
I don't understand how people claim this is hiding huge levels of complexity. It's trivial syntactic sugar. If stylistically, you don't like it, oppose it on those grounds. But complexity? It is syntactic sugar for a function call.
- kansface 7y agoI agree with you - so much so that I don’t use source maps to debug stuff. It’s also the same reason I strongly dislike hooks (they aren’t really JS) while at the same time, they solve a problem I very rarely have (shared behavior without shared state).
- kls 7y agoThe opposition to it on fundamental grounds is born out of wrongheaded and misapplied best practices and quite frankly it needs to die. Dijkstra is credited with the idea of separations of concerns which is a valid application of code organizational management. The problem is, somewhere along the way (in the dawn of the web) we conflated separation of technology with separations of concerns. Thinking that separating technologies for technologies sake somehow made code more maintainable but the reality is, that it was dogma, if a snippet of JS, a snippet of CSS and a snippet of HTML will only ever be used as a black box component and only ever be reused as that black box component in total, separation of technology only leads to more complexity in interfile dependency and mental compos-ability of the whole solution in ones mind. There is an argument that separation of technology leads to simpler build management, but I personally will take a little more complexity in my build over complexity in the code base as usually a build becomes fairly static as a project matures.
- sibeliuss 7y agoThis argument maps to CSS-in-JS, too. It's a misunderstanding that this pattern would be rejected outright.