Douglas Crockford on JavaScript

&gt; It used to be that we’d get new computer languages about every generation. […] And then it kind of stopped. There are still people developing languages, but nobody cares.<p>I think this is false. We can see great interest in new languages, and I feel like languages like Rust and Go have achieved to move the ball forward significantly for backend &#x2F; system software development.<p>It&#x27;s just that noone has been able to replicate that kind of success in the web-based frontend space.<p>This happened in the case of Rust and Go after LOTS of searching for better alternatives to C&#x2F;C++ and later Java. There are a lot of failed attempts along the way, and some which find their niche but fail to displace the older generation languages in any meaningful way.<p>There has been TypeScript and Dart and transpilers that have tried to shield us from the horrors of JavaScript development, but in the end they still are too closely related to JavaScript and its runtime to truly displace it. I feel like we have an opportunity now, with WebAssembly, to move beyond these limitations.<p>If browsers and web standards move to a point where we can use WebAssembly as a first class citizen, without the need for JavaScript scaffolding, we could see the rise of a new crop of languages for the frontend. Perhaps even making it possible to remove JavaScript entirely and move it into a WebAssembly module eventually, to remove it as the default choice and put it on equal footing with new alternatives.<p>We could take the lessons we have learned from other modern languages, and apply them more natively to frontend problems and practices, with language-native tooling and a higher level of integration in those tools than we have been able to achieve with JavaScript.

He is obviously right about the stagnation but he does not seem to be connecting the dots (at least in this video) about why this is so - which in turn might inform us as to when to except some change.<p>Languages and their tooling ecosystems express how computing is concretely embedded and used by society. People adopt the tools to get jobs and to get the job done, whatever the &quot;job&quot; is. In turn the available remunerative jobs fit certain business models and markets.<p>The ecological landscape that prevails today is largely monocultures centered around the distortion fields of a few oligopoly entities. But not exlcusively so. You still have all sort of remnants of previous era landscape, the enterprise world stuck in its java coffin, the quirky projects of the Web 1.0 era still trusting php etc.<p>Massive adoption of a fresh and &quot;clean&quot; new thing will only happen with the emergence of a new economic reality, expressed for example through new actors. New tools that make desirable new things possible <i>may</i> enable such an evolution and eventually may be synomymous with it but these things don&#x27;t happen made to order.

Trying not to make this an ad-hominim attack, but Crockford has been a net negative to JS for 20 years now.<p>While people like John Resig were innovating (jquery) working with the language and around all kinds of language quirks 15 years ago, Crockford wrote his book &quot;The good parts&quot; that tried to write java in javascript. And probably did more to make people write bad JS code than anything else.<p>Then he made the mess that was YUI at yahoo with the same enterprise patterns. When that failed he went right back to these types of doomsday messages in the media every few years calling for the end of Javascript.<p>Meanwhile we have seen ES6&#x2F;typescript&#x2F;react and countless other innovation take place.<p>He might be right on some fronts, but at some point its a case of put up or shut up imo. There are far better experts to talk to about the state of JS and its future.

Is he talking about the old &lt; ES5 javascript or the new ES6+ with WebAPI standards?<p>Because to me, it&#x27;s quite remarkable how JavaScript has evolved since &lt; ES5. ES6+ introduced a slew of features like arrow functions, template literals, async&#x2F;await, destructuring, classes, enhanced object literals and native modules. It&#x27;s way more developer friendly when writing new stuff than it used to be.<p>Not to mention, the integration with Web APIs has been a game changer. Fetch API, WebSockets, Web Storage, WebRTC and Service Workers, WebAssembly really enables a lot of functionality that&#x27;s all easy to use and very fast. TypeScript also helps with gradual typing together with syntax highlighting and lookups are superb for avoiding unexpected mutations and a lot easier re-factoring.<p>Also, what do he suggest would be the replacement? Because it&#x27;s not enough to replace the scripting language, it would need to fit into the DOM, HTML and CSS too.

&gt; &quot;[...] we are crushing ourselves with the accumulated complexity we’ve piled on top of bad foundations [...]&quot;<p>The same could be said about plain HTML&#x2F;CSS though. I think the author is correct overall and I don&#x27;t really see improvement on the horizon. WebAssembly, while great that it exists, can morph browsers into some poor mans virtual operating system and this can lead to a less open web.<p>We already see more closed Platforms like Discord. I use it too, the product is completely fine, but it sucks in information that isn&#x27;t availble on the open net if you don&#x27;t go through the platform. Some communities exclusively use it and they get little discoverability through web searches. Sure, this isn&#x27;t really related to Javascript&#x2F;Webassembly, just a development I fear will increase and which could be accelerated with different approaches to languages.<p>A front-end scripting language available in every browser is very, very useful. I think few new languages could replace it here, I don&#x27;t know of any at least. And I think a lot of flexibility is lost if you begin to transpile anthing into Javascript. Granted, for large projects it is pretty much a requirement to do so at some point.

