Weird things engineers believe about Web development

I wrote most of this post sometime in 2022 but I think it holds up alright in 2024 so I decided to publish it for posterity. I don’t really like doing posts like this—I’d much rather share some innocuous learnings or tips but it turns out I have opinions too 😓 Sorry!

2024-02-21: I’ve added a few reflections at the end of the post.

2024-04-27: Developpez.com has produced a French translation of this post.

Since I quit Mozilla and went back to full-time Web development, I’ve discovered a few surprises. It turns out Web development is actually pretty hard, Web developers are actually very smart, and some of these frameworks and techniques we mocked as browser engineers aren’t so bad. Oops.

At the same time, it turns out some Web developers have ideas about browsers and the Web that, as a former browser engineer and standards editor, I’m a bit dubious of.

Here are a few of the things that surprised me.

  1. “Web browser engineers know Web development really well”
  2. “The people who make Web specifications know Web development really well”
  3. “Web developers know Web development really well”
  4. “Browsers aren’t made to run SPAs”
  5. ”MPAs will replace SPAs”
  6. “All sites should work without JavaScript”
  7. “Web development shouldn’t need a build step”
  8. “My blog is representative of Web development at large”

“Web browser engineers know Web development really well”

It’s easy to imagine that Web browser engineers, who write the code that makes up the Web platform, must know the Web inside-out like no-one else.

The trouble is, writing Web browsers is hard.

Most browser engineers focus on a particular area and know it really well with only a superficial understanding of other areas. Furthermore, browser platform engineers are writing C++ and Rust code all day long with a smattering of very simple JavaScript test cases. On top of that, they contribute to one massive respository where someone else takes care of all the tooling.

As a result, in their day jobs browser engineers are not fighting webpack, not trying to understand full-page TypeScript errors (they’ve got C++ template errors to fill that hole in their lives), not trying to get Safari on iOS to behave like other browsers, not struggling with CSS at scale, not trying to evaluate if the latest SSR/SSG/island framework is worth investing in, not refactoring massive JS codebases for more optimal chunking, not filing exasperated issues on GitHub because the latest version of one of their dependencies broke their app, not trying to get all their tools to agree on ESM vs CJS, and not losing sleep over whether or not they chose the right state management approach or if they should rewrite the entire thing for the tenth time over.

In short, they’re not doing Web development day in and day out so they know much less about real-world Web development than Web developers probably expect.

Now the engineers working on browser developer tools and the browser front-end often are using JS day-to-day and certainly have more awareness of the issues, but it’s still a few degrees removed from regular Web development. For example, they only need to target a single browser engine’s platform features, and often only a single browser version (being able to use the new and shiny features without worrying about compatibility is amazing), don’t need to worry about bundle size, or servers, or being offline, or so many other issues that make Web development hard.

Obviously some browser engineers have hobby projects, but the constraints on a hobby project are a world apart from being in a startup where you live or die by the success of your Web app.

I started my career in graphic design and Web development and even after I started contributing to Firefox I worked at a Web development company in Osaka for a time and produced some Web apps at Mozilla Japan too. However, after I quit Mozilla and got back into Web development full-time I was shocked at how much it had changed and how little I knew about it.

My experience as a browser engineer has been incredibly useful in Web development not least because I know where to look, who to ask, and where to file bugs, but I’d be kidding myself if I said that being a browser engineer automatically qualified me as a Web developer.

During my time at Mozilla, the Firefox OS days were by far the most enjoyable. We had internal teams building real-world mobile Web apps that we, as the platform team, had to debug and make successful as our highest priority. I saw how transitionend events could be unreliable and cause Web apps to be buggy and overly complicated and so I proposed and implemented the transitioncancel event and Web Animations’ Animation.finished promise.

But even working side-by-side with Web developers could not prepare me for actually being a full-time Web developer again. For the most part browser engineers just operate in a different world from Web developers and might not be the Web developer superheroes we imagine them to be.

”The people who make Web specifications know Web development really well”

Ok, but surely the people working on Web standards and specifications (who, it turns out, are mostly browser engineers) must be well-versed in Web development, right?

Back in 2012, Brendan Eich pointed out that, “Standards-making like law-making is definitely sausage-making” referring to the following quote from John Godfrey Saxe:

Laws, like sausages, cease to inspire respect in proportion as we know how they are made.

As a Web developer, it’s easy to imagine a group of people, infinitely wise about all things related to Web technology, making calm, rational decisions based on the technical merits of each proposal balanced against a thorough understanding of industry needs.

