We Should Stop Using JavaScript According to Douglas Crockford (2023) | Hacker News Reader

We Should Stop Using JavaScript According to Douglas Crockford (2023)

old.reddit.com

58 pointsandrewfromx72 comments

In this context, describing Crockford as “the inventor of JSON” is doing him a disservice.

I’d argue he’s one of the key people who made JS a respectable language through “the good parts”.

It’s not necessarily the specific suggestions that are relevant but he was responsible for making people recognize that yes, JS is highly flawed, and yet, you can use it as effectively as any of the other popular OOP languages at the time by focusing on “the good parts” and eliminating the “bad parts”. I believe (and don’t quote me on this) he also had a very popular linter that showed this distinction could be automated.

The less popular part he added to the discourse was the idea that not only could JS: The good Parts be as good as the popular OOP languages of the time, but in fact it could be better because of the strong functional capabilities that JS had and languages like Java, C# and C++ either lacked or made cumbersome to use 15 years ago (and being a believer in functional programming I was one of those who appreciated JS because of this).

So for him to say we should move away from JS, whether right or wrong, is a pretty big deal IMO.

It's a big deal if you're saying Doug Crockford still has his finger in the pie, or that he still has deep connections to ecosystem, browser, or JS politics, and that a needle is about to cross a decision boundary. If you lead with that then that's all the credibility you need to say that Doug Crockford's position on JS is a big deal.

IMO the WASM story might end up expanding to swallow JS, but Doug Crockford won't be making that happen any faster or slower. Google also tried to introduce Dart to the browser but experienced political whiplash. I don't think Doug Crockford can help that either, especially now that Google is extra afraid of regulatory attention.

I don’t think Crockford will be leading the movement away from JS.

But he was among the people most responsible for the movement to JS so for him to say JS has run its course is important even if he is wrong.

As stroustrup said, “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”

There are many better languages than JS, and the browser ecosystem has shut down innovation in PLs, but there are some pretty large upsides to the era of language stability that we have now. I'm wary of incrementally improving a root layer and throwing out the enormous ecosystem of tooling and libraries in the process.

> the enormous ecosystem of tooling and libraries in the process

Many of which don't even survive a year. And the worst is that they're actually solving the same stuff again and again. Managing libs manually in the jQuery era was not fun, but the NPM libraries galore we have now is worst IMO.

I think I agree with everything he's saying. There have been arguments against javascript for a long time. If anything though, I think they've diminished over time as the language has improved. I still don't really like it.

But there still isn't a technology that can do what js does. That is, distribute apps in a truly cross-platform, zero-install way. So people will keep using it at least as long as that's true.

I'm still bitter that he kept comments out of the JSON syntax out of a fear they would be used for processing directives. I want to have comments in my config files, so I've been left with having almost-JSON config files, or even weirder hacks like "_comment" properties. (which could also be used processing directives FWIW)

The difference is that the “_comment” as a processing directive is that the JS value and the raw file reflect the same data, where the comment would be invisible at runtime. In this way “_comment” isn’t a workaround, it’s the reflection of the reason the decision was made in the first place (no difference between value and raw).

This is exactly right. Comments in JSON would have killed it.

Strong disagree. We ended up with a Markdown-like menagerie of parsers and serializers with varying degrees of spec-compliance and non-compliant options. In practice, there are plenty of config files that consist of json-with-comments.

I'm good with banning comments in mostly machine-targeted files. But human edited config files that I work on are mostly json these days, and have been. The "_comment" field is not in any schema. No receiving system will read it, other than to throw for schema-non-compliance. I want to leave a message for other human readers inline. If comments would have killed JSON, then we shouldn't have adopted it for config files, because I guess JSON is killing config files?

> But there still isn't a technology that can do what js does. That is, distribute apps in a truly cross-platform, zero-install way.

It's not a technology problem. You could accomplish this with almost anything - the problem is getting enough adoption to be in a majority of devices. Aside from web browsers the only example I know of are the "super apps" like WeChat.

Something like roblox could eventually morph into it. Except the corporate overlords would not be able to help themselves from enshittifying out of usefulness.

Web standards (and email) occupy a unique position that will be hard to replicate. And not for technology reasons.

