Baldur Bjarnason

I don't care how you web dev; I just need more better web apps

– Baldur Bjarnason

Everybody seems to disagree with everybody #

You don’t need to look far on web dev social media to find somebody lecturing everybody and nobody about how you should do web development. Hell, I’ve been guilty of that myself.

You should use this or that framework.

Or, you should not use this or that framework and instead use a cognitive framework like Model-View-Controller with ‘vanilla’ web components.

No, no, no Functional Reactive is where it’s at.

You should be writing code test-first and unit test everything.

Or, you should go light on the unit tests and focus instead on integration tests.

Or, end-to-end tests. Just test the shit out of the actual running app.

Or, you should use this different kind of unit test which doesn’t look anything like that other kind of unit test.

Those aren’t integration tests! This is an integration test! What’s wrong with you?!

You don’t pair program? Wow, your code must suck.

Everybody seems to have an opinion on how you do your web dev and how websites and web apps should be structured.

Except… That’s just how it seems.

The different roles we play in online discourse #

Of course, web dev social media has a ton of posers and assholes who are genuinely lecturing the rest on the one true way to dev. But most in online discussions belong to one of five tags:

  1. They are describing how things are done where they work and assume that if you’re describing something different you must be describing it wrong or not following your place of employment’s best practices.
  2. They are describing how they’d prefer to work and are assuming that your different take means that you think that they’re making a big mistake.
  3. They are educators teaching a specific approach to solving a specific problem. They’re aware that there are often many different solutions to each problem but are describing the one they teach. They also are probably assuming that you think they’re teaching the wrong approach for bad reasons.
  4. They are testing out different approaches and weighing the pros and cons of each, with data. They’re assuming that you can’t make good decisions in a vacuum. Which is a good assumption, admittedly.
  5. They are concerned about the long-term sustainability of the field. They keep encountering highly flawed websites or web apps and are assuming that regular web devs can do something about it.

The first two are probably the most common. Given the casual and often escalating nature of most online discussions, it can get quite hard to tell them apart from the assholes. The third—marginally less common, but you can usually tell them apart because they tend to be specific about the problem being solved and use words like “many of my students found this helpful”.

The people who do number 4 are obviously gems that we should all cherish. They’re the sort who drive progress and keep the proverbial trains running on time (so to speak).

The fifth group of online ‘lecturers’ deserves a special mention because they frequently skate over into the obnoxious. After all, if you genuinely believe that the web is facing an existential threat and that developers can do something about it, then the stakes are high enough to bully people a bit, right?

I don’t think that’s a particularly productive way to go about it. Primarily because I’m of the opinion that bad apps are almost always down to management, not developers. But I’m also not in a position to judge anybody for being annoying on the internet.

Cultural differences mean everybody is operating under different rules of engagement #

Given how little context social media discussions have in general, it can get pretty tricky to tell the well-meaning from those who are being dicks. Are they being an asshole or are they Nordic and so not in the habit of using ambiguity qualifiers in their conversation? Are they arrogant or are they from a culture where the employment context of the conversation is assumed to be obvious? Are they from an environment where educators are expected to project an air of infallibility?

The web is a global environment and the rules of conversation and discourse vary a lot depending on the country and language.

For example, I’m Icelandic and Icelandic colloquial language tends to use absolutes. It’s the worst thing in the world. Or, it’s the greatest. Icelanders also tend to be blind to rank in conversation which regularly leads to accusations that we’re being disrespectful. (The Icelandic counter would be that your CEO/university dean/church bishop has done nothing to earn the Icelander’s respect.) I’m also raised in England and the tendency there is to assume that you will automatically adjust what is said depending on context. “He’s done a great job, all things considered”, can be genuine praise or a scathing condemnation depending on the context.

As you can imagine, I frequently get into disagreements with North Americans who either think I’m rude and disrespectful (if I’m operating in my Icelandic mode) or that I’m disingenuously downplaying important parts of the discussion (if I’m in my English mode).

Multiply the issue by the number of different cultures online and you can see how we have a problem. Every participant is operating under different rules of engagement.

Even though it might not feel like it’s true, it probably is true that very few of the people talking about how to web dev on social media actually care how you, in particular, do your web dev. If they are talking about specific methods, most aren’t implying that other methods are wrong, they’re just describing their favoured approach. If they are describing specific flaws in a particular method then that should only be taken as a call to ensure that flaw doesn’t recur in future projects.

(And a few are genuinely being dicks. Not much you can do about that.)

My intent: stated as plainly as I can #

I tend to fall squarely into the second category: my goal with most of my online writing about web development is to make it easier for me to work the way I think is best. Like most who have been in a field for more than five minutes, I have specific ideas, based on experience, about what works in what situation. The problem I’ve regularly encountered in my work is that I don’t get to do my job the way I think is best for both me and my employer or client. The employer, who isn’t the web development expert, almost always has a clear idea of what real web development is supposed to look like: Single-Page-Apps and React (or React-like frameworks).

Every solution I propose is measured against what they perceive to be the web development exemplar.

We might have a project that has a limited budget and resources but also a user-base that isn’t demanding the Single-Page-App ‘experience’. In which case, the logical approach is to make a multi-page web service instead of a Single Page App. It’ll cost less both in the short term and the long term. And you’re much more likely to be able to deliver it on time.

But you almost never get to do that these days because only a Single-Page-App is a ‘proper’ website. An intimation that it wouldn’t be the right solution for this particular problem is taken as an admission of incompetence. I must be arguing against an Single-Page-App because I don’t know how to make one.

Framework authors, well-meaning as they are, frequently make this situation worse. Many of them keep arguing in favour of Single-Page-Apps because of the theoretical superiority of the experience they can provide. They argue that a ‘properly’ made Single-Page-App won’t have the accessibility and correctness bugs that frequently plague many of the Single-Page-Apps you see in the wild.