That illusion typically won’t last your first working group meeting. Despite the best of intentions, sometimes decisions get made based, at least in part, on one person’s charisma or forceful personality, on who happens to be in the room at the time, on how tired everyone is, or, dare I suggest, maybe even someone’s need to ship a feature in order to fill out their promotion packet.

That sounds very cynical so let me make two clarifications.

Firstly, the folks on these groups are well-meaning, wonderful people. Furthermore, they are often aware of their limitations and try their best to elicit Web developer feedback. Unfortunately, I’ve yet to see a group do this very successfully. There are Twitter/X polls, for example, but they tend to only be answered by the Web developers on the bleeding edge and are easily skewed by who spreads the word about the poll.

Secondly, I haven’t had much experience with WHATWG specs like HTML and DOM where decisions appear to be made asynchronously (“any decisions made during in-person meetings are to be considered non-binding”—WHATWG meetings), but my impression is that they seem to make better decisions. Folks like Anne van Kesteren, Simon Pieters, and Domenic Denicola probably know the Web better than anyone else on the planet. But even that is not the same as knowing Web development.

”Web developers know Web development really well”

As a browser engineer it’s really satisfying to ship a new platform feature. There are articles about it on Smashing Magazine and CSS tricks and Twitter/X goes abuzz with the news. It’s easy to think that now the whole world now knows about this great new advance in the Web’s capabilities.

At one point a few years ago, a few of us in Mozilla’s Japan team decided to interview local Web developers in Tokyo to learn what developer tools they would benefit from.

The results were surprising.

Many didn’t know about new CSS features that had shipped 10 years ago. What’s more, even when we told them about them, they didn’t seem too excited. They were doing just fine with jQuery and WordPress, thank you.

Instead, they were having trouble with things like, “When I show clients a site in responsive design mode, if the window doesn’t have a mockup of an iPhone around it, clients can’t grasp that they are looking at a preview of how the site will look on a smartphone. I really need that iPhone mockup.”

As a browser engineer involved in developing new Web standards I was a little disappointed but my lasting impression was of the constraints on these folks who are making their living from shipping Web sites and Web apps.

Unlike people working on browsers or well-funded Silicon Valley startups, many of these people are working for little shops with considerable pressure to deliver something quickly and then move onto the next project in order to pay the bills. They don’t have the luxury of spending a morning tinkering with upcoming technologies and instead reach for tried and trusted solutions they have experience with.

”Browsers aren’t made to run SPAs”

Another surprise from moving from browser development back to Web development was some of the assertions about how browsers work.

When I worked on animations, I was surprised at how many people believed that some animations “run on the GPU” (the browser can offload some animations to a separate process or thread that updates animations using the GPU to composite or even paint each frame but it doesn’t offload them to the GPU wholesale) but that was a fairly minor misunderstanding compared to some of the other ones that get thrown around like, “browsers aren’t made to run SPAs (single page applications)“.

I believe the argument here is that originally browsers would load content off the network, progressively laying it out and rendering it and have been heavily optimized for this. Dynamic content came later and so has been less heavily optimized.

Having worked on a browser on and off for nearly two decades I’m not convinced this is the case, or at least not anymore.

After all, the Firefox front-end and developer tools are, in effect, SPAs. The developer tools in particular are written using React and Redux and are in every sense an SPA.

To the argument that browsers are deficient at handling complex and long-lived DOM trees with dynamic changes made via JavaScript, the browser itself stands in contradiction to that claim.

An argument could be made that on mobile browsers aren’t optimized to run SPAs. After all, on Android, Firefox switched from an HTML rendered browser chrome to a native browser chrome in order to improve performance. I’m not in a position to comment on what the particular performance constraints were that lead to that change, but a blog from that time suggests it was related to improving app startup time and panning and scrolling performance, neither of which point to browsers being deficient at handling SPAs compared to other architectures.

“Ok, so maybe browsers can handle complex long-lived DOM trees with frequent dynamic changes, but SPAs tend to have large JS bundles that are slow to download and parse, blocking the initial render.” That’s a fair argument, but it’s an argument for smaller render-blocking initial bundles, which applies to equally to your average WordPress site, not an argument that browsers are somehow unsuited to running SPAs.

MPAs will replace SPAs”

While we’re talking about SPAs and “the one true way to write Web apps”, a more recent variation on the “browsers can’t handle SPAs” take is, “MPAs (multi-page applications) will replace SPAs”.

I’m pretty excited about MPAs. More specifically, as someone who is involved with a lot of animation specs, I’m excited by the view transitions spec spec. It’s something we wanted to do at Mozilla for a while, particularly during the Firefox OS days, and made a proposal to that end. Kudos to Jake and others for finally making it happen.

