Tags: page

68

sparkline

Thursday, September 28th, 2023

Introducing Enhance Music — Begin Blog

I also think the number of situations in which an SPA architecture can be recommended is dwindling, chiefly due to how good the web platform has become (and how much better it’s getting every day). And because so much of the rest of the ‘struggle stack’ (transpilers, unique dialects, etc.) was built to get around gaps in the web platform that no longer exist, the use cases for these tools is dwindling in tandem.

This is good news: not only can we avoid piling up transient knowledge about a seemingly endless stream of dependencies, we can also eject from the routine stress of those dependencies changing or breaking under our feet and throwing wrenches into our workflows — all while delivering more robust and performant websites to end users.

Wednesday, September 27th, 2023

Why multi-page apps? | Go Make Things

There are absolutely use-cases for SPAs (media sites, primarily). Most of the other things we use them for make the user experience notably worse or band-aid over the real underlying issues without addressing them.

Wednesday, September 13th, 2023

Multi-page web apps

I received this email recently:

Subject: multi-page web apps

Hi Jeremy,

lately I’ve been following you through videos and texts and I’m curious as to why you advocate the use of multi-page web apps and not single-page ones.

Perhaps you can refer me to some sources where your position and reasoning is evident?

Here’s the response I sent…

Hi,

You can find a lot of my reasoning laid out in this (short and free) online book I wrote called Resilient Web Design:

https://resilientwebdesign.com/

The short answer to your question is this: user experience.

The slightly longer answer…

For most use cases, a website (or multi-page app if you prefer) is going to provide the most robust experience for the most number of users. That’s because a user’s web browser takes care of most of the heavy lifting.

Navigating from one page to another? That’s taken care of with links.

Gathering information from a user to process on a server? That’s taken care of with forms.

This frees me up to concentrate on the content and the design without having to reinvent the wheels of links and form fields.

These (let’s call them) multi-page apps are stateless, and for most use cases that’s absolutely fine.

There are some cases where you’d want a state to persist across pages. Let’s say you’re playing a song, or a podcast episode. Ideally you’d want that player to continue seamlessly playing even as the user navigates around the site. In that situation, a single-page app would be a suitable architecture.

But that architecture comes at a cost. Now you’ve got stop the browser doing what it would normally do with links and forms. It’s up to you to recreate that functionality. And you can’t do it with HTML, a robust fault-tolerant declarative language. You need to reimplement all that functionality in JavaScript, a less tolerant, more brittle language.

Then you’ve got to ship all that code to the user before they can use your site. It might be JavaScript code you’ve written yourself or it might be a third-party library designed for building single-page apps. Either way, the user pays a download tax (and a parsing tax, and an execution tax). Whereas with links and forms, all of that functionality is pre-bundled into the user’s web browser.

So that’s my reasoning. At least nine times out of ten, a multi-page approach is leaner, more robust, and simpler.

Like I said, there are times when a single-page approach makes sense—it all comes down to whether state needs to be constantly preserved. But these use cases are the exceptions, not the rule.

That’s why I find the framing of your question a little concerning. It should be inverted. The default approach should be to assume a multi-page approach (which is the way the web works by default). Deciding to take a JavaScript-driven single-page approach should be the exception.

It’s kind of like when people ask, “Why don’t you have children?” Surely the decision to have a child should require deliberation and commitment, rather than the other way around.

When it comes to front-end development, I’m worried that we’ve reached a state where the more complex over-engineered approach is viewed as the default.

I may be committing a fundamental attribution error here, but I think that we’ve reached this point not because of any consideration for users, but rather because of how it makes us developers feel. Perhaps building an old-fashioned website that uses HTML for navigations feels too easy, like it’s beneath us. But building an “app” that requires JavaScript just to render text on a screen feels like real programming.

I hope I’m wrong. I hope that other developers will start to consider user experience first and foremost when making architectural decisions.

Anyway. That’s my answer. User experience.

Cheers,

Jeremy

Monday, June 12th, 2023

Web Developer Ground Hog Day | Go Make Things

JavaScript is great. I love using it, and it does amazing things. But maybe it’s time we stop repeating these same patterns of development over and over again. Maybe we can use JavaScript more responsibly, and focus more effort on HTML and CSS.

Thursday, April 20th, 2023

Rich Harris: Hot takes on the web 🌶️ - YouTube

I don’t agree with all of these takes-of-varying-spiciness, but Rich Harris is always worth paying attention to.

Rich Harris on frameworks, the web, and the edge

Tuesday, March 28th, 2023

Defaulting on Single Page Applications (SPA)—zachleat.com

This isn’t an opinion piece. This is documentation.

You can’t JavaScript your way out of an excess-JavaScript problem.

Saturday, February 11th, 2023

Streams of Consciousness · Matthias Ott – User Experience Designer

Your website is a way for you to share your stream of consciousness, that temporary and subjective and highly biased snippet of the universe, with everyone else, including your future self.

Friday, February 10th, 2023

