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.
You should follow me on twitter, here.