View transitions were originally implemented for SPAs but have been adapted to work for MPAs and to the extent that they make multi-page sites more enjoyable they are a very welcome addition.

However, building on the “SPAs are bad” thinking, there seems to be a tendency to assume that MPAs are the future and SPAs are on the way out.

Unlike the earlier points in this post, my surprise at this take is not based on my experience with working on browsers, but on my more recent experience with working on Web apps.

First though, what do we even mean by MPAs?

My understanding is that whereas SPAs are characterized by having a long-lived DOM tree or two that are frequently updated by script, MPAs primarily update content by navigating to different HTML resources served from the network. These don’t have to be topmost navigations—it could be by navigating an <iframe>, for example. Similarly, SPAs might use <iframe>s as a means of chunking but there’s a difference in how content is typically updated.

By this definition, Google Docs is an SPA since although each document is served as a separate resource, most of the time you’re interacting with the one document that is continually updated via JavaScript. YouTube would probably be considered an MPA but it might actually be implemented as an SPA in order to smooth out changes in content, intercepting navigations and replacing the content via script—that is, until view transitions can help with that.

In either case, my surprise at the idea that MPAs will replace all SPAs is simple: How would Figma or Photoshop for Web work as an MPA? Or Slack, or Discord, or Google Maps?

I’m currently working on an offline-first mobile Web app that stores data locally and syncs to the server. Wanting to be on the forefront of Web tech I investigated how we could embrace MPAs.

To keep a long story short, if we’re to retain our desired UX which has independently navigable panels and our offline-first requirement, we could introduce some <iframe>s to partition out some of the functionality into separate HTML requests (as opposed to separate script chunk requests) and we could probably even pre-render some chunks sometimes. The trouble is it would increase the complexity ten-fold (two-way sync becomes three-way sync for a start) while providing no benefit to customers whatsoever—instead it would almost certainly lead to more bugs, more latency, and shipping features more slowly.

Given that our app is not currently released I realise that’s a fairly weak argument since no-one can look at the app and suggest a better approach so I’m just asking you to trust me on this one. I tried. I really did. It’s just not the right architecture for this particular app and I’m surprised by the suggestion that everything should be an MPA.

”All sites should work without JavaScript”

Continuing on our theme of Web development best practices, building a site that works without JavaScript is an admirable goal. Doing so probably means it degrades gracefully, has no JS blocking the initial render, and works on a wide range of browsers. But I’ve been surprised to see how often this becomes dogmatic: “all sites should work without JavaScript”.

I guess it’s easy to come to this conclusion if your site is able to work without JavaScript (see “My blog is representative of Web development at large”) but it feels a little myopic to me.

I’ve mentioned Figma and Photoshop for Web before; it’s hard to imagine how they could work without JavaScript. Likewise for a browser’s developer tools. Or even Parapara Animation!

Furthermore, although many advocates against JS are also concerned about accessibility, JavaScript is often necessary in order to make an app accessible.

One thing the accessibility folks at Mozilla taught me about keyboard navigation was that Tab navigation should be fairly coarse. That is, you use Tab to navigate to the control group (e.g. toolbar) and then use the arrow keys to move within that group. That allows you to move around an app more quickly without having to Tab through every single control first. WAI calls this a “roving tabindex”.

However, in order to implement this kind of coarse-grained keyboard navigation you’re going to need JavaScript. If you want to make the arrow-key based navigation two-dimensional, you’re going to need even more JavaScript. Maybe one day we’ll fill that gap in the platform (looking at you, focusgroup) but for now you should feel no shame about using client-side JavaScript to make your app accessible.

Honestly, I think some sites should use more JavaScript.

As an example, the Eleventy documentation seems to avoid using client-side JavaScript for the most part. As Eleventy supports various templating languages it provides code samples in each of the different languages. Unfortunately, it doesn’t record which language you’ve selected so if your chosen language is not the default one, you are forced to change tabs on every single code sample. A little client-side JavaScript here would make the experience so much more pleasant for users.

Update (2024-01-11): It seem that Eleventy have taken this feedback onboard and fixed this. Thank you! 🙏

“Web development shouldn’t need a build step”

While just about everything in this post is from 2022, while tidying it up I couldn’t resist adding just one more recent idea that surprised me.

Our final stop on the Web development dogma train is a view that’s come up a few times but still surprises me. The most recent rendition I saw went something like, “we’re so blind and stubborn that we’ve ended up with a hugely complex toolchain but we really should be able to ship Web apps without a build step at all”.