I think the issue with comments runs a bit deeper and is more pervasive than the (sad) fact that plain JSON does not support them. Case in point, I just tried and improved a frequently-used piece of 3rd-party software (written in Python) that I use as a CLI tool. Because I use it frequently I want to pass in parameters on the command line instead of editing a TOML file, so I got myself a TOML parser and wrote a teeny NodeJS script that reads the TOML and returns an object on which I set a property according to the argv value, then serialize it and write out to the TOML file, then run that Python tool which grabs the value from the config. Nice kludge and all BUT, as a matter of course, the code comments in the TOML file that instruct users what the entries are for and so on—those are gone after the update. I fixed that problem by making a copy of the original TOML file.

So long whine short, I believe comments should have some kind of 1st class status in configuration files and tools should ideally offer to preserve them even when settings are updated, and to delete them when e.g. talking to another electronic machine over the telephone network, if you know what I mean. The same really goes for comments in other languages like JS, CSS, HTML: they're quite often just fly-over territory, but sometimes, just sometimes folks, they should be kept, and I don't see a great many tools that readily give me that option.

This project claims to do that:

https://pypi.org/project/tomlkit/

kudos!

Javascript runs on every device, gets around corporate firewalls, has the backing of every major tech company and most crucially has way lower expectations of quality: If a desktop app crashes your users will curse your name, a Javascript app they'll just shrug and refresh the page.

Is it a bad language? Doesn't matter, nothing can beat that feature set. In the year 2424 people will be using machines a hundred thousand times more powerful than machines today and devs will still be fucking about dealing with javascript apps running like pigs.

> In the year 2424

...if Man is still alive

By any measure except by comparison to a hypothetical counterfactual universe, I think javascript is one of the most successful programming languages of all time, and one that has added more to the world than almost any other.

It's like standards: some have better performance characteristics than others, some are more elegant, and so on. But the the best standard is the one everybody actually uses, because that is the greatest value a standard can provide.

You could say "all that is true, but let's drop JS tomorrow and replace it with something even better," and I guess that's true. It's also true of English, and money, and shoes. Even though I'm on HN wasting time instead of working, that kind of fantasizing seems like a pointless exercise.

> I think javascript is one of the most successful programming languages of all time, and one that has added more to the world than almost any other.

It is just a scripting language. If it wasn't JavaScript, it would be something else. It hasn't added anything besides lots of crappy code, most of which shouldn't have been written in JavaScript anyway.

I can't understand how anyone could find its moronic semantics bearable.

Can you give an example?

Basically the entire argument boils down to: Javascript has some technical cruft, so we should tear everything down so we can start over with a clean slate.

This is an astoundingly simplistic take from someone as reputable as Douglas Crockford. Every widely used programming language has some cruft. If we stopped using all languages that had cruft we wouldn't be using any languages at all.

I also disagree with the premise that new languages cannot get any adoption. There are lots of great ones, that are seeing some adoption, like Go, Dart, Kotlin, and Rust. It's true that development seems to slow down, but that's due to the software engineering maturing: older languages have larger codebases and more libraries written for them, which makes them hard to displace. And the standard for a new language is much higher: people expect solid package management, generics, OOP features, garbage collection, and a ton of tooling. It takes a lot more development effort just to catch up with the status quo.

How about making WASM actually work for its target use-case (the browser) rather than needing to be chaperoned around by Javascript stubs?

https://andrewarrow.dev/frame/wasm everything I do now for the web is backend go, AND frontend go wasm

I think what the original comment means is that WASM is heavily sandboxed in the browser environment, and cannot interact with the DOM APIs directly. You still need JS for that.

not all all. I just have:

    <script>document.addEventListener("DOMContentLoaded", function() {
            const go = new Go();
  WebAssembly.instantiateStreaming(fetch("/assets/other/json.wasm.gz"), go.importObject).then((result) => {
                go.run(result.instance);
                WasmReady('welcome.html');
            });

});</script>

and <script src="/assets/javascript/wasm_exec.js" class="">

and that's it! Then from go there's nothing I can't do in the DOM.

Does wasm provide synchronous access through the perimeter?

WebAssembly itself does not provide synchronous access directly; the interactions with WebAssembly modules in browsers are asynchronous. This is because WebAssembly operations, like module instantiation and function calls, are designed to fit into JavaScript's event-driven, non-blocking model.

The `new Go();` is doing all the JS that you claim to not be doing.

but all my logic that changes the DOM is in go. What am I missing?

