Live data from Hacker News

Douglas Crockford on JavaScript

digest.browsertech.com

91–100 of 202 posts

Re: Douglas Crockford on JavaScript

#92

Earlier quoted context omitted.

> Meanwhile we have seen ES6/typescript/react and countless other innovation take place. I don't see these as innovations but workarounds to, or built upon, the poor foundations that the author mentions. They wouldn't need to exist if the foundations were solid, or at least not in the states they are in today

On the other hand, all the tools built on top of Javascript could just as easily be explained by solid foundations that are easily to target with higher levels of abstraction rather than symptoms of the foundation being rotten. It makes more sense to ask "compared to what?" and look at what's going on in the lateral client application platform space. On iOS, it's very hard to target the foundation with higher level c…

> could just as easily be explained by solid foundations

No they couldn't. There were two options for the web, build on js or find a different job.

Re: Douglas Crockford on JavaScript

#93

Trying not to make this an ad-hominim attack, but Crockford has been a net negative to JS for 20 years now. 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 "The good parts" that tried to write java in javascript. And probably did more to make people write bad JS code than anything else. Then he made the mess…

What? The man who created JSON was writing enterprise patterns? When, how?

This the same man who wrote this?

> JavaScript has a syntactic similarity to Java, much as Java has to C. But it is no more a subset of Java than Java is a subset of C. It is better than Java in the applications that Java (fka Oak) was originally intended for. ...

> This is misleading because JavaScript has more in common with functional languages like Lisp or Scheme than with C or Java.

https://www.crockford.com/javascript/javascript.html

> We would be making a tragic mistake if we didn’t retain the language’s simplicity. Most of the modifications I would like to make in the language would be to make it even simpler. There’s some cruft on it, and there are some attractive nuisances in it, which we don’t need but which people become dependent on. We’d be better off without that. https://www.sitepoint.com/interview-doug-crockford/

> A lot of JavaScript’s critics want to go back in the other direction, and make it more Java-like, but I think that would be a bad thing because it would alienate most web developers. So, I’d rather go in the other direction and train our web developers how to be programmers, how to be computer scientists, because you can in this language.

This the one? Writes Java in Javascript you say.

Re: Douglas Crockford on JavaScript

#94

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. 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 "job" is. In turn the available remunera…

> quirky projects of the Web 1.0 era still trusting php

Disagree with the dig at PHP. PhpStorm+Psalm doesn't give you perfection, but a perfectly respectable development environment. Using PHP isn't anachronistic, these shallow dismissals are. If anyone out there hasn't seen PHP 8 and Psalm yet, it's worth a look. All languages and ecosystems have trade offs, PHP is no exception, it is a good fit for many scenarios.

Re: Douglas Crockford on JavaScript

#95

Is he talking about the old Because to me, it's quite remarkable how JavaScript has evolved since 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's all easy to use and very fast. TypeScript also helps with gradual typing together with syntax highlighting and lookups are superb…

> ES6+ introduced a slew of features like arrow functions, template literals, async/await, destructuring, classes, enhanced object literals and native modules. This is the problem. All of this has made the language worse. Just accreting features doesn't make the foundation less broken.

What exactly is "broken" about the foundation of JS? I hear this all the time and people can never back it up.

It is extremely performant for a scripting language, it is easy to debug, and it works in many scenarios.

People try too hard to be contrarian. Same thing happened with PHP and many other languages.

Re: Douglas Crockford on JavaScript

#96

Trying not to make this an ad-hominim attack, but Crockford has been a net negative to JS for 20 years now. 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 "The good parts" that tried to write java in javascript. And probably did more to make people write bad JS code than anything else. Then he made the mess…

YUI 2 was very bad and java-like.

But YUI 3 was ahead of its time. The dependency management and lazy loading in YUI 3 would not make it to the mainstream for another 10 years.

Re: Douglas Crockford on JavaScript

#97

Trying not to make this an ad-hominim attack, but Crockford has been a net negative to JS for 20 years now. 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 "The good parts" that tried to write java in javascript. And probably did more to make people write bad JS code than anything else. Then he made the mess…

If you think "The Good Parts" was a bad idea, I can only assume you didn't work on any large (or even small) coding projects before it was popular. It was the wild, wild west where everyone wrote JS without learning the language and abused/misused the worst features it had to offer (actually, that sounds like a lot of devs today. Somethings never change...)

> Crockford wrote his book "The good parts" that tried to write java in javascript.

This is particularly untrue. At that time (look up his talks), he was always vocal about JS prototypal design being bad BECAUSE it tried to be like Java. He pushed for things like `Object.create()` in ES5 (and opposed the ES6 Java-style class syntax) because it is much closer to how JS prototypes actually work.

He also pushed for closures and higher-order functions as the right way to code JS -- something Java wasn't even capable of. He was very much in favor of things like map/filter/reduce which are functional rather than class-oriented.

There's a LOT of stuff you can criticize about Crockford, but "The Good Parts" certainly isn't one of those things.

Re: Douglas Crockford on JavaScript

#98

Earlier quoted context omitted.

> ES6+ introduced a slew of features like arrow functions, template literals, async/await, destructuring, classes, enhanced object literals and native modules. This is the problem. All of this has made the language worse. Just accreting features doesn't make the foundation less broken.

> All of this has made the language worse. Just accreting features doesn't make the foundation less broken. I see this view a lot - what I rarely ever see is a concrete discussion about what exactly is wrong with the "foundation" of javascript. Because to me... Javascript is actually a decent-ish solution to the UI space (it nicely balances reactivity and code complexity by presenting an event driven, single threaded…

I might not have the best take since don't have a huge grudge against javascript but I definitely think there are some concrete problems in its foundations.

Specifically js has very unusual attitudes to basic syntax operations that are at this stage undoable without breaking an insane amount of existing code. For some examples:

- Use of == does not do what it does in almost every other language, but won't flag an error if a user thinks if does. Instead very difficult to track bugs will be introduced.

- Calling nonexistent object keys won't flag an error but return None. I've seen this lead to weird errors that are hard to find a lot of times.

- Duck typing in a lot of operators like + and - can create unexpected results.

At a high level, I think these are all choices to bake "truthyiess" into fundamental operations that often end up masking errors. They could pretty easily be solved if js, with those errors present, wasn't such a massive foundation for so much stuff.

I obviously can't speak for anyone else, but I think those are the kind of things most people are referring to when they talk about js having problematic foundations.

Re: Douglas Crockford on JavaScript

#99
post #46

> 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. 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 / system software development. It's just that noone has been able to rep…

> It's just that noone has been able to replicate that kind of success [of Rust's and Go's achievements] in the web-based frontend space. While it's easy to dog on Javascript, it's also necessary to consider what Javascript does right. The main thing that comes to mind is JS' async-everything, async-by-default, and first class async abstractions (like the Promise). Not necessarily something you want all the time, but…

I think async-by-default was an interesting idea and well worth trying, but I don't really think it was a good idea. Turns out that most things you want to do are synchronous, and "sync-by-default unless mentioned otherwise" makes a lot more sense. This includes I/O by the way, because most of the time you want to wait until an operation has finished.

Or to put it in another way: JavaScript makes the uncommon case easy and the common case hard(er).

Re: Douglas Crockford on JavaScript

#100

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.

> has near native performance what do you mean by this? https://github.com/niklas-heer/speed-comparison https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

The second you remove threading and SIMD from those examples, they get rather close to JS. At most, you are making the argument that killing JS-SIMD for WASM and not adding native threading support was a mistake.
Post reply on HN