Why I Decided to Leave Frontend Frameworks Behind

As a Senior Full-Stack Developer for the past 7+ years, I have used many frontend libraries and frameworks, including Vue, Angular, Next.js, Svelte, Gatsby, Hugo, and more. Each one of them had its specific use cases.

Next.js, back in 2019-2020, introduced me to server-side rendering, which I used extensively to create custom e-commerce websites that performed really well at that time. Also, back then, many companies transitioned from React Class Components to Hooks, so this was a big jump for me and many developers.

Later that year, I used Gatsby, which introduced static websites. Coming from a client-rendering background, the performance was impressive.

Yet, after 7+ years of non-stop coding, I found myself disappointed and ended up going back to create-react-app or web components. In this article, we are going to explore all the reasons why these frameworks and libraries are often unnecessary and why, in most cases, they are not needed.

Abstractions

Taken directly from Wikipedia, "In computing, an abstraction layer or abstraction level is a way of hiding the working details of a subsystem." This means that we hide from ourselves how something works.

This is not a bad thing at all, but it should only be used on the backend where we deal with very complex systems. Even then, we should keep a lot of the basics.

Abstractions are proving themselves wrong. We use them to easily develop our applications and reduce the learning curve, but at the same time, it takes a lot of time to learn them.

Let's take Next.js for example. How it introduces routing to the users is far from how the actual routing works under the hood. Just to grasp what I am saying, the Next npm package is 86MB compared to the base React repo which is just over 300kB. For most projects, the only thing you do is have 10-15 pages, maybe have Stripe and a few charts, some side effects, basic state management, and that's it. Why do you need 86MB of code, all that learning curve, and the poor documentation of Next.js for your next project?

Why not use Lit or Create React App, which basically have zero learning curve? There are only a few abstraction layers, and they do not hide a lot of things.

Gatsby is basically the same, Angular, Vue, or Svelte. Everything is reinventing the wheel on how we write HTML.

Framework Positives

Now let's talk about some of the supposed positives these technologies have. Server-side rendering is better for SEO. Or is it? This snippet is directly from Google Search Docs as you can see JavaScript is not a problem for search engines anymore.

Performance is also not an issue. Five or six years ago, when computers and mobile phones weren't that powerful, server-side rendering transferred a lot of the page load to the server. However, as you can see here, this is the Lighthouse score of a create-react-app I have created. If you write clean code and don't use heavy dependencies, you can achieve amazing page load speed.

Scaling is also another big factor in choosing a framework for your next project. For that, I agree, and I believe it is the only reason to choose such a technology. Large teams are hard to work with. Frameworks introduce rules and ways of doing things.

This is a valid argument, and I can accept it if someone told me they are choosing it for that reason.

Dependencies

Here are my dependencies for one of my framework projects. A lot of dependencies are used and most of them could be replaced with something much simpler.

"dependencies": {
    "@emotion/react": "^11.11.3",
    "@emotion/styled": "^11.11.0",
    "@mui/icons-material": "^5.15.2",
    "@mui/material": "^5.15.2",
    "@mui/system": "^5.15.2",
    "@mui/x-data-grid": "^6.18.6",
    "@mui/x-date-pickers": "^6.18.6",
    "@stripe/react-stripe-js": "^2.4.0",
    "@stripe/stripe-js": "^2.2.2",
    "@visx/axis": "^3.5.0",
    "@visx/curve": "^3.3.0",
    "@visx/event": "^3.3.0",
    "@visx/gradient": "^3.3.0",
    "@visx/grid": "^3.5.0",
    "@visx/group": "^3.3.0",
    "@visx/mock-data": "^3.3.0",
    "@visx/responsive": "^3.3.0",
    "@visx/scale": "^3.5.0",
    "@visx/shape": "^3.5.0",
    "@visx/tooltip": "^3.3.0",
    "@visx/vendor": "^3.5.0",
    "@vitejs/plugin-legacy": "^5.3.2",
    "aos": "^2.3.4",
    "array-move": "^4.0.0",
    "axios": "^1.6.3",
    "bootstrap": "^5.3.2",
    "d3-array": "^3.2.4",
    "d3-time-format": "^4.1.0",
    "dayjs": "^1.11.10",
    "dotenv": "^16.3.1",
    "eslint-plugin-simple-import-sort": "^10.0.0",
    "i18next": "^23.7.13",
    "laravel-echo": "^1.15.3",
    "mui-phone-number": "^3.0.3",
    "preact": "^10.19.3",
    "prop-types": "^15.8.1",
    "pusher-js": "8.4.0-rc2",
    "react-country-flag": "^3.1.0",
    "react-debounce-input": "^3.3.0",
    "react-dropzone": "^14.2.3",
    "react-easy-sort": "^1.6.0",
    "react-hook-form": "^7.49.2",
    "react-hot-toast": "^2.4.1",
    "react-i18next": "^13.5.0",
    "react-icons": "^4.12.0",
    "react-loader-spinner": "^5.4.5",
    "react-modern-drawer": "^1.2.2",
    "react-phone-number-input": "^3.3.8",
    "react-query": "^3.39.3",
    "react-router-dom": "^6.21.1",
    "stripe": "^14.10.0",
    "use-local-storage-state": "^19.1.0",
    "use-sound": "^4.0.1"
  },

Here is another project where I use web components. Check my package.json. It is much smaller, and if I need charts, I include them over a CDN, along with Tailwind. I moved all the Stripe infrastructure to the backend. That way, I keep my code much cleaner.

  "dependencies": {
    "@vaadin/router": "^1.7.5",
    "lit": "^3.1.2"
  },

Deployment

Deploying a pure HTML website is significantly easier compared to using a framework. With a simple HTML site, you often only need to upload your static files—HTML, CSS, and JavaScript—directly to a web server or a hosting service.

There's no need for build processes, dependency management, or server-side configurations, making the deployment process straightforward and fast.

In contrast, deploying a site built with a framework often involves additional steps such as compiling code, managing dependencies, setting up a server environment, and configuring various build tools. These extra steps can introduce complexity and potential points of failure, making the deployment process more cumbersome and time-consuming.

I often use Docker when working with frameworks and that complicates the deployment process much more.

Final Words

In conclusion, while frontend frameworks offer certain advantages, such as scalability and established conventions for large teams, they often come with significant overhead and complexity that may not be necessary for many projects.

By opting for simpler tools like Create React App or web components, you can achieve excellent performance, easier deployment, and a more straightforward development process. Ultimately, the choice of technology should be guided by the specific needs of your project and the balance between complexity and efficiency.

Thanks for reading, and I hope you found this article helpful. If you have any questions, feel free to email me at [e-mail], and I will respond.

You can also keep up with my latest updates by checking out my X here: x.com/sotergreco