Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Douglas Crockford on JavaScript

digest.browsertech.com

Post reply on HN
Print view View original

171–180 of 202 posts

Re: Douglas Crockford on JavaScript

#171

Post by incrudible »

hajile wrote: post #120
bourneavent wrote: post #110

Earlier quoted context omitted.

>He might be right on some fronts, JS was designed in a week. He's completely right, it's just poorly designed. Javascript will always be around because of technical debt and habit. But that doesn't change the fact that Douglas is right. Also nobody really uses javascript anymore. It's completely insane. We compile Typescript into javascript then run javascript. That should tell you something about javascript.

TS is literally JS with a few unsound type hints. If you're writing TS, you are already writing JS.

> a few unsound type hints

Which turns out to be exactly what you need to be productive writing software. People who obsess about type systems and try to solve everything within them create a whole new bag of problems.

Re: Douglas Crockford on JavaScript

#172

Post by hajile »

incrudible wrote: post #171
hajile wrote: post #120

Earlier quoted context omitted.

TS is literally JS with a few unsound type hints. If you're writing TS, you are already writing JS.

> a few unsound type hints Which turns out to be exactly what you need to be productive writing software. People who obsess about type systems and try to solve everything within them create a whole new bag of problems.

StandardML is a counter-example. It has sound types but keeps them utilitarian and simple enough so people can’t easily overdo the typing. I’ve become very sick of the “type palaces” people construct (they remind me of “enterprise java” where people do stupidly complex stuff because they can).

Re: Douglas Crockford on JavaScript

#174

Post by bamfly »

ttfkam wrote: post #156
bamfly wrote: post #133

Earlier quoted context omitted.

Async in interface by default was a mistake and led to a ton of pain. Actually-async-under-the-hood is fine. See: how much JS is rightly and justifiably littered with "await" on seemingly almost every line, now that that's an option. It's downright comical to look at, and as clear a sign of mis-design in a language/runtime as you can get. Nine times out of ten (maybe more...) you just need to treat all that async stu…

> It's downright comical to look at, and as clear a sign of mis-design in a language/runtime as you can get. That's your opinion. Some of us prefer to know when a call is I/O-constrained and when the execution queue is being interrupted. JS had fearless concurrency before it was cool. When was the last time you heard of a JS program in a thread deadlock under load (other than a VM bug)? Never. It can get caught up in…

> Straight up doesn't allow it.

Right—so making the most-commonly-desired behavior (await-like behavior) default would have been a pretty big win, then, and not harmed that quality at all. Meanwhile it's only with the addition (and liberal sprinkling across most active JS codebases) of async/await that the default behavior doesn't result in ugly, awful code—wrestling with that defect is basically the story of the evolution of JS during and since the '00s. The number of person-hours lost to unwanted async-by-default semantics, writing competing libraries to work around it and make it less painful, learning those libraries, contorting code to use them just so you can (more often than not) cancel out the (perceived) effects of async behavior, learning the next set of libraries after that set's defunct, et c., must have been enormous—so incredibly large that I don't think there's any saving that decision from the "mistake" pile.

Now, it's merely funny and a little unsightly, seeing "await" rivaling, on a usage-count basis, keywords like "const" in so many JS codebases.

Re: Douglas Crockford on JavaScript

#175

Post by consilient »

bilalq wrote: post #164
consilient wrote: post #157

Earlier quoted context omitted.

People often get confused because they expect `await` to sequence promise resolution too. For example const example = async () => { const ifError = Promise.reject("something went wrong") const value = await someOtherPromise() await (valueIsOk(value) ? runNextStep(value) : ifError) } will always throw.

I don't think I follow. Your example left out all the definitions of these functions, so you can't really deterministically say what will happen. If `someOtherPromise()` fulfills, `valueIsOk(value)` evaluates to `true` or truthy, and `runNextStep(value)` fulfills, `example` will fulfill and not reject. If any of those conditions don't hold, `example` settles as rejected.

The issue is that `ifError` throws whether `example` fulfills or not. Promised values are sequenced by `async`, but promise side-effects are sequenced like side effects of any other javascript statement.

Re: Douglas Crockford on JavaScript

#176

Post by emodendroket »

