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

181–190 of 202 posts

Re: Douglas Crockford on JavaScript

#181

Post by culebron21 »

I remember Crockford's lectures at Yahoo in 2009, and they were inspiring, but in the hindsight, most his bold points turned out incorrect.

#1: The promise of high speed with event loop & JIT compiler. Crockford's idea was that if you make small functions that return quickly, JIT will boost their speed drammatically. Plus, fast yielding would make programs seem faster for the client.

By then, Google Chrome wrote impressively fast JS engine, but later the speed of JS didn't improve much. JIT-based languages and engines didn't match performance -- I myself tried Pypy, and it wasn't fast like C.

I must give him credit that his lectures made me finally get how the event loop works.

#2: That Promises and async would make async programming much easier. Promises do make code better than callback hell, but still are tedious. The side costs of async are well summarized in this post & presentation: https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

#3: Object construction with closure function. We tried that wholeheartedly at contemporary project, and it was awkward. I haven't seen any popular framework do this approach either.

#4: Decentralized web evangelism in mid-'10s. This is a bittorrent concept extrapolated to web hosting, later it got traction branded as Web3. It's clear by torrents that they work only when everyone cooperates, and carries some serious load, otherwise torrents die out. The decentralized web requires every user to host a good bit of data, and any document published puts this load on everyone in the system. As with Ted Nelson's concept, it makes sense only in small environment of cooperating users.

That being said, Crockford's lectures were interesting for history part, and he made a good point that one should looki into history and see what is logical and progressive, what we got just accidentally and it stays as legacy.

Re: Douglas Crockford on JavaScript

#182

Post by perilunar »

Devasta wrote: post #123

Software quality has never mattered in web development. When the W3C tried to push XHTML web devs balked at the idea that they should understand markup languages and not have syntax errors. JS is installed on every machine, you don't need to deal with IT bureaucracy getting apps installed or heaven forbid ports opened, and it'll never ever have anything less than the full backing of the browser developers. Even Brain…

> When the W3C tried to push XHTML web devs balked at the idea that they should understand markup languages and not have syntax errors

At the time a lot of the people generating content for the web were not web developers, so HTML had to be forgiving. Most CMSes allow people to add arbitrary markup — it is far preferable for the browsers to be forgiving than to refuse to show pages if there is a syntax error.

Re: Douglas Crockford on JavaScript

#183

Post by Cthulhu_ »

sspiff wrote: 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…

JS achieved critical mass especially with the advent of NodeJS; it'll be difficult for a competitor in the same space to take over.

But that's fine; JS is fine for what it's used for, i.e. browsers / webpages and at a stretch rich desktop UIs. I think the main issue that the author has is that for a lot of people it's become a golden hammer.

A few years ago I started applying for jobs again; what I found (but this might have been the recruiter) is that multiple companies were in the process of replacing their PHP backends with Javascript / NodeJS backends. I couldn't fathom why people were starting a new project - building the future of their company - on Node.

I mean it makes sense from a hiring point of view because JS developers are everywhere, but it doesn't make sense from a business point of view, or right-tool-for-the-job.

But maybe that's me being judgmental. I mean PHP is fine for back-end too, if that's what they were replacing.

Re: Douglas Crockford on JavaScript

#184

Post by DanielHB »

arp242 wrote: post #99
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…

I think async-by-default was an interesting idea and well worth trying, but I don't really think it was a good idea. Turns out that most things you want to do are synchronous, and "sync-by-default unless mentioned otherwise" makes a lot more sense. This includes I/O by the way, because most of the time you want to wait until an operation has finished. Or to put it in another way: JavaScript makes the uncommon case ea…

async-await is not the best solution for most things, but it is usually the best solution for UI and I/O (database interactions, data-fetching, file-system, etc)

Which makes it default-best for (and I speculate here) 90% of the code that is written because it covers client-side and server-side API layers. Ie business logic. Like you mention this kind of code is very rarely synchronous (in the sense that you want to block the execution thread until you get the result). An UI needs to keep answering to users inputs and an API server needs to keep answering requests while waiting on I/O

