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

161–170 of 202 posts

Re: Douglas Crockford on JavaScript

#161

Post by taeric »

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…

This is taking some liberties with "installed." Java was never meaningfully installed on all machines. Such that getting it to work was surprisingly difficult for most users. You could maybe argue that Flash was well entrenched, but I don't think that would get too many objections. Indeed, many early Flash sites were better at interactivity than many modern sites.

VBScript, I'm almost willing to cede. That said, I don't remember it ever being a thing that websites tried to use. Even back in the days of them ripping off Sun with JScript. I'm also curious when they had 90% of the browsers with it? Would love to see a solid timeline on that.

Note, too, that I never pushed that JavaScript is bad on this. Indeed, I agree with you that it is nowhere near as bad as is often stated. What it lacks, is discipline. Which is why it seems to have near every paradigm accounted for nowadays.

That said, /if/ Google teamed up with Apple and got that pushed on all devices for native, I suspect you would see it leak into the browsers in that 2 years and that we would indeed start seeing more Swift developers at large. And a ton of "reasons you should migrate to Swift" for your websites.

Re: Douglas Crockford on JavaScript

#162

Post by bartimus »

weinzierl wrote: post #44

As we nowadays compile TS to JS anyways, it would be a small step to go full WASM and have language agnosticism mostly. 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: - We don't need it, because you can do everything via a Javascript detour easily - We don't want it for reason X To me both feel a bit like excuses. I've yet…

I would imagine it a security risk to allow attackers accessing the DOM through WASM. Adding complexity to the sandbox environment.

Re: Douglas Crockford on JavaScript

#163

Post by ttfkam »

taeric wrote: post #161
ttfkam wrote: post #152

Earlier quoted context omitted.

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…

This is taking some liberties with "installed." Java was never meaningfully installed on all machines. Such that getting it to work was surprisingly difficult for most users. You could maybe argue that Flash was well entrenched, but I don't think that would get too many objections. Indeed, many early Flash sites were better at interactivity than many modern sites. VBScript, I'm almost willing to cede. That said, I do…

You probably misremember. Java was indeed installed on effectively all browser-capable machines from 1997-200x. All you needed was an tag, not an or like other plugins like Flash. Speaking of Flash, it came preloaded for a time, but mostly rode the ActiveX wave for installs. You could not count on it being installed though. I vividly remember the fallback markup when it was unavailable.

Internet Explorer had 90% marketshare in the years around 2004. Netscape was dead. Mozilla/Phoenix/Firefox was a hopeful, not a contender. VBScript was everywhere IE was, and folks still preferred JS, even if their sites proudly proclaimed "Best viewed with Internet Explorer". In the late 1990s/early 2000s, MSDN was full of examples pushing VBScript. It became second nature to myself and coworkers to just reason out what the equivalent JS looked like on the fly. Microsoft absolutely tried its best to replace JS, but devs wouldn't have it, and the number of JS-powered sites was just too large for Microsoft to simply drop compatibility.

It was around that time that Microsoft stopped making updates of any kind to Internet Explorer for years. Folks today really don't comprehend the debt we hold to Mozilla for breaking out of the notion that the web was feature complete.

Re: Douglas Crockford on JavaScript

#164

Post by bilalq »

consilient wrote: post #157
peferron wrote: post #127

Earlier quoted context omitted.

> I have some code here, and when exactly is this run? If there are `await` keywords previously in the function, then the line you're looking at will run after these async calls are done. Otherwise it'll run ASAP. Is there something else to it?

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.

Re: Douglas Crockford on JavaScript

#165

Post by taeric »

ttfkam wrote: post #163
taeric wrote: post #161

Earlier quoted context omitted.

This is taking some liberties with "installed." Java was never meaningfully installed on all machines. Such that getting it to work was surprisingly difficult for most users. You could maybe argue that Flash was well entrenched, but I don't think that would get too many objections. Indeed, many early Flash sites were better at interactivity than many modern sites. VBScript, I'm almost willing to cede. That said, I do…

