Let’s Replace JavaScript with Something Better(john.ankarstrom.se)
john.ankarstrom.se
Let’s Replace JavaScript with Something Better
https://john.ankarstrom.se/english/texts/replacing-javascript/
94 comments
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.
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.
You need HTML+JS if you want to deliver one single application to iOS, Android, MacOS, Android, Linux, BSD, Solaris, Chrome OS, Tizen, and OSes that don't even exist yet and not be held to a single proprietary platform owned and managed by a single entity.
You could argue that it's not necessary but that's what it is.
The site you're posting to now probably wouldn't even exist if it required installing a different proprietary application for every platform.
You could argue that it's not necessary but that's what it is.
The site you're posting to now probably wouldn't even exist if it required installing a different proprietary application for every platform.
You could argue that it's not necessary but that's what it is.
Yeah, that's the whole point I'm trying to make. That it's not necessary. That JS it no more special than any other language, and that there are recent, real, practical examples of absolute disruption (Apple/Android app stores) which broke what we thought it was required to deliver content to users.
As per the one single application, that's a gross oversimplification.
Yeah, that's the whole point I'm trying to make. That it's not necessary. That JS it no more special than any other language, and that there are recent, real, practical examples of absolute disruption (Apple/Android app stores) which broke what we thought it was required to deliver content to users.
As per the one single application, that's a gross oversimplification.
Nobody said JS is special but the point of the article is that code execution (of any kind) is unnecessary.
The ironic part is that app store you're arguing for wouldn't even exist without the web. The web is what made Mac OS X viable for users to switch to it (and MS Office). The platform network affects that made Windows a monopoly have been drastically cut down by the web.
> As per the one single application, that's a gross oversimplification.
Says another person posting on a web application that runs on every platform out there.
The ironic part is that app store you're arguing for wouldn't even exist without the web. The web is what made Mac OS X viable for users to switch to it (and MS Office). The platform network affects that made Windows a monopoly have been drastically cut down by the web.
> As per the one single application, that's a gross oversimplification.
Says another person posting on a web application that runs on every platform out there.
Everything you listed as a con is exactly what I’d like the web to be.
Says the person posting to a web application. Where exactly do you want to draw the line?
This website is the perfect example that a web app can be extremely functional without requiring Javascript, especially not for doing CSS and markup.
[deleted]
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.
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.
>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.
How many real "distributed applications" do you see on the web, though, versus documents with dynamic content?
Is Medium, which is primarily intended to serve text, but which depends on javascript, an app or a document? What about Facebook, which despite its complexity still looks and acts more or less like a document, albeit with interactivity and asynchronous loading. Is it a matter of static versus dynamic content? Memory usage and computation? Features like AJAX and session storage?
If documents are only static, non-scripted HTML pages, then do they become applications if there is server-side logic involved?
I don't think there is an objective description of "web app" versus "document", I don't think the web is as cleanly cut along those lines and many might like to believe.
How many real "distributed applications" do you see on the web, though, versus documents with dynamic content?
Is Medium, which is primarily intended to serve text, but which depends on javascript, an app or a document? What about Facebook, which despite its complexity still looks and acts more or less like a document, albeit with interactivity and asynchronous loading. Is it a matter of static versus dynamic content? Memory usage and computation? Features like AJAX and session storage?
If documents are only static, non-scripted HTML pages, then do they become applications if there is server-side logic involved?
I don't think there is an objective description of "web app" versus "document", I don't think the web is as cleanly cut along those lines and many might like to believe.
There's a simple heuristic that works pretty well for me: does it still make sense in Reader View? If so, it's a document, and it shouldn't have needed Javascript. If not, then it's probably a web app.
I am less concerned about server-side logic than the expectation that I'm just going to be happy to run arbitrary code provided by other people on my machine.
I am less concerned about server-side logic than the expectation that I'm just going to be happy to run arbitrary code provided by other people on my machine.
Doesn't the mere existence of reader view make your point moot?
The web browser is your software -- I have mine customized with plenty of plugins, blockers, and reader view. You can take content, remix it, and display it however you like. I can render this site as green text on a black background if I wanted to.
I can write my own web browser if none of the existing ones do what I want.
The web browser is your software -- I have mine customized with plenty of plugins, blockers, and reader view. You can take content, remix it, and display it however you like. I can render this site as green text on a black background if I wanted to.
I can write my own web browser if none of the existing ones do what I want.
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.
I just need full module support and I'll be laughing.
Maybe I'm just crotchety now and/or beyond front-end fatigue but I keep thinking, "you don't need all that!"
I prefer JavaScript to all the other languages I've learned/worked with (C#, Java, PHP, Python, Lisp, etc).
So thanks but no thanks.
So thanks but no thanks.
I prefer ActionScript to all the other languages I've learned/worked with (C#, Java, PHP, Python, Lisp, etc).
So thanks but no thanks.
Oh, wait...
So thanks but no thanks.
Oh, wait...
So, if you are one of the people who doesn't like JS, then... what? Screw you?
We're not gonna "kill JavaScript" (quoting the article) just cause some people don't like the language.
I don't think it's a matter of killing JS - that would be rediculous. I don't think it's unreasonable that people should be able to choose the right tools for the job and it's not ok for JS fans to just say that JS is always the right tool
> So, if you are one of the people who doesn't like JS, then... what? Screw you?
You can "compile" languages to JS and pretend you're not actually using JS, though, or wait for the hot mess that is WASM to maybe settle into something sane. Otherwise, if you want to write code that runs in the browser? Yeah, kind of.
You can "compile" languages to JS and pretend you're not actually using JS, though, or wait for the hot mess that is WASM to maybe settle into something sane. Otherwise, if you want to write code that runs in the browser? Yeah, kind of.
> 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?
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?
Agreed. When a user opens Microsoft Word, billions of lines of code are executed without supposed consent.
Not to mention when your operating system likely updates itself, when you import new dependencies from a repo, when any software is updated to a new version by any means other than the user recompiling from source, etc.
It happens all the time but for some reason, it's more evil when it's javascript.
It happens all the time but for some reason, it's more evil when it's javascript.
Ergo, "Let's Replace MS Word with Something Better".
JS is much more foisted upon users than MS Word ever was.
JS is much more foisted upon users than MS Word ever was.
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.
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
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
> Let’s Replace JavaScript
The entire article is about changing various browser APIs, not Javascript itself
The entire article is about changing various browser APIs, not Javascript itself
It's about adding browser APIs in order to replace Javascript in the most common use cases.
> 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).
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).
Wasn't this Google's premise when they released Dart?
Also CoffeeScript and TypeScript
Well, CoffeeScript and TypeScript are different in that they simply compile into Javascript, but Google initially intended dart to be available directly within web-pages. More on the reversal of that decision here: https://news.ycombinator.com/item?id=9264531
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.
What's your favored language? Because odds are good that it can compile to JS:
https://github.com/jashkenas/coffeescript/wiki/list-of-langu...
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'm curious: what's so bad about JavaScript that other languages seem to do better?
The implicit type coercion of JavaScript is terrible, the single-inheritance prototype system is awful, lack of integer types, and undefined.
Single inheritance prototype system is actually something I like about js. I'm wondering why you consider it awful?
It's too ad-hoc and over-complicated to implement common things such as classes and interfaces. In JavaScript you're essentially stuck with stringly typed values and chaining mix-ins together to emulate a class hierarchy. It's also difficult to get instanceof to work as one would expect. The other languages I'm used to all natively support it: Python and Java. Granted, Java is single-inheritance too but you can implement multiple interfaces.
Ah yes if you're thinking in terms of classes then that would be frustrating.
Even with the most ubiquitous language in the world using prototypical inheritance, the average (mean) programmer prefers to imagine and express themselves in an inheritance based system. At some point, everyone will have to accept that prototypical approach is fine for some, but less productive over time for the world.
NaN is the ultimate horror within JavaScript's type system.
Other than that, you're spot-on.
Other than that, you're spot-on.
How many times have NaN semantics actually broken your code? My guess is never.
NaN behaves as it does in any other language with IEEE 754 floats (the behaviour of NaN simply comes from IEEE 754), which is most…?
> NaN behaves as it does in any other language with IEEE 754 floats
Yes, but most other languages don't use IEEE 754 binsry floating point as their only numeric type. Or even their primary one.
Yes, but most other languages don't use IEEE 754 binsry floating point as their only numeric type. Or even their primary one.
While I dislike NaN and would much rather prefer an exception to be thrown, I can accept NaNs existence because it's at least part of the IEEE 754 standard. It still bugs me that `NaN != NaN`, and JavaScript's type coersions make NaN worse because it seems like they randomly popup.
or undefined and null.
I mean most languages have "problems" with null, but JS basically has two "problems".
The type system and standard library.
The standard library is improving a lot.
> The standard library is improving a lot.
Javascript has next to no standard lib, actually. Let's not forget that the DOM or WebAPI are not part of ECMAScript spec.
Javascript has next to no standard lib, actually. Let's not forget that the DOM or WebAPI are not part of ECMAScript spec.
What do you think it needs?
It still doesn't have integers.
Agreed. The fact that JavaScript lacks reasonable numeric types means that I never use it except when there is no alternative.
Not having numeric types is a real issue - but on the plus side BigInt is advancing quickly https://github.com/tc39/proposal-bigint
[deleted]
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
I wasn't aware of this. This is awesome! Thank you
No standard library hurt for a long time.
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.
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.
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.
Webassembly is the better thing we will replace JS with as a target language for browsers.
JS will stick around because it is easier to write. WASM will be for heavy lifting, not for making a modal pop up.
WASM will pave the way for other 'easier to write' languages to occupy the same space as JS. Rust is pushing heavy for native browser support and will likely be an early adopter in this space. It's only a matter of time until <your language of choice> will support compiling to WASM and run in the browser
The problem with that is, no one is going to be writing raw WASM code - it's going to be compiled from another language, which means requiring a compiler toolchain to replace an interpreted scripting language that only really requires a text editor.
For sites which are already using the paradigm of "compiling to javascript" that might not be an issue, but that doesn't cover all the use cases for Javascript.
Other languages can't really occupy that same space until it's possible to, say, embed Lua or Rust source in script tags and just have it work as easily as Javascript does, and have the browser handle compilation and execution entirely.
For sites which are already using the paradigm of "compiling to javascript" that might not be an issue, but that doesn't cover all the use cases for Javascript.
Other languages can't really occupy that same space until it's possible to, say, embed Lua or Rust source in script tags and just have it work as easily as Javascript does, and have the browser handle compilation and execution entirely.
> means requiring a compiler toolchain
If your compiler toolchain both runs on and generates WASM then you’ve removed about 90% of the pain of compiler toolchains. The experience should be on par with something like typescript or one of the ecma compatibility compilers. There’s still potential for classes of issues that would not exist in straight Javascript, but I’d rather debug most of those with browser tooling than gdb.
If your compiler toolchain both runs on and generates WASM then you’ve removed about 90% of the pain of compiler toolchains. The experience should be on par with something like typescript or one of the ecma compatibility compilers. There’s still potential for classes of issues that would not exist in straight Javascript, but I’d rather debug most of those with browser tooling than gdb.
That's an interesting thought. I didn't mean to suggest anyone code in WASM, but I think I see what you mean.
I have experience embedding lua applications within mobile apps, and it required a fair deal of wiring in C to marshal between java and lua (android) or swift and lua (ios).
To do the same in WASM sounds rather undesirable.
Edit: to finish my thought, I dont see the problem with using a compiler toolchain to create web applications. Can you elaborate on why that isn't a good thing?
I have experience embedding lua applications within mobile apps, and it required a fair deal of wiring in C to marshal between java and lua (android) or swift and lua (ios).
To do the same in WASM sounds rather undesirable.
Edit: to finish my thought, I dont see the problem with using a compiler toolchain to create web applications. Can you elaborate on why that isn't a good thing?
>Can you elaborate on why that isn't a good thing?
It's not a bad thing per se, but it's added complexity without any obvious benefit if that code is still doing what javascript already does, just as a binary blob, especially for simple uses like glue code around jQuery or the sort of JS running on Hacker News.
It's not a bad thing per se, but it's added complexity without any obvious benefit if that code is still doing what javascript already does, just as a binary blob, especially for simple uses like glue code around jQuery or the sort of JS running on Hacker News.
> To do the same in WASM sounds rather undesirable.
This can be automated though; it's what we've been working on in Rust, and the approach is fundamentally language-agnostic.
This can be automated though; it's what we've been working on in Rust, and the approach is fundamentally language-agnostic.
That's what I thought as well, because that's what's being told. However, Microsoft recently released the experimental Blazor framework, which is C# + Razor on WebAssembly. Among others things, it actually is for "making a modal pop up". Still early days, but I have to say I'm impressed.
people won't write in WASM, they will write in easy to write languages and compile to WASM
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.
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.
Whoever wrote this pile of crap hasn’t used a SPA and doesn’t understand what actually JS is used for nowadays.
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.
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.
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.
[deleted](1)
Nice to see Intercooler getting some recognition. I haven't done much front end stuff for a while but I always intended to do a deep dive into it.
[deleted]
It seems to me that you are criticizing JS as it were in 2005. There are well known -low overhead- solutions to all the 'problems' you identified.
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
I will love Python to replace JavaScript and Sass to replace CSS, but it will never happen.
WASM will mean compiling Python will be possible, and most of the useful Sass features are supported in CSS now?
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.