I am skeptical about the performance part (object lifecycle management being a subset of that), whether this is a serious issue causing bottlenecks in modern (not over engineered) production software. It seems to me that subset of software that needs the performance (like hashing, large binary data processing, geometric processing, etc) are things that should be offloaded to GPU for real performance or if it has to be done on the CPU, be run under optimized WebAssembly with no dynamic memory allocations. Since JavaScript has a very good packaging ecosystem compared to other languages, often you don&#x27;t even have to go out of your way to do that. Someone else has probably done it, and it may just be a require(&quot;xxhash&quot;) away.<p>I think it&#x27;s quite backward thinking actually to bend the language making it more complex for the human for the benefit of the compiler. Especially with the shift to LLMs, programming languages should be closer to natural language and expression, not vice versa.<p>The good JS packaging ecosystem takes care of the small standard library issue, but I definitely agree there&#x27;s room for expansion there. This seems like a surmountable problem. And by standard lib I&#x27;m not talking about things that can be trivially be implemented with Array&#x2F;Object&#x2F;Map (like queues or ordered maps), I mean things like RNG, math functions, or things like the recently added `fetch` method for HTTP calls.

As we nowadays compile TS to JS anyways, it would be a small step to go full WASM and have language agnosticism mostly.<p>A bit related: I still do not really understand why WASM has no direct DOM access. Answers to this question seem to fall into two categories:<p>- We don&#x27;t need it, because you can do everything via a Javascript detour easily<p>- We don&#x27;t want it for reason X<p>To me both feel a bit like excuses. I&#x27;ve yet to see a hard technical reason why it is not done. So, why not make WASM a first class citizen and do away with Javascript for good?

Software quality has never mattered in web development. When the W3C tried to push XHTML web devs balked at the idea that they should understand markup languages and not have syntax errors.<p>JS is installed on every machine, you don&#x27;t need to deal with IT bureaucracy getting apps installed or heaven forbid ports opened, and it&#x27;ll never ever have anything less than the full backing of the browser developers. Even Brainfuck would be the dominant language with that feature set.<p>So long as that remains the case, as it will in my lifetime, nothing will change.

&gt; But as increasingly complex software targets the browser, developers are wrangling codebases where UI is not the dominant source of complexity, like CAD tools and scientific data visualization.<p>I guess WASM is already taking this place?

Ok show me another language which has near native performance, gradual typing (thinking TypeScript here), and lets me do lightweight functional and lightweight OO programming.

First we need a good alternative. JavaScript may not be the best, but it works well.

I wish! I wish!! I so wish this would happen. And the ‘type’ attribute to the script tag would finally mean something!<p>But nope. It won’t be. Just as var remains to support old webpages. Use strict to support newer features without affecting old ones. Imports. Etc.<p>But the post is factually off. In fact there is now an ordered map in JS. I think whoever is responsible for the spec and the implementations need to be complimented. Its actually shocking that it works so well. I have written painting software (much more computationally expensive than CAD software) using Canvas and WebGL apis and it’s pretty darn performant. Never native. But still very very good.<p>Although I don’t know about the vitriol in the comments toward old crocky. And his good parts book was good and useful to me in parts.

What is one of those &#x27;really clean&#x27; languages that we should be using then?<p>I&#x27;m interested!

JavaScript is fine, the real problem is HTML&#x2F;CSS and the DOM.<p>We were so, so close to a semantic, reader-based web ~20 years ago.<p>The ad supported Internet killed it. Now that the ad supported Internet is dying, maybe we can get back to it.

Any time something is adopted as broadly as JavaScript it&#x27;s going to be a mess. Even outside the world of computing. Take... city planning. Cities are a mess. In fact human civilization is one big freakin&#x27; mess.<p>Wouldn&#x27;t it be nice if we could start over and apply all the lessons we&#x27;ve learned over the generations? The world would be a much better place!<p>Or would it?<p>We&#x27;d end up with yet another mess. It&#x27;ll be a different mess but it&#x27;ll be a mess nonetheless. Or worse - we&#x27;ll end up with two big messes instead of one big mess!