As someone who spent most of his career working with compiled languages the desire to go without a build step is surprising. The things compiler engineers do amaze me. They are geniuses who layer clever optimization on top of clever optimization transforming my very average code into something unrecognizable and insanely fast. If anything, I want more of that compiler magic in my Web development.

Obviously JavaScript presents its own challenges since it can be very hard to statically determine the side effects of a certain operation but I’m sure there’s still more room to explore in optimizing JavaScript at compile time.

Web developers seem to agree on optimizing image assets and pre-generating static HTML pages where it makes sense, why is there resistance to optimizing code assets too? Why defer computation and I/O to runtime that can be done once at build time? If nothing else, I have no desire to ship my megabyte-long comments cursing iOS Safari to every user on every request.

Maybe 2024 will be the year where client-side Rust/WASM frontend frameworks start to get traction and if that’s the case, we’d better get used to having a build step!

”My blog is representative of Web development at large”

A number of the points above could possibly be summarised as “My blog is representative of Web development at large”. That is, coming from browser engineer to Web developer, most of the notions about Web development that have surprised me are the result of people extrapolating their experience of the Web in a way that doesn’t overlap with mine.

Since I left Mozilla over four years ago, I’ve spent most of my time working on a Web app. I’ve also spent way too long setting up this blog. Surprisingly, with regards to tooling, architecture, or Web platform features used, I’ve found almost no overlap between the two. It’s almost as if blogs and apps exist in entirely disparate corners of the Web development landscape.

My app is a mass of TypeScript code, my blog uses almost no client-side JavaScript. My app is hugely complicated by two-directional data sync, my blog is read-only. My app uses webpack, Playwright E2E tests, a component framework, and a state management library, my blog uses none of those.

If you’re mostly engaged with one or the other, it’s easy to think that’s what Web development looks like. In truth, Web development is probably more diverse than any of us imagines.

Conclusion

There are other notions I’ve found surprising but the common theme in the above is it’s easy to assume our experience of the Web is representative of Web development in general.

Moving from browser development back to Web development has been humbling because it’s so much broader and deeper than I knew. I have a much greater respect for Web developers, especially those at little Web shops and startups that live or die by the success of their Web apps.

If that’s you, I hope reading this post gives you confidence that even if browser engineers, standards editors, and other Web developers insist on a particular way of doing things, you know your constraints better than anyone else and you’re probably doing things just fine.

Reflections a couple of months later

Since posting this article I’ve received some very useful feedback which I’ll summarise below:

  • Some people pointed out that the background behind a lot of anti-JavaScript and anti-SPA sentiment is a reaction to seeing static sites being rendered as React SPAs which is a very poor fit. That was helpful context that I hadn’t appreciated.

  • Others clarified that the “no build step” argument is more about local development and not about production assets. That makes a lot of sense and is something I can appreciate.

    My point wasn’t to say you should have a build step but simply to say that coming from browser development I was surprised at the anti-build-step sentiment because I’m used to compilers and I’d be interested in seeing what more they can do for us.

  • Some people took issue with some of the later points because I failed to clearly summarise my main contention. Here it is:

    I worked on browsers for over a decade and am still involved in Web standards and browser development. I love the platform and encourage others to make full use of it.

    My contention is with the absolute terms with which Web development best practices are sometimes asserted. Web development social media can be a fierce place—something I was sheltered from when working on browsers.

    I’m certainly not trying to establish a new dogma but just to push back and say that using JavaScript, writing an SPA, and having a build step is sometimes the right choice and you shouldn’t feel bad about it.

Comments

Art

I love this article. So on point and very funny.

The part about the things that browser devs don’t have to deal with really touched my soul (and is hilarious).

My only complaint is that you don’t have a Mastodon/Fediverse account that I could follow for more of this!

Brian Birtles

Thank you so much Art! That’s very encouraging!

I’m afraid I’ve been holding out to see which Twitter alternative wins before joining in. Hopefully I’ll get there sometime this year!

There’s an RSS feed, though, if that helps: https://birtles.blog/feed.xml

Artur Kot

Many great insights! I love that the article is balanced and touches on the fact browsers are super complex software which doesn’t always work as we may expect.

Re. “anti JavaScript club”. I believe it’s about React (and similar libraries/framework) being misused for things like blogs or some e-commerce sites where there’s no clear benefit of them. People seem to treat it as a default for whatever they do on the web and can’t see simpler alternatives for some reason.

Mike

What do SPA and MPA stand for?

DDR

