3 ms·
I've found it cleaner and easier to track changes to your model data and let the view be a declarative representation of said model. YMMV though. I'd much rath
by lowboy 11y ago
I've found it cleaner and easier to track changes to your model data and let the view be a declarative representation of said model. YMMV though.
I'd much rather punt the ball into a stadium with some properties/parameters than run the logistics of a game myself (security, ticket sales, refereeing, etc). It's saved me gobs of time as a developer. Again YMMV.
- sago 11y agoI agree on the first line. I think there are very simple cases where hardcoding HTML in Javascript might be okay, but it is dubious. We use templating (both an internal simple templating system which is literally 20 lines of code, and in some cases React, when it is warranted). But I don't think you're getting what I was trying to say. Sorry, for the confusion. On the second point, it depends on how hard you think the logistics are. Often the logistics consist of a couple of sweaters for a goal, and a ball. Knowing when you need a 100,000 person stadium, and when a back yard will do is the trick. Which gets lost in framework-hype. And when a post lauds a stadium because 'it has grass, guys!' then it sounds like they're buying into the hype rather than the reality. If the OP had said 'it has a kick-ass virtual DOM - never write DOM synchronization code again!' then that's a different matter. But it didn't. See what I'm saying? I'm definitely not being anti-React or anti-Framework.
- lowboy 11y agoI agree that people should think about the proper tool for the job. And that hype can lead to poor decisions.