Your logic still needs to run JS code to change the DOM. You are indirectly relying on JS despite using WASM.

ok but I have all the advantages of go. I can code my go in a modern way and escape JS traps despite the end result is still using js.

Yeah I know. I don't care if it needs a bit of JS to bootstrap either. At some point it should get to a state where you can have a site with WASM and no JS required.

the problem is that because it's js, it's much slower than it can be.

your code is not manipulating dom. your code is interacting with a library that manipulates the dom. That library has to interface with javascript. You are still doing all dom manipulation via js, it's just hidden behind the library. If you inlined all functions from that library you'd get code that interacts with js.

tldr: no, you can't possibly be doing that. Because an api for it literally, objectively does not exist.

but you are missing the bigger picture no? We can, today, stop writing business logic in javascript/typescript for any frontend code. Yes it will call an api that runs via js. But step 1, stop writing any NEW javascript right?

the wasm-js bridge is quite slow. because wasm is a 2nd class citizen. It's not about which language you write, per se. You wrote those parts in go. Great! Those parts slower because of it, due to this.

oh but not noticeably to the user. Network latency is always what the user perceive as the slow part. Here's a complex site done this way: https://linkscopic.com/space does it feel slow?

I think GP was referring to running wasm directly rather than using (as your website does with WebAssembly.instantiateStreaming) JS APIs to bootstrap it and JS APIs every time it needs to do something with the browser's built-in functionality (like manipulate the DOM).

can you link me to example that does wasm in browser without calling instantiateStreaming?

His entire point is that it can't be done currently.

so what's the big problem with calling instantiateStreaming? Explain it to me like i'm 5

instantiateStreaming is not the problem; the problem is that JS code is necessary (via that function or another) to execute WASM, and JS is necessary to call back from WASM into browser APIs. Because of that, WASM in the browser is, at present, effectively a JavaScript extension language, and it cannot meet the goals discussed by Crockford in TFA.

This hybrid approach that requires JS both at bootstrap and browser-API-interaction time significantly undercuts the benefits of WASM as a javascript replacement for several reasons. Some of those reasons are: this likely means JS will remain supported/enabled/required-for-many-sites in browsers, warts and all, in perpetuity; the advantages of WASM's sandboxability will be mitigated by the presence of a much more permissive runtime that must be present in order to load and run WASM artifacts; more performant/parallel access to browser APIs will remain difficult or impossible; multi-language/multi-build system competence will be needed due to large parts of the ecosystem remaining in browser JS.

but I'm still able to write lots of logic in Go and escape having to use the "bad language". I feel like despite the above there is still big wins by just having no application logic written in javascript or typescript.

Not only that. The DOM API and general browser APIs are designed with JS semantics in mind, and for JS. Just like the UNIX APIs are designed in C and expect to be called from C.

So even if you get other languages working alright on browsers, they are always going to be second-class citizens IMO, because they are going to be interfacing with JS APIs.

I can't think of a way to avoid this TBH, other than designing a different API for the new language, at which point i think we'd be no longer talking about the web as we know it.

ok but I still don't understand why it's not a great idea for everyone to embrace WASM as it is today and write your frontend logic in go or rust EVEN if you have to use instantiateStreaming.

You'd still need to interface with the JS APIs, wouldn't you?

For example, an API like `Element.prototype.addEventListener(string, callback)` wouldn't make much sense in Rust, IDK about Go. Sure, you can make it work, but you'll always be rubbing against an API that was not designed for that language. Hell, addEventListener isn't even on the Element prototype, but on the EventTarget prototype, which Element.prototype inherits from. And that's something else that wouldn't make sense at all in Rust: prototypical inheritance. But it's part of the DOM API. It's part of the web. So we'd have to deal with it too, even if we switch to a new language.

