TLDR

Don’t start your webapp using a SPA javascript framework. Read this and this if you want to hear the same message in a different tone (I freely accept that I’m brusque about this). Read Thoughtbot’s experience on this if you are still unconvinced.

Context

I used to hang out on internet forums in the 2000s. I remember a program called PhpBB taking over all the forums. Everyone started switching to it. We all needed to re-log-in and recreate our accounts since this program just took over. Yes, it was written in PHP. And yes, it worked. It did the job. This was before Google Maps blew everyone’s mind with AJAX calls. This was before the phrase Single-Page Application existed. PhpBB was the Ruby on Rails of the internet-forum ecosystem. It just worked. You could count on it.

I’m a member-berry

For those of you who don’t know what a member-berry is, please edumicate yo’self by starting out with this link. You will probably lose an hour of your life. Time you enjoy wasting is not wasted time (wisdom courtesy of the Schnitzel Queen).

• Remember when you didn’t have to worry about the submit button not working after you spent 15 minutes composing a helpful comment in phpBB?
• Remember when you hit the submit button and you just waited for the server to return a new HTML page with your stuff completely submitted?
• Remember not having to worry about hitting “Submit” and your fancy-pants single-page application confirming to you that its submitted but the server not having actually saved your input?
• Remember not loading 5 bajillion megabytes of javascript over your internet connection before you could fill in a form?
• Remember loading websites on your family’s slow dial-up internet connection from the middle of nowhere?
• Remember those websites loading faster than a single-page application in the downtown of a metropolis over your fancy-shmancy 4G LTE mobile connection?
• Remember not having to load 1 million megabytes of javascript in your browser before you see a list of updates of friends, products, email, coworkers, etc?
• Remember not having all that javascript chew through your CPU usage and battery life? See this, then read through that entire website.

I’m a technological grumpy grandpa

There was a time when people used to say that a website’s UI should be determined by the needs of the end-users. There was a time when we built things using the simplest pieces and no more. A time when we accepted that simplicity was a necessary condition for reliability. We accepted that premature optimization was the root of all evil.

We used to render the HTML for a page on the server, and send it over the wire to the web-browser. Then we started including “feeds” into our webpages and realized that most of the page didn’t change, but we still sent all that HTML over the wire. Some big companies realized that it made financial sense to preload these templates into a javascript application running in the browser, and then send only a small bit of content over the wire, and have the JS manage the presentation of that content. These big companies found that its better for the end-users’ data-plans to incur the fixed cost of loading up an SPA and then charging a lower variable cost of the content in JSON form.

The single-page application (SPA) pattern is a performance optimization. It attempts to optimize the amount of data sent over the wire, and the end-users’ internet costs. Performance optimizations SHOULD NOT (RFC 2119) be done without A/B testing. And yet we find ourselves in a world where the SPA performance-optimization pattern is reached for right at the beginning of a project.

My problem with this is the trade-offs we make when solving problems. As programmers, we build solutions to our customers’ problems. But we SHOULD solve the problems with the simplest tools at hand. Complicated tools just cause complicated problems of their own. A SPA creates the problem of handling state in 2 places instead of one; the problem of synchronizing state across a network. This is covered in the CAP theorem.

When you have a SPA, the programmers have to think about the CAP theorem the same time they are fitting together a simple form. Are your programmers thinking about that? If you believe that the median javascript programmer thinks about the CAP theorem when duct-taping together a form that is supposed to be “responsive” and “live” and “seamless” and “work as if it was a desktop application”, I have a bridge to sell you.

Copy-pasta works, right till the point it doesn’t

Its a running joke in software circles that you can put together a website by copying and pasting together random snippets of code one finds on the internet. This joke has been running a long time; we laughed about doing this with HTML, and with CSS, and with PHP, and with Ruby, and with Javascript. It wasn’t so bad when we started out as programmers in the 90s and the early 2000s and were copying HTML and CSS snippets and calling ourselves “HTML programmers”. HTML doesn’t have state and we never had to worry about the CAP theorem.

The kids these days that are copying and pasting together Javascript code in the newest, shiniest, sparkliest, sexiest frontend frameworks are

• • building SPAs that hold state in the client’s browser and
  • they should be thinking about the CAP theorem, but
  • they don’t.

Copy-pasta isn’t good enough anymore.

The front will fall off.

The end-users don’t need it to be fast

• • Listen, dude(tte) with a great business idea that is looking for a programmer to realize that vision, I get it.
  • Listen, new programmer trying to get started in the field. I understand.

You just need to get a webapp going and you networked and someone said you should use a SPA so that you have a website that responds faster to the user. You did a web-search for “why speed matters in a website” and immediately found every smarty-pants on the internet who quotes from the exact same study about how users don’t engage with a website that doesn’t load in 2 seconds. Please understand that this only really applies to your home page. It doesn’t apply for when the end-users are in the guts of your system. It doesn’t apply when the end-users have already purchased and are using your actual web-application to improve their lives in some way, shape, or form.

Once they’ve forked over the cash, they care about a system that works reliably. They care about a webapp that takes their input and does the right thing with it. Do you really think that an end user punching in any of the following data would be impressed if they found out that the confirmation popup they are presented isn’t actually shown after the data is safely stored in the database? Do you think the end-user would say “Man, my data wasn’t saved but I’m so impressed with how quickly they said it was saved. This is a professional piece of work done by professionals who deserve to get paid professional gobs of money.”? Go ahead, ask your business partners if this is what you want your customers saying when they entrust your business with:

