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
waitingscreaming 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!
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.
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.
- Web app development questions
- The Disastrous Fragmentation Of Web Apps
- Why Page Size Matters even more for Mobile Web Apps
- Mention Launches Social Media and Web Monitoring App to Take On Google Alerts
I write mindblowing emails 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 👇
Join Swizec's Newsletter and get mindblowing 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
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
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️