Sorry, I won't. I don't trust you and I won't simply run your code by default. It's not like I actually need whatever your web site wants to provide; there are plenty of other things to do on the internet.
> I don't follow that. You can't make a fast JS runtime in your previous examples (the JVM, PNaCl, .NET, etc.).
I included ones you could, such a NaCL. And I should probably have also included the native platforms (Apple, MS, Google), because they're the competition, even if their sandboxing or runtime environment isn't what one might call 'state of the art'.
At the end of the day, it's the two-tier universe that bothers me the most. You're content to foist the JS runtime on everyone but yourselves. Once you implement Firefox entirely as an application running in a JS VM, the argument that JS is good enough might carry some weight.
> If my code works out of the box in an unmodified browser, then it is Vanilla JS. If I have to load a framework for it to work, then it isn't, period.
Minor nitpick, third party library and framework does not modify your browser. They all still run on unmodified browsers.
> Websites should still be functional (even if a bit inconvenient) without Javascript.
I don't see why it needs to go that far. They could have just not used the optional chaining operator, or used a pre-processor if they really wanted to use it.
Very few people are browsing with no JS at all, and they are doing it deliberately. They probably disagree with me, but I don't think anyone should do extra work for them.
> Yes but if it was „incredibly naive“ to download and run JavaScript in the browser sandbox how naive would it have been to download and run native code outside of any sandbox?
It would be naive to download and run native code for every website you visiti, yes. A few that you trust and where you think that is warranted is a different matter.
Running javascript in a sandbox provides the illusion of safety so it gets enabled by default while still creating tons of problems.
> browsers have various popular language runtimes (and perhaps even popular libraries) preloaded, so that all web pages requiring that runtime can share the same (read-only) copy of that code.
That sounds a lot like the idea from some years past that commonly used JavaScript frameworks would be served from a few common CDNs and would be widely enough used to be almost always in cache in the browser, and therefore won't need to actually be downloaded for most pages (hence, the size of the js frameworks shouldn't matter so much)
I'm no expert but from what I understand, that didn't really work out very well. A combination of too many different versions of these libraries (so each individual version is actually not that widely used), and later privacy concerns that moved browsers toward partitioning cache by site or origin. Maybe other reasons too.
Of course, you didn't mention caching and perhaps that's not what you had in mind, but I think it's a tricky problem (a social problem more than a technical one): do you add baseline browser support for increasing numbers of language runtimes? That raises the bar for new browsers even further and anyway you'll never support all the libraries and runtimes people want. Do you let people bring their own and rely on caching? Then how do you avoid the problems previously encountered with caching JS libs?
If code doesn't run in 1 of 2 the browser-engines we currently have, I would consider that a major short-coming preventing me from using it in production.
> Modern web applications, for better or worse are written in JavaScript.
As a non-JS user, I have no expectation that I can use web applications, so I don't disagree here.
However, most of the web does not consist of web applications. What about those sites? I don't see any compelling reasons (other than spite, maybe) for those sites to fail to work without JS.
Not my problem. I want quick loading sites with as few malware vectors as possible.
You should be building web applications which facilitate the transfer of information. You don't need javascript and all the other crap people are using these days for that. I mean, if you're all about pure eye candy and doing..I dunno, mandelbrots or something in the browser, then yeah, you're going to need javascript. But it's not going to work on mobile. Hardly anything like that works on mobile, which is fine by me; I do most of my browsing there.
To be honest, I think there's a market for a firefox addon which removes links to sites which don't work on mobile/require you to have javascript enabled to save me the effort of clicking back when i arrive at am empty page or when the screen is dimmed and all I can see is the corner of some dialog I have no interest in zooming out to look at.
I didnt't say you never need js code that reacts to input. I said: does anybody have real world examples where this type of library is useful?
Because most of the time I get along well with sending input to the server. And in the few cases I needed js to deal with user input I got along nicely with simple event handlers.
No, since they are already in the browser at first place. That's the point. I don't need any extra runtime to run JS in the browser.
reply