• • sales info,
  • family photos,
  • legal info,
  • tax returns,
  • multi-million dollar B2B purchases,
  • their last and final will,
  • etc.

Your end-users don’t need that speed. They don’t need a webapp that is so responsive it feels like a native desktop-or-mobile application. They need something they can count on.

Are you worried that your customers will leave your product if they don’t get a dopamine hit every 0.3 seconds? If so, I’d respectfully suggest you don’t put any more time, effort, and energy (as the entrepreneur or the employee) into a product that people are willing to leave in less time than it takes to take a sip of water. You are in a race to the bottom, and its not worth it.

Cut the bullshit

The fact is the Javascript community has been acting like a spoiled brat for years. They aren’t happy with the toy they got last week, and they want a new one today. And this has been going on for years.

• • BackboneJS was a shiny new toy.
  • EmberJS was a shiny new toy.
  • AngularJS was a shiny new toy.
  • ReactJS was a shiny new toy.
  • MeteorJS was a shiny new toy.
  • KnockoutJS was a shiny new toy.
  • VueJS is a shiny new toy.
  • Webpack was a shiny new toy.
  • Grunt was a shiny new toy.
  • Gulp was a shiny new toy.
  • Yarn was a shiny new toy.
  • Bower was a shiny new toy.

Every year they swarm like moths to a flame onto a new build system. Every 6-12 months the JS community loses its shit over a new “framework” thats going to “revolutionize the way people code in javascript”.

Do you want to bet your livelihood on this? Do you want to ask your friends and family for seed funding in your new business so you can hire a bunch of fashionistas to make technical decisions about your product? Do you want to wake up in year two of your startup and have the programmer who made these initial decisions based on what was shiny two years ago come up to you and say “Hey boss, our frontend development is going slow. We need to re-write this. There is a shiny new thing that came out a month ago that will solve all our woes.”? Do you want to build a product thats going to last at least 20 years and pay the programmers to rewrite it every 3 years? Does it seem like a good idea to apply for VC funding and tell them this is your plan? Do you have a great day when your fashionista programmer threatens to quit (in the present labour market) if you ask them to suck it up and deal with the consequences of their own decisions? Do you like being between a rock and a hard place? Do you like being up shit creek without a paddle?

Its obnoxious how many times I’ve heard of a situation similar to this in the last 4 years. Its gross. This dynamic results in a gigantic waste of paid effort, which results in a gigantic waste of money, which unnecessarily reduces the runway for many young businesses. As programmers in this job market, we are very lucky. We are in the middle of a gold rush right now, and its a seller’s market in the programming labour market. It behooves us to not screw over our clients; we should base our technical decisions on our customers’ needs, not on the latest fashion. The less money our clients waste, the longer their runway will be, and the longer our gold rush will last.

Counterpoint

Fine, you really need your website (or webapp, whatever, it all just runs in the same browser) to be interactive? Bugger off. Do your paying clients really need your website to be interactive? Ok, fine, just use this JS framework. This one isn’t going anywhere, and its pretty nice, as long as you stick to the good parts. If you are building a chat app or a browser-based video game, I’ll recommend you use vanilla-JS. Just stop using all these SPA frameworks. Noone needs 50 megatons of javascript running on their mobile phones to have an interactive form.

Chat app

So you are building a chat app (even though you could buy one as a service). If you’ve added javascript for non-primary functionality but not for the primary functionality, you’ve got problems I can’t help you with. Lets assume you have added javascript for the primary functionality. Your users want to not have to press “F5” every few seconds to see if their buds have responded in a particular channel

All you need to do is get the browser to poll the backend every 2 seconds to get a list of updates. Step 1 is to execute a function every 2 seconds. VanillaJS does that; its called setInterval(). Step 2 is to write the function. All the function needs to do is make a HTTP request to your backend, and if there are updates in the response, pop those updates into the DOM of the browser so the end-user sees the updates. Step 3 is profit.

Et Voilà . No SPA needed. No 20 KB of external JS dependencies needed. No webpack-grunt-gulp-yarn-bower-shmower needed.

Wah wah wah but I want real-time updates. A 2-second delay isn’t good enough

BTFO. A 2-second delay is good enough for human users, and machine users don’t care.

Also, vanillaJS supports websockets, in case you really need the communication to be ASAP. Your programmers just need to parse the messages that come in from the websocket channel. You still don’t need a SPA.

Browser-based video games

You want to use a SPA framework for your browser-based video game?

• 
• 
• 
• 
• 

A SPA framework isn’t going to help you with this. You’ll be using VanillaJS anyway, because you’ll want to eke out the best performance for your end-users.

Conclusion

The JS community has lost its way. It chases the false gods of shiny, and millions of paid hours have been lost to retraining employees on the latest shiny. It doesn’t have to be this way.

Old is gold. Boring is beautiful.

If you want someone to tell you how to get things done using reliable tech that isn’t going to be abandoned by its community after 5 years, send me an email. If I like you, I’ll even smile when I eventually tell you to get off my lawn.