Seems like most (all?) people in this thread are not picking up on the key insight that he's putting forward here -- which is the encapsulated process & security capability model that was in E.<p>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.<p>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.<p>I encourage people to read up on caps, and actually on E itself.<p>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.<p>EDIT: obligatory WP links: <a href="https://en.wikipedia.org/wiki/Object-capability_model" rel="nofollow">https://en.wikipedia.org/wiki/Object-capability_model</a> and <a href="https://en.wikipedia.org/wiki/E_(programming_language)" rel="nofollow">https://en.wikipedia.org/wiki/E_(programming_language)</a>
In your opinion, what expected changes in JavaScript are going to be the most important?<p>"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."<p>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.
He knows perfectly well there is zero chance JS is going to be retired. It certainly has some serious flaws but the ecosystem is only growing richer by the day. Typescript plus React/Svelte/Vue etc is an extremely productive development experience.<p>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.
Mr Crockford has done a lot for the JS world, but I think he's on the wrong track. The best thing we should be doing is focusing on building a best-of-breed VM replacement in WebAssembly where the language is disconnected from the page itself.<p>Build infrastructure and the right languages will come. Build another language, and we'll end up building a second Javascript.
JavaScript is far too popular to be retired any time soon. It may be that one day it will go the way of Perl - still used in niche areas, even still maintained as a language, but effectively replaced in the mainstream by something else - but it's going to be around for a long, long time.
The JVM + applets were supposed to be the future. Flash was supposed to be the future. ActiveX, Silverlight, OpenLaslo, etc.<p>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.
The worst thing about javascript is all the legacy cruft, but if you could get everyone to agree to replace javascript with something else you could probably also get them to agree to break support for legacy stuff to clean up the language.
"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."<p>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.
Interesting interview, some rather ... direct opinions like the title showed.<p>I had to go look up [1] to resolve the ambiguity, that was not the language he meant (as I assumed).<p>[1] <a href="https://en.m.wikipedia.org/wiki/Amiga_E" rel="nofollow">https://en.m.wikipedia.org/wiki/Amiga_E</a>
It's already happening isn't it? When WebAssembly gets direct DOM access, there will be many contenders to JavaScript's throne, e.g. Rust or some superset of AssemblyScript. Perhaps TypeScript will eventually transpile directly to WebAssembly.
For me, the most valuable part of this interview was -<p>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.<p>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.<p>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.
The Bushnell anecdote is pretty funny. Especially considering Bushnell was famously offered a 1/3 stake in Apple for $50K and declined. Who knows how that might have changed history, but 1/3 of Apple today would make him the richest man in the world by a mile.
The dailies idea is super interesting, it would be nice to get your team on board but you can do this individually without permission.<p>Reading the previous day’s code won’t even take that long.<p>Also yes, javascript has had a long and industrious life, I agree with retiring it.
Anybody smarter than me can explain why the E language is more adept at security?<p>It looks like Java with different syntax to me. Is it the compiler what is special?