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

51–60 of 88 posts

Re: Building websites with lots of little HTML pages

#51

Post by _benton »

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…

Modern JS frameworks work in this same way. You just create a form and provide the action which corresponds to one you define in your route file. It even still works without client side JS!

Re: Building websites with lots of little HTML pages

#52

Post by internetter »

gwern wrote: post #46
alberth wrote: post #27

Earlier quoted context omitted.

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.

If you use it in a browser that doesn't support view transitions, the pages just don't animate. no harm no fowl

Re: Building websites with lots of little HTML pages

#53

Post by moron4hire »

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…

This is good up to a point. If you have only a medium amount of CRUD-like data jn a basic structure in a single user context, this is fine. But when you get into complex relationships, collaborative editing, and unique visual representations of data, this guess right out the window.

The easiest example is probably also the first app to really sell dynamic web apps to the populace: Google Maps. There were meeting applications before Google Maps, and they operated much as you describe--through HTTP round trips--and they sucked. As a user, it was such a pain in the ass to wait for those things to rerender after every click. As a developer, it was such a pain in the ass to field those complaints from those users and know--barring some new invention in browser tech that nobody saw coming (XMLHttpRequest in Internet Explorer)--there really wasn't anything you could do about it.

It's true that a lot of sites go over board with their interactions. But that's not the same thing as needing to ditch asynchronous requests completely.

Re: Building websites with lots of little HTML pages

#54

Post by joeguilmette »

freedomben wrote: post #19
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…

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 some questionable design choices, it was in general a breath of fresh air in terms of UI.

I’d like to hope that they’ll fix it, but I know they won’t.

Re: Building websites with lots of little HTML pages

#56

Post by codazoda »

arnley wrote: post #6

Views transitions are very useful in content-first websites. I've used them extensively when working on https://stack.lol Try and navigate through pages, or change the language, and you'll get these neat effects "for free". Frameworks like AstroJS also help a lot as they facilitate using view transitions.

This site doesn't work well on desktop Safari either. Clicking things doesn't seem to do anything but a few seconds later I'll see some movement. I suspect something is wildly broken or I just don't understand the navigation.

Re: Building websites with lots of little HTML pages

#57

Post by stevage »

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…

>In the current landscape doing things "the hard way" in plain JS is often simpler than with React.

I'm not sure what "simpler" means to you.

It is extremely simple to create and deploy a framework based app; `npm create vue` give it a name, answer a few questions or accept the defaults.

I find programming in such an environment very "simple", because the framework is hiding a lot of complexity.

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

All I can say is: if you have a codebase that has those issues, then the alternative implementation without a framework would be much more difficult to manage.

It's true that Webpack can be very complex to configure, but out of the box configuration gets you pretty far.

Re: Building websites with lots of little HTML pages

#58

Post by holoduke »

nchmy wrote: post #39
holoduke wrote: post #28

Earlier quoted context omitted.

You can also have both. Our apps are all spa. Bundled in single js, html and and js file. But we also have an ssr app runner that contains hundreds of thousands cached static html pages. Initial page load is from the ssr. Further interaction pure clientside. This way you have best app like experience and maximum seo. Setup is maybe 400 lines of code.

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.
Post reply on HN