Stitch together lots of little HTML pages with navigations for interactions

https://blog.jim-nielsen.com/2026/small-html-pages/

by OuterVale • 3 months ago

90 33 3 months ago

cluckindan• 3 months ago

This is close to how things used to be, in the time before server-side includes.

I dunno, it wants to challenge our dependence on javascript and then to make it work it needs to inject a “back” behavior into a normal link?

Js and fallbacks for menus is a solved issue. this is just another form of LLM dunning krueger derangement where you think the LLM-suggested solution is novel because you haven’t encountered it before, or because you fundamentally don’t understand the underlying problems that we have already solved.

OuterVale2• 3 months ago

I'm unsure why you think this was an LLM-suggested solution.

danaris2• 3 months ago

...because the opening line of the blog post says he's been "building websites with LLMs", and then attempts to cutely redefine that abbreviation as "Lots of Little htMl pages" in a parenthetical.

It's, um. Not the best kind of communication, and very easily leads to this kind of misunderstanding.

snowe2010• 3 months ago

Why do you think this is LLM?

CraigJPerry• 3 months ago

I guess it doesn't have to use JavaScript for the back behavior. It could use a server-side rendered referrer if that hasn't been stripped by the browser?

You say that JavaScript and fallbacks for menus is a solved issue but the number of menus that are just an absolute clusterfuck is ridiculous on the web today. They're really not a solved issue, Progressive enhancement is hard to do. Genuinely hard in some cases.

On balance, while this is not without flaws, it's interesting. Accessibility, deep linking, reduction in cognitive load for the developer. There's some merit here.

sheept2• 3 months ago

Yeah, I don't think the menu should've been a separate page. It can be made JavaScript-less as a dialog opened by the popover HTML attributes,[0] and the escape key would be able to close it.

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

nchmy3• 3 months ago

I'm not at all against using some js for the menu, but a native dialog or popover is definitely a nice idea here.

drawfloat• 3 months ago

Could be achieved with a checkbox input and a hidden div too

bingemaker2• 3 months ago

I have a question: After clicking on a blog in the listing page ("Collective Speed is..."), the page navigated to that particular blog. What CSS transitions are used to convert that title to a header? I saw some animation which pushed that title to become a header. How does that work? I'm curious

OuterVale2• 3 months ago

That'd be the View Transition API. Specifically, it is a cross-document view transition. https://developer.chrome.com/docs/web-platform/view-transiti...

Really awesome new(ish) feature of the web platform. It doesn't yet have full support in Firefox unfortunately, but is supported in Chrome and Safari.

bingemaker2• 3 months ago

Thanks

meander_water• 3 months ago

Isn't this just HATEOAS as espoused by libraries like htmx, datastar, hotwire etc.

https://htmx.org/essays/hateoas/

sheept2• 3 months ago

No, they're not related. The submission's article is about CSS view transitions. HATEOAS seems to involve interacting with an API, but linking between pages on a blog does not require this.

regularfry• 3 months ago

HATEOAS does not require interacting with an API.

nchmy3• 3 months ago

As the article in the comment you are replying to makes very clear, this couldn't be more wrong

nchmy3• 3 months ago

When I first saw the title, I thought "great! Someone else has (re)discovered hypermedia".

But they have gone in a completely bewildering direction. Rather than swap/morph html fragments in, they're doing full page navigations and using view transitions to make it look smooth.

Worse, they are manipulating the history to cover these blasphemous tracks.

Datastar would make this particularly simple - just include whatever menu/nav stuff that you need and show/hide/toggle it with a few signals/attributes.

danaris2• 3 months ago

OK...and what does that look like on a desktop browser?

Because if I click on a menu button on a desktop browser, I generally don't expect it to take over the entire page with a menu.

This seems like an example of unhelpfully mobile-centric website design, which has been becoming more prevalent in recent years.

graemep• 3 months ago

I agree, but its not intrinsic to the approach of less JS and more pages.

carlosjobim• 3 months ago

You should of course not have a menu button on a desktop view. There is plenty of space to show the menu without hiding it behind a button.

Maybe it is you who are mobile centric?

alentred• 3 months ago

I just tried it on their website, using the desktop browser, and the experience is absolutely OK: you just get the menu as in any web app, and you can close it to go back, etc. Just an old-school page which is blazing fast ... because it is an old-school page. It renders faster than a typical animation to open a sidebar.

pibaker• 3 months ago

But you don't need to open a menu to navigate to another page on an old school web page. Web pages in the 00s just showed you links to other parts of the website on a navbar that is always there. I agree this website is optimized for phones and works poorly on desktop — there is absolutely no reason to hide your links behind a burger menu when I have more than enough pixels on my monitor for all your links.

sourcecodeplz• 3 months ago

Wow, I love it when people discover these NEW ways of doing things.

Havoc• 3 months ago

I've been trying to steer LLMs towards the Astro framework due to this - the island concept seems like a perfect fit

https://docs.astro.build/en/concepts/islands/

avipeltz• 3 months ago

isnt this just the old school way of making a static website? its nice and chill and peaceful

est• 3 months ago

the go-to method is using frames.

Brendinooo• 3 months ago

Would love to hear anecdata from others but I'd say...not really? I was a kid in those days but there's no way I'd make a server round trip for /menu/ to open a menu.

jstanley• 3 months ago

I agree with what you're saying, of course, simplicity is better, etc.

But the nav on your blog is a terrible example.

Firstly, you don't get to just click on the links to go to where you want to go, you first have to click the three-lines button, even on a desktop with an enormous screen.

And secondly, despite your claims about an "enhanced experience with a modern browser", it seems to work exactly as if there was no enhancement at all? I click the three-lines menu and it takes me to a new page listing the links I can click. The "X" button to "close" the menu navigates me back particularly quickly, but that is all that I can tell that is unusual.

I'm using Firefox 136 on Ubuntu.

And in any event, this is all unnecessary, because you can make a nav by just putting a bunch of links at the top of the page, like HN does.

SuperV1234• 3 months ago

Not a fan of the nav, but loved the transitions. Applied them to my website (bespoke C++ static generator + template library): https://vittorioromeo.com/

dTal• 3 months ago

My god, a "web" of documents - it's brilliant! The best part is the documents can even be on different domains, world wide!

moritzwarhier• 3 months ago

The approach to have a separate page for a website's menu and leveraging bfcache and the CSS view transitions API for a smooth experience is not that traditional though, is it?

I'm only used to seeing menus as separate pages in book-like websites and as comprehensive sitemaps. Or, for very small sites, a "homepage" that also acts as a menu, instead of an on-page MPA menu (think a portfolio website, or Space Jam).

f30e3dfed1c9• 3 months ago

I like it. Simple, fast, easy to use. Much better than most of the web these days, although honestly, that's a regrettably low bar. Most of the web these days is horrible and has been for a while.

Stitch together lots of little HTML pages with navigations for interactions

Related Stories