> JavaScript always was a bad idea, for the simple fact that automatically executing untrusted code from untrusted and unknown sources is a bad idea.
The premise here is completely wrong. A modern web browser is a sandboxed application delivery platform. The entire purpose is to execute untrusted code and it does so remarkably well. Take this away and you just have a document viewer -- a sophisticated one for sure -- but one always limited to its original purpose.
This proposed solution would eliminate many of the applications that web users use every single day and many more that haven't even been invented yet. HTML5 games would be impossible. Forget Google Maps. It's not even worth entertaining.
> In the company of the two declarative languages HTML and CSS, the imperative, all-purpose JavaScript always seemed the odd one out.
Declarative languages are extremely limiting and the trend has been to move away from them. For example, the introduction of Service Workers to replace manifest files.
Much of the success of the web has been in defiance of the declarative nature of the formats rather than in support of them. We're building complex applications in a declarative format designed for documents and that's only possible because we can imperatively manipulate those documents with code.
This proposed solution would eliminate many of the applications that web users use every single day and many more that haven't even been invented yet.
No big deal. When Apple introduced the App store, a maybe-not-new-but-finally-practical way of shipping applications to end-user devices was born. And they weren't webapps. No JS at first, mostly Objective-C and plists. And was still revolutionary in its reach, and consequences. Then Android came. Still no JS, but XML and Java.
So, no, you don't need HTML+JS to deliver rich content application to users.
That all sounds like a pretty good idea to me. I was happy with the distributed document viewer system and never actually wanted the complex application platform. I still don't want it, but I'm forced to put up with it if I want access to the document viewer system, because the two wildly different projects have been smashed awkwardly together.
Since the web as a document viewer system appears to be dying, leaving only the distributed application system I don't really want to use anyway, perhaps in a few more years I'll be able to abandon the web thing and do something else.
Every 2-3 years this gets suggested again. Somebody builds something to "compile" their pet language x to JS. At the same time 3 new JS libraries or frameworks come out to abstract an abstraction. I've been writing JS since '94 and I'm sorry but at this point all I can muster is an eye roll.
It has also grown unbelievably well. ES6 alone has added in so many quality of life features that I find myself using fewer and fewer libraries every time I go to do a project and check compatibility.
I just need full module support and I'll be laughing.
> Above all, what’s dangerous about JavaScript is that it is executed without the user’s knowledge or consent.
Ummm ... is this not how all software works? Is the average person 'aware' of the code that is executing as he/she clicks around in any piece of software? How is a web browser any different?
How a web browser is different is that simply by stumbling into some web site, your browser is suddenly loading code from ten other domains. The current version of all that code, not the one the site tested with.
No signatures are checked; for none of those sites is there a validation whether it came from a trusted publisher and a prompt to install it.
With regular software, you explicitly download and install and in newer operating systems, there are certificates and signatures to give some modicum of protection. If you install something unsigned, you give your explicit consent.
“JavaScript is also weird because it is imperative, forcing the programmer to describe the means in which to achieve the desired result, instead of declaratively describing the desired result itself, like in HTML and CSS.”
It actually has First Class Functions that enables declarative programming, there’s a lot of cool libraries out there(ramda as an example) that let you express your apps in declarative way. Not saying that is a Pure functional language nor that was born as a functional language, it is indeed a general purpose language enabling more styles of programming with a plenty of good and bad ideas. However it gets better as it is continuosly improved by a lot of smart guys. Btw as I can see it, the main point or your article is not about javascript but about browser APIs
> The entire article is about changing various browser APIs, not Javascript itself
No, it's mostly about browser languages, specifically, extending the declarative languages (HTML and CSS) to reduce (And ideally eliminate) the need for the imperative language (JS).
My view is that instead of running JS, browsers should run a standard bytecode with a well-defined and safe interface to the browser and managed access to the user's machine. The article covers some of these concerns. I really think a byte code is the way to go, just so people can use whatever language they prefer. It is ridiculous that if I want to solve a problem on my computer I can use whatever language I like but if I want to write something on a browser - one of the most important IT systems in the world - I only have one choice.
My sentiment here is that modern JavaScript is _much_ better than its predecessors. The real issue, as it pertains to the web browser, is supporting legacy functionality that's causing drag on the web as a whole.
I'm curious: what's so bad about JavaScript that other languages seem to do better?
I miss true integers! And literally almost every other type. I'm looking forward to trying out typescript, but it would be nice if this was a part of the pure language itself
This article has some interesting ideas, and it's definitely true that the web has a lot of problems, but I'm not sure how much of it is actually related to the underlying technology. Sites that use a lot of javascript tend to fall into one of two categories:
* News sites with a billion ads and tracking scripts.
* Actual web apps (Google Docs, Gmail, etc).
For the first category of websites, it's basically an economic problem - sites are including all this junk because it makes money. If this proposal were implemented, most sites would just find ways to work around it - and if you can send network requests in response to events, it's always going to be possible to track users. You could easily just send a network request every time something on the page is clicked, hovered over, etc. and doing that would likely be even less efficient than what we have today. The article mentions alerting people when a network request is made, but if you had to click a button every time a site wanted to make a network request, it would be so annoying that most people would just give up and go back to the old web. Ultimately, the only way to stop tracking is to somehow fix the economic model so that there's no incentive to do it, although it's not entirely clear how that would happen.
For the second category of things that are real apps, this system is probably not going to work in most cases. There's a practically infinite number of actions that a real app would need to do, and if you implement an API for every single one, you'd end up with something that's really similar to what we have today. Most likely, you would just go back to downloading and installing native apps, which provides even less security protections than a web browser does (and it also makes it much harder to distribute your apps, which is the whole reason the web won in the first place).
Rather than getting rid of javascript completely, I think there's a few things that we could do that would solve a lot of the problems present today:
* Create a way for sites to easily accept micropayments so that there's an alternative to ads. Brave seems to be the only company attempting this right now; it will be interesting to see whether they succeed or not.
* Have your web browser notify you if a site is using too many resources. Firefox already kind of has this with the "x is slowing down your browser" notification, something like "x has used 100MB of data. Stop loading?" would work really well.
* Enable first-party isolation by default, which would do a lot to reduce cross-site tracking.
The article seems to suggest that javascript should be replaced by extensions to HTML and CSS, making both more or less Turing complete.
However, I don't think it sufficiently defends the premise of being objectively superior to javascript, given that all of the features mentioned could be implemented in javascript. There is nothing fundamental to the language which prevents designers from being proactive about consent in the way described.
I feel like the author blames the language for what are, essentially, design paradigms with which he disagrees, and I think a lot of people who criticize javascript do the same thing. We don't need to replace javascript to accomplish what the article describes, we just need to write javascript more ethically.
It’s unlikely that vendors will ever support multiple JIT engines, so wasm is likely to be AOT only for the foreseeable future: you likely won’t see other languages inside script tags.
And secondly, it’s going to be a long time before the entirety of the Web API (which is much bigger than just the DOM) is supported in wasm, if ever.
As much as I disagree with getting rid of imperative languages on the web, that CSS Prolog idea is amazing. Styling is exactly the kind of niche I can see it succeeding in. Though I would be a little worried about my CSS looping infinitely...
JS clearly has issues and I wish some of these issues could have been alleviated when ECMA introduced "use strict". It was a one time opportunity to correct the language at its core, AKA remove a bunch of features and behavior.
Not one time. They also considered "use strong" but declined. I don't recall why. But you can always do it again and make further subsets of the language that clean up for modern use with modern support.
But I also question the purpose. Just use dev tools to help enforce more strict code.
My only issue with javascript ecosystem, i.e. nodejs, is that when I 'npm install', all of sudden I get hundreds of modules pulled in with a few hundred MB of content, which I feel bloated and who-knows-what-just-pulled-in.
A glibc-style standard binary library might be better to maintain and for production use. Making the 'standard library' modularized so I can customize will be even better.
Despite being a js fan i don't think this criticism of the article is true. The critique applies equally to today as 2005 no? It seems that the article wants a language whose capabilities vs js are heavily neutered
[+] [-] wvenable|8 years ago|reply
The premise here is completely wrong. A modern web browser is a sandboxed application delivery platform. The entire purpose is to execute untrusted code and it does so remarkably well. Take this away and you just have a document viewer -- a sophisticated one for sure -- but one always limited to its original purpose.
This proposed solution would eliminate many of the applications that web users use every single day and many more that haven't even been invented yet. HTML5 games would be impossible. Forget Google Maps. It's not even worth entertaining.
> In the company of the two declarative languages HTML and CSS, the imperative, all-purpose JavaScript always seemed the odd one out.
Declarative languages are extremely limiting and the trend has been to move away from them. For example, the introduction of Service Workers to replace manifest files.
Much of the success of the web has been in defiance of the declarative nature of the formats rather than in support of them. We're building complex applications in a declarative format designed for documents and that's only possible because we can imperatively manipulate those documents with code.
[+] [-] bassman9000|8 years ago|reply
No big deal. When Apple introduced the App store, a maybe-not-new-but-finally-practical way of shipping applications to end-user devices was born. And they weren't webapps. No JS at first, mostly Objective-C and plists. And was still revolutionary in its reach, and consequences. Then Android came. Still no JS, but XML and Java.
So, no, you don't need HTML+JS to deliver rich content application to users.
[+] [-] leadingthenet|8 years ago|reply
[+] [-] marssaxman|8 years ago|reply
Since the web as a document viewer system appears to be dying, leaving only the distributed application system I don't really want to use anyway, perhaps in a few more years I'll be able to abandon the web thing and do something else.
[+] [-] dickbasedregex|8 years ago|reply
[+] [-] Waterluvian|8 years ago|reply
I just need full module support and I'll be laughing.
[+] [-] ggregoire|8 years ago|reply
So thanks but no thanks.
[+] [-] ASalazarMX|8 years ago|reply
So thanks but no thanks.
Oh, wait...
[+] [-] peterashford|8 years ago|reply
[+] [-] Archanian|8 years ago|reply
Ummm ... is this not how all software works? Is the average person 'aware' of the code that is executing as he/she clicks around in any piece of software? How is a web browser any different?
[+] [-] dplgk|8 years ago|reply
[+] [-] kazinator|8 years ago|reply
No signatures are checked; for none of those sites is there a validation whether it came from a trusted publisher and a prompt to install it.
With regular software, you explicitly download and install and in newer operating systems, there are certificates and signatures to give some modicum of protection. If you install something unsigned, you give your explicit consent.
[+] [-] hollowturtle|8 years ago|reply
It actually has First Class Functions that enables declarative programming, there’s a lot of cool libraries out there(ramda as an example) that let you express your apps in declarative way. Not saying that is a Pure functional language nor that was born as a functional language, it is indeed a general purpose language enabling more styles of programming with a plenty of good and bad ideas. However it gets better as it is continuosly improved by a lot of smart guys. Btw as I can see it, the main point or your article is not about javascript but about browser APIs
[+] [-] fenwick67|8 years ago|reply
The entire article is about changing various browser APIs, not Javascript itself
[+] [-] pdonis|8 years ago|reply
[+] [-] dragonwriter|8 years ago|reply
No, it's mostly about browser languages, specifically, extending the declarative languages (HTML and CSS) to reduce (And ideally eliminate) the need for the imperative language (JS).
[+] [-] johnhenry|8 years ago|reply
[+] [-] forgot-my-pw|8 years ago|reply
[+] [-] peterashford|8 years ago|reply
[+] [-] electric_sheep|8 years ago|reply
[+] [-] mrskitch|8 years ago|reply
I'm curious: what's so bad about JavaScript that other languages seem to do better?
[+] [-] cpburns2009|8 years ago|reply
[+] [-] mplewis|8 years ago|reply
[+] [-] ben-schaaf|8 years ago|reply
[+] [-] thsowers|8 years ago|reply
[+] [-] tboyd47|8 years ago|reply
[+] [-] tobltobs|8 years ago|reply
[+] [-] 43920|8 years ago|reply
For the first category of websites, it's basically an economic problem - sites are including all this junk because it makes money. If this proposal were implemented, most sites would just find ways to work around it - and if you can send network requests in response to events, it's always going to be possible to track users. You could easily just send a network request every time something on the page is clicked, hovered over, etc. and doing that would likely be even less efficient than what we have today. The article mentions alerting people when a network request is made, but if you had to click a button every time a site wanted to make a network request, it would be so annoying that most people would just give up and go back to the old web. Ultimately, the only way to stop tracking is to somehow fix the economic model so that there's no incentive to do it, although it's not entirely clear how that would happen.
For the second category of things that are real apps, this system is probably not going to work in most cases. There's a practically infinite number of actions that a real app would need to do, and if you implement an API for every single one, you'd end up with something that's really similar to what we have today. Most likely, you would just go back to downloading and installing native apps, which provides even less security protections than a web browser does (and it also makes it much harder to distribute your apps, which is the whole reason the web won in the first place).
Rather than getting rid of javascript completely, I think there's a few things that we could do that would solve a lot of the problems present today: * Create a way for sites to easily accept micropayments so that there's an alternative to ads. Brave seems to be the only company attempting this right now; it will be interesting to see whether they succeed or not. * Have your web browser notify you if a site is using too many resources. Firefox already kind of has this with the "x is slowing down your browser" notification, something like "x has used 100MB of data. Stop loading?" would work really well. * Enable first-party isolation by default, which would do a lot to reduce cross-site tracking.
[+] [-] krapp|8 years ago|reply
However, I don't think it sufficiently defends the premise of being objectively superior to javascript, given that all of the features mentioned could be implemented in javascript. There is nothing fundamental to the language which prevents designers from being proactive about consent in the way described.
I feel like the author blames the language for what are, essentially, design paradigms with which he disagrees, and I think a lot of people who criticize javascript do the same thing. We don't need to replace javascript to accomplish what the article describes, we just need to write javascript more ethically.
[+] [-] mykull|8 years ago|reply
[+] [-] vdnkh|8 years ago|reply
[+] [-] mr_toad|8 years ago|reply
And secondly, it’s going to be a long time before the entirety of the Web API (which is much bigger than just the DOM) is supported in wasm, if ever.
[+] [-] alexandernst|8 years ago|reply
[+] [-] ben-schaaf|8 years ago|reply
[+] [-] nostalgeek|8 years ago|reply
[+] [-] Waterluvian|8 years ago|reply
But I also question the purpose. Just use dev tools to help enforce more strict code.
[+] [-] ausjke|8 years ago|reply
A glibc-style standard binary library might be better to maintain and for production use. Making the 'standard library' modularized so I can customize will be even better.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] andybak|8 years ago|reply
[+] [-] dcwca|8 years ago|reply
[+] [-] bradym|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] optimalKEK|8 years ago|reply
[+] [-] darepublic|8 years ago|reply