9 ms·

How I write React after 8 years

81 points by Fudgel 4y ago

Fudgel 4y ago
Mirror: https://scribe.rip/how-i-write-react-after-8-years-12cbf82c351 https://scribe.rip/how-i-write-react-after-8-years-12cbf82c3...
mikepasz 4y ago
Love to see Meteor still out there in the wild. We migrated about six years ago to Node/Express/Typescript/Postgres + React/Mobx and never looked back, but have fond memories w/ the Meteor magic - not so much of Mongo :)
- 015a 4y ago
  Agreed; nothing in JS has hit the level of productivity I got with Meteor, and while its still going along, its pretty sad that it (or its ideas) didn't catch on.
  - sergiotapia 4y ago
    They mistakenly tried to support every frontend under the sun and not even bother shipping a router with their fullstack framework. Crazy in hindsight! If only they focus on React and included a default vetted router, Meteor would probably still be thriving today. Instead they tried to please everybody and ended up satisfying nobody. MDG ultimately pivoted to Apollo and _that_ stuck like glue everywhere, so I am happy they ultimately found success. I still miss Meteor though, it was so stupidly productive early on.
- eyelidlessness 4y ago
  > not so much of Mongo So, the Meteor magic was just not thinking about await?
  - dham 4y ago
    Meteor predates Promises and Async/Await. You have to remember at the time all you had was callbacks and async.js to manage them. There was Bluebird around 2014 but Meteor was even before that. Meteor uses node-fiber, I assume it still does, but it was very "non-standard" at the time and definitely now. You rarely saw it in any codebase.
    - eyelidlessness 4y ago
      I’m well aware of Fibers, and the big async API kerfuffle of 200*s! I was amused to see Q pop up unmentioned in git blames just today. I’d be curious if Fibers would find adoption if it were introduced today. I suspect yes, with much regret because knowing when functions suspend is not something people would give up knowing the implications.
AirMax98 4y ago
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.
- jgalt212 4y ago
  > writing your own date picker That's a good one. The next time I run into my competitors at a trade show, I'll be sure to recommend they do this.
- phendrenad2 4y ago
  Several years ago I tried to find a good date and time picker, but most were rather bad, and I had to heavily modify a date picker to add time to it. I assume that things are better now.
  - pamelafox 4y ago
    The web has it built in now! Try input type=“date”
  - bigDinosaur 4y ago
    It's not much better now afaik. I still just default to using separate fields for day/month/year etc. If anything good and fully accessible/mobile friendly/etc. exists I'd be happy to know. The browser native solutions have never been very good as well.
- usrusr 4y ago
  But implementing a date picker UI isn't hard at all. If you have some particular extra requirement or a novel idea, go for it. That's also what front-end devs are for, reinvent UI for, I don't know, reasons. Just, I certainly agree in this point, just leave the management of leap years to the date data type of the platform. Don't ever, not for a second (leap or not), think that += 24*60*60*1000 could be acceptable. But chances are you'd be far more aware of that wrongness while throwing together some novel date picker than anywhere else you might be tempted, where usually the peculiarities of calendar are far out of scope.