The problem is that doing a Single-Page-App ‘properly’ is even more expensive than doing a mediocre Single-Page-App, which in turn is considerably more expensive than an old-style multi-page web service. If a lack of resources is the limiting factor for the project, any suggestion that involves more work or more resources makes the problem worse.

What we end up with is an industry plagued with cost and time overruns. Projects go way over budget and get delivered much too late, if ever. Because everybody wants to do ‘proper’ web development and nobody wants to adjust their expectations of what can be accomplished with their resources to something more realistic.

Static site generators did turn things around a bit, for certain types of websites. But then you also have static site generators that take Single-Page-Apps to new excessive extremes: when you have no server-side, some people respond by shipping everything to the client as JS.

So, I don’t think talking is working. But one thing that static site generators showed is that examples work.

Which makes a lot of sense if you believe in a Kuhn-style paradigm model of how fields work.

Paradigms, what the word actually means #

The short version of the theory in Kuhn’s Structure of Scientific Revolutions:

Now, I’m not going to debate whether web development is currently facing a paradigm shift or not. That sort of thing only becomes clear after the fact. But what we are missing is more variety in our exemplars.

Not to put a too fine a point on it but most of the web apps and websites I’ve had to use over the past few years are kinda awful. The amazing benefits offered by all the latest versions of all the latest frameworks remain thoroughly hypothetical. Demoware, if you will.

Some of the web apps and websites are just stupendously awful. Even many widely celebrated apps tend to be highly flawed. Some suffer from major accessibility problems. Others are unusable on a slow connection. Almost all of them have serious UX flaws or resort to UX compromises that are disastrous on one major OS or another. (A fake context menu is a common one, which disconnects your app from a host of vital native OS features on macOS. Another frequently fatal flaw is making an app real-time when that only serves a minority of your end users and does an active disservice to the rest. I could go on as the list of UX flaws is quite long. We seem to be pretty bad at it as an industry.)

Many of the popular apps are borderline unusable but survive by virtue of being free or next to free (i.e. bundled with another service or paid for at the enterprise level making them the default for all employees, even if they find the app unusable).

I’m hard-pressed to name more than a handful of web apps that I would say are genuinely good with no major flaw.

Content websites are a different matter. A static or server-rendered content website with adequate typography and semantic markup is generally going to do its job pretty well.

But web apps? There are a ton that I tolerate because they are marginally more useful than they are flawed but very few are what I’d say were genuinely good.

Native apps are a different story. Both because there are many more genuinely great native apps, but also because many of these apps are made by small teams, which are exactly the examples I’m looking for. Y’know, teams that are way too small to be able to pull off a quality React Single-Page-App.

Small- to medium-software houses that make decent specialised native apps are a thing. Almost all of my favourite native apps are made by small- to medium-sized businesses. Not all, but definitely most of them. They aren’t that common but there’s enough—enough of them to prove that you can indeed make a quality native app with a small team. It isn’t easy by any means, but the notion of a single person or two person team being able to make a decent native app isn’t too far-fetched.

But a single person making a decent web app seems to be a fantastical notion. Hell, you rarely even see big teams making decent web apps these days.

I would like to see that change. And there are two ways to make that change happen.

We need more better apps #

It’s clear that whatever we’re doing now, whatever it is that passes as standard practice in the industry, isn’t resulting in a high number of great web apps.

Which is fine. Our job isn’t to make great web apps or websites. The job is to make whatever the client or employer wants us to make. If they have bad taste, the outcome will be in bad taste. Arguing against that is pointless and counterproductive.

But the best way to get the client to ask for better apps, made within the bounds of the resources that are available to them, is to have more examples of great web apps, made by modestly sized teams.

This should be doable. Right? After all, a single person can make a great native app. So we should be able to figure out a way for small teams to make great web apps. Right?

Right?

Anyway, I believe in you all. It can be done. But I do think we’re at a point where we’re going to have to admit that it’ll only be done by doing something different from the way we’ve been doing things so far.

We need to talk more about the better web apps that are already out there #

Web dev is thoroughly in bed with money, more so than the native app ecosystem which has a long history of small- to medium-sized software houses. Web dev was born in the dot-com financial bubble and has been riding VC money and big tech money ever since, to a degree that pays very little attention to the proverbial “little guy”. A lot of the online web dev community just sounds like a bunch of MBAs that just happen to be using a different set of buzzwords.

Web dev social media discourse is almost entirely about:

Whether any of the stuff people work on is actually good barely gets a mention.

So, I’d like to challenge us (mostly myself, but you are more than welcome to try as well) to talk more about the good apps we see and use. The more we remind each other of the well-made apps that exist, the more likely we are to make more apps like them and the more likely our employers and clients are to want something like them.

The Recap #

So to recap:

I would like us to be making more better web apps, please and thank you. I don’t really care how we make them, but they do need to be genuinely good.

Because it’s the exemplars that define the practice.

I would also like us to talk more about the good apps that are out there. I’m guessing that there is a bunch of them out there that I don’t know about. We should know about them.

A genuinely good web app will guide us and help us convince our clients and employers to follow suit.

Which will lead to more better web apps; creating a virtuous cycle. And we like those because they’re, y’know, virtuous.

The way to get there is for us to focus on the outcomes. What matters is the end result: the site, the service, the app. What matters less is the particular approach, architecture, testing strategy, or even programming language. Once we have more exemplars, their commonalities will become more and more obvious and new approaches will fall out from that.

Make cool web things. Then talk about them. Find cool web things. Then talk about why they’re cool. Let the exemplars drive the field; don’t let the discourse drag us down.