Mike: “Single-Page App” and (after some thinking, probably) “Mulit-Page App”?

Brian Birtles

Thanks Artur!

Re. “anti JavaScript club”. I believe it’s about React (and similar libraries/framework) being misused for things like blogs or some e-commerce sites where there’s no clear benefit of them. People seem to treat it as a default for whatever they do on the web and can’t see simpler alternatives for some reason.

That makes a lot of sense and is worth making a fuss about! Hopefully we can do it without reducing it to blanket statements about all apps.

Brian Birtles

Thanks DDR, yes, that’s right. Sorry, I annotated those abbreviations with <abbr> but that’s not very obvious and not usable on mobile either. I’ve updated the article to expand those abbreviations now.

Anon

Web developers seem to agree on optimizing image assets and pre-generating static HTML pages where it makes sense, why is there resistance to optimizing code assets too?

Imagine if browsers dropped support for all image formats and replaced it with a super optimized .simg. Now every time you want to change an assets there is now an extra build step where you have to “compile” your images into a format the browser would load. This adds extra friction to the development process versus just being able to load unoptimized assets. The same thing applies to code. It is useful for iteration speed if developers do not have to go through a build step. When developers want to then ship this code to the world they then can run an build step to optimize it.

For “Web development shouldn’t need a build step” this article spends too much time thinking the problem here is “build step” where the actual problem is with “need.”

Brian Birtles

When developers want to then ship this code to the world they then can run an build step to optimize it.

I see, so you’re saying you’d like to avoid a build step during local development but use one when shipping? I can see that being useful—not having to strip TS types when creating little test cases (because type annotations was available), for example, would be great. That’s not the take I was surprised by, however. It was people saying that there should never be a build step (and we’re silly for not realising that).

Personally, when it comes to app building, I’d rather not have local development and production deviate too fundamentally since I’ve experienced how problematic that is while working with Astro. But that’s just my preference!

Flaki

This was excellent! (miss u Brian, hope u well <3)

