Dan Abramov & Joe Savona from the React Team join Jerod & Nick for a wide-ranging discussion about React’s place in the frontend ecosystem. We cover everything from React competing with React, their responses to SPA fatigue and recent criticisms, to Server Components and the future of the framework.
Dan Abramov cuts right to the chase:
Have you heard the story about the boy who cried wolf? Spoiler alert: the wolf eats the sheep. If we don’t want our sheep to be eaten, we need better tools.
As of today,
npm auditis a stain on the entire npm ecosystem. The best time to fix it was before rolling it out as a default. The next best time to fix it is now.
He goes on to lay out how it works, why it’s broken, and what changes he’s hoping to see.
Dan Abramov on the dangers of doing DRY wrong:
Obsessing with “clean code” and removing duplication is a phase many of us go through. When we don’t feel confident in our code, it is tempting to attach our sense of self-worth and professional pride to something that can be measured. A set of strict lint rules, a naming schema, a file structure, a lack of duplication.
First you have to learn the rule of writing software. Then you have to learn how and when to let go of the rules.
Like so many of Dan Abramov’s posts, this blew my mind. He is incredible at breaking down complicated concepts and making them understandable, as well as showing the reasons behind the concepts. Should you read this post? I’d say yes, but Dan would say:
If you’re the kind of person who likes to learn about programming ideas several years before they hit the mainstream, it might be a good time to get curious about algebraic effects. Don’t feel like you have to though. It is a bit like thinking about async / await in 1999.
This post from Dan Abramov about why he moved off Medium summarizes both why we’re no longer linking to Medium and why we’ve never put our content there.
Some of my Medium articles unexpectedly got behind a paywall. I’m not sure what happened and whether that’s still the case. But I didn’t do it myself, and that caused a blow to my confidence in Medium as a platform. I respect their need to monetize, but it felt wrong when done retroactively.
At a 37 minute read time, this post from Dan Abramov on using React as a programming runtime is near book length and will give you a deeper understanding of React “than 90% of its users.”
We’ve touched on pretty much all important aspects of the React runtime environment. If you finished this page, you probably know React in more detail than 90% of its users. And there’s nothing wrong with that!
Dan Abramov, writing for Increment:
The documentation for “adding React to existing app” was updated this week by Dan Abramov to make the installation of React into any website a much simpler process.
Dan writes in the opening paragraphs of the updated docs.
React has been designed from the start for gradual adoption. You can use as little or as much React as you need. Perhaps you only want to add some “sprinkles of interactivity” to an existing page. React components are a great way to do that.
The majority of websites aren’t, and don’t need to be, single-page apps. With a few lines of code and no build tooling, try React in a small part of your website. You can then either gradually expand its presence, or keep it contained to a few dynamic widgets.
Here’s the GitHub issue that kicked things off which might provide a slight bit more context.
In this episode Michael Jackson talks with Dan Abramov, author of Redux and create-react-app, about the responsibility that comes with being an influential voice for React, how future versions of React will leverage requestIdleCallback to schedule work, and the possibility of a future API for React that makes it easier to do async work.