joco-sveltekit
joco-sveltekit copied to clipboard
josh-collinsworth
blog/antiquated-react
Things you forgot (or never knew) because of React - Josh Collinsworth blog
If you don't often look beyond established comfortable defaults, you might be surprised to learn just how far the world of frontend has moved away from React, and how big that gap continues to grow.
https://joshcollinsworth.com/blog/antiquated-react
Good read and many of the perspectives match my own through experience with React on a handful of large projects. My conclusion:
React is the new IBM: you should learn it, you should understand its faults, you should probably still deploy it in the right context. You’ll never get fired for picking it, but it’s going to be expensive, bloated, difficult to get right, and it’s going to be joyless implementing it every step of the way. React is “the status quo mindset — the biggest enemy of pure innovation”.
My take here: https://chrlschn.dev/blog/2023/02/react-is-the-new-ibm/
Could you speak more to this, please?
These days, though, we’ve mostly figured out solutions to the pitfalls of two-way data binding, and found that in many cases, it’s actually much more convenient.
Ugh, forms in React are the worst. So much boilerplate and redundancy for so very little benefit. Every project I've had to do with React, I've tried to find a way out of the madness. And worst of all, you likely don't even need the form state for most of your fields anyway.
In some ways, I'd rather see a return to proper server-first rendering (as in actual PHP), figure out a way to component-ize UI elements, but still have an easy way to add functionality in JS when actually required.
And worst of all, you likely don't even need the form state for most of your fields anyway.
@timw4mail in that case, you don't need to write any of the boilerplate. Just attach a listener on submit, create new FormData(event.currentTarget) and use that to get form values. (I would do the same in Vue and other frameworks, too. There's just no need to create bindings for every field.)
The only reason to use controlled fields is when you need to react to every change, most commonly for validation. But in that case, it's better to use React Hook Form or similar.
Great article, and tbh kind-of an eye opener for me to see in what state React actually is nowadays. Subconsciously, I guess, I am in the mindset that React is amongst the hip-and-happening frontend tech, but that's maybe because I've been in Angular-land for the past 8 years and only made the leap to React last year. I knew of the existence of Vue, Svelte and Solid of course, but was under the impression that React is still the most mature of them all.
One thing that I've experienced working as a professional frontend dev: companies look at that maturity and track record, which also means it's easier to find people that can develop in React because there's just so many of 'em. Which in turn perpetuates the staying power of React of course, and with all the React code being written, no one wants to re-do it all in that new popular framework...
Whether or not React is outdated, picking React is a business decision, because a “niche” framework narrows the pool of available / experienced developers to pick from.
@cutiful Yes, I have done that solution. My contention is that mixing controlled and uncontrolled fields is a mess, and the two categories of form state created (React and DOM) are clunky. This is an area where I've always felt that React gets in the way more than it helps.
really good article , thanks for sharing. regarding how and when to use memoization I would recommend your this cheatsheet :-) https://betterprogramming.pub/react-native-memoization-cheatsheet-769ee2841aa2
Really glad to see someone push back on the entrenched React mindset. I have an old Meteor/React project that needs upgrading and was considering using Vue since I'm more experienced there. However, I'm increasingly interested in a different approach, like https://htmx.org/. I would love to hear your thoughts on it. Thanks again for posting!
Thanks for sharing idea. It's such a great article.
I expected this article to focus more on UX-side rather than DX-side because you have started the article as "Developer experience (DX) shouldn’t ever supersede user experience (UX).". But honestly speaking this article still strongly focus more on DX. What do you think would be advantage of using such newer frameworks over React in terms of UX?
And one more thing I want to add is that 'larger ecosystem helps when you face a complex issue'.
Yes, you may not notice any difference between frameworks with different size of ecosystem at a glance. But when you're project gets bigger and bigger and you dive into the system deeper and deeper, some sort of complex and intricate issues arise. In such case, if you're in a smaller ecosystem, you may fail to find a proper solution because you might be the very first one to face such issue.
I expected this article to focus more on UX-side rather than DX-side because you have started the article as "Developer experience (DX) shouldn’t ever supersede user experience (UX).". But honestly speaking this article still strongly focus more on DX. What do you think would be advantage of using such newer frameworks over React in terms of UX?
@bb-in-hoodie I cover that more in another post, The self-fulfilling prophecy of React. Though you're right; I could've done a better job of elaborating here. Maybe in a future update I'll do a better job of closing that loop.
@josh-collinsworth @bb-in-hoodie My take on the DX/UX is that they are intimately linked. The React DX is such that it easily leads to bad UX precisely because it's so easy to generate errant side effects in React. The most common way this surfaces to the UX is performance issues. I've also seen cases where developers mistakenly put API calls in the path of a render which caused a ridiculous render loop (the API was trigger on a change of a progress bar of all things!).
Aside from that, the poor network payload size of React and poor runtime performance is definitely a UX concern, especially on mobile networks and devices.
@josh-collinsworth , I'll check that out too. Thank you!
@CharlieDigital , yes I also agree on your words. Poor DX leads to technical issues and those technical issues lead to poor UX. But the word 'UX' covers way broader topics.
As you said, runtime performance is of course a very important part of UX. But at the same time, there are tons of so called UX-stuff resides in our web apps including better transition, smooth animation, proper reaction of UI elements and so on. Usually what users more care about are those things with regard to user experience. What I'm saying is that when Josh said "UX is important", I thought those kind of less-technical-UX-stuff would be covered in this post.
Nice article on the topic. I have been reading similar, less comprehensive pieces for the last couple years, but presented like this, there is a lot to chew on.
I manage a coding bootcamp and I am always looking to try and stay ahead of the changing job market. We teach a React/SQL program and focus on new developers. In terms of where the jobs are, React is still the best bet for people breaking in to the industry, but i'm going to share this with our recent grads.
There is way too much syntax sugar in Svelte for my liking. It's not pure pure JavaScript, more like its own subset of JS.
It's not just about React. React Native is a big deal! It's a way bigger ecosystem than you imagine. Most of the latest shiny improvements are marginally better, not a giant leap. We've got to a point where all the UI libraries/frameworks are good enough for productivity. So yes, React is still going to win until a giant leap in UI development shows up again. I think the UI ecosystem has matured and settled on React. People just want to be productive and build things instead of chasing marginal improvements in UI tooling. And that might be a good thing.
I've learned to build complex websites without fancy frameworks but that required fancy code from myself, including for the build system. I learned OOP with Smalltalk and functional programming with Clojure. After all of this I find that React (with hooks) and Typescript are very good.
You have type checking without classes. It's fully compatible with FP. The build system is great. Performance is good enough for most projects.
Sure useEffect is complex but it solves complex problems like adding and removing an event listener. If you don't know what to put in the dependency array then just listen to Eslint. In most cases your effect is not supposed to create problems even it's called a lot.
Thank you for the article!
I've been working with React for the last 5 years. Previously I was working with Vue 2 and Angular.JS (first version). I'm really tired of React and it's ecosystem. Even now, with NextJS there still a lot of pain points at many levels. I've tried Vue 3 and Svelte for some of my pet project and that was amazing. Everything just works without any overwhelming nuances
When comparing technologies with regards to SSR, I suggest to test the following use case: render personalized content statically. Say a dark or light theme, translated content, a page personalized depending on your marketing segment, A/B tests... There are 2 approaches to achieve that:
- alter the render in middleware at the end of the request chain (Eleventy can do that)
- redirect the request to the right content depending on its content (like if the "theme" cookie is dark redirect to the dark rendered version of the page)
This is purely a server concern, you can also do that with HTML templates, but when you compare "metaframework" like say Astro, Next.js, SvelteKit I think that's relevant. My feeling is that the React ecosystem tends to be one step ahead in this area thanks to Next.js, eventhough I think there is room for progress (pre-rendering based on a cookie, a header or a search param is more difficult than it should).
That was an interesting read, but I have to disagree on many things that it would take a whole article to answer properly.
Of course I'm biased toward React, as the author of This Week In React.
To me, it's not fair to write an article like this without even mentioning any of these:
- React works on all platforms: web, desktop, video, 3D, terminal...
- React has concurrent features and UX benefits hard to measure with current performance tooling. We don't even benefit yet from all the architectural work they have made to enable Concurrent React, give it some time.
- React has Server Components: come on, you don't even mention that we are just entering the third era of React 🤷♂️
- React is getting closer to the web platform. Frameworks like Remix use web primitives extensively. Next.js is also moving in that direction. Even React core is currently working on Server Action primitives that enable progressive enhancement. Controlled forms are not particularly recommended anymore in the official docs
The way you see React seems a bit outdated to me, stuck somewhere in 2019-2022 after hooks were introduced. By not mentioning any new React innovation of course you can focus on where React does not shine.
If I wrote a blog post on how React 18 is better than Svelte 1.0, is it fair to you?
Something we can probably agree on: React does not have to be the best framework on the web to win, it only has to be good enough everywhere.
And I can agree that maybe there is a better option on the web today, or that there will be soon.
But come on, even if React is not the best web framework right now, it's still probably not as bad as you think if you take into account its recent and upcoming innovation, and all the other advantages you get using it: cross-platform, code sharing, hiring, a strong community...
@timw4mail started working on something that does exactly that, please check it out and let me know what you think https://github.com/joshamaju/hono-mvc
@slorber your points on server components and actions are actually a con imo
Thanks for the great article. There are a lot of important points in here, though I feel it's mostly coming from a developer perspective, rather than a business one. You say "I’ve come to believe React’s popularity is, in no small part, because folks don’t look beyond it" but that's not my experience at all. I've worked for various leading system integrators where the FE devs often advocate for other tools (or approaches) but when major businesses are about to invest millions in a replatform, they are risk averse and will opt for a tool or an econsystem that they feel has the most market share and offers the most stability, flexibility and longevity. To change this trend I think we need better business cases for tools like Svelte, that clearly show how it will speed up development, improve the UX and so on.
Thanks for this article. i think if you are choosing a framework. try not forget its ecosystem, your friends and application's performance requirements.
@slorber You’re right, it wasn’t fair at all to write the article without mentioning Concurrent React and RSC, which only add complexity and contribute to confusion and mental overload with literally zero benefit for the developer 😉
Sarcasm aside, one should always critically think about everything and not just blindly accept what a few people have chosen “to be right”.
If something works for you, then great! But that doesn’t mean it works (or will work) for other people. I’d say it’s still early to judge whether any of these are a good thing, or better yet, what use cases they are great for, no matter what the React team, Next.js team or whoever is saying.
Great article. As someone who spent eight years working in React, and the last two in Lit (and Web Components in general), I can provide a little insight into what parts of React you can replace with basic web component:
All of it.
My favorite memory of React, way back when I was learning, was this line: "You team might not benefit from React if 1) They already know HTML, 2) They already know CSS." That wasn't entirely true or fair, but it was close, especially for the younger developers.
It is true that standalone web components, driven entirely using attributes for getting information in and using the browser-native event system for getting information out (and therefore enforcing the one-way data flow, which I still think is useful for functionally-minded developers, the people like me who think Haskell and Lisp are cool), cannot replace React entirely.
Web Components are HTML components, objected-oriented as any DOM object; attributes that pass data in can only be strings. But there is a workaround: Lit uses "the properties compromise" very well; your state manager or orchestrator can hold references to the components for which it is responsible, and push complex objects to the fields of the child objects, which are identified with symbolic prefixes in the tag (. for "object", ? for "boolean"). Lit manages all that under the covers for a runtime cost of less than 5KB.
LitContext is a nifty work-around that makes the one-way data-flow easy; a parent object catches context mutation events; changes to the context are then sent to every object that needs to re-render with the new information. Optional lifecycle hooks in every child object can also intercept the change and determine if it really needs to be re-rendered, and in a way that's hella more intuitive than anything I recall from React.
It's straightforward, after understanding these basic concepts, to replace literally the whole of the React base ecosystem, at least on the client-rendering side. The "catch," if you can call it that, is that you have to really understand the platform, understand Node, DOMNode, Element, Event, CustomEvent, etc. You'll spend a lot of time inside MDN. But they are the native stuff, and the speed is mind-boggling once you get it.
All of it.
Learning Lit and Web components is something I would recommend to all web developers, it's extremely insightful. But I am very cautious on upbeat comments about replacing React (or whatever SPA-oriented JS framework) by Lit:
- try implementing a dark/light toggle with Lit. I can't find the link to Reddit new version with Lit back but that's the first thing I've checked and it was indeed not implemented
- try to access highlighted text reliably
- try to tell the cursor position in a text
- no SSR (work in progress though), and worse, component flicker when they load unless you had some CSS hack
- you need to be ready to install libs to pierce the shadow DOM in your fav testing tool (unless it's playwright)
- Lit won't remove newlines/spaces from their HTML template leading to surprising interactions with other libs ("normal" web components without string templates won't have this issue)
- No portals, tooltips
Lit maintainers are perfectly aware of all those issues, have solutions, and some may have been solved since the last time I've checked (earlier this year). Lit is a great options to write some part of the UI, you don't have to do everything in React, quite the contrary. But my point is that it's certainly not a drop-in replacement for React.
I'm primarily a back-end developer. When I do write JS and front-end stuff it's mostly to make ugly-but-functional working mockups of how to interact with the APIs I am building (when a simple documentation approach isn't enough; it turns out "when" equals "fairly often" once you get away from Just Plain CRUD stuff.)
I'd love it if someone could give me a pointer to a brief and coherent explanation of what problem 'state' is trying to solve. The state seems to be already right there in the DOM.
And don't point me to this guy:
https://gomakethings.com/state-based-ui-vs.-manual-dom-manipulation/
He's been very helpful on a lot of little JS things, but in the above document I read as far as the following and then gave up. If you really do have multiple forms and/or multiple submit buttons on the page, why on earth would you want to centralize all submissions only to have to separate them out again inside the callback?
document.addEventListener('submit', function (event) { ...
i.e. as opposed to
specific_button_reference.addEventListener('click', function (event) { ...
My uncertainty or confusion ultimately rests on this:
- JS provides an element listing every 'field' on the form. It's pretty darn easy to write a compact, generic function that serializes all the data (or, better yet, only the changed data) into either FormData or JSON.
- Every field, whether an input, select, or textarea, provides its own previous + current state.
- The previous-state attributes are writable, so on a successful Ajax or Fetch update, you can push the new current values back into defaultValue (etc.)
So what do I gain, besides complexity, from a separate state object with two-way data binding?
Oh, and my motivation for asking--anything to streamline the production of those 'ugly-but-functional working mockups' is of interest to me.