5 ms·
I couldn't disagree more. What all these React spinoffs seem to be doing is unlearning the lessons encoded in the React architecture and replacing them with mo
by unconed 4y ago
I couldn't disagree more.
What all these React spinoffs seem to be doing is unlearning the lessons encoded in the React architecture and replacing them with more magic by "helpfully" applying state changes immediately instead of in a controlled fashion. But this is going to create mixtures of old and new state, which creates subtle bugs down the line.
Discussions about VDOM also seem mostly pointless because it is clear to me most people's mental model of how React renders is flat out wrong. If you are redundantly touching the DOM, that means you haven't memoized your components, or you are needlessly making copies of the same state. All of these have far bigger performance implications. In fact, even without memo(...), React renders can halt early.
Quoting from the Use.GPU/Live docs, which is a true React extension with the same semantics:
"If a component renders the exact same JSX object as before, React will not re-render that child, even if the child is not memoized.
So there is a hidden semantic in React: when you construct a JSX expression anew, you are requesting that those children be re-rendered unless memoized. But if you reuse a JSX expression from before, you are implicitly giving permission to ignore any unchanged children."
This is crucial to understand when stacking context providers.
I don't get the sense that React derivatives have been used to build e.g. desktop-class apps. They mostly seem optimized for web sites.
While it is true that React does a lot of things at run-time instead of build time, this is necessary for building truly data driven apps. JSX is really Lisp quoting in disguise. If you can't recognize this, you should probably brush up on the fundamentals.
- sdgluck 4y agoHere's a link to the docs for anyone else who is interested to read them: https://usegpu.live/docs/guides-memoization https://usegpu.live/docs/guides-memoization
- danielvaughn 4y agoAgreed. Last year, for instance, I tried Svelte. I had a great time for a while, everything was fairly simple...but then I hit a specific scenario. I can't recall what it was, but it led to me digging as deep as I could into their docs to try and understand how Svelte was doing that whole $ thing. I nearly melted my brain trying to understand it. That's not to say hooks are much better, but I find the overall mental model to be fairly simple to understand, and I don't often find myself bumping up against React's edges.
- deleted 4y ago[deleted]
- alex504 4y agoThat's the thing about react, there basically are no edges or very very few edges left. There were edges in like 2018, but the team has made it relatively easy to do anything you want to do, while writing scalable and maintainable code.
- BigJono 4y agoHooks are much better. The only problem with hooks is that people don't get them. But once you get them, every other approach looks like a complicated pile of shit. I think the dev community does really poorly with these kinds of abstractions that are very simple but completely unintuitive. I place a lot of the blame on the React team too. When hooks came out, their docs were absolutely terrible. They probably still are. They were full of shitty editorialising like "we created hooks because we found classes were too difficult for people to understand!", which made every dev I worked with feel insecure for not immediately knowing how to write super awesome clean code.
- danielvaughn 4y agoI'm a big fan of hooks, but I'm still not completely sold on them. I like code that reads in logical sequence, like you're telling a story. When you use `useEffect` to coordinate side effects from prop changes, it makes me feel like I'm reading a story written by Quentin Tarantino. That being said, it's a relatively small complaint.
- imbnwa 4y ago>I'm a big fan of hooks, but I'm still not completely sold on them. I like code that reads in logical sequence, like you're telling a story. When you use `useEffect` to coordinate side effects from prop changes, it makes me feel like I'm reading a story written by Quentin Tarantino. I actually read this as a compliment considering Tarantino himself spoke in an interview about how his non-linear storytelling style comes from the way novels he'd read were written.
- girvo 4y agoAgreed. I think a lot of people forgot how much pain we went through with Knockout and Angular 1 and similar magic frameworks. We seem doomed to repeat it, in some ways.
- jmcgough 4y agoI'm learning Vue for work and getting bad flashbacks to Angular 1. Just hoping it doesn't come with some of the terrible flaws in that framework.
- girvo 4y agoI can promise that it doesn’t— nothing is as bad as $digest loop hell was lol. It has its own quirks and gotchas of course, all frameworks do, but it did learn from Angular 1. That said, I’m not up to date on Vue nowadays, I was using it on its first release because we’d been hurt so bad by Angular 1 at the time.
- neon_electro 4y ago"this is necessary for building truly data driven apps". So where should we try to draw the line at what is truly the kind of "app" that deserves this much JavaScript, versus a "glorified website" that management wants to see lots of interactivity/animations/etc.? In my career, I've struggled far less with choosing a JavaScript framework for front-end interactivity, and far more with justifying how much JavaScript goes into Web experiences these days, without any concern for the end-user performance impact or other impacts that may not be as obvious, e.g. accessibility.
- moltar 4y agoCan you recommend some really in depth reading about React?
- acemarke 4y agoAnything particular you want to know about it? Assuming you're asking more along the lines of "how does it work internally?", these are my usual recommendations: - My own extensive post "A (Mostly) Complete Guide to React Rendering Behavior": https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-... - Related, "When does React render your component?", which looks more at the source level checks: https://www.zhenghao.io/posts/react-rerender https://www.zhenghao.io/posts/react-rerender - Dan Abramov's "A Complete Guide to useEffect" https://overreacted.io/a-complete-guide-to-useeffect/ https://overreacted.io/a-complete-guide-to-useeffect/ - Shawn Swyx Wang's talk "Getting Closure on React Hooks" that builds a mini version of React hooks: https://www.swyx.io/hooks/ https://www.swyx.io/hooks/ - Rodrigo Pomber's excellent "Didact: Build a Miniature React with Hooks": https://pomb.us/build-your-own-react https://pomb.us/build-your-own-react
- galaxyLogic 4y agoIs it possible to explain the big idea behind React in a single paragraph?
- eastbound 4y agoWrite your code as components. The JS is nearby the corresponding HTML, and thus several teams can work on large web applications because it is so nicely componentized.
- galaxyLogic 4y agoA great and succinct explanation, thanks.
- noman-land 4y ago
- cageface 4y agoApplying state changes in a controlled fashion is just about the last quality I'd ascribe to a non-trivial React codebase. By the time you've finished with all the ceremony of memoizing everything just right so you get acceptable performance you're left with a brittle codebase full of surprises. Making one innocuous change can break all your memoizations. Or you're just as likely to find something failing to update because it's been over memoized. Manually managing all the dependency arrays for all this is very poor DX. React deserves credit for bringing fresh thinking into the JS framework space but there's a tremendous amount of room for improvement.
- ironmagma 4y agoSo don’t memoize unless you need to. Most of the time, you don’t. This is a fairly classic case of overeager optimization. The state changes shouldn’t* particularly depend on memoizations anyway though as memoize should be mostly for view stuff (which should* be idempotent) rather than model stuff. * = subjective and there are a few rare exceptions
- cageface 4y agoIf you want acceptable performance in a reasonably complex react app you absolutely have to memoize. The fact you think this isn’t the case suggests to me you haven’t worked on a big react app.
- ironmagma 4y agoThere’s a significant difference between having to memoize and having to memoize tons of stuff. Generally you should only need to memoize a few things, and if you find that your app becomes brittle due to the amount of memoization you’re doing you probably are not handling state in the right way. If you’re using Redux that’s a common reason for this; don’t use Redux (is my advice). And yes, I’ve worked on several large enterprise React apps at successful startups.
- moonchrome 4y ago> If you want acceptable performance in a reasonably complex react app you absolutely have to memoize I think what OP was suggesting is that you don't have to memoize at every level of the tree / where it doesn't make sense.
- toddmorey 4y agoI think your comment here perhaps proves the author's point
- sussmannbaka 4y agoIt’s worth to note that this crucial to understand thing is only ever mentioned deep inside the API reference. If it’s this essential and never once mentioned even in the advanced section of the documentation, that’s on the project and not on the developer struggling with react. They are using it as advertised.
- zero_shift 4y agoFor context, the author has only been working professionally as a front end developer for about three years - so has no such memory of $digest or ko.computed() or other such miserable kludges.