I'm that minutia in your statistics that is still rocking NoScript in 2026, enabling JavaScript on a site-by-site basis, but this is increasingly difficult with the modern web.
Hopefully these and others modern HTML features gain adoption, along with realizing perhaps a Single Page Application isn't necessary in most instances.
I don't often have to write frontend code, but when I do, there is very little in terms of interactivity you cannot do with HTML these days, worst case a little sprinkle of something like HTMX.
Single page applications are one of the most anoying web patterns i know of. Please just let me have one page for each ting to do so i actually can bookmark it properly.
Once backend and frontend became two separate teams frontend people didn't want to keep asking backend to make logic changes for state, so frontend took things into their own hands. The mistake was making it two separate teams.
[−]impulsivepuppet · 2026-08-21 Fri 11:15 UTC ·
link
the frontend team can write a BFF to make all pages render server-side. there is an advocacy group for keeping oauth2 clients out of browsers which gives this idea some _political_ merit. in ways more than one, SPA is not the only solution when a dedicated _frontend team_ is employed.
The separation of teams happened before the BFF pattern came into existence so all frontend engineers became specialists in frameworks like React. Unless you can do it with React, FE's won't touch a BFF or anything else for that matter.
[−]ThunderSizzle · 2026-08-20 Thu 16:52 UTC ·
link
Ive made SPAs in Blazor that make it a point to update the URL whenever a "navigation" occurs. I also made it a point to ensure refreshing or loading the URL restored the state.
It's a small problem compared to the ease of use for development you can gain via Blazor, so I don't see any reason not to solve it.
This is possible and, in my experience building them, the norm. SPAs have routers and update navigation state, including history for browser Back/Forward
It's the norm to try to re-implement browser functionality in JS but it is very far from the norm for the re-implementation to work as well and as reliably as the native browser functionality.
I remember when it was considered ridiculous to have a page take more than 250ms to complete its loading. Now nobody bats an eye at a 25MB page that takes over 30 seconds to load. I'm sticking with the old ways, thank you very much.
This is part of how I judge how well made or how shitty a website is. If it requires scripts from a dozen third parties, then it usually sucks and one can easily recognize when not much effort has been put into making it.
One thing you notice running NoScript is how prevalent Google is.
Even if a site doesn’t monetize with Google Ads, there’s a decent chance it’s pulling a script from ajax.googleapis.com, and Google still knows that you visited the site from the Referer of the script download.
And lucky for Google, browser vendors (including Google) even decided that caches shouldn't work cross origin so this request needs to be made for every site even if you already visited another site that used the same resource.
I got frustrated with sites that should just be documents bolting on a pile of javascript libraries, third-party requests etc so I made a standard for sites that are just documents, and wrote a checker for document-only pages. For SSL, the thing that actually changed the web was browsers flagging non-SSL - probably similar is needed here. https://certifiedweb10.org/ if you're interested.
[−]michaelchisari · 2026-08-20 Thu 22:43 UTC ·
link
The View Transition API makes this even more viable.
> I don't often have to write frontend code, but when I do, there is very little in terms of interactivity you cannot do with HTML these days, worst case a little sprinkle of something like HTMX.
And for some front-end form field validation in the spirit of htmx, ParsleyJS[0] is quite nice. Below is one way to enable the former to support the latter:
htmx.defineExtension (
'parsley-validation',
{
onEvent : function (name, evt) {
var allow = true;
if (name === 'htmx:load')
$(evt.target).parsley ();
else if (name === 'htmx:confirm') {
var theForm = $(evt.target).parsley ();
theForm.validationResult = allow = theForm.isValid ();
if (!allow)
evt.preventDefault ();
}
return allow;
}
}
)
I always try to develop having in mind that some people have disabled JavaScript or isn't running the last version of Firefox or Chromium bases browsers. So if someone enters with disabled JavaScript, keeps having the basic functionality of search, navigate and download. I do webservices for public digital libraries that shares public domain stuff and I true believe that always should be accessible to everyone.
Hopefully these and others modern HTML features gain adoption, along with realizing perhaps a Single Page Application isn't necessary in most instances.
I don't often have to write frontend code, but when I do, there is very little in terms of interactivity you cannot do with HTML these days, worst case a little sprinkle of something like HTMX.
(+1)
It's a small problem compared to the ease of use for development you can gain via Blazor, so I don't see any reason not to solve it.
But this can be done in any JavaScript framework and ofcourse Vanilla JavaScript. It takes some effort, but creates a much better user experience.
https://noscript.net/
Even if a site doesn’t monetize with Google Ads, there’s a decent chance it’s pulling a script from ajax.googleapis.com, and Google still knows that you visited the site from the Referer of the script download.
https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...
https://view-transitions.chrome.dev
Best part about it is how gracefully it degrades.
And for some front-end form field validation in the spirit of htmx, ParsleyJS[0] is quite nice. Below is one way to enable the former to support the latter:
0 - https://parsleyjs.org/