You probably misremember. Java was indeed installed on effectively all browser-capable machines from 1997-200x. All you needed was an tag, not an or like other plugins like Flash. Speaking of Flash, it came preloaded for a time, but mostly rode the ActiveX wave for installs. You could not count on it being installed though. I vividly remember the fallback markup when it was unavailable. Internet Explorer had 90% mark…

No, I remember quite well how that never worked as well as you'd have wanted it to. So, yes, there was an installation of java. No, it probably didn't work correctly. Worse, it was probably not updated. With no real path on how to update for most folks.

Such that, yes it was "installed," but it was about like relying on vanilla JavaScript back then. Which you didn't do. You pulled in jquery or whatever and monkey patched some sanity into the environment. Something you couldn't do with Java.

VB had the odd curse of being VB. Everyone was certain that MS wanted it dead, and everyone also knew that if you were writing a VB application, you might as well just make it directly in Access. Which, granted, wasn't a bad solution for a lot of things.

Re: Douglas Crockford on JavaScript

#166

Post by consilient »

calrain wrote: post #10

What is one of those 'really clean' languages that we should be using then? I'm interested!

Purescript. By far the best type system of any frontend language, good interop, type-directed emit (so that you can, for instance, automatically generate parsers from type definitions), and unlike Elm actually treats users like adults.

Re: Douglas Crockford on JavaScript

#169

Post by aardvark179 »

ttfkam wrote: post #158
aardvark179 wrote: post #125

Earlier quoted context omitted.

How performant a scripting language ends up being is partly due to a couple of fundamental design choices, and partly just due to investment. The fact JS has very limited interaction between threads makes a JIT much easier to write. In terms of design there’s a lot of annoying things round equality, operators, and coercion which makes everything just that little bit harder to keep in your head. The standard library a…

> The fact JS has very limited interaction between threads makes a JIT much easier to write. And easier for developers to write and reason about. This is not small thing. Re-entrant code by default (and basically by mandate) eliminated deadlocks in even a beginner's code. Do you understand how amazing a language is than encourages concurrency and allows parallelism with any fear of deadlocks or explicit atomism?

You can absolutely have concurrency bugs in async JavaScript code, don’t kid yourself that you can’t, or even that it’s hard to do.

The reason I mentioned the concurrency model making the JIT easier is that the concurrency model makes it easier to manage the replacement of methods on the stack when an assumption has been invalidated, and this helps with the speed of the compiled code. The same also applied to various languages with green threads or global locks, but outside the JS world being able to use multiple cores has proved more useful than the difference in single threaded code.

Re: Douglas Crockford on JavaScript

#170

Post by ttfkam »

aardvark179 wrote: post #169
ttfkam wrote: post #158

Earlier quoted context omitted.

> The fact JS has very limited interaction between threads makes a JIT much easier to write. And easier for developers to write and reason about. This is not small thing. Re-entrant code by default (and basically by mandate) eliminated deadlocks in even a beginner's code. Do you understand how amazing a language is than encourages concurrency and allows parallelism with any fear of deadlocks or explicit atomism?

You can absolutely have concurrency bugs in async JavaScript code, don’t kid yourself that you can’t, or even that it’s hard to do. The reason I mentioned the concurrency model making the JIT easier is that the concurrency model makes it easier to manage the replacement of methods on the stack when an assumption has been invalidated, and this helps with the speed of the compiled code. The same also applied to various…

Never said you couldn't have concurrency bugs.

I specifically mentioned thread deadlocks and atomism. You cannot claim locks, so you cannot claim them out of order. JavaScript has no notion of "atomic integer increment" since all variable access is atomic/single threaded.

That is not the same as the straw man claim you asserted for me.

And I reiterate: no deadlocks or atomism concerns greatly aids developers in writing secure and robust code. It does not eliminate all bugs, concurrent or otherwise, nor did I ever claim it did.

If you can find a code example in browser-based JS that triggers a deadlock, I'd be fascinated to learn about it.

Post reply on HN