Me too. There will be dozens of us.
I dunno, it just seems like common sense at this point. Javascript is a powerful attack vector, like ads. And many people already use adblockers in some capacity, for that kind of reason.
It'll definitely suck as HTML5's various peripheral features become strong and widely-used attack vectors.
Server-side rendering is a mature technology, don't measure it's pervasiveness in how often you see articles in the news about it...
You didn’t say that, you said “server side rendering is basically dead”.
Believe it or not, lots of people are still building things without JavaScript front ends.
Removing JavaScript prevents malware and adware vendors from running their programs on our machines, but it doesn't empower users. We can control or data but we still can't analyze data websites give us.
The way forward, I think, is to create more standardized document types and let people build renderers for them. If I go to a cookbook website, I should be able to download recipe documents. If I don't like how my cookbook program renders the recipe, I should be able to download another program can render it. This breaks the power that websites have as the sole entities with the capability to render their documents, and gives the power back to users.
https://news.ycombinator.com/item?id=13214134
"""
I'm not sure this goal is very practical, even in the toy example you used (being able to swap data sources for weather forecasts).
If you can use a common vocabulary to access multiple APIs, that requires that all APIs implement the same feature set. Which means getting the API sources to agree on the features to implement, and how to describe them, and stop them from adding any features on that the others don't have. But of course, they'll all be motivated to add their own features, to distinguish themselves from their competition.
And once a API consumer is using a feature that other API producers don't support, then the consumer is locked into that producer, and the whole shared vocabulary is for naught. And of course the API consumers will be looking for additional features, because those translate into features that they can offer to their customers.
Basically, this requires API producers to work together to hobble their ability to meet their customers' needs, all to make it easier for their customers to drop them for a competing endpoint. So it looks like a net negative for everybody.
"""
To still allow for competition, you define a base feature set and representation, and then you allow vendor extensions. You need some sort of standards body that can promote vendor extensions to standardized, supported things. And clients can choose to support whatever (or no) vendor extensions that they want to.
However, I agree with you that it's not very practical, but for different reasons: 1) competitors don't necessarily like to cooperate to that level and 2) it will slow down progress a lot, which is a decently good reason for #1. And 3), which I think is the big one:
Companies doing this stuff really don't want standards if they're the first-mover, because standards necessarily enable competition. If I'm an anti-competitive producer (or even just a producer that doesn't mind competition, but wants to maintain a head start long enough to secure a market position), I don't want to start off with a standard: I want to do my own thing, and get people to adopt it, and then I can lock them in, at least temporarily. If someone comes along later and clones my format, that's fine, but they have to do work to figure it out, and I still own the format, so I'm naturally ahead.
Right. The problem is in the first step. The moment a consumer likes a vendor extension and begins relying on it, they are locked in until the standards body gets around to standardizing it. So all this cooperation to pick a standard and maintain it, and consumers still end up locked in because they like certain extensions more than others. And software providers for consumers still have to write individualized support for all the providers to in order to manage all their extensions.
So all these cycles went to building a standard, and where's the actual win? We still have handlers customized to individual providers. We still have consumers choosing to rely on singular providers.
Yes, this model makes it so content creators actually have to create content or their customers will drop them for a better content creator. That sounds great for users.
I'm not sure why I should care that a few user-hostile rent-seeking entities won't have complete control of the internet anymore.
The API extensions causing vendor lock-in complaint is fairly bogus. Features would be driven by the content renderers, not the content creators. It's that very abdication of power that browsers have given to content creators that the system I'm proposing would avoid.
One must simply route their VPN traffic through Eritrea => Thailand => Russia => Cyprus => China => back to some AWS server in SF & rejoice.
Just make it more expensive to trace you than the value of what you took/broke/F'd-with! Lawyers' fees not necessary!
Gotta push back against the "create more standardized doc types" bit (wat) -- it sounds like you want more APIs and more user-friendly tools for consuming them, which would be great and is more compatible with reality. SoA and recent shifts toward empowered-client approaches like GraphQL are steps in that direction.
I'm also glad you mentioned "documents" so often, because your ideas relate to a document-centric web. Which is not what we have. Rather it's evolved into an application delivery context.
That's exactly what I'm saying. JavaScript isn't the only part of the problem: HTML and CSS are also components of the problem.
Your distinction between applications and documents is an insightful one. Perhaps one way to describe the problem is that HTML and CSS contain elements of "application" rather than "document". If we think of a document as being purely semantic and layout/style as being elements of an application's rendering, then it becomes clear that only a fraction of HTML is actually document-relevant. CSS and the rest of HTML is application.
Few alternatives already exist (like gopher, the protocol).
I found a new interesting one recently (ala markdown but tab-based and parseable with regexps):
There is also a new browser that is being developped (not related to ContNet):
Unfortunately, among the crucial functions nowadays are the silly cosmetics, the parallax scrolling, the animated backgrounds, that allow marketers to pretend to have a website when all they have is formating for zero content. We failed to provide them with this fluff.
Yet almost 10 years later, they are still playing catchup with native apps.
Hard to believe in 2017, but as recently as five years ago Google (of all people) published the Caja compiler [1] for sandboxed/statically verified JavaScript subsets, and there was AdSafe aiming for safe JavaScript as well.
the only sane solution on ads is SafeFrames [1]. Which does not do much, but at least it prevents ads from scrapping the page and stealing your cookies from the main domain you are visiting. That is already a win, considering the mess it is now without it.
Your computer belongs to you. I'm ready to escape the cycle of 'oh they own everything because they snuck human rights violations into their software and hardware and nobody stopped them'.
The Web is used for so many things these days. It is a publishing platform that allows anyone to host their own content to the entire internet, thanks to Web Browsers just loading it. I can see IPFS being an improvement over the Web but besides the web server being a single point of failure, why is a DRM standard specifically going to destroy the Web?
Wordpress is used to power 20% of new sites. My own company is developing an open source platform for communities to run their own social networks (https://qbix.com) so what is this "eating" you speak of?
EDIT: This has been one of my most downvoted comments ever. Can someone explain the rationale? (Is it super obvious that the Web will be killed by DRM that asking the question should be punished?)
Sure, Javascript uglifiers and frameworks mucking with HTML standards and the DOM had already made "view source" nigh-worthless, and there were DRM'd plugins of course, and browsers had supported some schemes for a while as a de facto standard, but this still feels like a last-straw kind of situation to me.
> My own company is developing an open source platform for communities to run their own social networks (https://qbix.com) so what is this "eating" you speak of?
Sure, it's already the world's premiere delivery mechanism for "apps", advertisements, and mass surveillance software. I know. That's exactly the kind of thing that I don't mind living somewhere, but I'd like it not to be all mixed up in my networked hypertext document reader.
This Web's over. Anyone hosting an After-Web? I could do with a little more Webbing.
[EDIT] Though actually your thing seems fine. I saw "social network" and glossed over the rest. Sorry.
http://help.opera.com/operaconfig/versions/Win32/11.50/en/in...
[0]: https://gngr.info
If it takes only well formed x/html/5 it's not that big a deal.
Ideally a lot of "hooks" so that the more determined can make it do their thing. Not the thing that somebody else wants to force on them.
I wonder who's game?
Why not just do this yourself? Fork chromium and start commenting stuff you don't want out. It would likely only take a weekend or two of hacking...
If you really want a separate internet without the "bad parts", you can still use Gopher. There are still sites around, and you won't even get images, which were the first thing to "ruin" the internet, and were the launching point down the slippery slope to DRM video.
On a side note, it's interesting that so many HN readers are against this kind of DRM, but at the same time there's a large group here who are against ad-blockers. Ad-revenue is the main driver motivating companies to shoe-horn this crap into the web. It's not a coincidence that the biggest ad company in the world also makes one of the most popular web browsers and is a huge media distributor.
Really, I just need to find the time to do it.
This Web's about to be eaten by DRM and WebAssembly anyway. Pretty soon it'll just be a way to deliver QT apps (or some other framework that runs in WebAssembly and renders to OpenGL or similar) and video. A web where the only thing you'll find when you follow a link is more documents (or a download) and pages can't try to make your computer do a bunch of stuff you don't want it to would be nice to have again, and it's clear now that the system itself has to ban the capabilities that enable all the garbage, or it'll take over.