Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building websites with lots of little HTML pages

blog.jim-nielsen.com

Post reply on HN
Print view View original

61–70 of 88 posts

Re: Building websites with lots of little HTML pages

#61

Post by mablopoule »

ahallock wrote: post #55

I love the how he simulates the hamburger menu with a page navigation. It just feels so wholesome in a sea of complex JS frameworks

I haven't seen it mentioned here, but one other classic trick for hamburger menu is to use a checkbox, and let CSS handle the rest.

Something like:

  
    
    Some icon here
    My menu here
and then use the `:checked` CSS selector to display or not the hamburger menu, you can see it working in my (very barebone :D) website [1]. Note that this implementation is not keyboard-navigable because the input is not visible, I should fix it someday.

[1] https://www.marc-monchablon.fr/

Re: Building websites with lots of little HTML pages

#62

Post by netsharc »

Ouch, the back button becomes "Let's move backwards through all your mouse clicks".

Open menu (marvel at the animation), close menu -> hitting back means "reopen menu". Clicking through the tabs, and hitting back means navigating through them again, backwards.

I guess hijacking the link with window.location.replace can mitigate this, but the "Javascript is evil!"-Amish web-dwellers will scream at me.

Re: Building websites with lots of little HTML pages

#63

Post by reportgunner »

netsharc wrote: post #62

Ouch, the back button becomes "Let's move backwards through all your mouse clicks". Open menu (marvel at the animation), close menu -> hitting back means "reopen menu". Clicking through the tabs, and hitting back means navigating through them again, backwards. I guess hijacking the link with window.location.replace can mitigate this, but the "Javascript is evil!"-Amish web-dwellers will scream at me.

Hey I'll take that over the back button not doing anything any day.

Re: Building websites with lots of little HTML pages

#64

Post by MonkeyClub »

jiggawatts wrote: post #42
bob1029 wrote: post #11

Old school web tech is the best. I still reach for multipart/form-data every day. Many of my web applications do not even have javascript. I hope at some point the original pattern is re-discovered and made popular again because it would make things so much snappier: 1. Initial GET request from user's browser against index and maybe favicon. 2. Server provides static/dynamic HTML document w/ optional JS, all based up…

> some incredibly shocking statistics I recently had a discussion with some "web developers" that just... couldn't understand how a web application could interact with the server without JavaScript and a REST API. They had never heard of traditional web forms! They didn't even know that was an option. That blew my mind. PS: Look into https://htmx.org/

A definite +1 on HTMX, which removes a lot of the necessity for frontend stuff for most simple and semi-complex use cases.

Re: Building websites with lots of little HTML pages

#65

Post by nchmy »

joeguilmette wrote: post #54
freedomben wrote: post #19

Earlier quoted context omitted.

I'm increasingly getting to this point as well. I think modern webtech is incredible in many ways, and if properly used could be pretty great but overall and for the most part we are pretty terrible at it. I've started to dread using SPAs because I know it's going to be sluggish and load megabytes of junk, and will still require frequent page reloads when clicking stuff Even though ostensibly it should not. There's a…

Yes, SPAs are absolutely horrid. I tried to use HEY Calendar and the iOS app is just so absurdly slow I went back to the native iOS calendar app. Maybe it speeds up their dev time but a native app should not feel like a (poorly engineered) web app. Every click loads for a second or two and sometimes it hangs for even longer. I grew to dread adding and managing events. It’s a shame because even though the app made som…

When did you try hey calendar? I've never used anything from hey, but saw a lot of griping about its performance, and eventually saw that they apparently addressed the primary issues.

Re: Building websites with lots of little HTML pages

#66

Post by nchmy »

holoduke wrote: post #58
nchmy wrote: post #39

Earlier quoted context omitted.

Would you mind elaborating some more on how this works?

Basically serverside you have a simple route app that is able to run the web applications through a headless chrome instance. The output is cached in static html files. Now when the initial site is served to the end users browser from then on all interactions are all dynamic. This setup works for all kinds of stacks. Angular, vue, react or just custom. The logic is pretty simple. No bloated layers of complexity.

Interesting, thanks very much.

To clarify, the headless chrome is because it's ultimately a js-rendered app, so you just pre-render all the routes on the server to get the final html, cache that, then serve the html on any first request. Then when the app is loaded in the browser, it just does everything client-side?

Re: Building websites with lots of little HTML pages

#67

Post by SigmundurM »

I really like the idea!

But an instant drawback I see is keyboard accessibility.

The focused element is lost whenever you navigate to a new page, meaning I have to tab all the way through the menu again to get to where I was.

An example: I tab 4 times to get to the open menu "button", press enter, and then I have to tab 4 times again to actually enter the menu.

Re: Building websites with lots of little HTML pages

#68

Post by Matumio »

endemic wrote: post #43
stevage wrote: post #41

I did not find this very convincing. I suspect it has to do with the author being very comfortable with site-generation tools, and not super comfortable with JavaScript. They don't mention any frameworks (React, Vue etc) so I suspect the JavaScript they write is doing things "the hard way" from scratch. > My first impulse was to have a list of posts you can filter with JavaScript. > But the more I built it, the more…

It’s rough for the old timers because as consumers of the web, we’re forced to use SPAs that have objectively worse UX. And sites are built that way now “because it’s how everyone does it.”

The sad thing is, there is no real obstacle to building a fast SPA. It's certainly not harder than to do it all "the old way". But you have to pay attention to performance.

If you just implement as many features as you can in as little time as possible, then the outcome will be something like Confluence, I guess, where you wait several seconds to load a documentation page you wanted to just read, not even edit.

Re: Building websites with lots of little HTML pages

#70

Post by holoduke »

nchmy wrote: post #66
holoduke wrote: post #58

Earlier quoted context omitted.

Basically serverside you have a simple route app that is able to run the web applications through a headless chrome instance. The output is cached in static html files. Now when the initial site is served to the end users browser from then on all interactions are all dynamic. This setup works for all kinds of stacks. Angular, vue, react or just custom. The logic is pretty simple. No bloated layers of complexity.

Interesting, thanks very much. To clarify, the headless chrome is because it's ultimately a js-rendered app, so you just pre-render all the routes on the server to get the final html, cache that, then serve the html on any first request. Then when the app is loaded in the browser, it just does everything client-side?

Indeed. Thats how it works. Of course when your website is pure html you can simply return the html content. No need to go through a headless browser.
Post reply on HN