I know, and I’m still researching the best way to mitigate this. So far, I’ve come away with the impression that Tor Browser and Brave do the best jobs of minimising fingerprinting, otherwise I would have just disabled JS in Vanadium and called it a day.

(Not talking about a specific browser, just in general) Maybe I’m misunderstanding but when the VPN makes a request for the page information the request isn’t forwarding the browser information is it? So wouldn’t most of that be mitigated there?

As in the VPNs sever making the request should show when they scrape that information, not the end user. Maybe I’m not understanding that though.

As it happens, Brave started crashing for no apparent reason shortly after I posted this, so I’m back on Tor Browser. ¯\_(ツ)_/¯

He’s also one of the inventors of Javascript as a browser feature. I feel like that would matter to OP.

I’m saying your point about static content being all we would get sounds great

I unironically use Lynx from my home lab s when I’m ssh’d in snce it’s headless. Sometimes at work I miss the simplicity. I used to use Pine for Gmail as well. 😁

😆 that do be what they sound like

Search is easier to implement without Javascript than with.

<form method="GET" action="/search">
<input name="q">
<input type=submit>
</form>

Some provinces in Canada have rules that businesses’ websites must meet or exceed the WCAG 2.0 accessibility guidelines when they exceed a certain employee headcount, which includes screen reader support that ensures all content must be available to a browser that doesn’t have JavaScript enabled.

You can say fuck on the internet

a slide out menu needs JavaScript

A slide out menu can be done in pure CSS and HTML. Imho, it would look bad regardless.

When if you said just send the parts of the page that changed, that dynamic content loading would still be JavaScript

OP is trying to access a restaurant website that has no interactivity. It has a bunch of static information, a few download links for menu PDFs, a link to a different domain to place an order online, and an iframe (to a different domain) for making a table reservation.

The web dev using javascript on that page is lazy, yet also creating way more work for themself.

https://htmx.org/ solves the problem of full page loads. Yes, it’s a JavaScript library, but it’s a tiny JS library (14k over the wire) that is easily cached. And in most cases, it’s the only JavaScript you need. The vast majority of content can be rendered server side.

JS is just a janky hotfix.

As it was, HTML was all sites had. When these were called “ugly”, CSS was invented for style and presentation stuff. When the need for advanced interactivity (not doable on Internet speeds of 20-30 years ago), someone just said “fuck it, do whatever you want” and added scripting to browsers.

The real solution came in the form of HTML5. You no longer needed, and I can’t stress this enough, Flash to play a video in-browser. For other things as well.

Well, HTML5 is over 15 years old by now. And maybe the time has come to bring in new functionality into either HTML, CSS or a new, third component of web sites (maybe even JS itself?)

Stuff like menus. There’s no need for then to be limited by the half-assed workaround known as CSS pseudoclasses or for every website to have its own JS implementation.

Stuff like basic math stuff. HTML has had forms since forever. Letting it do some more, like counting down, accessing its equivalent of the Date and Math classes, and tallying up a shopping cart on a webshop seems like a better fix than a bunch of frameworks.

Just make a standardized “framework” built directly into the browser - it’d speed up development, lower complexity, reduce bloat and increase performance. And that’s just the stuff off the top of my head.

Something as simple as a slide out menu needs JavaScript and couldn’t really be done server side.

I’m not trying to tell anyone how to design their webpages. I’m also a bit old fashioned. But I stopped making animated gimmicks many years ago. When someone is viewing such things on a small screen, in landscape mode, it’s going to be a shit user experience at best. That’s just my 2 cents from personal experience.

I’m sure there are examples of where js is necessary. It certainly has it’s place. I just feel like it’s over used. Now if you’re at the mercy of someone else that demands x y and z, then I guess you gotta do what you gotta do.

and its not even the devs. its the higher ups forcing them to do shit that won’t work.

if im building something complex im using an actual server side language not a javascript framework

