Should I upgrade my web app to modern Javascript frameworks?

The modern Javascript ecosystem is one that is always evolving. If you are in love with a JS framework that is “all the rage”, chances are that in about 5 minutes, that framework will be obsolete.

Photo by Andrew Seaman on Unsplash

Moving on from the old

I’ve spent the last 5 years working at LumiraDx developing Javascript applications. In our applications of old (ca. 2012), we had relied on front-end frameworks such as Backbone.js, CoffeeScript, and LESS, among others. No module bundler was involved here, so that meant using Node to transpile our CoffeeScript into Javascript in a 1:1 file structure.

Photo by Patrick Schneider on Unsplash

So what were the problems with these older UI frameworks? Well, they were numerous:

• Backbone was messy. Views became easily de-synced with their respective data models, and it was also hard to track down specific instantiations of those models, too. Application state became a bear to manage.
• CoffeeScript felt too loose and free. You could accomplish the same task in 5 different ways. This sounds great on the surface. However, in a large application worked on by many developers, it led to unpredictable, inconsistent, and sometimes untraceable code. It was sort of the opposite to what TypeScript now represents.
• LESS was alright, but it still felt too similar to vanilla CSS, plus mixins and variables. I didn’t actually feel like I was writing much less CSS overall. We ended up using Stylus, which in my opinion, is the CoffeeScript of CSS preprocessors.
• The absence of a module bundler left us with hundreds of Javascript files to be required dynamically. This slowed down the browser significantly due to the large number of requests. This may actually be a better thing for you HTTP v2 users, but back in 2013 it was all HTTP 1.1.

Every Javascript developer has gone through this. They built an application (or many) using an “established” set of frameworks, only to abandon nearly the entire stack to start using a new stack that is now considered “in”.

How do I deal with the framework churn?

“A vintage, iron grain grinder attached to a wooden workbench” by Clem Onojeghuo on Unsplash

The most apparent answer is, you don’t–especially if your application is in support mode.

On a practical level, it’s not realistic to rewrite an entire application simply because the chosen tech isn’t considered bleeding-edge. Usually, you’d only start new development in a new set of frameworks.

If you must re-write an existing application, do it in stages:

1. Introduce to your build process a way to handle any new file types and frameworks, and confirm that code written with those frameworks properly function alongside your existing application. A module bundler such as Webpack is a must for modern applications.
2. Start writing all new features in the new frameworks. When feasible, rewrite the old files into the new frameworks when they are touched, or when there is downtime.
3. Start re-writing old files using the new frameworks and phase out the old ones. This part will take the most time, depending on the size of your application.

Why should I modernize my frameworks?

In the modern Javascript world, it is a necessity to stay (mostly) up-to-date with modern tech. Here is why:

• Javascript === open source. Nearly all of the Javascript ecosystem is open source, that also means that bugs are constantly being fixed. Security holes are being filled, and performance improvements are being made. Your framework from 2012 may be filled with security holes that have since been patched.
• Web browsers are the future of apps. Modern browsers are in the best state they’ve ever been in the history of the internet. Security is better. Feature support is better. Connectivity is better. Speed is better. Mobile support is better. New frameworks take advantage of these updated browser features and can help your application reach new audiences and capabilities.
• Developers are arrogant about frameworks. There, I said it. Javascript is the language of coding hipsters with square yellow “JS” stickers on their laptops. That means that hiring Javascript developers can be difficult if you are not running the “hot framework on the block”. While this may not be a good enough reason to dedicate dozens of man-hours to rewriting a large application, it may be something to think about if you are running a CoffeeScript application written in Backbone.
• Support and resources. There is a bevy of information available on the web about most of the matured frameworks. Choosing a more modern framework that has heavy usage may have the added benefit of the support of the community.

Where do I start?

While there are literally hundreds of frameworks that you could adopt for your next (or first!) application, it is hard to know which direction to go. Here are my personal preferences for the ultimate modern Javascript workflow:

“Six doors of varying colors stacked on top of each other.” by moren hsu on Unsplash

• Node.js–Javascript runtime. Using Node for development is essential. It allows quick setup of a development server with a module system that works right alongside the rest of your toolset. Node is also great in production, as is very fast.
• Babel.js–compiler for modern Javascript. Modern Javascript features have poor support by modern browsers (it is getting much better though!), so Babel is a way to convert modern Javascript features down to workable ES5 code for older browsers.
• Webpack — module bundler. Webpack is used to squish all of your source files into one, compact bundle. This will allow you to modularize your entire application into bite-sized chunks for development, but then compressing everything into a single minified bundle.js file, that you can import into index.html.
• React–Javascript UI library. React is all the rage. Right now, it is the hottest Javascript UI framework. It’s fast, it’s tiny, and it’s easy to use. I’ve used React for the past 5 years professionally, and I have not felt a desire to shift away from the library, as it seems to suit every need I’ve encountered.
• TypeScript–Typed superscript language. TypeScript helps to fill the holes that a dynamic language like Javascript leaves open. It brings predictability to the code, adds structure, and ultimately saves time during development. The other great thing about TypeScript is that it’s just Javascript–but with more features. You can write as much or as little of it as you need, but I prefer to use as much as I possibly can.
• Stylus–CSS preprocessor. Stylus is a CSS preprocessor that is extremely flexible. It takes much of the pain out of writing CSS with features such as mixins, variables, and syntactic niceties such as optional semicolons and curly braces. CSS is generally a pain to maintain, but using CSS modules in conjunction with Webpack makes much of that pain go away.
• MobX–application state management. Medium-large sized applications require a state management framework. Other popular frameworks require lots of boilerplate, so I prefer MobX. Observer/observable decorators make for a super-clean way to connect MobX to your React components, and allows for the developer to flexibly define their own state management design pattern.

While learning how to connect all of these pieces for the first time, I sometimes found it difficult to make basic connections that other people had already made when setting up tools like Webpack or Babel. This nuance in the current ecosystem can make for a very complex setup process.

However, it may be worth your time to at least explore the latest trends in the ecosystem so you don’t fall too far behind. It can be hard to keep up with for sure, but it will eventually settle down and the best frameworks will emerge as the clear choices for your next app.