Live data from Hacker News

Douglas Crockford on JavaScript

digest.browsertech.com

21–30 of 202 posts

Re: Douglas Crockford on JavaScript

#21

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

Much faster than Python or almost any non-native-compiled language (except Java)

Re: Douglas Crockford on JavaScript

#23

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.

I wouldn't class NodeJS as being near native based on benchmarks.

And its poor concurrency story compared to other languages e.g. Scala means that it's hard to push the runtime in real-world situations.

Re: Douglas Crockford on JavaScript

#24
post #11

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.

Typescript is very nice, just need to get rid of the javascript underneath.

I'm sure microsoft would absolutely love that!

and that's why it should never happen.

Re: Douglas Crockford on JavaScript

#25

> "[...] we are crushing ourselves with the accumulated complexity we’ve piled on top of bad foundations [...]" The same could be said about plain HTML/CSS though. I think the author is correct overall and I don't really see improvement on the horizon. WebAssembly, while great that it exists, can morph browsers into some poor mans virtual operating system and this can lead to a less open web. We already see more clos…

> The same could be said about plain HTML/CSS though. Genuine question: How much of the complexity of working with HTML/CSS is unnecessary and how much is inherent to the problem they solve? Is it as bad as with Javascript? I would say that we, for the most part, have a very clear idea of how we could (theoretically) replace Javascript with something much better. I don't know of alternative layout languages, so I don…

Seriously, every time people complain about CSS and HTML I think about how much work it is to support all the localisation and layout stuff they do. Managing massively different sized screens as elegantly as them is hard and yeah, it's still not that elegant or easy, but I haven't used anything better that didn't sacrifice something for it.

Re: Douglas Crockford on JavaScript

#26
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?

This is a good point, yes you are right about that.

Re: Douglas Crockford on JavaScript

#28
Any time something is adopted as broadly as JavaScript it's going to be a mess. Even outside the world of computing. Take... city planning. Cities are a mess. In fact human civilization is one big freakin' mess.

Wouldn't it be nice if we could start over and apply all the lessons we've learned over the generations? The world would be a much better place!

Or would it?

We'd end up with yet another mess. It'll be a different mess but it'll be a mess nonetheless. Or worse - we'll end up with two big messes instead of one big mess!

Re: Douglas Crockford on JavaScript

#29

[flagged]

> The new COBOL is here to stay.

Very much. :) We have a javascript interpreter parked at the L2 Lagrange point.[1] As far as the preservation of human made artefacts go that is basically one of the safest places it can be. When us and all of our earthly possessions have long crumbled to dust that thing is still going to be out there. (Albeit very likely drifting without power around the sun.)

1: Event-driven James Webb Space Telescope Operations - https://arc.aiaa.org/doi/pdf/10.2514/6.2006-5747

Re: Douglas Crockford on JavaScript

#30

Earlier quoted context omitted.

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

Much faster than Python or almost any non-native-compiled language (except Java)

Python is a notoriously slow language so that's not saying much.

And there are a number of languages on the JVM e.g. Java, Scala, Kotlin, Clojure as well as countless compiled ones which are near-native.

Post reply on HN