This is the source code for the blog: https://github.com/jimniels/blog, in case anyone was looking for it
Building websites with lots of little HTML pages
31–40 of 88 posts
Re: Building websites with lots of little HTML pages
#32Interesting thoughts. I’ve been using both Hotwire and HTMX recently. The swapping in of different html is making a come back.
Yeah, this is `manual` htmx.
Re: Building websites with lots of little HTML pages
#33Old 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…
What exactly do you mean by "part of the same context"?
The same HTTP request/response pair. In some languages there are types like HttpContext that contain both sides.
Re: Building websites with lots of little HTML pages
#34Earlier 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
It's not that surprising if you consider that all the browsers on that page, except for Firefox and Safari, are Chrome-based
Re: Building websites with lots of little HTML pages
#35What 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…
Macromedia's Rich Internet Application (RIA) concept aimed beyond mere navigation, delivering purposeful, desktop-like experiences.
Re: Building websites with lots of little HTML pages
#36the web is so built for this. when you go to sites like this it just feels right. we could have had this as our future instead of the craziness of javascript and nextjs and react. now some new devs dont know html exist. they think react is the web.
The designers make us commit war crimes with JavaScript. Can’t even use native form elements.
Re: Building websites with lots of little HTML pages
#37Earlier quoted context omitted.
One spanning the world, perhaps. Even ... widely.
It's a great idea, but I don't see it working long-term. At some point I suspect big tech will aggregate and centralize and kill off these little sites. They may even start implementing technology that locks them down so that you can only visit them with approved devices. Hopefully Netscape refuses to go along with it, though I do worry about their business model's long term viability.
Netscape's too big to fail, yo.
Re: Building websites with lots of little HTML pages
#38Views 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.
> https://stack.lol/
The page layout is broken in Firefox 136.0.1 but okay in Chrome 134.0.6998.89 =(. I don't have time to debug what CSS feature might be causing this problem.
Re: Building websites with lots of little HTML pages
#39Old 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…
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?
Re: Building websites with lots of little HTML pages
#40Old 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…
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.
> Bundled in single js, html and and js file. But we also have an ssr app runner ...
This is exactly the kind of complexity and bloat the GP wishes we can get rid of so that we can return to simpler web applications with forms that do a simple POST and get the updated web page in response.