I like React, but Svelte really hits the spot. But no matter what framework you use, let’s all be glad that we’re not like those reality averse people complaining in this thread 🙏

For a web store you probably only need Javascript for payment processing. Insofar as I’ve seen pretty much all of the widgets provided by the card processors outright require Javascript (and most of them are also exceedingly janky, regardless of what they look like on the outside to the user).

You definitely don’t need Javascript just for a shopping cart, though. That can all be done server side.

The only non-heated comment.

You mean people replying to you? I wouldn’t call those heated, rather derisive. Just like your own original comment. You come across as presumptuous and pretending to be more knowledgeable than you really are. People react.

Obfuscation, OK.

Look, I’m willing to have a conversation with you, but you need to address my points first, that is if you want one too.

Source code is the code devs write.

For compiled languages like C, only the compiled machine code is made available to the user.

JS is interpreted, meaning it doesn’t get compiled, but an interpreter interprets source code directly during runtime.

Obfuscsted code, while not technically unaltered source code is still source code. Key word being unaltered. It isn’t source code due to the virtue of not being straight from the source (i.e. because it’s altered).

However, obfuscated code is basically source code. The only things to obfuscate are variable and function names, and perhaps some pre-compile order of operations optimizations. The core syntax and structure of the program has to remain “visible”, because otherwise the interpreter couldn’t run the code.

Analyzing obfuscated code is much closer to analyzing source code than reverse-engineering compiled binaries.

It may not be human-readable. But other programs systems can analyze (as they can even compiled code), but more importantly - they can alter it in a trivial manner. Because it’s source code with basically names censored out. Which makes evaluating the code only a bit harder than if it were truly “closed-source”.

That’s why website source code is basically almostsource-available.

A reminder, in the past, large pages downloaded all stuff at once. In contrast, with dynamic imports the first load is much much faster. And that matters most. And any changes in dynamic content would just require the dynamic data to be downloaded.

Unfortunately, you’re very mistaken.

In the past, pages needed to download any stuff they want to display to the user. Now, here’s the kicker: that hasn’t changed!

Pages today are loaded more dinamically and sensibly. First basic stuff (text), then styles, then scripts, then media.

However, it’s not Angular, React Bootstrap or any other framework doing the fetching. It’s the browser. Frameworks don’t change that. What they do, instead, is add additional megabytes of (mostly) bloat to download every day or week (depending on the timeout).

Any web page gets HTML loaded first, since the dawn of the Web. That’s the page itself. Even IE did that. At first, browsers loaded sequentially, but then they figured out it’s better UX to load CSS first, then the rest. Media probably takes precedence to frameworks as well (because thet’s what the user actually sees).

Browsers are smart enough to cache images themselves. No framework can do it even if it wanted to because of sandboxing. It’s the browser’s job.

What frameworks do is make devs’ lives easier. At the cost of performance for the user.

That cost is multiple-fold: first the framework has to load. In order to do that, it takes bandwidth, which may or may not be a steeply-priced commodity depending on your ISO contract. Loading also takes time, i.e. waiting, i.e. bad UX.

Other than that, the framework beeds to run. That uses CPU cycles, which wastes power and lowers battery life. It’s also less efficient than the browser doing it because it’s a higher level of abstraction than letting the browser do it on its own.

With phones being as trigger-happy about killing “unused” apps, all the frameworks in use by various websites need to spin up from being killed as often as every few minutes. A less extreme amount of “rebooting” the framework happens when low-powered PCs run oit of RAM and a frameworked site is chosen by the browser to be “frozen”.

What a framework does is, basically, fill a hole in HTML and CSS - it adds functionality needed for a website which is otherwise unattainable. Stuff like cart, checkout, some complex display styles, etc.

