5 ms·

Stitch together lots of little HTML pages with navigations for interactions

90 points by OuterVale 5mo ago

cluckindan 5mo ago
This is close to how things used to be, in the time before server-side includes.
jazzypants 5mo ago
[flagged]
- OuterVale 5mo ago
  You're pre-emptive hostility seems rather unwarranted. This article is my usual go-to and lists several reasons why JavaScript might not be available, and thus why you shouldn't take it for granted: https://piccalil.li/blog/a-handful-of-reasons-javascript-wont-be-available/ https://piccalil.li/blog/a-handful-of-reasons-javascript-won...
  - mr_mitm 5mo ago
    I feel compelled to add: - the user explicitly disabled JavaScript - the browser does not support JavaScript (I sometimes view websites using elinks) AFAIK screen readers also work better without JavaScript, so it's also an accessibility issue.
    - jazzypants 5mo ago
      JavaScript doesn't effect screen readers at all unless you dynamically add content without the proper ARIA roles. It is trivial to correct. As I just said, users who explicitly disable JavaScript cannot even use Google Search. Why should I accommodate those users when even Google refuses to do so? They are actively choosing to have a limited web experience. The vast majority of the internet is completely broken for them.
  - jazzypants 5mo ago
    [flagged]
    - ivan_gammel 5mo ago
      >A spotty connection hasn’t loaded the dependencies correctly - Either they load or they don't. How would the dependencies load "incorrectly"? Let‘s say you have 5-7 dependencies to load, but 3 of them timed out because your train entered the tunnel. Your app ends up in incorrect state, fails silently and UX degrades unpredictably. This is where the conversion often drops visibly and the reason SSR is now a go-to solution for any marketing website.
      - jazzypants 5mo ago
        Why am I loading dependencies from 5-7 places? Why is my website not using a bundler if it has so many varied dependencies? Why do we not expect the user to understand that they are in a tunnel without internet? Regardless, this isn't really restricted to the usage of JavaScript. The website would likely have pretty bad UX if only half of the CSS loaded correctly, but no one programs defensively around it being absent.
        ivan_gammel 5mo ago
        Have you ever developed an enterprise scale frontend applications optimized for conversion targets? It feels like you have not. You may ship your own code in a bundle, yes. All integrations come on top of that. That chatbot, tracker, A/B testing logic etc - all are loaded separately from your service provider CDN. An user opening a web page is not expecting a full-blown app with multi-second loading times. If that happens, they bounce, and you loose revenue. Web is supposed to have very short time to first content paint and very short time to interactive, the shorter, the better, less than 0.5s is the goal. It can deliver that, if built properly. Many SPAs, bulky JS apps are built this way for developer convenience, not for end users. The only real use case for SPA is when you deal with a lot of local data. A spreadsheet, document or image editor, a diagram tool (but then wasm is probably a better choice). You may say, you are not building enterprise grade frontend. But if you are small enough, you don’t need SPA either.
- rikroots 5mo ago
  > when it's much easier to just build a nice website using JavaScript I'm currently building a web-based tool that uses dynamic forms for UI, without the help of of a framework (yeah I know; I have reasons). This is the result: https://github.com/KaliedaRik/sc-filter-builder/blob/main/js-modules/form-builder.js https://github.com/KaliedaRik/sc-filter-builder/blob/main/js... It's not "easier" using Javascript; raw Javascript websites are a nightmare to build, maintain and reason about. It is "easier" with Javascript + current-favourite-framework-of-the-day. Also: accessibility, SEO, the all-new Generative Engine Optimization (GEO) thing, etc.
- voidUpdate 5mo ago
  Why wouldn't google work without javascript? Just use some forms, submit the text the user entered, get back a page with the search results...
  - danaw 5mo ago
    OP is right. a quick google (hehe) shows you they require it as of 2024.
    - voidUpdate 5mo ago
      But you don't need JS to make a search engine work. I'm pretty sure I've used links2 in the past to google things just fine. Google Search would work fine without JS, Google just wants to track people
      - Diti 5mo ago
        Google is an advertising company. Not a search engine company.
  - jazzypants 5mo ago
    They don't want your patronage if they can't track you and commodify you.