Does this make some sense? I feel like i'm repeating what's been said before in this comment chain, so maybe i'm missing something about what you're not understanding (:

https://github.com/andrewarrow/homeducky/blob/main/browser/v...

https://github.com/andrewarrow/homeducky/blob/main/browser/r...

https://github.com/andrewarrow/homeducky/blob/main/browser/t...

https://www.youtube.com/watch?v=dxO94MvfRCg

here's example coding frontend in go. I think I've achieved with vote.go and register.go and timer.go above a nice way in Go to do Javascript things. I don't feel limited.

That's the point.

Actual video (2023): https://www.youtube.com/watch?v=lc5Np9OqDHU

Instead of the reddit convo, some more discussions here:

Last week: https://news.ycombinator.com/item?id=41064461

Last year:

https://news.ycombinator.com/item?id=36241965

https://news.ycombinator.com/item?id=36164909

wow, good finds!

I started with Javascript the same week it was released in Netscape. Before that I was using Lynx on an Amiga, and I often opined that this internet thing needed a scripting language. Javascript came along and it was amazing, it answered my prayers. As Javascript and browser tech evolved, I grew with it, doing amazing things long before anyone else was, like "AJAX", and "Dynamic HTML", etc.

I'm still coding Javascript every day today. While I know a dozen other languages, I really don't understand the hate that Javascript gets. Other languages suck too, just in different ways. If you know the rules of a language, and you don't do obviously stupid stuff, then you can get a lot done in any language, even Javascript.

It seems like lots of programmers always want perfection in everything, and that's just counterproductive. Javascript isn't perfect, but I can get a lot done with it. I can say the same for a dozen other programming languages.

People need to stop complaining and just build stuff. Javascript is not the thing stopping anyone from building cool stuff, it's their own mental blocks and avoidance of tech they don't fully understand, or their refusal to fully understand it because they think it's somehow inferior.

I don't really need Javascript to change, I don't need it to be like every other bloated language. Keep bloating it and it will end up being something nobody wants to use, including die-hards like me.

I’m glad I found your comment at the bottom of this thread, because while I avoid JS like the plague, I love Typescript, and I can build what feels like anything for any platform faster than many people believe is possible when I quote them.

I just need some more advanced features from C# / some runtime types… not a new language altogether. But even still, of all the languages I’ve tried, I prefer Typescript and its flexibility, power, and ecosystem by a decent margin.

I must be missing a hell of a lot because I find it very hard to relate to anyone in this thread.

Typescript isn't Javascript, no matter how much propaganda you've read.

Years ago, I went to one of Douglas Crockford's talks where he advocated for non-blocking server-side code with Node.js. This was long before Javascript and Node.js had "async."

At the time, Node.js only worked with callbacks, and compared to threaded code in most other languages, the callbacks quickly became cumbersome and difficult to follow.

I asked, "Is there a way to make callback code cleaner?"

Doug's answer had no insight, it was basically something like, "they're messy, deal with it."

A few years later, C# introduced "async" and Javascript quickly followed.

---

The thing is, maintainability of code is very critical. A lot of code doesn't need the kind of scalability that Douglas was advocating in his speech; maintainability is a lot more important than shaving off a few CPU cycles.

I now take everything he says with a lot of grains of salt.

The broader point Douglas makes is the same one Jonathan Blow and Alan Kay make. "Why are we stuck with 20, 30, 40 year old software?"

We've learned a lot and we can re-build new clean stuff based on the new, richer understanding of what actually matters. But as Alan Kay talks about frequently, anything new has to be immediately just as good and usually better than the mediocre, bloated software for people to switch.

"Worse is better" still continues ...

The real culprit here is UI. Yes, there are many better languages and runtimes than JS without a doubt. But most of their UI libraries are just as terrible if not more terrible than HTML/CSS/JS. And that is because developing sensible but also flexible and easy-to-use patterns for user-reactivity and data-presentation is HARD.

So sure, start a clean new operating system with a clean language with a clean runtime. I don't look forward to using whatever mess of a UI toolkit that gets built on top of it.

To add on top of that HTML/CSS/JS is really only serious open/free not owned by any for profit org cross platform UI toolkit. That is why Electron is quite popular.

This heading is delightfully ambiguous:

1) we should stop using Javascript the way Douglas Crockford is using it/teaches us to use it

2) Douglas Crockford says Javascript should be not used

"According to" part does feel like a 15 - 25 yo writer.

The entire history of programming languages has been:

- Create a simplistic programming language that looks easy to learn and use but ends up being deceptively complex to apply to real world problems

- Fix those problems with a more rigorous approach that's hard to learn but stands up to real pressure

- Ignore all the lessons learned and create another simplistic programming language that looks easy to learn and use but ends up being deceptively complex to apply to real world problems

If we all agree to stop using Javascript and replace it with something that doesn't have Javascript's baggage I have full confidence that somebody will invent a new "simple" approach on top of that approach that will have all the same oversights Javascript had.