SPAs and frameworks could dispel 90% of my discontent towards them if just once I saw a React app that upon viewing the source (or opening devtools) wasn’t such an obtuse, obfuscated 〈div〉-soup, but looked like an actual wepage (-skeleton).
I miss view source :‘(

Brian Birtles

Hi Flaki! Great to hear from you mate! Thank you!

Yeah, I hear you. Although I think CSS shoulders more of the blame for the explosion of divs than SPAs—I’m always adding “just one more flexbox wrapper” in order to get the layout right. But maybe that’s just because I’m uniquely bad at CSS (which is true).

(Out of curiousity I just compared the amount of nested divs on my SPA with my sister’s WordPress site and it looks like WordPress pays bigger div-idends 😅)

Maybe Web components will save us from this one day 🤞

Tim

Summary: Use the right tool for the job.

Dan

I enjoyed this; thank you. Most of my apps today are SPAs, and not a single one of them has used React. In fact, I prefer to keep that level of abstraction to only when necessary. I find I use so little of what those frameworks do that it becomes counter-productive–not to mention nearly impossible to maintain for things like PCI Compliance.

Bruno

Hotwire takes the framing approach to the next level. It really is how I would like vanilla web development to be. It doesn’t try to take over everything, it just tries to fill in the gaps.

Daniel Rotter

Great Article! There are two arguments I’d like to add.

SPA/MPA: I am not saying that everything should be a MPA, but in my opinion it is problematic that SPAs are the default for many developers, and MPAs are not even evaluated.

That kinda leads to my second argument: Bundle size. I agree that this is a fair argument in either case, but SPAs tend to be bigger, because there is certain builtin browser functionality that needs to be rebuilt, like e.g. the browser history and back button. That is definitely not a problem for dev tools, but for many other types of web apps it is. What usually happens then is that some kind of library is included helping with that, which increases the bundle size.

Jay

The reply by Anon above covers part of this, but I want to add more to the story. I will quote them here for context:

For “Web development shouldn’t need a build step” this article spends too much time thinking the problem here is “build step” where the actual problem is with “need.”

This is an excellent argument, but it’s only part of the issue. Before I get into it, I acknowledge that there are going to be apps that need a build step because their business logic is simply the entirety of the app. PhotoShop is a particularly relevant example. All of the canvas painting, layering, brushes, patterns, paths, masks, filters, etc. that you do in photo editing just has to be done client-side in a mass of bespoke code (JavaScript, WASM, or otherwise). It’s inescapable because browsers do not have painting operations natively built in.

However, most apps are not PhotoShop (or HTML5 games, or several other classes of applications with tons of unavoidable JS). Discord, another example mentioned in the article, doesn’t need a gargantuan blob of script for what it does. It’s just chat! It boils down to a collection of UI components and a persistent connection to chat servers. You can strip it down to a lean MVP (Minimal Viable Product) without gobs of JS because most of what Discord needs does in fact already exist natively in the browser. The app’s business logic literally just glues those native pieces together.

I’m going to hand-wave away the fact that most apps can’t live eternally as MVPs. Using “MVP” as a starting point means that your app, in all likelihood, can actually be shipped without a build step at all. In the best cases, the entire product lifecycle can stick with the same constraints. And that, in my understanding, is what Anon’s comment is really getting at under the subtext.

There’s also this bit from the article that I partially agree with (I have a caveat to add) and is directly related to the build-step theme:

Honestly, I think some sites should use more JavaScript.

Yes, most sites should use more JavaScript, but caveat emptor: they should use more JavaScript smartly and less JavaScript poorly. A perfect example of “poor utilization of JavaScript” is encryption primitives. If you have any encryption algorithms written in JavaScript, delete them immediately and replace with the browser-native Web Crypto API. It’s supported on everything since 2021! Get yourself out of the habit of supporting dead browsers. If not for eliminating useless JavaScript, then for the sake of security.

If you prefer TypeScript, hoist the type annotations to JSdoc comments. Let your IDE do the type checking and your browser do the runtime with vanilla JS. All the benefits of TS and no build step required.

In case it wasn’t clear, “The more JS removed, the less JS overall == less code to build.” Bundling your JS is appealing when you have 15,000 source files, but not when you have 15. HTTP compression makes comments for 10K lines of JS inconsequential. Eventually you get to a point where the build step is entirely superfluous. Then it’s only getting in your way and adding negative value to both the developer and user experience.

You are probably not building PhotoShop. If you are, more power to you, and I hope your compiler does an excellent job with optimizations. But for everyone else, especially “little shops with considerable pressure to deliver something quickly and then move onto the next project in order to pay the bills”, do the sane thing and rapidly deliver value to your clients by using what the browser provides. Don’t succumb to the inner-platform effect. In the end, you can probably avoid the build step, too.

The fundamental issue is that the dogma is pushing for a one-size-fits-all solution for many different (often unrelated or competing) concerns. It’s premature optimization. The root of all evil.

Brian Birtles

Tim wrote:

Summary: Use the right tool for the job.

Sounds good!

Brian Birtles

Dan wrote:

Most of my apps today are SPAs, and not a single one of them has used React. In fact, I prefer to keep that level of abstraction to only when necessary. I find I use so little of what those frameworks do that it becomes counter-productive–not to mention nearly impossible to maintain for things like PCI Compliance.

Thanks Dan! Yes, I can relate to that. I’ve certainly found writing my own router has suited my needs better for the apps I’ve worked on.

Brian Birtles

Bruno wrote:

Hotwire takes the framing approach to the next level. It really is how I would like vanilla web development to be. It doesn’t try to take over everything, it just tries to fill in the gaps.

I love it when frameworks don’t try to take over everything! I’ll have to look into Hotwire more closely some time.

Brian Birtles

Daniel Rotter wrote:

Great Article! There are two arguments I’d like to add.

SPA/MPA: I am not saying that everything should be a MPA, but in my opinion it is problematic that SPAs are the default for many developers, and MPAs are not even evaluated.

Thanks! Yes, I think starting with an MPA is a great default position for most apps.

That kinda leads to my second argument: Bundle size. I agree that this is a fair argument in either case, but SPAs tend to be bigger, because there is certain builtin browser functionality that needs to be rebuilt, like e.g. the browser history and back button. That is definitely not a problem for dev tools, but for many other types of web apps it is. What usually happens then is that some kind of library is included helping with that, which increases the bundle size.

Yes, I feel the constant fight against bundle size to the point where I’ve made a hobby of forking libraries and removing everything I don’t need 😅 I find that everywhere, however. For example, the headless UI components are very well made and I’d love to use them as-is but boy will they swell your bundle size!

Brian Birtles

Hi Jay, thanks for your very thoughtful comment. I very much agree with using the platform for all its worth. After all, I spent so many years building the platform and I hope developers use it!

I also agree with removing support for “dead browsers”. It’s so incredibly satisfying to take a library, remove all the IE support code and see it shrink to almost nothing!

I literally spent all last week rewriting a “drawer” component to use the now-widely available <dialog> element so I can benefit from its focus handling and save a few bytes of JS along the way.

I’ve used JSdoc in a few projects, but I find it can get very cumbersome so I wouldn’t want to go all-in on it if I can help it!

I hadn’t heard of the inner platform effect before but now that I’ve looked it up I’ve certainly seen it many times! I think you’ve just given me the vocabulary to articulate why there are some services I am hesitant about using too heavily.

Personally, the apps I’m building and the ones I’m most interested in building in future really are Photoshop-style apps so I don’t think I’ll be avoiding a build step any time soon!

The fundamental issue is that the dogma is pushing for a one-size-fits-all solution for many different (often unrelated or competing) concerns.

Yes, you’ve nailed it. The real thrust of this post, especially the second half, was just expressing alarm at the dogmatism surrounding Web development—something I never really encountered in my safe little world of browser development!

There really are so many kinds of Web sites and Web apps with different constraints and requirements. I’m certainly not interested in establishing a new dogmatism but rather I wanted to say that using JavaScript, writing an SPA, and having a build step is sometimes the right choice and you shouldn’t feel bad about it.

Jay

It’s indeed a very difficult problem! Managing complexity is the name of the game, after all.

Thank you so much for the extra context. And by the way, great work on the article. I came into it kind of skeptical and left with a valuable new perspective.

Blair

Hi Brian, this is somewhat off-topic but anyway: the content width “jumps” when resizing the window, and another part of the content “jumps” into view along with that.

zakius

SPA aren’t bad per se, just need to be done well and only when needed, when you respect these two rules they work just fine and basically all the problems we experience with them comes from not respecting these rules
Sure, SPA is an overhead, especially painful when user needs multiple tabs (maybe we could move some of the code to service workers to eliminate the dupliaction?), but when it’s not dozens of megabytes worth of JS it works quite well anyway

regarding webSITES working without JS let’s be honest: most of them don’t need JS at all (at least for the guest/visitor/reader view) and the onlyimportant (from users’ perspective) thing that may use JS are some forms: comment or contact but these can be progressively enhanced or (when embeded comments system is used) use oneliner to load that embed on demand so the main load happens in a blink of an eye, sure you won’t be able to navigate the way you described but the site will be usable, you can add this enhancement and that’s fine too, it’s lightweight and doesn’t cost much to run, but the site won’t completely break if that script doesn’t load for whatever reason

and a bit offtopic but: I miss Firefox, the powerful browser that allowed me to do everything comfortably and efficiently, a browser that wasn’t doing things the wrong way just because someone else does it wrong, nowadays it feels like we’re constantly fighting instead of working together
sure, other browsers fight me more but that just doesn’t feel right

Max Paperno

Hello Brian, good post. I don’t usually comment on blogs, but spot-on.

It is disturbing when I hear that standards and implementations are being made based on arbitrary reasons. This stuff is supposed to be Computer Science (emphasis mine :), not “opinions and schedules.” Not saying I’m surprised, but it’s not s sustainable strategy.

Opinions change all the time for arbitrary reasons, while “science” is supposed to be a lot more stable. Not that “science facts” can’t change, but rather that the decisions/changes are supposed to be based on actual observation, not just some person’s or group’s “feelings” or “guess”.

As a “grumpy old geek” (“using” and programming for > 40 years now) I’m also alarmed/annoyed with what seems to be a growing trend in general of app[plication] developers being disconnected from how their product is actually used.

I mean it’s always been an issue, and I’ve been guilty of it myself, no doubt. But seems with the “recent” (for me 10 years is “recent,” ok? :-) influx of newly opinionated coders, this lesson has been forgotten by some/many. The most general example of this, I think, is prioritizing shipping new product features (often not even requested) vs. fixing known bugs/solidifying the core code base. (If what I read on some other blogs is true, then as an “ex-Mozzie” you know what I’m talking about.)

This attitude spreading to core standards and implementations is not a good thing. On a mature platform the trend should be going the other way. I’d argue browser-based presentation (vs. “OS based” or “native” for example) is pretty mature at this point, at least in terms of widespread usage (for better or worse). And in general things have indeed come a very long way (I started Web dev. in 1995). I can only hope that the “science” part gets an edge over the… errr.. “BS” parts (let’s just call it what it is).

Maybe not a perfect example, but this can be somewhat related to the evolution of C++. We started out with multiple “flavors” which slowly (oh so slowly) coalesced into what is now, arguably, an actual core and standard library which is implemented by all vendors. This basically had to happen for C++ to survive as a viable language/technology in a rapidly growing field of alternatives (most of those will be forgotten within 10-20 years).

Anyway, a lot of this is/can be mitigated by the end user being able to switch browsers… as long as they’re able to do so (ahem… Apple… ahem…). As long as any of those browser devs are paying attention!

Cheers,
-Max

Brian Birtles

zakius wrote:

SPA aren’t bad per se, just need to be done well and only when needed… Sure, SPA is an overhead, especially painful when user needs multiple tabs (maybe we could move some of the code to service workers to eliminate the dupliaction?), but when it’s not dozens of megabytes worth of JS it works quite well anyway

Absolutely. SPAs can and should support multi-tab browsing well by using workers to handle shared concerns like synchronization. We now have SharedWorker, BroadcastChannel and Web Locks in all modern browsers making this coordination much easier.

regarding webSITES working without JS let’s be honest: most of them don’t need JS at all (at least for the guest/visitor/reader view) and the onlyimportant (from users’ perspective) thing that may use JS are some forms: comment or contact but these can be progressively enhanced … but the site won’t completely break if that script doesn’t load for whatever reason

Yes, I think this is the sort of case that many who oppose requiring JS have in mind: requiring JS where it shouldn’t be required. Unfortunately I feel some people overstate their case by suggesting that all sites should not require JS.

and a bit offtopic but: I miss Firefox, the powerful browser that allowed me to do everything comfortably and efficiently, a browser that wasn’t doing things the wrong way just because someone else does it wrong…

Yes, I’m a Firefox user and it works very well for me (especially the awesome bar and container tabs).

Brian Birtles

Max Paperno wrote:

Hello Brian, good post. I don’t usually comment on blogs, but spot-on.

Hi Max! Thanks for taking the time to write a comment.

It is disturbing when I hear that standards and implementations are being made based on arbitrary reasons. This stuff is supposed to be Computer Science (emphasis mine :), not “opinions and schedules.” Not saying I’m surprised, but it’s not s sustainable strategy.

Yes, standards organizations are a frustratingly human enterprise!

Opinions change all the time for arbitrary reasons, while “science” is supposed to be a lot more stable. Not that “science facts” can’t change, but rather that the decisions/changes are supposed to be based on actual observation, not just some person’s or group’s “feelings” or “guess”.

I agree there could be more rigor involved in many decisions. Some people have genuinely been trying to fix this. You can see some ideas in this Twitter/X thread, for example.

I feel that one of the struggles is that the incentives are not always well-aligned. In many companies, engineers get promoted for shipping features, particularly features that help their company—perhaps because they make the company’s websites/apps work better, or make the browser itself work better, or simply provide good PR.

Researching developer needs thoroughly is not necessarily rewarded, particularly if the outcome is that we should do the hard work of fixing existing features, rather than the glamorous work of shipping new ones.

Fortunately things aren’t as bad as they could be simply because so many people involved in the standards process (both engineers and their managers too) really care about the Web and doing the right thing. Unfortunately, if they’re not daily struggling to build Web apps, they might not know what is best, and their employer may not be incentivized to allow them to find out.

I mean it’s always been an issue, and I’ve been guilty of it myself, no doubt. But seems with the “recent” (for me 10 years is “recent,” ok? :-) influx of newly opinionated coders, this lesson has been forgotten by some/many. The most general example of this, I think, is prioritizing shipping new product features (often not even requested) vs. fixing known bugs/solidifying the core code base. (If what I read on some other blogs is true, then as an “ex-Mozzie” you know what I’m talking about.)

Absolutely. I wish we could fix existing text input issues like this one before implementing new features like EditContext but there sometimes isn’t a lot of appetite for that.

Maybe not a perfect example, but this can be somewhat related to the evolution of C++. We started out with multiple “flavors” which slowly (oh so slowly) coalesced into what is now, arguably, an actual core and standard library which is implemented by all vendors. This basically had to happen for C++ to survive as a viable language/technology in a rapidly growing field of alternatives (most of those will be forgotten within 10-20 years).

Certainly competition with other runtimes could really help to solidify parts of the Web but I suppose that only works to the extent that browser vendors need the Web to win. Fortunately, projects like Interop 2023 have been helping to reduce browser inconsistencies and that certainly helps to make the Web a more competitive platform.

Simon Pieters
Simon Pieters

This is great! People who know web development well and browser development are great to have at the web standards table, but not all standards have that luxury.

Brian Birtles

Thanks Simon! That’s very kind. That’s for your amazing work on fixing and improving the Web.

Leave a reply

Most markdown like **bold** and _italic_ is supported.

Never shown. Only used for looking up your gravatar.

Optional
https://