All of this stuff is fully doable server-side. Mind you, login is so doable it didn’t even slip onto my little list. It’s just simpler to do it all client-side for the programmer (as opposed to making forms and HTML requests that much more often, together with the tiny UX addition of not needing to wait for the bac(-and-forth to finish.

Which itself isn’t really a problem. In fact, the “white flashes” are more common on framework sites than not.

When a browser loads any site, it loads HTML first. That’s “the site”. The rest is just icing on the cake. First is CSS, then media and JS (these two are havily browser dependent as far as load priority goes).

Now comes the difference between “classic”, “js-enhanced” and “fully js-based” sites.

A classic site loads fast. First HTML. The browser fetches the CSS soon enough, not even bothering to show the “raw HTML” for a few hundered miliseconds if the CSS loads fast enough. So the user doesn’t even see the “white flash” most of the time, since networks today are fast enough.

As the user moves through different pages of the site, the CSS was cached - any HTML page wishing to use the same CSS won’t even need to wait for it to load again!

Then there’s the js-enhanced site. It’s like the classic site, but with some fancy code to make it potentially infinitely more powerful. Stuff like responsive UI’s and the ability to do fancy math one would exoect of a traditional desktop/native app. Having JS saves having to run every little thing needing some consideration to the server when the browser can do it. It’s actually a privacy benefit, since a lot less things need to leave the user’s device. It can even mend its HTML, its internal structure and its backbone to suit its needs. That’s how powerful JS is.

But, as they say, with great power comes great responsibility. The frameworked-to-hell site. Initially, its HTML is pretty much empty. It’s less of like ordering a car and more of building a house. When you “buy the car” (visit the site), it has to get made right in front of your eyes. Fun the first few times, but otherwise very impractical.

A frameworked site also loads slower by default - the browser gets HTML first, then CSS. Since there’s no media there yet, it goes for the JS. Hell, some leave even CSS out of the empty shell of the page when you first enter so you really get blasted by the browser’s default (usually white, although today theme-based) CSS stylesheet. Only once the JS loads the framework can the foundation of the site (HTML) start being built.

Once that’s been built, it has CSS, and you no longer see the white sea of nothing.

As you move through pages of the site, each is being built in-browser, on-demand. Imagine the car turning into a funhouse where whenever you enter a new room, the bell rings. An employee has to hear it and react quickly! They have to bring the Buld-A-Room kit quickly and deploy it, lest you leave before that happens!

Not only is that slow and asinine, it’s just plain inefficient. There’s no need for it in 99% of cases. It slows stuff down, creates needless bandwidth, wastes needless data and wastes energy.

There’s another aspect to frameworked sites’ inefficiency I’d like to touch.

It’s the fact that they’re less “dynamic” and more “quicksand”.

They change. A lot. Frameworks get updates, and using multiple isn’t even unheard of. Devs push updates left and right, which are expected to be visible and deployed faster than the D-Day landings.

Which in practice means that max resource age is set very low. Days, maybe even hours. Which means, instead of having the huge little 15 MB on-average framework fetched once a week or month, it’s more like 4 to dozens of times per week. Multiply by each site’s preferred framework and version, and add to that their own, custom code which also takes up some (albeit usually less-than-frameork) space.

That can easily cross into gigabytes a month. Gigabytes wasted.

Sure, in today’s 4K HDR multimedia days that’s a few minutes of video, but it isn’t 0 minutes of nothing.

My phone also reliably lasts a day without charge. It’s not about my battery being bad, but about power being wasted. Do you think it normal that checking battery use, Chrome used 64% according to the abdroid settings?

You bet I tried out Firefox the very same day. Googling for some optimizations led me down a privacy rabbit-hole. Today I use Firefox, and battery use fell from 64% to 24%. A 40% decrease! I still can’t believe it myself!

I admit, I tend to use my phone less and less so my current 24% may not be the best metric, but even before when I did, the average was somewhere between 25% and 30%.

There’s a middle-ground in all of this.

Where the Web is today is anything but.

The old days, while not as golden they might seem to me are also not as brown as you paint them out to be.