Nobody has any fucking idea what’s going on in their react projects. I work with incredibly bright people and not a single one can explain accurately what happens when you press a button. On the way to solving UI consistency it actually made it impossible for anyone to reason about what’s happening on the screen, and bugs like the ones shown simply pop up in random places, due to the complete lack of visibility into the system. No, the debug tooling is not enough. I’m really looking forward to whatever next thing becomes popular and replaces this shit show.
I'm with you, but motivation to really learn a system tanks when there's something else on the horizon. And what happens when new-thing appears really great for the first 1-2 years, but goes downhill and we're back to asking for its replacement only 5 years after its release? That tells me we're still chasing 'new', but instead of a positive 'new', it's a negative one.
This was also reinforced constantly by people claiming you'll be unemployable if you aren't riding the 'new' wave or doing X amount of things in your spare time.
It's a natural consequence of an industry that moves quickly. If we want a more stable bedrock, we MUST slow down.
I devised a way of using plain closures to create DOM nodes and express how the nodes and their descendants should change when the model changes. So a component is a function that creates a node and returns a function not unlike a ReactComponent#render() method:
props => newNodeState
When called, that function returns an object describing the new state of the node. Roughly:
{ node, className: 'foo', childNodes: [ childComponent(props) ] }
So, it's organized exactly like a react app. A simple reconciliation function (~100 lines) applies a state description to the topmost node and then iterates recursively through childNodes. A DOM node is touched if and only if its previous state object differs from its current state object - no fancy tree diffing. And we don't have to fake events or any of that; everything is just the native platform.
I implemented an in-browser code editor this way. Syntax highlighting, bracket matching, soft wrap, sophisticated selection, copy/cut/paste, basic linting, code hints, all of it... It edits huge files with no hint of delay as you type, select, &c. It was a thorough test of the approach.
Also, when we animate something, we can hook right in to the way reconciliation works and pass control of the update to the component itself, to execute its own transition states and then pass control back to the reconcile function... This has made some really beautiful things possible. Fine grained control over everything - timing, order, &c. - but only when you want it.
Sorry for the wall of text.
I think it's good to keep that in mind as a reference point.
--
When it comes to developer experience I'd say that React and company are ahead of most desktop UI technologies, and has inspired others (Flutter, SwiftUI).
Literally anything built with NPM: megabytes? tens of megabytes? in size, totally inscrutable, code being pulled in from hundreds of megabytes of code in tens of thousands of packages from hundreds or thousands of people of unknown (and unknowable) competence and trustworthiness, if it breaks not only do you not know who to blame but you probably have literally no idea what wrong.
Yeah, jQuery was probably better.
So initially an equivalent React and jQuery app would have React look a lot faster, due to smart / batched DOM updates. However, because React is so fast it made people create apps differently.
As always in software development, an application will grow to fill up available performance / memory. If people were to develop on intentionally constricted computers they would do things differently.
(IIRC, at Facebook they'll throttle the internet on some days to 3g speeds to force this exact thing. Tangentially related, at Netflix (iirc) they have Chaos Monkey which randomly shuts down servers and causes problems, so errors are a day to day thing instead of an exception they've not foreseen).
React is just so, so much nicer to work with. It's easy to be dismissive if you've never had to develop UIs with jQuery and didn't experience yourself the transition to React which is a million times better in terms of developer experience.
I feel like people that don't build UIs themselves think of them too much in a completely functional way as in "it's just buttons and form inputs that do X", and forget about the massive complexity, edge cases, aesthetic requirements, accessibility, rendering on different viewports, huge statefulness, and so on.
Reading Computer Lib/Dream Machine over the holidays and I wonder where it all went so wrong.
On both ends.
Software developers hate boring software for pragmatic HR-driven career reasons and because devs are apes and apes are faddish and like the shiny new thing.
And commercial hegemony tends to go to the companies that slap something together with duct tape and bubble gum and rush it out the door.
So you get clusterfucks like Unix winning out against elegantly designed Lisp systems, and clusterfucks like Linux winning out against elegantly designed Unix systems, and clusterfucks like Docker and microservices and whatever other "innovations" "winning out" over elegantly design Linux package management and normal webservers and whatnot.
At some point someone important will figure out that no software should ever need to be updated for any reason ever, and a software update should carry the same stigma as...I don't know...adultery once carried. Or an oil spill. Or cooking the books. Whatever.
But then also it's important to be realistic. If anyone ever goes back and fixes any of this, well, a whole lot of very smart people are going to go unemployed.
Speaking of which...
I wrote a little bit more about my thoughts on the problem here: https://blog.usejournal.com/you-probably-shouldt-be-using-re...
> Nobody
Speak for yourself
React is huge, it’s unlikely you’ll implement the synthetic events, lifecycle hooks, bottom up updates, context, hooks with their magical stacks, rendering “optimizations” and all of react-specific warts.
There are simple reimplementations like hyperapp and preact and I completely recommend using those instead. I really meant React the library and ecosystem are at fault, not the general model.
(which is not specific to React but more like an issue for any framework that tries to do everything)
I like Svelte, the simplicity of programming in it is great, and it has several advantages compared to React. But I have no idea how it works, past a point of complexity. Like, yes: I can run the compiler and check out the JS it generates, same as I can do in React. For simple components, sometimes the compiled code even makes sense. But when I introduce repeated state mutations or components that reference each other, I no longer know what's going on at all, and I don't think I'm alone in this.
Svelte might be an improvement in ergonomics (and that's a good and much needed thing!) but it does nothing to answer the obscurity/too-far-up-the-abstraction-stack-itis that GP mentioned. The whole point of that is frameworks/abstraction layers that tell you "you don't need to understand what's going on below here" are . . . maybe not lying, exactly, but also not telling the whole truth about the costs of operating at that level of both tooling abstraction and developer comprehension.
