Month: June 2020

Today’s rant is inspired by yet another website that managed to waste 20 minutes of my time. It was a web-app that lost all of my input after I spent that time filling the forms and tried to submit. The app belongs to a international corporation and probably cost hundreds of thousands of dollars to develop, but it’s not unusual.

So, somehow, the brightest idea of web development in the last couple of years is that everything should be a single page application. Interactive game? Make it a SPA. A single-page website with some content? SPA. Multi-page series of forms? You guessed it, SPA.

I’m here to tell you that it’s not, usually, a very good idea. Why? For starters, you are abandoning basic web browser features, because your app breaks some assumptions browser makes about web content.

Here’s a partial list of things that you lose, and have to re-implement:

• History operations
• Reload-friendliness
• Deep linking
• Basic accessibility features
• Working on devices/browsers that can’t even JavaScript
• Search-engine readability

All those features have been part of standard web browsers for decades, and they worked. Now, every other website is an all-JavaScript SPA shit-show, and almost every single one of them has a buggy re-implementation of basic web browser features. Sure, there are libraries out there, but they still need non-trivial amounts of custom code to use them, and that code is often buggy. “Back” and “forward” buttons don’t work; reloading a page does moves user to the main page; clicking on links does not work. We go out of our way just to add more code that can break. Why are we doing it to ourselves and our users?

I get it – the code surrounding navigation has some tricky bits, and it is boring to test it thoroughly. But guess what? – users don’t care about that.

Maybe you think you are special and you will not make any of those mistakes? I envy your confidence, but I’m sorry for your users. Because companies like Twitter and Facebook – with all their billions of dollars and armies of (supposedly) the smartest programmers – routinely cause navigation bugs.

What angers me the most is that I commonly see SPAs used for things that just perfectly fit the “traditional” model of multiple pages being separately requested and rendered. Surprisingly big part of the web consists just of text, images, video, and forms. That’s where most of the money is. We like to read news and blogs, watch cat pictures, buy stuff, and it’s nice being able to do most of our banking without having to leave my apartment. There are some really cool and sophisticated things out there that make good use of JavaScript – games, interactive maps, simulations (check out Fireflies). Your line-of-business web-app doesn’t need any of that.

Not only that, but also that projects often start as SPAs just because it’s the default approach in given org, without bothering to analyze if it makes any sense in the given context. And all that SPA-specific cruft is usually the first thing built. But hey, why waste time thinking what your users actually need if you can spend it re-implementing navigation, poorly?

BTW, I googled for other blog posts on the web that talk about SPAs. In ironic twist, the first result for my query, which seems to be a corporate blog, fails to show any text. The page loaded, but instead of the blog content, I see infinitely-scrolling loading circle. Why? Because some moron thought that a blog should be implemented as a SPA. You had one job – show me text – and you still managed to fail.

Perfectionism is often seen as a virtue in the software world, but it is a disease.

Perfectionism is a belief that anything less than perfect is unacceptable, and that we should avoid mistakes at all costs. It’s rejection of vulnerability. It results not only in misery, but also cancelled projects and bad products.

It’s not that striving to be outstanding is bad; it’s just foolish to believe that you can achieve great results without exposing yourself to failure. To make good product, you need to start with a small product, and let your users tell you which part of it suck.

Perfectionism kills projects. Often, the vision dreamt up by a perfectionist designer is not feasible to realize within a sensible timeframe, or at all. What’s worse, a perfectionist believes that the product they imagine would be great – but, arguably, it wouldn’t be. It has not been used; it could not benefit from feedback; you just can’t know if it is any good without having a good number of people trying it.

An an industry, we know that starting small and learning from feedback is the way to go – books praising this approach to product development are classics (think “Mythical Man Month”, “Lean Startup”), and “Agile” is the ultimate buzzword. We have known it for decades, but we don’t act like it. It’s still common for software projects to take multiple months before it is ready for the initial release. It’s even more common to fool ourselves that it serves the users better than iterative approach.

Perfectionism can hurt individual programmers in similar way. When we hide from critique, we can’t grow. When we skip the simplest approach that could work and instead immediately reach for overcomplicated ones, we miss the point. It strokes our egos, it makes us look better for other programmers, but It’s not about us; it’s about the users.

There is also the opposite problem – there are plenty of people who don’t give a shit about quality. But that is another story.