How I write React after 8 years

&gt; The only reason people use redux is that they want a sharable state across the app<p>No. You can do that with a global variable. Redux’s main features are serializable actions, serializable state, plus localized updates if you use immutable data. It gives you the ability to throw your state at localstorage, send actions over a websocket, easily traverse history (undo, time travel) and keep a log of changes. It’s ok to not need any of this, most projects don’t, but at least write off the library for the correct reasons.<p>&gt; React is fast by default<p>Also not true. React does basically no optimization at all besides batching state updates. Your computer is just fast enough that you’ll think it doesn’t matter until it’s too late. Optimizing rendering is 100% on the application author.

It&#x27;s almost funny how he starts off the article by saying he doesn&#x27;t use libraries, then shows you a function for an API call he wrote that is ~100 LOC. Had this guy pulled in something like react-query, he could have written that entire hook in about 5 LOC.<p>I&#x27;d rather write 5 lines of code using a library that I might have to replace later than write 100 line of code to future proof my function from the start.

Lots of opinions here, both in the post and the comments.<p>The only opinion I&#x27;ll give is that if you think there&#x27;s a right way to do anything all of the time, your opinion is probably wrong.<p>Every project is different. Just on the to use &#x2F; not to use libraries bit, most of the time you probably want to optimise for fewer lines of code (assuming you can find a decent library that does what you want). However, sometimes if you&#x27;re writing frontend code you&#x27;ll want to optimise for other things like bundle size, browser support or performance. In which case you might actually want to write something in 50 lines, instead of a library import + 10 lines, because that import might add 200kbs to your bundle or not support IE properly.<p>A good developer is one that understands these trade-offs and considers them in the context of the project&#x27;s objectives. Hell, sometimes it&#x27;s not even about the project, but just developer preference. There have been times I&#x27;ve done things in ways I don&#x27;t like simply because I know it&#x27;s the way the most of my team prefer.

Lots of good ideas here but writing your own date picker — both suggested and pictured — is just a silly idea. As a front end dev you are in the business of making products, not managing leap years.

A really big problem with web app dev is that it covers a very broad area.<p>Advice like not using libraries will have very polarized reactions (as evidenced by this thread) based on what kind of goals people are working on. Some react projects are very short lived so common problems like a library no longer being maintained are a non-factor. For large scale projects, typing loc is not a bottle neck, changing a foundational library that everything is based on is a potential massive timebomb.<p>And then there&#x27;s all the decisions (like a date picker) where it can go either way.

I hate React. I fully understand why it was created and how it normalized data binding with HTML through the virtual DOM, but it (and Angular and Vue and so many others) are like building skyscrapers on a bed of sand.<p>const [count, setCount] = useState(0);<p>And that&#x27;s after the import and wrapping in a function (sorry, &quot;hook&quot;). For a variable. A single variable. Every. Single. &quot;Reactive&quot; variable. To which there&#x27;s also rxJS and its observables.<p>Can you build bigger things more cleanly than with vanilla JS? Arguably, yes. I came up when the web was new, before JQuery and Prototype. I remember the chaos. I&#x27;m not saying we should go back. Again, React and the others were created for very good reasons.<p>let count = 0;<p>That&#x27;s what I want: to bind that to a tag and walk away. For that, you need a compiler. Not the JSX nonsense and TypeScript transpilation, a real compiler. Like Svelte. I honestly don&#x27;t care if Svelte specifically &quot;wins&quot;, but that model needs to prevail. Otherwise we&#x27;ll just keep building on sand and wondering why the code turns to crap every two years as new folks are added to the team and old ones leave after the React team decides functions are better than classes after all.

Agree:<p>- Don’t use (almost) any libraries<p>- Redux is scrap - These days I use hooks and a tiny store with Immer, but I carry the golden lesson from Redux about one-directional data flow and UI as (mostly pure) function of state<p>- Centralizing API calls in one place<p>- Decoupling logic from components<p>- Any component that expects a state has a hook<p>- Components with index.js and index.scss<p>Less agree:<p>- CSS: Use styled components - I prefer Sass, CSS modules, Tailwind (gradually moving to latter)<p>- Route-based folder structure - Yes but more feature-based structure<p>- Native like Page Transition - Meh, not worth it unless done really well to improve UX<p>- Context - Never needed it

