Why We Moved From React to Svelte
By: Maxime Nadeau
Tags: JavaScript, Programming, Productivity, Svelte, React

Why We Moved From React to Svelte

Should JavaScript really be that complicated?

Photo by Fabrizio Chiagano on Unsplash

I feel I am getting old, ever so slightly getting on the “Should it really be that complicated?” bandwagon. Simplifying the process of creating dynamic front ends is getting quite chaotic.

When you work for a large firm and expect to maintain a product for many years, it’s a stellar solution. It’s best when everything revolves around a commonly agreed-upon workflow. React brings tremendous freedom around how you want stuff to work.

We are a small team that produce fast and iterative digital products for mid-sized to large clients — usually a few of them in parallel. We recognized that keeping up with the “fad of the moment” hurts our productivity. The React ecosystem changes paradigms every now and then. The temporal load of the projects makes maintenance a burden. We regularly roll back our brain to the way things transpired in the past.

Containerization made everything more comfortable because we could anchor the development environments in time. A considerable part of JavaScript fatigue is continually moving back and forth between the different bundlers and task managers — Grunt, Gulp, Webpack 1-2-3-4-5, Browsersync, Nodemon, blahhh! Now it’s all behind docker-compose, and it helps us sleep at night. Our CI/CD pipeline (almost) ensures that we are not doing dumb things in production.

But still, it doesn’t make us happier. React got tedious and boilerplatey.

I guess we all want to find that thrill of humble beginnings. Everything was exciting. “Look, when I click that button, that thingy moves. Holy cow!” But then you slowly realize that you included a 250kb library, wrote a class, fumbled with a shadowy representation of your DOM — bundled down with your fonts, your social security number, and the recent weather forecast. What the heck? Should it be that complicated?

I assure you we tried all the cool stuff before moving on, but like in a relationship that is slowly drifting apart, it was hard to tie back to the early and naive excitement. Every time something new got considered for testing, we instantly felt that overarching pressure to memorize past projects that didn’t use that paradigm. By default, the changes away from our “known” territory induced technical debt.

Onboarding new ninjas is a struggle for us. Sure, you can state in the application form that you are looking for experienced React developers, but there are many flavors. The holy wars of determining the right tools are getting old — just like me.

I look at the codebases with a feeling that I need to Marie Kondo the crap out of them to find any joy out of working with them.

So then we started our journey: Vue, Angular, Yew, Blazer, you name it. But we always came back with our fix because we, developers, are creatures of habit.

We focused precisely on what creates either a great developer experience or direct value for our clients. These lenses reduced the hassle and time involved with changing our toolbelt. We settled on our custom-built server-side-rendered React project and very few libraries that we liked for the longest time.