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

101–110 of 202 posts

Re: Douglas Crockford on JavaScript

#101

Post by echeese »

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…

Because DOM access would have bloated the MVP, and you _can_ access the DOM through JS.

Re: Douglas Crockford on JavaScript

#102

Post by nologic01 »

user3939382 wrote: post #94
nologic01 wrote: post #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 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.

Sorry, I didn't mean to sound dismissive (much less shallow!) about php. In fact I have great admiration for projects from wikipedia, to wordpress, moodle, matomo, you name it, before even talking about the modern php landscape you mention. In my book what you achieve is far more important than how you achieve it.

Crockford is arguing about "clean starts" and that is fine but the thrust of my comment that this will be driven by business models, not so much by tools. Sometimes tools are enablers of new things, so there is a chicken-and-egg aspect to it.

So we have all these ecosystems that were once flourishing but are now in a stationary state because the business models are in stationary state. There is a variety of tools that are good enough to get the current "job" done, but its not clear what will bring us to the next phase...

Re: Douglas Crockford on JavaScript

#103

Post by arp242 »

Solvency wrote: post #72
SenHeng wrote: 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...

The UI of many games break if you scale the text though, if it offers such a feature (e.g. text won't fit in boxes). This is also the case on the web at times, but much less often.

Re: Douglas Crockford on JavaScript

#104

Post by yakshaving_jgt »

leetharris wrote: post #95
yakshaving_jgt wrote: post #61

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.

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.

Have you ever read JavaScript: The Good Parts? It does a great job of describing lots of broken bits.

More specifically, a few things that I think are pretty bad off the top of my head:

- Implicit type coercion

- Confusing scope binding, i.e., `this`, `bind`, etc.

- Inconsistent Array API — some methods return a new value; some methods mutate the value![0]

- `['1', '7', '11'].map(parseInt)` …lol?!

Maybe you shouldn't be so quick to jump to this conclusion that any criticism of your pet technology comes from a place of ignorance or pretension.

[0]: I've actually spoken with Brendan Eich about this one, and he conceded it wasn't a good idea. IIRC, he was just copying what Perl did.

Re: Douglas Crockford on JavaScript

#105

Post by arp242 »

glutamate wrote: post #21
datadeft wrote: post #13

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)

"Faster than Python" is a very different thing than "near native performance".

Re: Douglas Crockford on JavaScript

#106

Post by yxre »

paulgb wrote: post #73
yxre wrote: post #34

Earlier quoted context omitted.

He has been saying this for a decade. I had to double check the dates to see if it was even relevant. A problem is that the 3 problems that the articles highlights have been fixed with incremental fixes. Performance with V8. Object lifecycle management has had improvements from ES6 WeakMap and WeakRef although JS will never have RAII. ES6 also added more data structures. No new alternative will be able to keep up wit…

> A problem is that the 3 problems that the articles highlights have been fixed with incremental fixes. (author here) - I disagree. If V8 solved performance, we wouldn't see so much of the JS tooling stack being rewritten in Rust. Modern JS runtimes are fast because they are tuned for the types of workloads that are common on the web. This is great for the performance of a virtual DOM, but if you go off the beaten pa…

Javascript is optimized for workloads to keep latency low and maximize concurrency while constraining itself for resources. This is pretty ideal for a GUI scripting language, and covers most use cases for the web.

It is hard to get performance perfect in all workloads. I have always been able to optimize my scripts to get the responsiveness that I need.

Re: Douglas Crockford on JavaScript

#107

Post by [deleted] »

ramblerman wrote: post #50

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…

[deleted]

Re: Douglas Crockford on JavaScript

#108

Post by ecshafer »

ramblerman wrote: post #50

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…

"Javascript the good parts" is explicitly about avoid Java like programming in JS. It is about writing Javascript like its a bad implementation of Scheme (which is closer to reality than a version of Java).

Re: Douglas Crockford on JavaScript

#109

Post by igouy »

datadeft wrote: post #13
glutamate wrote: post #6

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

> speed-comparison

a tiny tiny ten-line snippet of code

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Douglas Crockford on JavaScript

#110

Post by bourneavent »

ramblerman wrote: post #50

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…

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

Post reply on HN