Home stream

Ben wrote a post a little while back about maybe organising his home page differently. It’s currently a stream.

That prompted Om to ask is “stream” as a design paradigm over? Mind you, he’s not talking about personal websites:

Across the web, one can see “streams” losing their preeminence. Social networks are increasingly algorithmically organized, so their stream isn’t really a free-flowing stream. It is more like a river that has been heavily dammed. It is organized around what the machine thinks we need to see based on what we have seen in the past.

Funnily enough, I’ve some recent examples of personal homepages become more like social networks, at least in terms of visual design. A lot of people I know are liking the recent redesigns from Adam and Jhey.

Here on my site, my home page is kind of a stream. I’ve got notes, links, and blog posts one after another in chronological order. The other sections of my site are ways of focusing in on the specific types of content links, short notes, blog posts in my journal.

Behind the scenes, entries those separate sections of my site are all stored in the same database table. In some ways, the separation into different sections of the site is more like tagging. So the home page is actually the simplest bit to implement: grab the latest 20 entries out of that database table.

I don’t make too much visual distinction between the different kinds of posts. My links and my notes look quite similar. And if I post a lot of commentary with a link, it looks a lot like a blog post.

Maybe I should make them more distinct, visually. Because I actually like the higgedly-piggedly nature of a stream of different kinds of stuff. I want the vibe to be less like a pristine Apple store, and more like a chaotic second-hand bookstore.

Going back to what Ben wrote about his site:

As of right now, the homepage is a mix of long-form posts, short thoughts, and links I consider interesting, presented as a stream. It’s a genuine representation of what I’m reading and thinking about, and each post’s permalink page looks fine to me, but it doesn’t quite hold together as a whole. If you look at my homepage with fresh eyes, my stream is a hodgepodge. There’s no through line.

For me, that’s a feature, not a bug. There’s no through line on my home page either. I like that.

Why I’m not the biggest fan of Single Page Applications - Manuel Matuzović

I guess the biggest criticism here is that it feels like people who believe in the superiority of single page applications and the entire ecosystem focus more on developer experience (DX) than user experience. That sounds like a dangerous blanket statement, but after all these years, I never had the feeling that the argument “better DX leads to better UX” was ever true. It’s nothing more than a justification for the immense complexity and potentially significantly worse UX. And even if the core argument isn’t DX, other arguments like scalability, maintainability, competitive ability, easier recruiting (“everyone uses React”), and cost effectiveness, in my experience, only sound good, but rarely hold up to their promises.

Thursday, February 2nd, 2023

WebPageTest’s Guiding Principles - WebPageTest Blog

  1. Make the right thing easy
  2. Always answer “so what”?
  3. Close the gap between “something is wrong” to “we fixed it”

Wednesday, February 1st, 2023

We’re all trying to find the guy who did this

Imagine the web is a storefront, React is a hot dog car, and here’s Create React App dressed as a hot dog:

HTML is the cornerstone of the web — so why does creating a “React app” produce an empty HTML file? Why are we not taking advantage of the most basic feature of the web—the ability to see content quickly before all the interactive code loads? Why do we wait to start loading the data until after all the client-side code has finished loading?

Saturday, November 5th, 2022

Negativity bias

When I wrote about my hopes and fears for the View Transitions API, a few people latched on to this sentiment:

If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.

But I also wrote:

If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.

I think it’s worth focusing on that.

Part of the problem is that I gave my hopes and fears an equal airing. But they’re not equally likely.

Take the possibility that the View Transitions API only ships for single page apps, but never ships for regular page transitions. The consequences of that would be big—the API would act as an incentive to build single page apps. But the likelihood of that happening is small. In fact, according to Jake, there’s already an implemention for page transitions in the works at Chrome.

Now what if the View Transitions API ships for pages? The consequences would be equally big—the API would act as an incentive to ditch single page apps and build in a more performant, resilient way. Best of all, the chances of that happening are very large indeed (pretty much a certainty now, given Jake’s update).

So I made a comparison between both of the consequences, which are equally large, but I didn’t make a corresponding comparison of the likelihoods, which are not equally large. Mea culpa!

I should’ve made it clearer that, although the consequences would be really bad if the View Transitions API only supports single page apps, the actual likelihood of that is pretty slim.

That’s probably my negativity bias showing through. (The reason I have a negativity bias is because I am a human. Like, have you ever noticed that if you get feedback on something and 98% of it is positive, you inevitably fixate on the 2%?)

Anyway, the real takeaway here is that if the View Transitions API ships for pages, then the consequences will be really, really good! It would be another nail in the coffin for monolithic JavaScript frameworks slowing down the web. And best of all, the likelihood of this happening is very high!

So let me amend my closing sentences from my previous post:

If the View Transitions API only works for single page apps—which is very unlikely—it could be the single worst thing to happen to the web in years.

If the View Transitions API works across page navigations—which is very, very likely—it could be the single best thing to happen to the web in years.

The glass is half full and it’s only going to get fuller. Time to start planning for a turbo-charged web now.