&gt; &quot;Notably, none of these are walls you’ll hit if you’re writing a blog or e-commerce site, which is why JavaScript isn’t going away.&quot;<p>Pretty much sums up everything :(

Most of boilerplate code i wrote is mapping data structures between API standards. None of the is related to javascript. So i won&#x27;t stop using javascript.

He&#x27;s got a point. TypeScript alleviates some pain, but I still feel like JS is not a great language. I have some nostalgic love for it because I used to be &quot;the JavaScript guy&quot; at the beginning of my career. But ever since I started using TS and Go, using Vanilla JS feels like fighting code smells and complexity all the time. At the same time, I acknowledge and appreciate how much JS has improved.

As a culture, we are stuck. This article illustrates this well: <a href="https:&#x2F;&#x2F;lindynewsletter.beehiiv.com&#x2F;p&#x2F;culture-stuck" rel="nofollow noreferrer">https:&#x2F;&#x2F;lindynewsletter.beehiiv.com&#x2F;p&#x2F;culture-stuck</a><p>This language refusing to fade away like other ancient languages is just a symptom of the root cause. Myself, I use Elixir as my primary language.

I remember Crockford&#x27;s lectures at Yahoo in 2009, and they were inspiring, but in the hindsight, most his bold points turned out incorrect.<p>#1: The promise of high speed with event loop &amp; JIT compiler. Crockford&#x27;s idea was that if you make small functions that return quickly, JIT will boost their speed drammatically. Plus, fast yielding would make programs seem faster for the client.<p>By then, Google Chrome wrote impressively fast JS engine, but later the speed of JS didn&#x27;t improve much. JIT-based languages and engines didn&#x27;t match performance -- I myself tried Pypy, and it wasn&#x27;t fast like C.<p>I must give him credit that his lectures made me finally get how the event loop works.<p>#2: That Promises and async would make async programming much easier. Promises do make code better than callback hell, but still are tedious. The side costs of async are well summarized in this post &amp; presentation: <a href="https:&#x2F;&#x2F;vorpus.org&#x2F;blog&#x2F;notes-on-structured-concurrency-or-go-statement-considered-harmful&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;vorpus.org&#x2F;blog&#x2F;notes-on-structured-concurrency-or-g...</a><p>#3: Object construction with closure function. We tried that wholeheartedly at contemporary project, and it was awkward. I haven&#x27;t seen any popular framework do this approach either.<p>#4: Decentralized web evangelism in mid-&#x27;10s. This is a bittorrent concept extrapolated to web hosting, later it got traction branded as Web3. It&#x27;s clear by torrents that they work only when everyone cooperates, and carries some serious load, otherwise torrents die out. The decentralized web requires every user to host a good bit of data, and any document published puts this load on everyone in the system. As with Ted Nelson&#x27;s concept, it makes sense only in small environment of cooperating users.<p>That being said, Crockford&#x27;s lectures were interesting for history part, and he made a good point that one should looki into history and see what is logical and progressive, what we got just accidentally and it stays as legacy.

I get his point, but it may be too late for it as some applications even have backends in js..<p>However I agree that it is somewhat problematic that instead of creating new languages, we create frameworks (sometimes frameworks based on other frameworks like nextjs). Especially considering how messy js can be.

He is promoting an &quot;actor language&quot; to replace JavaScript. <a href="https:&#x2F;&#x2F;www.crockford.com&#x2F;misty&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.crockford.com&#x2F;misty&#x2F;</a>

We had this argument in 2012-13 when Google Dart came out. I advocated for a Dart VM in the browser but the Blink team killed that idea. Brenden Eich explained here on HN what the problems were and made good sense. Now there would seem to be even less reason by using JS as a target language and by using WASM. JS devs have other options, but they still choose JS or TypeScript. Crockford sounds like an old man yelling at clouds (I&#x27;m older than him, so not ageism)

Strip down the browser APIs and make the web more user friendly and deterministic again while your at it. The History API, for example, should never have been implemented.

The problem is not just a language problem. The problem is the repurpose of the web as an &quot;operating system&quot;. HTML and CSS are OK for document layout and styling, and JS is OK for simple interactions. BUT none of these were designed to handle highly complex and dynamic applications. We are just building on the wrong foundation, hacking to extremes to twist the the framework to the current trend. We are using the wrong tools for the job.

&gt; we’d get new computer languages about every generation.<p>&gt; accumulated complexity we’ve piled on top of bad foundations<p>OTOH when we get new computer languages, they usually start really simple as a sort of protest against the &quot;old&quot; complexity and then spend the next few decades shoehorning back in all the things they left out to keep it simple but that it turns out we actually needed.

While we&#x27;re at it, we should stop using VHS.

Listen also to Crockford&#x27;s interview on the Corecursive podcast: <a href="https:&#x2F;&#x2F;corecursive.com&#x2F;json-vs-xml-douglas-crockford&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;corecursive.com&#x2F;json-vs-xml-douglas-crockford&#x2F;</a>

Languages are validated by their use. All other interpretations of their value are abstractions from the only real metric, that people use it and it is alive in that way. We don’t speak dead languages and we don’t adopt them either.

He says that a new language used to pop up every generation -- and that seems to me like it&#x27;s been the case -- Elixir, Rust, and Go all seem to have arisen during the last 15 years.

How can you take seriously a guy who didn’t allow comments in JSON?<p>As smart as he is - he obviously doesn’t give a single f* about real life problems and challenges of real life programmers.

Can someone summarize crockfords opinion on the current state of the browser js api? And his opinion on reactjs