- danaw 5mo ago
  i'd say it really depends on the website you're building and what you define as "using javascript" are you comparing fully client rendering vs SSR without client JS at all? are you building a marketing site or a dashboard type tool? there is subtly to why each decision would be made based on these. i think HN tends to demonize JS because we're all well aware of how bad the state of a lot of web apps have become with developers only knowing react and having no background in web fundamentals or accessibility. i see no reason to completely shun JS, just use it intentionally and not reflexively.
  - jazzypants 5mo ago
    Thank you so much for having one of the few measured takes in this thread. I'm not advocating for throwing React and NPM at every problem, but a little bit of hand-written JS is rarely an issue.
- atwrk 5mo ago
  Lots of important points already posted, from reliability over accessibility to SEO. To add a personal reason: speed. I hate slow computer things. If I open a page I e.g. don't have to use for work or similar (like Google Ads or Linkedin or similar horror shows), and loading the page takes longer than a second, I just bounce. I built and maintain a static site for a company, and it's just wonderful. It opens instantly (which the search engines like), rebuilding and deploying is trivial, I am not forced to update every week because the JS framework has a new vuln.(There are a few dynamic, JS-based parts that load dynamically and fail gracefully.)
  - jazzypants 5mo ago
    None of this refutes my post whatsoever. The amount of JavaScript to open a hamburger menu is literally around 500 bytes. It can easily gracefully degrade just like your last sentence said. You're going to load much, much more than that by following TFA. It loads an entire new HTML page! This argument just doesn't work here.
    - atwrk 5mo ago
      There's nothing to refute in your post; you only told the audience that you don't get OP, and people tried to explain the appeal to you. What you do with that information is your thing.
      - jazzypants 5mo ago
        None of what you said explained the appeal of OP's technique! Using JavaScript doesn't have to affect your reliability, accessibility, SEO, or any of the things you said. How am I supposed to do anything with useless information? If anything, hiding the hamburger menu behind an HTTP response is *less accessible*!
        c-hendricks 5mo ago
        Not to mention the article's menu "close" button relies on JS to send you back to the correct page, and doesn't work with open in new tab / window even with JS enabled.
camillomiller 5mo ago
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.
- OuterVale 5mo ago
  I'm unsure why you think this was an LLM-suggested solution.
  - danaris 5mo 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 5mo ago
  Why do you think this is LLM?
- CraigJPerry 5mo 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.
- sheept 5mo 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/Global_attributes/popover#nesting_popovers https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
bingemaker 5mo 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
- OuterVale 5mo ago
  That'd be the View Transition API. Specifically, it is a cross-document view transition. https://developer.chrome.com/docs/web-platform/view-transitions/cross-document 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.
  - bingemaker 5mo ago
    Thanks
- deleted 5mo ago
  [deleted]
meander_water 5mo ago
Isn't this just HATEOAS as espoused by libraries like htmx, datastar, hotwire etc. https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/
- sheept 5mo 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 5mo ago
    HATEOAS does not require interacting with an API.
  - nchmy 5mo ago
    As the article in the comment you are replying to makes very clear, this couldn't be more wrong
- nchmy 5mo 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.
alex1sa 5mo ago
[dead]
danaris 5mo 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 5mo ago
  I agree, but its not intrinsic to the approach of less JS and more pages.
- carlosjobim 5mo 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 5mo 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 5mo 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 5mo ago
Wow, I love it when people discover these NEW ways of doing things.
Havoc 5mo 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/ https://docs.astro.build/en/concepts/islands/
avipeltz 5mo ago
isnt this just the old school way of making a static website? its nice and chill and peaceful
- est 5mo ago
  the go-to method is using frames.
