The best thing we can do today to JavaScript is to retire it
crockford.com
crockford.com
I think he's absolutely right that the "right" replacement for JS is something built on that kind of foundation. It's not a matter of a language with a better syntax or a better arbitrary runtime like WASM, or whatever. It's the component and security model itself.
Unfortunately 30ish years on, people still don't seem in general to understand capabilities and what this can provide for us, especially in a environment with the trust model of the browser, which is executing arbitrary code from all over.
I encourage people to read up on caps, and actually on E itself.
I'm glad to see Fuchsia running with the capabilities baton. And it's in a lot of devices in the form of SeL4. But almost never exposed as an aspect of "end user" programming.
EDIT: obligatory WP links: https://en.wikipedia.org/wiki/Object-capability_model and https://en.wikipedia.org/wiki/E_(programming_language)
> It's the component and security model itself.
WASI and the WASM component model proposal [1] are moving to a capability based system (enabled by unforgeable references aka `reftype`) and to isolation between different parts of your code, which would make isolating and restricting dependencies really easy.
Combined with interface types (essentially a universal cross-language ABI) the ecosystem has the building blocks for building very secure systems.
Sadly progress has been very slow, with no end in sight, but I remain hopeful.
Probably I should watch this more closely, or see if there's a reasonable way I could get involved.
I still think there's a long rough road to "get there from here" in the context of the browser though, which has already defined its own (non-capability based) security and component model. Luckily what I work on right now doesn't involve the browser.
That's because they think they've seen it, and what they saw was horrible.
First was the UAC stuff in Windows Vista that caused no end of unnecessary headaches. Next was all of the permissions flags (capabilities) in their phones in the name of "security"
It's a Java/Javascript situation. I'm not sure what the best way to route around this is. Recently I've used these analogies:
Cash in a wallet - if you hand someone $10, there's no way that it can lead to a loss of more than $10, as opposed to access to your entire wallet
Circuit breaker / Outlet - An circuit is only capable of delivering up to the limit of the circuit breaker that is protecting it
The notion that the "handle" or "reference" is the capability and the API itself is the 'permissions' layer is harder to explain maybe. I still struggle fully with the vocabulary around it.
Capability Based Security - No, you really don't know what it is (like Java/Javascript, there's confusion.. it's not Windows Vista UAC, nor the flags for apps on your phone, not even AppArmor or SElinux)
Currently, when you start your favorite GUI based editor, and tell it to open a file, it calls on the OS to present a dialog box, who chooses file(s), those names are then passed back to the editor. The editor then uses the users permission to open the file(s), and allow you to edit your data. Note that there is NOTHING stopping the program from getting confused or malicious and opening any arbitrary file using that user's account.
The exact same workflow happens in a Capabilities based OS, except the names of the parts and constraints (that you don't see) are different. It works exactly the same, as far as the user is concerned.
Instead of calling on the OS to present a dialog, then directly accessing the files, the program calls the OS to present a PowerBox to the user, and it returns capabilities to files or folders, the program has NO access to any other folders or files. No matter how confused or rogue the editor can not corrupt anything outside of the objects specifically chosen by the user.
"The best thing we can do today to JavaScript is to retire it. Twenty years ago, I was one of the few advocates for JavaScript. Its cobbling together of nested functions and dynamic objects was brilliant. I spent a decade trying to correct its flaws. I had a minor success with ES5. But since then, there has been strong interest in further bloating the language instead of making it better. So JavaScript, like the other dinosaur languages, has become a barrier to progress. We should be focused on the next language, which should look more like E than like JavaScript."
Well he is right about that, the amount bloatware in terms of frameworks, libraries. I wish JS would have better goal or vision than to just make it like all for one kind of language mentality. These JS committees are hell bent on creating browser OS so they could eventually force everything to subscription based garbage software in running browsers requiring 64GB of ram. I guess we might be headed for those future sooner than we think. PS: Sorry for grim outlook but it kind makes sense from business perspective.
In order to displace an entrenched technology it's not enough to be marginally better. You need to be an order of magnitude more productive to get people to pay the switching costs. None of the proposed JS replacements meet that criterion.
Build infrastructure and the right languages will come. Build another language, and we'll end up building a second Javascript.
Wasms safety is dependent upon the runtime implementation, not the language.
"Fast" is a motivation in web. If it renders slow, it loses money. We have 20 years of hacky methods to make JavaScript fast. These lead to security flaws.
I have no idea how anyone could ever keep up with all this stuff. The language spec just grows ever larger each year. It's just far too much.
Imagine if all the authors of C++ compilers got together for an international symposium and some catastrophe struck. Like a gas leak causes an explosion and they all die tragically. I could absolutely see the language transitioning to being an anachronism. All the knowledge to actually work on the language implementation would be lost. We could still maintain existing software in C++ for a while, but eventually we'd even need to use legacy systems just to host the compilers.
Edit: downvoting will not change that
‘Growing a Language’ by Guy Steele is probably more relevant than ever here — and for all the dislike Java as a language gets, it is remarkable in how lean it remains even today, resisting the urge to add everything and the kitchen sink.
HTML, CSS, and JavaScript have so much momentum behind them. They are each a warty mess, but upon that warty mess is built the foundation of the worldwide information ocean.
That seems much better than the mandatory code reviews that are pervasive nowadays. Most of my annoyance with those is the mandatory part - I think it increases the threshold to make small improvements sufficiently that they either don't happen, or happen together with unrelated changes, which is then a reason for the resident purist to scold you. I also think doing them asynchronously, as a form of email, rather than in-person or video introduces friction unnecessarily.
I had to go look up [1] to resolve the ambiguity, that was not the language he meant (as I assumed).
Is that going to happen in the foreseeable future, i.e. is there a roadmap? Can't find much about that.
In filmmaking, there is a time in the morning called "dailies", when the previous day's footage is examined. It looks like everyone is just sitting around watching movies and wasting time, but it is critically important in finding problems early and assuring the quality of the product. I believe that we should do the same thing in programming. We have a time every morning when the team gets together and reviews all of the code and designs that were developed the previous day.
The benefits are obvious. As an individual, you collect professional experience points faster by reviewing the work of others. As a team, you have more eyes looking for errors and faulty designs and giving praise for good work and instruction where needed.
It is easy to convince smart programmers to adopt this practice. It is harder to convince managers because the code reading time looks like lost time. But it is not. It is explicitly scheduling quality into the process. It usually does not take much time because we can not write that much code in a day. It can only work if management requires it and it becomes part of the culture.
Reading the previous day’s code won’t even take that long.
Also yes, javascript has had a long and industrious life, I agree with retiring it.
It looks like Java with different syntax to me. Is it the compiler what is special?