Hacker News Reader

Comment by jamescun | Hacker News Reader

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.

View on HN

Thank goodness you exist, the fingerprinters will be confused as to which one of the two of us went to their website!

How? There are dozens of us! DOZENS!

How would you count?

"you don't have to, they'll tell you."

(+1)

i'm right there with you!

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.

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.

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. I also create a lot of Blazor apps and I always make sure things like filters are based on GET query parameters.

But this can be done in any JavaScript framework and ofcourse Vanilla JavaScript. It takes some effort, but creates a much better user experience.

This is possible and, in my experience building them, the norm. SPAs have routers and update navigation state, including history for browser Back/Forward

Yes true. But also way to often neglected.

Right but most of the time they don’t work. For example, LinkedIn, and instagram. I understand they have apps but… come on.

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.

On the other hand, converting a SPA to a PWA is often a breeze

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.

> 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;
          }
      }
  )

0 - https://parsleyjs.org/

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.

The View Transition API makes this even more viable.

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.

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.

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.

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.

Does HTMX work with NoScript? Doesn't it require JS?

Nope, doesn't work. Doesn't stop you from making it a PWA, though.

oh my. Looks like NoScript is way better than what I've been using. Thanks!

https://noscript.net/

Reply on news.ycombinator.com