- Brendinooo 5mo 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 5mo 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 5mo 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/ https://vittorioromeo.com/
dTal 5mo 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 5mo 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 5mo 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.

90 points by OuterVale 5mo ago

cluckindan 5mo ago

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

jazzypants 5mo ago

[flagged]

OuterVale 5mo ago
You're pre-emptive hostility seems rather unwarranted. This article is my usual go-to and lists several reasons why JavaScript might not be available, and thus why you shouldn't take it for granted: https://piccalil.li/blog/a-handful-of-reasons-javascript-wont-be-available/ https://piccalil.li/blog/a-handful-of-reasons-javascript-won...
- mr_mitm 5mo ago
  I feel compelled to add: - the user explicitly disabled JavaScript - the browser does not support JavaScript (I sometimes view websites using elinks) AFAIK screen readers also work better without JavaScript, so it's also an accessibility issue.
  - jazzypants 5mo ago
    JavaScript doesn't effect screen readers at all unless you dynamically add content without the proper ARIA roles. It is trivial to correct. As I just said, users who explicitly disable JavaScript cannot even use Google Search. Why should I accommodate those users when even Google refuses to do so? They are actively choosing to have a limited web experience. The vast majority of the internet is completely broken for them.
- jazzypants 5mo ago
  [flagged]
  - ivan_gammel 5mo ago
    >A spotty connection hasn’t loaded the dependencies correctly - Either they load or they don't. How would the dependencies load "incorrectly"? Let‘s say you have 5-7 dependencies to load, but 3 of them timed out because your train entered the tunnel. Your app ends up in incorrect state, fails silently and UX degrades unpredictably. This is where the conversion often drops visibly and the reason SSR is now a go-to solution for any marketing website.
    - jazzypants 5mo ago
      Why am I loading dependencies from 5-7 places? Why is my website not using a bundler if it has so many varied dependencies? Why do we not expect the user to understand that they are in a tunnel without internet? Regardless, this isn't really restricted to the usage of JavaScript. The website would likely have pretty bad UX if only half of the CSS loaded correctly, but no one programs defensively around it being absent.
      - ivan_gammel 5mo ago
        Have you ever developed an enterprise scale frontend applications optimized for conversion targets? It feels like you have not. You may ship your own code in a bundle, yes. All integrations come on top of that. That chatbot, tracker, A/B testing logic etc - all are loaded separately from your service provider CDN. An user opening a web page is not expecting a full-blown app with multi-second loading times. If that happens, they bounce, and you loose revenue. Web is supposed to have very short time to first content paint and very short time to interactive, the shorter, the better, less than 0.5s is the goal. It can deliver that, if built properly. Many SPAs, bulky JS apps are built this way for developer convenience, not for end users. The only real use case for SPA is when you deal with a lot of local data. A spreadsheet, document or image editor, a diagram tool (but then wasm is probably a better choice). You may say, you are not building enterprise grade frontend. But if you are small enough, you don’t need SPA either.
rikroots 5mo ago
> when it's much easier to just build a nice website using JavaScript I'm currently building a web-based tool that uses dynamic forms for UI, without the help of of a framework (yeah I know; I have reasons). This is the result: https://github.com/KaliedaRik/sc-filter-builder/blob/main/js-modules/form-builder.js https://github.com/KaliedaRik/sc-filter-builder/blob/main/js... It's not "easier" using Javascript; raw Javascript websites are a nightmare to build, maintain and reason about. It is "easier" with Javascript + current-favourite-framework-of-the-day. Also: accessibility, SEO, the all-new Generative Engine Optimization (GEO) thing, etc.
voidUpdate 5mo ago
Why wouldn't google work without javascript? Just use some forms, submit the text the user entered, get back a page with the search results...
- danaw 5mo ago
  OP is right. a quick google (hehe) shows you they require it as of 2024.
  - voidUpdate 5mo ago
    But you don't need JS to make a search engine work. I'm pretty sure I've used links2 in the past to google things just fine. Google Search would work fine without JS, Google just wants to track people
    - Diti 5mo ago
      Google is an advertising company. Not a search engine company.
