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

41–50 of 88 posts

Re: Building websites with lots of little HTML pages

#41

Post by stevage »

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 complicated it got. Each “list” of posts needed a slightly different set of data. And each one had a different sort order. What I thought was going to be “stick a bunch of s in the DOM, and show hide some based on the current filter” turned into lots of data-x attributes, per-list sorting logic, etc. I realized quickly this wasn’t a trivial, progressively-enhanced feature. I didn’t want to write a bunch of client-side JavaScript for what would take me seconds to write on “the server” (my static site generator).

This is pretty trivial to implement in any framework.

Generally speaking, I find most of the "You don't need Javascript and frontend frameworks, just write static HTML!" posts reflect the skillsets of their authors. Me, I never really did any site-generation or server-side rendering stuff, so writing everything in VueJS + JavaScript is the easy way.

Re: Building websites with lots of little HTML pages

#42

Post by jiggawatts »

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/

Re: Building websites with lots of little HTML pages

#43

Post by endemic »

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

Re: Building websites with lots of little HTML pages

#44

Post by dredmorbius »

The one element so far I dislike out of this is having search redirect to a new page.

This is something SPAs are doing as well, though in the case of, say Google Web Search (last I used it directly, which is months if not years ago). Namely, when I begin typing a search the currently-displayed content blanks out.

Why is this annoying?

Because often what I'm typing is being prompted by that content, and if I can't continue to view it as I'm typing my search I lose that context and my train of thought.

So: embed your search directly in every page on your website, rather than having it be a separate page. It's fine for the results page to redirect elsewhere, and if the search mechanics need that page to function, so be it (that's what form submissions are all about).

But other than that, I like the implementation, after realising that it was the blogpage and site themselves which were the demonstration. (I'm ... slow like that sometimes.)

Re: Building websites with lots of little HTML pages

#45

Post by ricardobeat »

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…

> doing things "the hard way" from scratch

In the current landscape doing things "the hard way" in plain JS is often simpler than with React. You will give up reactivity, testability, declarative rendering, and the ability to hire any passersby, in exchange for not having to deal with a rube goldberg contraption of hooks, dependency tracking, query caches and state management, with a complex build system. Terrible idea for a team. For a bunch of tabs in your blog? Probably worth the trade.

That said, the problems he describes would occur with React/Vue as well since they are a result of mixing a statically generated site with client-side rendering logic. It would not, in fact, be trivial without changing the server.

> Me, I never really did any site-generation or server-side rendering stuff

> I find [...] reflect the skillsets of their authors

now I'm unsure if this is satire...

Re: Building websites with lots of little HTML pages

#46

Post by gwern »

alberth wrote: post #27
andypants wrote: post #26

Earlier quoted context omitted.

View transitions api, it's pretty new: https://developer.chrome.com/docs/web-platform/view-transiti...

Surprisingly, Firefox of all browsers doesn't support it. https://caniuse.com/view-transitions

That's a pretty major deal breaker for OP to leave out of his post touting it as something to build everything in your site on (especially for a tech blog)! Does it at least have a polyfill story? I see no mention of how to make it work on, uh, the other 15% of browsers worldwide, CanIUse is telling me.

Re: Building websites with lots of little HTML pages

#48

Post by dredmorbius »

pavlov wrote: post #17
dredmorbius wrote: post #7

What were the arguments in favour of SPAs in the first place? I'm finding it interesting that most of the top HN submissions (by popularity) matching "single page app" are critical, not positive. First 15 follow, all but 5 are negative: - You probably don't need a single-page app ( https://journal.plausible.io/you-probably-dont-need-a-single... ) 816 points | 6 years ago | 499 comments - A single-page app is almost a…

That’s also because they were not called SPAs for the first 15 years of the web. The very first technology for building “SPAs” was Java Applets. Corel released a web-based office suite already in 1997, and it was practically an applet for each app. This was replaced by Flash because Macromedia did an incredible job of getting Flash Player preinstalled on every desktop computer. If you wanted to deliver a rich and sea…

Appreciate the history lesson. And yes, I was there for all of that (though not engaged in Web-app development).

One of the first AJAX apps I recall was the original Gmail. That was a revolution in what the browser could do, followed fairly shortly by others (notably Google Earth which launched about the same time).

SPAs simply to deliver relatively static content however seem ... a poor fit. I'll note that HN itself is LLML.

Which leaves my original question: what specifically was the selling point of SPAs, or Flash, or early AJAX? Because despite having live through that the emergence was both sufficiently diverse (a number of different approaches) and gradual that I don't have a sharp recollection of what that was.

Re: Building websites with lots of little HTML pages

#49

Post by bob1029 »

ricardobeat wrote: post #45
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…

> doing things "the hard way" from scratch In the current landscape doing things "the hard way" in plain JS is often simpler than with React. You will give up reactivity, testability, declarative rendering, and the ability to hire any passersby, in exchange for not having to deal with a rube goldberg contraption of hooks, dependency tracking, query caches and state management, with a complex build system. Terrible id…

> Terrible idea for a team.

I disagree, but I am 100% with you on the imperative for structure and order in the codebase.

A typical angle - and it used to be very good - is that vanilla JS doesn't offer a good way to organize common code or impose some sort of structure. I find this to be at the heart of "wont work with a team" arguments. This is no longer the case and hasn't been for some time now (~10 years):

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

Re: Building websites with lots of little HTML pages

#50

Post by AgentME »

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

React doesn't necessarily mean SPAs. It has great support for server-side rendering and that was a big part of why React became more popular than other client-side JS frameworks of the time.
Post reply on HN