Single page web apps are the promised land of modern javascript MVC frameworks like Backbone or Ember.
Deliver a dynamic experience right to the browser, they said, use the server like a smart database, they said. Your site will be quicker and your users will love it, they said. Page loads in the blink of a second, static content via CDN, no more flickery full page reloads ... they said.
All of those promises are true.
Servers should handle data. They're very good at that and having a central authority to handle data consistency amongst clients is perhaps the simplest distributed system architecture one can think of. Sure, it gets a bit complicate when "A server" becomes a few tens of boxes spread out in data centers across the globe, but that's still not the client's problem.
Conversely, clients are exceptionally good at presenting data! It's practically all they do. They give some data to the user, then they sit quietly in the user's face ~~waiting~~screaming to be poked so they can send some changes back to the server.
This separation makes sense.
Makes organising teams easier, separating talent becomes a walk in the park, it's even friendlier for the user who doesn't have to wait for a signal to travel halfway around the world just to open a menu!
Win-win-win!
Not really.
Good single page web apps are a bitch to develop. A bitch with a few screws loose, to put it mildly.
In traditional web development the one thing you can count on is everything being stateless. A request comes in containing everything you need to know, maybe you have to fetch a few things from a database. Once you've answered the request, that's it, you don't care about the client until a new request comes in.
This is easy. Easy to reason about, easy to make robust, easy to test and easy to avoid strange errors. You're basically ensuring a clean slate every time.
In traditional app development, you know for a fact everything is stateful. You keep things in memory and you know that's where they will remain until the app is closed and reopened. Nothing will randomly go missing and nobody seriously expects you to maintain state across sessions.
Yeah yeah, sometimes gunk can accumulate when an app is left running too long. A restart either of the machine or the app usually solves the problem and even though many apps and even OS's have started experimenting with cross-session state it still isn't expected.
A lot of people don't even want to restore tabs!
This clear divide between websites and apps helps in a lot of ways. Mostly it separates developers into those who don't have a problem re-imagining their universe around every request from those who prefer dealing with accumulating memory gunk.
And then come modern web apps. Sitting confusingly on the fence between both worlds.
Very simple in theory - the server is stateless and the frontend is stateful.
But think about it. The frontend is stateful in the sense that very complex things can happen when the user clicks around. Data changes in memory and we expect the data to stay there, javascript being asynchronous aaaaalmost creates all the same problems traditional developers deal with in regards to multi-threaded code and it's very easy to accumulate all that gunk and start producing some very strange errors.
Then your user clicks refresh.
Sometimes right after losing wi-fi signal in the middle of sending a request to the server ... or they closed the browser. Maybe it's not even the same user because they shared a link!
Bang! Your app stateful just lost state.
After a refresh the user expects to see exactly the same things they saw before. That's how the web works, right? You click around and you send a link to somebody and it's the same thing. You don't expect to sometimes get the homepage and sometimes a blog post when going to /blog/some-title-of-a-post
As developers we've found ourselves in a situation where we must assume our app is both stateless **and **stateful. Every URL still points to a unique page, but if you got there after a reload, all the models must be refetched from server - preferably the server would bootstrap them into place - all open sockets must be re-established and a bunch of other minor things have to be taken care of.
All in all, you get at least double of the complexity and for what? A shinier and smoother experience for the user ... which is exactly what we want.
I would love to propose a good solution for this problem. But I can't. I am left sitting here, wondering, hoping for a humane solution to this conundrum. My Google searches are coming up short.
Continue reading about Single page web apps: the worst of both worlds
Semantically similar articles hand-picked by GPT-4
- A lesson about client-side templating
- How serverless beats servers
- 90% of performance is data access patterns
- The web moves fast, how do you keep up?
- Do you really need immutable data?
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️