So…. The author doesn’t use any libraries, hates libraries but uses libraries especially for forms and oh yeah many other things that make his job better… I’m lost.

This and the many of the comments here are what keeps me away from react. There are too many ways to skin this cat.

what is it about frontend that people have such strong but different opinions? it’s so strange. i think almost everything here is wrong, redux is good, index.js is cursed (love to have five tabs in my editor with the same name, very helpful), and so on. but why does frontend provoke such weird and narrow holy wars

I stopped reading at the first code sample, which contained a singleton. My impression up to that point was that the author did not understand how redux works and what it is for (its purpose is not sharing state across the app).

&gt; don&#x27;t use (almost) any libraries<p>Proceeds to recommend several libraries.<p>Unfortunately the opinions in this post are an odd mix of correct, incorrect, or irrelevant.

Love to see Meteor still out there in the wild. We migrated about six years ago to Node&#x2F;Express&#x2F;Typescript&#x2F;Postgres + React&#x2F;Mobx and never looked back, but have fond memories w&#x2F; the Meteor magic - not so much of Mongo :)

Mirror: <a href="https:&#x2F;&#x2F;scribe.rip&#x2F;how-i-write-react-after-8-years-12cbf82c351" rel="nofollow">https:&#x2F;&#x2F;scribe.rip&#x2F;how-i-write-react-after-8-years-12cbf82c3...</a>

I would replace don&#x27;t use any libraries with properly vet the libraries which you want to use (in any language). Having a dependency has its costs and benefits, and you should weight these against each other.

every javascript discussion also ends up as a long series of ackchyually(ies)

Agreed, component libraries are for freelancers who need to satisfy a client with limited technical knowledge and not for serious businesses with large development teams.

Yes, your component is compromised (sic)

Almost 100% of this post is completely wrong.<p>Don&#x27;t use 3rd party libraries: NIH syndrome is plaguing our industry like a disease already. Can&#x27;t wait until companies realize they need half the devs they do now. Our industry needs a wake up call, especially for immature developers who waste company money<p>Forms don’t have to suck: Just use hook form, or use uncontrolled forms. Or better yet if you have a simple form don&#x27;t use a frontend library at all.<p>Any component that expects a state has a hook: Please God no. Write code. When you write it 3 times abstract it.<p>CSS: Use styled components: No<p>Components: No, use flat file structure. Don&#x27;t use the whole Folder&#x2F;index mess. It&#x27;s a nightmare. Just do Button.tsx, UserFeed.txt &#x2F; etc. Put components next to feature unless they&#x27;re generic. Just use tailwind.<p>Split the routes using loadable components or the equivalent in Next: Ok.<p>Folder Structures: No<p>Decoupling logic from components: 100% never do this. Ever.<p>Native like Page Transition: No. Don&#x27;t use animations for page transitions on web or PWA&#x27;s. Those are reserved for actual native apps.<p>Context’s: Don&#x27;t use Context, unless it&#x27;s literally for if the user is logged in. Everything else should use some kind of 3rd party library (Mobx, Redux, Recoil, Zustand) that uses subscriptions to circumvent React&#x27;s extremely slow and outdated way of rendering. Alternative: Use react-query for most date fetching &#x2F; global state.

&gt; Don’t use (almost) any libraries<p>I will not hire someone who holds this view, straight up. It&#x27;s the only technical belief (aside from crazy things like don&#x27;t care about quality) I can think of that would instantly disqualify a candidate in my mind. Everything else feels negotiable and perspective-relevant, but not this.<p>It&#x27;s such a massive waste of time to try and rewrite functionality that already exists elsewhere, and an inability to trust other people is a <i>huge</i>, bright red flag when it comes to working with others on the team.<p>Being very selective of which libraries you use? Sure, fair. We can talk about various lines and where to draw them, but categorically denying library use? That&#x27;s unacceptable.