If you’ve got a website with full page navigations, start thinking about how you’ll be able to apply the View Transitions API as a progressive enhancement to improve the user experience.

If you’ve got a single page app, start thinking about how to ditch a whole bunch of uneccessary dependencies to make a more lightweight foundation of HTML instead of JavaScript, and still get all those slick transitions you get in a single page app!

Time for transitions

I am simultaneously very excited and very nervous about the View Transitions API.

You may know it by its former name—Shared Element Transitions. The name change is very recent.

I’ve been saying for years that some kind of API like this would be brilliant:

I honestly think if browsers implemented this, 80% of client-rendered Single Page Apps could be done as regular good ol’-fashioned websites.

Miriam Suzanne describes the theory of View Transitions succinctly:

Shared-element transitions are designed to work with standard web navigation across multiple page loads, as well as page transitions in ‘single-page’ apps (often called SPAs).

This all sounds brilliant. But the devil is in the implementation details. Right now, the API only works for single page apps. This is totally understandable. For purely pragmatic reasons, single page apps are a simple use case to solve for. It’s going to take a lot more work to get this API to work for multi-page apps (or as we used to call them, websites).

If we get a View Transitions API that works across page navigations, it could potentially turbo-charge the web. It will act as a disencentive to building single page apps—you’d be able to provide swish transitions without sacrificing performance or resilience at the alter of a heavy-handed JavaScript-only architecture.

But if the API only ever works for single page apps (which is the current situation), then it will act as an incentive to make any kind of website into a single page app, regardless of whether it’s actually the appropriate architecture.

That prospect has me very worried indeed.

I’m making my feelings on this known just in case any of the implementators out there are thinking, “Hey, maybe it’s fine that this API only works for single page apps—I’m sure most people would be happy with that.”

If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.

If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.

Update: Jake says:

We’re currently landing code in Chrome for the MPA version.

Very happy to hear that! It’s already in the spec, but it’s good to hear that the implementation isn’t going to lag too much.

Also, read this follow-up.

Monday, October 24th, 2022

The transitional web | Go Make Things

I’ve smelt the same change in the wind that Chris describes here—there’s finally a reckoning happening in the world of JavaScript frameworks and single page apps.

Thursday, October 20th, 2022

Why We’re Breaking Up with CSS-in-JS | Brad Frost

I’ve seen the pendulum swing back and forth many times over my years building on the web. I too feel like there’s something in the air right now, and people are finally acknowledging that most single page apps are crap.

But Brad makes the interesting point that, because they were incubated when profligate client-side JavaScript was all the rage, web components may have ended up inheriting the wrong mindset:

So now the world of web components has egg on its face because the zeitgeist at the time of its design didn’t have such a strong focus on SSR/HTML-first/ progressive enhancement. Had web components been designed in the current zeitgeist, things would almost certainly be different.

Wednesday, September 21st, 2022

Will Serving Real HTML Content Make A Website Faster? Let’s Experiment! - WebPageTest Blog

Spoiler: the answer to the question in the title is a resounding “hell yeah!”

Scott brings receipts.

Tuesday, July 12th, 2022

I don’t care how you web dev; I just need more better web apps – Baldur Bjarnason

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).

An intimation that it wouldn’t be the right solution for this particular problem is taken as an admission of incompetence.

I’ve experienced this. And I think this observation is even more true when it comes to recruitment.

Thursday, June 30th, 2022

10 Years of Meteor

While I’ve always been bothered by the downsides of SPAs, I always thought the gap would be bridged sooner or later, and that performance concerns would eventually vanish thanks to things like code splitting, tree shaking, or SSR. But ten years later, many of these issues remain. Many SPA bundles are still bloated with too many dependencies, hydration is still slow, and content is still duplicated in memory on the client even if it already lives in the DOM.

Yet something might be changing: for whatever reason, it feels like people are finally starting to take note and ask why things have to be this way.

Interesting to see a decade-long perspective. I especially like how Sacha revisits and reasseses design principles from ten years ago:

  1. Data on the Wire. Don’t send HTML over the network. Send data and let the client decide how to render it.

Verdict: 👎

It’s since become apparent that you often do need to send HTML over the network, and things seem to be moving back towards handling as much as possible of your HTML compilation on the server, not on the client.

Monday, June 27th, 2022

SPAs: theory versus practice | Read the Tea Leaves

At the risk of grossly oversimplifying things, I propose that the core of the debate can be summed up by these truisms:

  1. The best SPA is better than the best MPA.
  2. The average SPA is worse than the average MPA.

Tuesday, June 7th, 2022

Introducing Opportunities & Experiments: Taking the Guesswork out of Performance - WebPageTest Blog

WebPageTest just got even better! Now you can mimic the results of what would’ve previously required actually shipping, like adding third-party scripts, switching from a client-rendered to a server-rendered architecture and other changes that could potentially have a big effect on performance. Now you can run an experiment to get the results before actual implementation.