- jazzypants 5mo ago
  They don't want your patronage if they can't track you and commodify you.
danaw 5mo ago
i'd say it really depends on the website you're building and what you define as "using javascript" are you comparing fully client rendering vs SSR without client JS at all? are you building a marketing site or a dashboard type tool? there is subtly to why each decision would be made based on these. i think HN tends to demonize JS because we're all well aware of how bad the state of a lot of web apps have become with developers only knowing react and having no background in web fundamentals or accessibility. i see no reason to completely shun JS, just use it intentionally and not reflexively.
- jazzypants 5mo ago
  Thank you so much for having one of the few measured takes in this thread. I'm not advocating for throwing React and NPM at every problem, but a little bit of hand-written JS is rarely an issue.
atwrk 5mo ago
Lots of important points already posted, from reliability over accessibility to SEO. To add a personal reason: speed. I hate slow computer things. If I open a page I e.g. don't have to use for work or similar (like Google Ads or Linkedin or similar horror shows), and loading the page takes longer than a second, I just bounce. I built and maintain a static site for a company, and it's just wonderful. It opens instantly (which the search engines like), rebuilding and deploying is trivial, I am not forced to update every week because the JS framework has a new vuln.(There are a few dynamic, JS-based parts that load dynamically and fail gracefully.)
- jazzypants 5mo ago
  None of this refutes my post whatsoever. The amount of JavaScript to open a hamburger menu is literally around 500 bytes. It can easily gracefully degrade just like your last sentence said. You're going to load much, much more than that by following TFA. It loads an entire new HTML page! This argument just doesn't work here.
  - atwrk 5mo ago
    There's nothing to refute in your post; you only told the audience that you don't get OP, and people tried to explain the appeal to you. What you do with that information is your thing.
    - jazzypants 5mo ago
      None of what you said explained the appeal of OP's technique! Using JavaScript doesn't have to affect your reliability, accessibility, SEO, or any of the things you said. How am I supposed to do anything with useless information? If anything, hiding the hamburger menu behind an HTTP response is *less accessible*!
      - c-hendricks 5mo ago
        Not to mention the article's menu "close" button relies on JS to send you back to the correct page, and doesn't work with open in new tab / window even with JS enabled.

camillomiller 5mo ago

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.

OuterVale 5mo ago
I'm unsure why you think this was an LLM-suggested solution.
- danaris 5mo 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 5mo ago
Why do you think this is LLM?
CraigJPerry 5mo 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.
sheept 5mo 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/Global_attributes/popover#nesting_popovers https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

bingemaker 5mo 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

OuterVale 5mo ago
That'd be the View Transition API. Specifically, it is a cross-document view transition. https://developer.chrome.com/docs/web-platform/view-transitions/cross-document 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.
- bingemaker 5mo ago
  Thanks
deleted 5mo ago
[deleted]

meander_water 5mo ago

Isn't this just HATEOAS as espoused by libraries like htmx, datastar, hotwire etc. https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/

sheept 5mo 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 5mo ago
  HATEOAS does not require interacting with an API.
- nchmy 5mo ago
  As the article in the comment you are replying to makes very clear, this couldn't be more wrong
nchmy 5mo 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.

alex1sa 5mo ago

[dead]

danaris 5mo 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 5mo ago
I agree, but its not intrinsic to the approach of less JS and more pages.
carlosjobim 5mo 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 5mo 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 5mo 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 5mo ago

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

Havoc 5mo 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/ https://docs.astro.build/en/concepts/islands/

avipeltz 5mo ago

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

est 5mo ago
the go-to method is using frames.
Brendinooo 5mo 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 5mo 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 5mo 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/ https://vittorioromeo.com/

dTal 5mo 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 5mo 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 5mo 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.