Single Page Web Apps: The Worst of Both Worlds

source: xkcd

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.

trello – perhaps the best web app i’ve seen

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.