Live data from Hacker News

Douglas Crockford on JavaScript

digest.browsertech.com

81–90 of 202 posts

Re: Douglas Crockford on JavaScript

#81
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…

What JavaScript does right, is to have an installed VM on basically every computer out there. If you are building a consumer focused thing, it is hard to argue for any other installation method. Especially when you consider you can remove the need to track multiple deployments in the same way, since you can basically force an update to all users.

Re: Douglas Crockford on JavaScript

#82
post #18

Earlier quoted context omitted.

I forgot to add "not controlled by a single corporation" to my list of requirements. Also not gradually typed, I think? But I would consider it if it weren't all tied into Google and had a larger ecosystem.

Isn't Typescript "controlled" by Microsoft?

Typescript is completely open source (Apache 2.0 licensed) and all of its roadmap, planning, issue tracking, peer reviewing, is also out in the open (in GitHub Issues). It's about as "controlled" by Microsoft as Linux is "controlled" by Red Hat at this point.

Re: Douglas Crockford on JavaScript

#83

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 don't even mind the classes - just because it makes Crockford and the other enterprise java folks shut up

This is the second time I've seen in this thread that people lump Crockford in with Java enterprise folks, but Crockford routinely says `class` was the worst addition to JS.

> What I do find particularly impressive is how flexible JS is, and how much support can be added without actually changing the runtime

Funny enough, this sounds a lot like something Crockford would say.

I think Crockford's main gripe with JS these days is that TC39 is more concerned with adding superfluous features than cleaning up footguns. There is a video from 2018 where he goes through some of the more popular ES6 features and mentioned which ones he likes/dislikes. [1]

[1] https://www.youtube.com/watch?v=XFTOG895C7c

Re: Douglas Crockford on JavaScript

#84
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 agree with you that JavaScript's async abstractions are nice, but I think a lot of people will misunderstand the example you've given, as ensuring that the asynchronous value for `b` and `c` will be resolved prior to the asynchronous value of `a`.

Promises begin to resolve as soon as they are created. Therefore, assuming that the three executions of `promise()` in that code take 3 seconds, 10 seconds and 2 seconds respectively, we should expect `aPromise` to be resolved during `Promise.all([promise(), promise()])` immediately prior to `b` and `c`. The only thing is that we do not unwrap `aPromise` with `await` and point `a` towards it until 10 seconds after `await Promise.all([promise(), promise()])` was called.

Re: Douglas Crockford on JavaScript

#85
post #76

Earlier quoted context omitted.

> Crockford has been a net negative to JS for 20 years now. I'd say JSON is pretty successful as a protocol, even beyond JavaScript. Also The Good Parts is probably as important now as it was when it was published. The language hasn't improved — it's just grown.

JSON is a protocol? I'm not sure I follow. That said, JSON is still an interesting study. Basically, "take the object literal syntax of javascript, get rid of functions, require double quotes, don't recognize comments." It is good to get folks to stop using 'eval' to pull some data into the browser, though it is a shame that couldn't have been preserved a bit more safely. And, of course, json-lines and then the stead…

Ok, perhaps not strictly a protocol, but a data format. I'm using the word a little more loosely than some dictionaries suggest, though it appears to comport with this definition published on Cloudflare.

> In networking, a protocol is a set of rules for formatting and processing data. Network protocols are like a common language for computers. The computers within a network may use vastly different software and hardware; however, the use of protocols enables them to communicate with each other regardless.

https://www.cloudflare.com/learning/network-layer/what-is-a-...

Re: Douglas Crockford on JavaScript

#86
I wish! I wish!! I so wish this would happen. And the ‘type’ attribute to the script tag would finally mean something!

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.

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.

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.

Re: Douglas Crockford on JavaScript

#87
post #49

Earlier quoted context omitted.

Every time I have to build a UI in canvas, I yearn for all the conveniences CSS and the DOM provide. Do people even realise how much trouble it is to make text wrap within a given space?

It is, but yet thousands of videogames have been doing this for decades...

And most games will use an engine like Unity or Unreal so they don't have to re-invent the wheel. HTML and CSS may not be perfect, but they've been battle tested for a good 30 years and have had improvements added. No need to re-invent that wheel.

Re: Douglas Crockford on JavaScript

#88
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 remunerative jobs fit certain business models and markets.

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.

Massive adoption of a fresh and "clean" 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 may enable such an evolution and eventually may be synomymous with it but these things don't happen made to order.

Re: Douglas Crockford on JavaScript

#89
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'm older than him, so not ageism)

Re: Douglas Crockford on JavaScript

#90

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…

> Crockford wrote his book "The good parts" that tried to write java in javascript This is a weird statement because Crockford is known for actively recommending against writing JavaScript like Java, and goes as far as saying JS is best used when you avoid classes and `this`.

I think this must be a reaction to his generally conservative, “avoid using these features and write wordier code” views.
Post reply on HN