React Strikes Me as Ridiculous

https://news.ycombinator.com/item?id=28057950
by noduerme • 5 years ago
4 10 5 years ago

This is probably the third time in 10 years I've noticed job listings clamoring for React, and went and submerged myself again in what exactly React and JSX look like, in case I'd ever want or need to take a job involving that framework. And again I just can't believe this method of writing an interface is popular. It's like turning your socks inside out and claiming you're wearing magic shoes. On one hand, I'm permanently offended at the removal of the ever-elegant `${}` as a way to concatenate strings and JS. I was one of those coders who used to write PHP and never, ever, inlined it in a mainly HTML doc. I'd never touch inline javascript in HTML tags. It's just unreadable. I'd much rather have a pure piece of HTML as a template, with all the properties and roles and id's, and then a pure piece of code that modifies it or updates it. In some rare cases I'll inline templates with >>>EOT or `` syntax. The other thing is, Facebook started as a company doing PHP inline in HTML, and raced to find a way to compile PHP and then raced to find a way to turn Javascript inside out like a sock; they are not good hierarchical thinkers.

I think the promise of a virtual DOM is fun, but ultimately once you've dispensed with IDs and everything is an object, you still need keys; which means you need to bring back IDs in the model; which means you still have to go back to interacting with the DOM where you started, there's just a further layer of abstraction, one which you can't control the lifecycle of. And a hard-to-read abstraction! Now you can't just check the properties of a tag to see what hooks into it; it's instantiating something beyond your control, on its own.

Why does every new front-end developer job now ask for React as a core competency? Do people think it's going to still be a dominant framework in a few years? I really hope coders are able to think outside this paradigm and create their own element / component hierarchies without relying on this extremely hinky observational system to run the DOM for them. For instance (as an alternative) in big web apps I register components with my own MVC pattern, giving them unique Class.struct.IDs and assign them broad (global), narrow (within a parent component) or specific (just this component) listeners, to cause DOM redraws / updates; and these refreshes can be triggered by setting off events anywhere else in the app when a specific piece of data changes, and only when it changes, regardless of whether one or many related components are on-screen at the time. So refreshes aren't based on which DOM component happens to be on screen and whether its key matches some state, and consequently, you don't have to hunt for every component that might need that state. Encapsulating states in component-level architecture is stupid if you're dealing with apps that have hundreds of components and need to abstract model changes to any or all of them. Looking at React code and trying to figure out how to turn off specific listeners, or only target certain elements in sub-components when big models update seems like a recipe for hell.

And I also don't get why something that came out of Facebook has gained such popularity. Have you looked at Facebook's website since 2011? Is that a framework you would use to build an app?

Related Stories

Loading related stories...

Source preview

news.ycombinator.com