React.js is perhaps one of the most controversial topics among web developers in recent years. Some love it, some hate it, some can't live without it. This post aims to toe the line of both sides as I share my experience thus-far and explain what I learned by converting my React-based portfolio back to a bog-standard HTML/CSS/JavaScript page.
Strap in, this might be a long one...
The Alluring Trap of React
So you're like myself, a freshly self-taught developer who has spent months years working from the ground up, building your development knowledgebase and skillset from absolutely nothing. HTML and CSS are finally your bread-and-butter, you can craft a stylish (albeit plain-as-a-pancake) TO-DO list in no time flat. With your rudimentary JavaScript knowledge, you've made it interactive, perhaps it even talks to an Express server for that extra zest.
Now what?
Back to the land of tutorial-hell to try and pick up the next tool for your belt. You really enjoy the logical programming paradigms you learned in vanilla JavaScript, so you venture down that rabbit hole once again, this time looking to learn a framework. You quickly smash the keywords into Google.
best javascript framework to get rich quick
Instantly, you're bombarded with a never-ending wall of different catchy names and logos, but one stands out among the crowd, a sleek light-blue atom... it's calling to you, promising you fame, promising fortune... promising the future...
TIME MACHINE ENGAGED!
Six long months have passed. You've watched endless YouTube tutorial videos and read various blog posts about React and its many spinoff-frameworks. You're now able to wield Hooks
and Context Providers
like it's nobody's business. You've even assembled an impressive (at least to the lay-person) catalogue of React-based applications. Time to share your new-found mastery with the world, time to bring your personal portfolio into THE FUTURE™.
The next few months are spent designing and building the most incredible site you've created to date. I'm talking a global Context system, real-time updated personal stats from your npm and GitHub profiles (with lazy-loaded components!), and it's even got a custom Context-based multi-theme UI framework you built to drastically reduce the amount of CSS you need to write and load in. You're convinced it's the second coming, or at least the third.
Head now properly over-inflated, you decide to share your creation with your favorite online community to get some proper feedback.
Feedback quickly rolls in... It's got potential they say, but falls well short of expectations. Lethal bugs are discovered that you overlooked. Questionable design choices are picked apart. The worst part of all, your page's Lighthouse Performance Score on anything but your own machine SUCKS. It stings, but don't forget... you literally asked for this.
What Went Wrong?
Well, it turns out that the foundation of your website is made of some sort of radioactive (React's logo is an atom, get it? Get it...?) elements. And such as irradiated things tend to do, a tumor had quietly begun to grow at the heart of your project. A nasty little bugger known as the node_modules
directory, and it was sapping the life out of your pride-and-joy.
If you're not aware, React applications are based on the idea of building your project by cobbling together bits and pieces of open-source code in the form of modules to bring developer-friendly functionality to different things. While a well experienced and season development team will likely have found ways to mitigate the shortfalls inherent to this development style, it can quickly swallow a green solo-dev alive.
The Ultimate Decision
Bloodied and beaten by the constructive criticism you received, you crawl back into your development lair, dim the lights and take a good hard look at your life code. A suggestion had been made to you by someone much more experienced in the field, and it has stuck in your mind.
Why even use React for a single-page portfolio... it's overkill. Do it all over again, but this time, just use HTML/CSS/JavaScript like the good-old-days.
"React is cool though... I WAS PROMISED IT WAS THE FUTURE!™", you maniacally howl at the gray mid-winter sky.
After sobbing yourself to sleep, you wake up the next morning and a decision has been made.
TEAR IT DOWN.
The next week or so is spent looking over notes taken from your original public showing (don't forget, constructive criticism is worthless if you don't utilize it!). The entire project needs to be re-written in the archaic, primitive language you haven't spoken in what feels like eons. So with the steadily thumping melodies of Retrowave | Synthwave radio in the background, you set to work, relearning the basics (and picking up a few new tricks along the way that never occurred to you before, since React took care of things behind the scenes for you).
The Result
You're exhausted. You're dehydrated. You haven't seen the sun in days... but it's complete. You take a tentative step back and prepare to gaze upon what now lies breathing on your Dr. Frankenstein's table, prepared to quickly avert your eyes from the horrors you're sure to find...
You throw back the curtains...
And...
✧・゚: ✧・゚: I T ' S A M A Z I N G :・゚✧:・゚✧
Your music choice has clearly had a profound impact on the style choices this time round (in perhaps the best way possible). The buggy-ness inherent in your original project nearly eradicated, thanks to no longer needing to worry about a million npm
modules playing nicely together. The interface simplified and more intuitive. The layout, ironically, now properly reactive to different screen sizes. And The code base...
Literally 10% the size of its React counterpart.
Okay, okay. So you've made something that looks better and is physically a fraction of the size... But how does that translate to metered performance...
Well, I'll just let Chrome speak on that front.
So my friends, as someone who is still deeply in love with the concept of React.js and the development and scalability advantages it provides, I can confidently tell you that it definitely has it's place in anyone's toolkit. However, that place does not appear to be a website as simple as a developer portfolio (even one who is actively pursuing work in this specific discipline)!
If you currently use React for your own small-scale website, I strongly urge you to take a good hard look at your project, and consider cutting off the tumor before it grows too large and ends up killing you in the long run!
Want to check out the differences first-hand?
Here is the original:
React-based portfolio
And here is the new-and-improved:
Jeff Puls | Front End Developer
Have you had a similar experience to my own? Want to crucify me for daring to speak out against the usage of THE FUTURE™ of web development?
Let's talk about it in the comments below 🙂
Top comments (12)
While React might be an overkill for a portfolio as your mentor mentioned (it depends! if you are more comfortable with React and code itself is more maintainable, is it an overkill?), it does not seem like React itself is the cause of your poor Lighthouse scores. It can surely hit 100 on all stats without changing the framework.
The size of NPM modules can be a bottleneck if you are running low on memory, but otherwise it does not relate itself to the website in anyway. But you can use features like Yarn PnP if the size of bother.
I feel like it is definitely overkill (at least in the context of my site). Unless you are integrating some feature that really NEEDS something like React (hosting your own blog on the same site, for example), simpler is better. It is good to know when to use the right tool for the job.
While no, the physical size of node_modules itself is not the straw that broke the camel's back, it is the complexity of the underlying JavaScript bloat it contains, which needs to be loaded just to make the app function, in addition to any plugin features you might add that compounds the issue. (I myself am guilty of being very
npm install some-cool-package
trigger happy).Like I mentioned though, while a seasoned dev (or dev team) can certainly mitigate these performance issues, for a noobie it's probably not the best choice.
This article is awesome! I am not nearly as experienced as you with React but I could smell this a mile away. Very entertaining article with completely air tight real world examples. You obviously put a lot of work into this. Come check out my framework analysis article here if you like. :) dev.to/matthewekeller/web-applicat...
This!!!
This is the kind of writing style I strive towards. Funny, quippy, yet on point.
Great work man!
Thanks!
I'll be honest, I feel like my writing style is just a sarcastic byproduct of viewing one-too-many memes 😅
Got it!! Thanks for giving me the formula. Heading to Reddit now 😂
React is intended to use for single page applications, not single webpage... Your portfolio isn't an application but just static HTML/CSS...
You're right, and that's exactly why it made perfect sense to scrap React all together in this case.
I will say though, when I was first designing my portfolio, I had intentions of creating my own blog and such for it, but then ultimately decided it made more sense to simply include a feed to my recent DEV posts, rendering the site unnecessarily complex.
Live and learn 🤡
Single page applications are quite easy to write with HTML and CSS, some server side rendering, and ajax calls to refresh parts of the page. Huge client side JS frameworks are complete overkill and while a great solution for Facebook, not necessary at all for 95% of web applications.
Very well written post Jeff, and what a cool portfolio by the way! 😊
Thank you, I appreciate it!