I'm pretty sure we could skip some of the worst ones, such as the interrelations of type coercion and equality. Variable hoisting isn't as big a deal with let, but we could remove that entirely. We could align null and undefined.

We could fix parseint. Instanceof/typeof could align with expectations. Array could be a first class type, and we could have a split between floating point and integer.

We could force global scope to be intentional, with some sort of global keyword. We could get rid of optional semicolons and go one way or the other. We could get rid if "==".

I think cleaning up equality would do the best for bug removal, but with what we've learned over the last 30 years we absolutely could clean up the worst sources of confusion.

20 years ago, I was advocating for javascript.

0:03 My story was that javascript is a much better language than anybody knows.

0:10 And that if we use it properly, we can do amazing things about it and it can change the world and in fact that happened.

0:19 But now my evangel is that we should stop using javascript that it has so many congenital defects.

0:28 It really is a smelly language.

0:31 There's just a lot of crap in it and it still may be for its field of application, the best language in the world for doing that kind of stuff.

0:44 But that's not good enough.

0:45 We should be moving on to the next generation of languages.

0:48 It used to be that we'd get a new computer languages about every generation I started with FORTRAN and then C and C and java and javascript and so on.

1:01 And then it kind of stopped.

1:03 There are still people developing languages, but nobody cares, one person can make a programming language, a really good one, but you can't get adoption for it.

1:12 There are lots of terrible mistakes in the way that the web works in the way our operating systems work.

1:19 And we can't get new ones.

1:22 We're just stuck with this crap and, and they keep piling new features on everything and the new features always create new problems and it doesn't have to be like that.

1:33 We could be using really clean operating systems with really clean languages and really clean runtime and doing all this stuff in a much more reliable way.

1:45 But, but we don't seem to want to do that.

1:49 I've done javascript for a generation.

1:53 It's time for the next thing.

1:55 I, I don't think that should be AAA, considered a radical point of view.

1:59 I think it should be a normal evolutionary, view.

> It's time for the next thing.

It's https://caniuse.com/wasm

Reddit thread on “Why We Should Stop Using JavaScript According to Douglas Crockford (Inventor of JSON)” (2023, video 2’15”) https://youtu.be/lc5Np9OqDHU?si=u5a3feWZa946sk7D

He doesn’t really say much other than it could be better if we used “clean” operating systems and “clean” programming languages, whatever that means.

JavaScript is a colossal solution to the demands of product, design, business, users and other stakeholders. Crockford was one of the first to effectively sell it to engineers. It has developed into a nice language with modern features and an incredible debugger, and objectively (to the people we serve, whether users or other clients) the browser is a much richer, more capable and reliable platform today as a result.

NPM has by its nature and on many individual occasions done lasting damage to the project, the reputation of the language and professionalism of the JavaScript community. There is a lot of frustration over this, as well as the "10,000 frameworks" issues (which seemed overwhelming for a time), these and other experiences justifiably put a lot of people off who decided never to get into JavaScript because it seemed like a shitshow.

How much criticism of the web platform today is about its vestigial language features? Very little it seems, compared to 10-20 years ago when the language actually sucked and was considered a joke. It doesn't make sense to stop using it because it's mature and in place, we invested in this thing (as far as the web goes). No, JavaScript's biggest issues are apparently cultural.

I have disabled JavaScript on mobile Safari because I can’t install uBlock Origin and most websites are blackmailing me with either injecting surveillance stuff or credit my bank.

Without JavaScript, all popups are gone

Yup, and it’s faster, but most websites don’t work.

Some don’t. If they are worth it, you can open them with another browser

Sharing a reddit link for the purpose of sharing a youtube video seems weird. WHat's the point of that? Is it to game the HN algorithm somehow?

~that's a reddit video~

update: confirmed it's a youtube video posted to reddit

I was able to download it with:

yt-dlp "https://www.reddit.com/r/programming/comments/1eht39z/why_we..."

The point is the comments on reddit, this is a big news story.

The reddit post is just an embedded youtube video: https://www.youtube.com/watch?v=lc5Np9OqDHU&t=1s

ok but if I post that link to youtube directly no one would have the context that it's blowing up on reddit.

My "devil's advocate" take is that that the reddit post provides an additional source of discussion points.

Reply on news.ycombinator.com