The places where it isn't good are usually the kind of software that can be packaged and reused (libraries, ie the heavy lifting software). Things like databases, image processing, neural networks, etc

Talking about JS specifically there are a few more use-cases where it isn't good even though an async-await system makes sense, like embedded low-memory environments

IMO the main problem with JS is not JS, it is the browsers DOM. It is about time we get a replacement.

Re: Douglas Crockford on JavaScript

#185

Post by DanielHB »

bamfly wrote: post #133
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…

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…

localStorage is not async and it often causes problems because of that It seems to me what you are suggesting is implicit async (or rather automatic await insertion) which I guess could work. However I fail to see how it would make code easier to write or understand while actively increasing problems due to unclear async vs sync calls. Especially now that typecheckers can detect non-awaited calls.

Explicit await in a sense is documentation, sure 90% of async functions just do things sequentially, but the awaits in there are clear signs that "hey things won't happen instantaneously here"

Re: Douglas Crockford on JavaScript

#186

Post by DanielHB »

bamfly wrote: post #133
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…

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…

also don't forget pretty much all similar event-loop systems in other languages also have explicit await calls

Re: Douglas Crockford on JavaScript

#187

Post by DanielHB »

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.

Modern Java with its modern IDEs used with good coding patterns is a completely fine environment as well

I think he meant more in the sense of projects that weren't adapted to modern coding standards

Re: Douglas Crockford on JavaScript

#188

Post by DanielHB »

andrewl-hn wrote: post #130
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…

At the time - we talking 2005-2008 - Crockford made a few net positive contributions to JavaScript and web: 1. He educated people about JavaScript the language and made it accessible to a large body of programmers as "a real language". Before him a lot of JS knowledge was obscure, and people were doing all JS programming by sharing random snippets here and there. Crockford showed how to build modular systems in JavaS…

Not only JavaScript but pretty much all server web programming stacks Ruby on Rails and similar frameworks wouldn't be nearly as popular if we were still using XML as data exchange format

Re: Douglas Crockford on JavaScript

#189

Post by DanielHB »

culebron21 wrote: post #181

I remember Crockford's lectures at Yahoo in 2009, and they were inspiring, but in the hindsight, most his bold points turned out incorrect. #1: The promise of high speed with event loop & JIT compiler. Crockford's idea was that if you make small functions that return quickly, JIT will boost their speed drammatically. Plus, fast yielding would make programs seem faster for the client. By then, Google Chrome wrote impr…

> #3: Object construction with closure function. We tried that wholeheartedly at contemporary project, and it was awkward. I haven't seen any popular framework do this approach either.

yeah I have been struggling with this for a while, at my project we use typescript and non stateful objects we just use plain objects, no classes. However we started using classes for stateful code, I was opposed to the idea and thought that using closure-based state would be better but I ended up losing that battle A lot of those classes are single-instance in the application, which feels even more of an anti-pattern to be classes

To be clear I am not advocating for closure-based state, but classes also feel awkward. It feels we should just have bit the bullet and used some kind of state-management library

Re: Douglas Crockford on JavaScript

#190

Post by cies »

yakshaving_jgt wrote: post #61
tmikaeld wrote: post #42

Is he talking about the old Because to me, it's quite remarkable how JavaScript has evolved since Not to mention, the integration with Web APIs has been a game changer. Fetch API, WebSockets, Web Storage, WebRTC and Service Workers, WebAssembly really enables a lot of functionality that's all easy to use and very fast. TypeScript also helps with gradual typing together with syntax highlighting and lookups are superb…

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

> Just accreting features doesn't make the foundation less broken.

That's indeed the gist of Douglas' remark.

But if you have not much experience beyond JS, that is very hard to recognize.

Douglas is grey and old. Most JS devs are on the younger side of the IT work force.

Post reply on HN