Hacker News Reader

Comment by ozim | Hacker News Reader

I totally agree with that. It is not like some web police force is holding people at gunpoint to add javascript and angular or react. People use all those features because they want to and they find it useful.

View on HN

There kinda is?

While web sites can avoid JavaScript all right, browsing most sites does require JavaScript. As a NoScript user, I'm keenly aware of how many web sites simply do not work without JavaScript.

And I'm not even talking about all the third party spyware.

I had to give up doing this. I couldn't manage all of the different times websites broke over just CDNs. Lord help me if the website is Ad driven.

I encourage every web developer to try running NoScript for a week. You will find it enlightening.

If you're already using uBlock Origin you can disable JS per site (or by default, like NoScript). I've found that the UI is way easier to understand compared to NoScript.

uMatrix is similarly excellent (finer grained control I think is the difference).

For frequently visited sites you can save which bits you want to allow so its not as onerous as you'd think.

Blocks Google Analytics and Facebook's poison by default.

I'm not sure what you would gain from disabling things like the ability to upload multiple files, autocomplete fields and rich text editing. Raging against and disabling Javascript is just stupid in my viewpoint. I'm not going to cut out absolutely essential features just to satisfy some fringe group.

What if JS over gemini:// would only be able to render some things and would not have network access? It just is a question of what your html renderer allows. Add Lua if you think that's better! But you will have the same problems if embedded Lua can do network stuff.

...or let's just P2P our Emacsens... the last non divisive browser... :-P

gemini doesn't at the moment have any formalized systems for client-side scripting, effectively eliminating the need for that, and most of the gemini community seems pretty opposed to ever implementing such a thing, so it doesn't seem like that will ever change.

This is more intended to be a comfier gopher than a less-shitty http. Most of its early adherents are ex-phloggers attracted to its features relative to gopher, not ex-webbers attracted to its lack of client-side scripting or whatever.

The fact that this has attracted a fair number of gopher users (who have always very strongly opposed http/s) would seem proof enough of it's success, imo, at least within particular circles, and at least within the context of its goals. It was never intended to draw people away from the web, it was intended to be a sort of superpowered gopher.

This protocol doesn't seem to be aimed at commercial use, but the "web police" called "the manager" or "the marketing department" or whatever are the ones forcing the use of the privacy-invading tools.

Legacy and momentum plays a greater role in adopting a framework than sheer choice. If I could choose I would use frameworks in haskell or rust 100% of the time where I work. I don't because there is nothing built around it there and I need to get the job done right now. I would like to be the change I want to see, but sometimes there is just not enough time.

That is a solid point, at the end of the day, programming languages and frameworks are just tools we use to build a product that has some use to someone (Be that monetary value or art or whatever). At work, it is almost always better to just iterate on the existing tool stack rather than try to spool up new one. I love writing Rust, but I'd need a good reason (or at least a big project to amortize the cost over) to reach for it over the existing very function c++ libraries I already use for our embedded work.

The original Facebook and Google did not use much JavaScript, so I'm always skeptical when literal documents need it for anything other than ads (and even then...).

And the screen refreshed every time you did something as it loaded a new page. Just because it’s abused doesn’t mean JS doesn’t have uses.

the screen refreshed every time you browsed to new content or did something that required accessing new content, as one would intuitively expect

I never understood the hangup on screen refreshes - I mean, why is it important that the screen doesn't refresh?

And if it's that important that EVERYBODY deploys JS to render client side to avoid the refreshes, why isn't this handled at the browser level in the first place (i.e. declare "ExtendDisplayTime"-something on your document and the browser should replace the screen content only AFTER the new page is completely painted).

But at the core of it, the web is a document-display system, and back-hammering and shoe-horning apps that masquerade as documents will always be painful.

Maybe, instead of the spec allowing/banning javascript, it would only allow usage of curated list of "apps" to be part of the page ?

For example, i'm thinking of a roam research like content platform, without tracking and ads. It would be interesting to see shared content around that.

> they find it useful

Sometimes it is just the latest trend...

Actually they do. If you do not fill in your taxes, which are powered by JavaScript, people with hubs are going to come for you and take you hostage, I. Order to rob you from your “tax” money..

I can file my taxes without using a computer. I've done so for many years.

Reply on news.ycombinator.com