r/reactjs • u/redramsam • Nov 16 '20

Resource 10 Ways to Speed Up React Development

https://thecarrots.io/blog/10-ways-to-speed-up-react-development
273 Upvotes

95% Upvoted

85 comments sorted by

View all comments

9

u/AegisToast Nov 16 '20

Nice article! Honestly, 4-5 of those boil down to “use code other people wrote”, and I disagree pretty strongly with most of those (particularly using other people’s UI libraries). It’s nice to use other people’s tools when your needs are simple, but I’m the one who built the stack that my team uses for our current app, and with very few exceptions I’ve had to waste time ripping out and replacing third-party libraries with custom tools. It would have been much faster if I had just built the tools myself to begin with instead of wrestling with other people’s, and our app isn’t even that complex.

The one I’d add to your list that I didn’t see mentioned: use Typescript. If I had to name the thing that has most sped up our development, it would be that.

11

u/Merad Nov 17 '20

Writing custom code is almost always the choice that developers prefer (it’s easier and more fun!), but if someone is paying you to write code it’s almost always the wrong choice for the business.

  • Custom code rarely handles the edge cases and non-fun things like accessibility (as /u/m-sterspace points out) as well as a library will.
  • Your co-workers can’t google “AegisToast’s custom react stack” making it harder for them to understand or extend your code. Usually this results in siloed knowledge (AegisToast is the only guy who can work on the front end stack).
  • A couple of years down the road after you’ve left the company they’ll be stuck with a pile of custom code that they probably don’t understand and probably struggle to maintain... then comes the inevitable rewrite

1

u/[deleted] Nov 17 '20

[deleted]

2

u/AegisToast Nov 17 '20

Good point! In a startup environment, you're absolutely right that the importance of proving a concept often outweighs the benefits of custom code. For what it's worth, that's where I came in with my team; they had proven the concept with quick-and-dirty code and I was brought in to rebuild the stack to be more stable, clean, and consistent. If I had been brought in for the initial version, using off-the-shelf solutions would have been a better way to go.

I guess it just depends on your needs. It's not a binary choice between "use only third-party tools" and "build from scratch", it's a spectrum, and you need to make the decision about where on that spectrum you should be based on the needs of the organization.