dham 4y ago
Almost 100% of this post is completely wrong. Don't use 3rd party libraries: NIH syndrome is plaguing our industry like a disease already. Can'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 Forms don’t have to suck: Just use hook form, or use uncontrolled forms. Or better yet if you have a simple form don't use a frontend library at all. Any component that expects a state has a hook: Please God no. Write code. When you write it 3 times abstract it. CSS: Use styled components: No Components: No, use flat file structure. Don't use the whole Folder/index mess. It's a nightmare. Just do Button.tsx, UserFeed.txt / etc. Put components next to feature unless they're generic. Just use tailwind. Split the routes using loadable components or the equivalent in Next: Ok. Folder Structures: No Decoupling logic from components: 100% never do this. Ever. Native like Page Transition: No. Don't use animations for page transitions on web or PWA's. Those are reserved for actual native apps. Context’s: Don't use Context, unless it'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's extremely slow and outdated way of rendering. Alternative: Use react-query for most date fetching / global state.
- hunterb123 4y ago
  I disagree with most of what you said (as well as most of the opinions in the article) I'm sure you have your reasons for your opinions, but you didn't define them, you just said "no this, trust me" essentially. You did expand on usage of the Context API but I agree with your opinion already on that one.
  - llanowarelves 4y ago
    I agree with him but if he wanted to go more in-depth it might spawn a whole article (which I'd read)
- djbusby 4y ago
  Holup. React is slow and outdated for rendering? I thought one of the big selling points was VDOM and it improves rendering speed. (Can you tell I don't use react?)
aporetics 4y ago
Yes, your component is compromised (sic)
TameAntelope 4y ago
> Don’t use (almost) any libraries I will not hire someone who holds this view, straight up. It's the only technical belief (aside from crazy things like don'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. It'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 huge, bright red flag when it comes to working with others on the team. 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's unacceptable.
- nkozyra 4y ago
  Plus "Most libraries are crap, they are written by junior developers." is nonsense and cannot be validated. I definitely agree with being conservative about what you use but writing almost everything yourself is a disaster waiting to happen.
  - asaph 4y ago
    Sturgeon’s Law[0] states that “90 percent of everything is crap.” [0] https://en.m.wikipedia.org/wiki/Sturgeon%27s_law https://en.m.wikipedia.org/wiki/Sturgeon%27s_law
- andrewmcwatters 4y ago
  Most React development is comprised of using React and Fetch.
  - eyelidlessness 4y ago
    Weird. From my perspective most React development is comprised of finding the most expressive way to use Algebraic Effects where the language wasn’t designed for it
    - Gravyness 4y ago
lioeters 4y ago
Agree: - Don’t use (almost) any libraries - 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 - Centralizing API calls in one place - Decoupling logic from components - Any component that expects a state has a hook - Components with index.js and index.scss Less agree: - CSS: Use styled components - I prefer Sass, CSS modules, Tailwind (gradually moving to latter) - Route-based folder structure - Yes but more feature-based structure - Native like Page Transition - Meh, not worth it unless done really well to improve UX - Context - Never needed it
- dham 4y ago
  > 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 You've just reinvented Redux, except worse in every way. Just use Redux toolkit.
  - deleted 4y ago
    [deleted]
- schwartzworld 4y ago
  > one-directional data flow and UI as (mostly pure) function of state This is a fundamental react principal as well. It's how I wouod explain react to a newbie.
  - WorldMaker 4y ago
    That's also the impetus that led to flow/relay "architecture" that led to redux in the first place. Possibly a reason such tools will continue to be reinvented every so often in React. React is a flat circle.
_fat_santa 4y ago
It's almost funny how he starts off the article by saying he doesn'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. I'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.
- rtsil 4y ago
  And when I have to modify the code a couple of years down the road, after working on completely different codebases, I would hate my past self if he left me 100 LOC that I have then to decypher by having to remember all the context instead of the 5 lines of a well-documented library.
- maxxk 4y ago
  However, these 100 LOC probably could be split into an internal library function which won't change until necessary. If you use an external library (especially in JS and especially in frontend), you or your successor will have to update all these 5 LOC entries all over the code every 1-1.5 years in a non-trivial way when a new major version arrives. For example, the migration guide for react-query: https://tanstack.com/query/v4/docs/guides/migrating-to-react-query-4 https://tanstack.com/query/v4/docs/guides/migrating-to-react...
  - bartaxyz 4y ago
    That's why you can use fixed library versions to make sure nothing changes. If you need to update something in the library, you can apply a patch and keep going.
- serjester 4y ago
  It’s funny he mentions most libraries being written by junior developers looking to beef up their resume. Even if we assume this is true, you’ll get some other junior developer writing the same functionality at your company. Except now they have no tangible incentive to write maintainable code.
- 4y ago
jupp0r 4y ago
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).
ranman 4y ago
> don't use (almost) any libraries Proceeds to recommend several libraries. Unfortunately the opinions in this post are an odd mix of correct, incorrect, or irrelevant.
gbro3n 4y ago
This and the many of the comments here are what keeps me away from react. There are too many ways to skin this cat.
- pkstn 4y ago
  100 % agree, react is so horrible
  - selfmodruntime 4y ago
    It‘s the best current solution by a mile and has conquered the front-end app world like a storm. It generates billions of networth a year. It enables startups to quickly put out working products.
- fckthisguy 4y ago
  Honestly, give it a go. There's a few (a dozen or so) stylistic choices to make but it's mostly the same and standards are shared across the community far more than HTML+CSS / Angular .NET in my experience.
ricardobeat 4y ago
> The only reason people use redux is that they want a sharable state across the app 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. > React is fast by default 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.
- deleted 4y ago
  [deleted]
- collegeburner 4y ago
  any tips or resources you seen good for optimizing react?
  - acemarke 4y ago
    Generally: - Use the React DevTools Profiler to identify components that are rendering more than expected, or taking too long to render - Wrap key components in `React.memo()` to have React avoid recursing through those subtrees unless the component props have actually changed - Avoid putting large state objects into a single context provider, as all components reading that context will re-render whenever it changes (and all of their children too) - Use `useMemo` to cache any expensive transformations that happen during rendering I've got an extensive post that covers how rendering works as a whole, and has a section on understanding React perf optimizations: - 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-...
- brhsagain 4y ago
  That doesn't entirely contradict the author's statement. Redux may do all of those things, but the proximate need of most people who use Redux is sharable state. Then they use something like Redux because it provides "structure" and has lots of stars on Github. Incidentally, I have to agree with the author directionally on this point. Redux makes codebases such a pain in the ass to work with. Every new change you want to make to the store, you have to make about five changes across five different files. When you're working on a new feature you spend most of your time just wrestling with Redux, creating an action type, creating an action creator, creating a reducer, importing/exporting all this shit, blah blah blah. Then a new engineer who wants to figure out what the code is actually doing has to trace through the action, then the action creator, then the reducer, blah blah. This is before you throw in stuff like epics and run API calls through your action/reducer pipeline. It is no wonder productivity per capita in tech is so low.
preommr 4y ago
A really big problem with web app dev is that it covers a very broad area. 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. And then there's all the decisions (like a date picker) where it can go either way.
- likortera 4y ago
  Of you are not using libraries, the smallest of the projects will become a large scale project. I prefer having to keep up to date with libraries than having to deal with tons of some "smart ass" reinvention of the wheel that doesn't have documentation and tests and it's full of bugs and corner cases. The code you write yourself also requires maintenance.
solomatov 4y ago
I would replace don'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.
efficax 4y ago
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
- dham 4y ago
  The index.js thing is a very bizarre thing that I think is result of people not knowing how to use an editor. Literally just use a flat directory and use your editor to group / roll up the files in a directory. Button.tsx Button.spec.tx Button.css
plitarko 4y ago
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.
kypro 4y ago
Lots of opinions here, both in the post and the comments. The only opinion I'll give is that if you think there's a right way to do anything all of the time, your opinion is probably wrong. Every project is different. Just on the to use / 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're writing frontend code you'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. A good developer is one that understands these trade-offs and considers them in the context of the project's objectives. Hell, sometimes it's not even about the project, but just developer preference. There have been times I've done things in ways I don't like simply because I know it's the way the most of my team prefer.
ttfkam 4y ago
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. const [count, setCount] = useState(0); And that's after the import and wrapping in a function (sorry, "hook"). For a variable. A single variable. Every. Single. "Reactive" variable. To which there's also rxJS and its observables. 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'm not saying we should go back. Again, React and the others were created for very good reasons. let count = 0; That'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't care if Svelte specifically "wins", but that model needs to prevail. Otherwise we'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.
5350-uiop-1130 4y ago
every javascript discussion also ends up as a long series of ackchyually(ies)
dikaio 4y ago
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.

81 points by Fudgel 4y ago

Mirror: https://scribe.rip/how-i-write-react-after-8-years-12cbf82c351 https://scribe.rip/how-i-write-react-after-8-years-12cbf82c3...

mikepasz 4y ago

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

015a 4y ago
Agreed; nothing in JS has hit the level of productivity I got with Meteor, and while its still going along, its pretty sad that it (or its ideas) didn't catch on.
- sergiotapia 4y ago
  They mistakenly tried to support every frontend under the sun and not even bother shipping a router with their fullstack framework. Crazy in hindsight! If only they focus on React and included a default vetted router, Meteor would probably still be thriving today. Instead they tried to please everybody and ended up satisfying nobody. MDG ultimately pivoted to Apollo and _that_ stuck like glue everywhere, so I am happy they ultimately found success. I still miss Meteor though, it was so stupidly productive early on.
eyelidlessness 4y ago
> not so much of Mongo So, the Meteor magic was just not thinking about await?
- dham 4y ago
  Meteor predates Promises and Async/Await. You have to remember at the time all you had was callbacks and async.js to manage them. There was Bluebird around 2014 but Meteor was even before that. Meteor uses node-fiber, I assume it still does, but it was very "non-standard" at the time and definitely now. You rarely saw it in any codebase.
  - eyelidlessness 4y ago
    I’m well aware of Fibers, and the big async API kerfuffle of 200*s! I was amused to see Q pop up unmentioned in git blames just today. I’d be curious if Fibers would find adoption if it were introduced today. I suspect yes, with much regret because knowing when functions suspend is not something people would give up knowing the implications.

AirMax98 4y ago

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.

jgalt212 4y ago
> writing your own date picker That's a good one. The next time I run into my competitors at a trade show, I'll be sure to recommend they do this.
phendrenad2 4y ago
Several years ago I tried to find a good date and time picker, but most were rather bad, and I had to heavily modify a date picker to add time to it. I assume that things are better now.
- pamelafox 4y ago
  The web has it built in now! Try input type=“date”
- bigDinosaur 4y ago
  It's not much better now afaik. I still just default to using separate fields for day/month/year etc. If anything good and fully accessible/mobile friendly/etc. exists I'd be happy to know. The browser native solutions have never been very good as well.
usrusr 4y ago
But implementing a date picker UI isn't hard at all. If you have some particular extra requirement or a novel idea, go for it. That's also what front-end devs are for, reinvent UI for, I don't know, reasons. Just, I certainly agree in this point, just leave the management of leap years to the date data type of the platform. Don't ever, not for a second (leap or not), think that += 24*60*60*1000 could be acceptable. But chances are you'd be far more aware of that wrongness while throwing together some novel date picker than anywhere else you might be tempted, where usually the peculiarities of calendar are far out of scope.

dham 4y ago

Almost 100% of this post is completely wrong. Don't use 3rd party libraries: NIH syndrome is plaguing our industry like a disease already. Can'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 Forms don’t have to suck: Just use hook form, or use uncontrolled forms. Or better yet if you have a simple form don't use a frontend library at all. Any component that expects a state has a hook: Please God no. Write code. When you write it 3 times abstract it. CSS: Use styled components: No Components: No, use flat file structure. Don't use the whole Folder/index mess. It's a nightmare. Just do Button.tsx, UserFeed.txt / etc. Put components next to feature unless they're generic. Just use tailwind. Split the routes using loadable components or the equivalent in Next: Ok. Folder Structures: No Decoupling logic from components: 100% never do this. Ever. Native like Page Transition: No. Don't use animations for page transitions on web or PWA's. Those are reserved for actual native apps. Context’s: Don't use Context, unless it'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's extremely slow and outdated way of rendering. Alternative: Use react-query for most date fetching / global state.

hunterb123 4y ago
I disagree with most of what you said (as well as most of the opinions in the article) I'm sure you have your reasons for your opinions, but you didn't define them, you just said "no this, trust me" essentially. You did expand on usage of the Context API but I agree with your opinion already on that one.
- llanowarelves 4y ago
  I agree with him but if he wanted to go more in-depth it might spawn a whole article (which I'd read)
djbusby 4y ago
Holup. React is slow and outdated for rendering? I thought one of the big selling points was VDOM and it improves rendering speed. (Can you tell I don't use react?)

aporetics 4y ago

Yes, your component is compromised (sic)

TameAntelope 4y ago

> Don’t use (almost) any libraries I will not hire someone who holds this view, straight up. It's the only technical belief (aside from crazy things like don'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. It'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 huge, bright red flag when it comes to working with others on the team. 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's unacceptable.

nkozyra 4y ago
Plus "Most libraries are crap, they are written by junior developers." is nonsense and cannot be validated. I definitely agree with being conservative about what you use but writing almost everything yourself is a disaster waiting to happen.
- asaph 4y ago
  Sturgeon’s Law[0] states that “90 percent of everything is crap.” [0] https://en.m.wikipedia.org/wiki/Sturgeon%27s_law https://en.m.wikipedia.org/wiki/Sturgeon%27s_law
andrewmcwatters 4y ago
Most React development is comprised of using React and Fetch.
- eyelidlessness 4y ago
  Weird. From my perspective most React development is comprised of finding the most expressive way to use Algebraic Effects where the language wasn’t designed for it
  - Gravyness 4y ago

lioeters 4y ago

Agree: - Don’t use (almost) any libraries - 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 - Centralizing API calls in one place - Decoupling logic from components - Any component that expects a state has a hook - Components with index.js and index.scss Less agree: - CSS: Use styled components - I prefer Sass, CSS modules, Tailwind (gradually moving to latter) - Route-based folder structure - Yes but more feature-based structure - Native like Page Transition - Meh, not worth it unless done really well to improve UX - Context - Never needed it

dham 4y ago
> 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 You've just reinvented Redux, except worse in every way. Just use Redux toolkit.
- deleted 4y ago
  [deleted]
schwartzworld 4y ago
> one-directional data flow and UI as (mostly pure) function of state This is a fundamental react principal as well. It's how I wouod explain react to a newbie.
- WorldMaker 4y ago
  That's also the impetus that led to flow/relay "architecture" that led to redux in the first place. Possibly a reason such tools will continue to be reinvented every so often in React. React is a flat circle.

_fat_santa 4y ago

It's almost funny how he starts off the article by saying he doesn'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. I'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.

rtsil 4y ago
And when I have to modify the code a couple of years down the road, after working on completely different codebases, I would hate my past self if he left me 100 LOC that I have then to decypher by having to remember all the context instead of the 5 lines of a well-documented library.
maxxk 4y ago
However, these 100 LOC probably could be split into an internal library function which won't change until necessary. If you use an external library (especially in JS and especially in frontend), you or your successor will have to update all these 5 LOC entries all over the code every 1-1.5 years in a non-trivial way when a new major version arrives. For example, the migration guide for react-query: https://tanstack.com/query/v4/docs/guides/migrating-to-react-query-4 https://tanstack.com/query/v4/docs/guides/migrating-to-react...
- bartaxyz 4y ago
  That's why you can use fixed library versions to make sure nothing changes. If you need to update something in the library, you can apply a patch and keep going.
serjester 4y ago
It’s funny he mentions most libraries being written by junior developers looking to beef up their resume. Even if we assume this is true, you’ll get some other junior developer writing the same functionality at your company. Except now they have no tangible incentive to write maintainable code.
4y ago

jupp0r 4y ago

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).

ranman 4y ago

> don't use (almost) any libraries Proceeds to recommend several libraries. Unfortunately the opinions in this post are an odd mix of correct, incorrect, or irrelevant.

gbro3n 4y ago

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

pkstn 4y ago
100 % agree, react is so horrible
- selfmodruntime 4y ago
  It‘s the best current solution by a mile and has conquered the front-end app world like a storm. It generates billions of networth a year. It enables startups to quickly put out working products.
fckthisguy 4y ago
Honestly, give it a go. There's a few (a dozen or so) stylistic choices to make but it's mostly the same and standards are shared across the community far more than HTML+CSS / Angular .NET in my experience.

ricardobeat 4y ago

> The only reason people use redux is that they want a sharable state across the app 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. > React is fast by default 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.

deleted 4y ago
[deleted]
collegeburner 4y ago
any tips or resources you seen good for optimizing react?
- acemarke 4y ago
  Generally: - Use the React DevTools Profiler to identify components that are rendering more than expected, or taking too long to render - Wrap key components in `React.memo()` to have React avoid recursing through those subtrees unless the component props have actually changed - Avoid putting large state objects into a single context provider, as all components reading that context will re-render whenever it changes (and all of their children too) - Use `useMemo` to cache any expensive transformations that happen during rendering I've got an extensive post that covers how rendering works as a whole, and has a section on understanding React perf optimizations: - 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-...
brhsagain 4y ago
That doesn't entirely contradict the author's statement. Redux may do all of those things, but the proximate need of most people who use Redux is sharable state. Then they use something like Redux because it provides "structure" and has lots of stars on Github. Incidentally, I have to agree with the author directionally on this point. Redux makes codebases such a pain in the ass to work with. Every new change you want to make to the store, you have to make about five changes across five different files. When you're working on a new feature you spend most of your time just wrestling with Redux, creating an action type, creating an action creator, creating a reducer, importing/exporting all this shit, blah blah blah. Then a new engineer who wants to figure out what the code is actually doing has to trace through the action, then the action creator, then the reducer, blah blah. This is before you throw in stuff like epics and run API calls through your action/reducer pipeline. It is no wonder productivity per capita in tech is so low.

preommr 4y ago

A really big problem with web app dev is that it covers a very broad area. 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. And then there's all the decisions (like a date picker) where it can go either way.

likortera 4y ago
Of you are not using libraries, the smallest of the projects will become a large scale project. I prefer having to keep up to date with libraries than having to deal with tons of some "smart ass" reinvention of the wheel that doesn't have documentation and tests and it's full of bugs and corner cases. The code you write yourself also requires maintenance.

solomatov 4y ago

I would replace don'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.

efficax 4y ago

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

dham 4y ago
The index.js thing is a very bizarre thing that I think is result of people not knowing how to use an editor. Literally just use a flat directory and use your editor to group / roll up the files in a directory. Button.tsx Button.spec.tx Button.css

plitarko 4y ago

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.

kypro 4y ago

Lots of opinions here, both in the post and the comments. The only opinion I'll give is that if you think there's a right way to do anything all of the time, your opinion is probably wrong. Every project is different. Just on the to use / 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're writing frontend code you'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. A good developer is one that understands these trade-offs and considers them in the context of the project's objectives. Hell, sometimes it's not even about the project, but just developer preference. There have been times I've done things in ways I don't like simply because I know it's the way the most of my team prefer.

ttfkam 4y ago

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. const [count, setCount] = useState(0); And that's after the import and wrapping in a function (sorry, "hook"). For a variable. A single variable. Every. Single. "Reactive" variable. To which there's also rxJS and its observables. 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'm not saying we should go back. Again, React and the others were created for very good reasons. let count = 0; That'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't care if Svelte specifically "wins", but that model needs to prevail. Otherwise we'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.

5350-uiop-1130 4y ago

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

dikaio 4y ago

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.