taeric wrote: post #81
hombre_fatal wrote: post #65

Earlier quoted context omitted.

> 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.

Yeah, I agree. Whether you like it is almost beside the point. And then eventually people do start to like it through familiarity and tons of investment going into it and the momentum is tough to stop.

Re: Douglas Crockford on JavaScript

#177

Post by emodendroket »

ttfkam wrote: post #152
taeric wrote: post #81

Earlier quoted context omitted.

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.

Microsoft had VBScript installed on >90% of all browsers at one time. Google almost installed Dart by default in Chrome and then walked it back. Java was installed on all browsers for a decade, but no one wanted it. WebAssembly allows for languages like Rust to be used, but its adoption is still very niche. JavaScript lives on. It's not just inertia. IE for example supported multiple languages at the same time. As a…

The big difference is we’re talking about it working on many devices, plus a lot of people have very bitter memories of Windows XP deprecation breaking apps. And you seem to be contradicting your own thesis here, since people saying “this isn’t so much better to justify rewrites and retraining” is precisely inertia.

Re: Douglas Crockford on JavaScript

#178

Post by bilalq »

consilient wrote: post #175
bilalq wrote: post #164

Earlier quoted context omitted.

I don't think I follow. Your example left out all the definitions of these functions, so you can't really deterministically say what will happen. If `someOtherPromise()` fulfills, `valueIsOk(value)` evaluates to `true` or truthy, and `runNextStep(value)` fulfills, `example` will fulfill and not reject. If any of those conditions don't hold, `example` settles as rejected.

The issue is that `ifError` throws whether `example` fulfills or not. Promised values are sequenced by `async`, but promise side-effects are sequenced like side effects of any other javascript statement.

Sure, ifError rejects, but I don't think the behavior here is surprising or strange at all. This is exactly how one would want it to work. If you wanted to await it, you could do that.

Is the concern you're raising that people may accidentally orphan floating promises? That can be addressed with linter rules. [1][2]

[1]: https://github.com/typescript-eslint/typescript-eslint/blob/...

[2]: https://github.com/typescript-eslint/typescript-eslint/blob/...

Re: Douglas Crockford on JavaScript

#179

Post by ttfkam »

bamfly wrote: post #174
ttfkam wrote: post #156

Earlier quoted context omitted.

> It's downright comical to look at, and as clear a sign of mis-design in a language/runtime as you can get. That's your opinion. Some of us prefer to know when a call is I/O-constrained and when the execution queue is being interrupted. JS had fearless concurrency before it was cool. When was the last time you heard of a JS program in a thread deadlock under load (other than a VM bug)? Never. It can get caught up in…

> Straight up doesn't allow it. Right—so making the most-commonly-desired behavior (await-like behavior) default would have been a pretty big win, then, and not harmed that quality at all. Meanwhile it's only with the addition (and liberal sprinkling across most active JS codebases) of async/await that the default behavior doesn't result in ugly, awful code—wrestling with that defect is basically the story of the evo…

Straight up doesn't allow deadlocks.

> Right—so making the most-commonly-desired behavior (await-like behavior) default would have been a pretty big win, then, and not harmed that quality at all.

And you'd eliminate easy access to things like Promise.all, Promise.allSettled, and Promise.race. You'd also make it harder to see when the execution queue has a break.

If you want implicit awaits, Lua will welcome you with open arms. It is not to my liking.

Re: Douglas Crockford on JavaScript

#180

Post by consilient »

bilalq wrote: post #178
consilient wrote: post #175

Earlier quoted context omitted.

The issue is that `ifError` throws whether `example` fulfills or not. Promised values are sequenced by `async`, but promise side-effects are sequenced like side effects of any other javascript statement.

Sure, ifError rejects, but I don't think the behavior here is surprising or strange at all. This is exactly how one would want it to work. If you wanted to await it, you could do that. Is the concern you're raising that people may accidentally orphan floating promises? That can be addressed with linter rules. [1][2] [1]: https://github.com/typescript-eslint/typescript-eslint/blob/... [2]: https://github.com/typescrip…

> but I don't think the behavior here is surprising or strange at all.

Tell that to my junior coworkers. It's probably the single most common cause of async bugs in our codebase.

Post reply on HN