Earlier quoted context omitted.
> Crockford has been a net negative to JS for 20 years now. I'd say JSON is pretty successful as a protocol, even beyond JavaScript. Also The Good Parts is probably as important now as it was when it was published. The language hasn't improved — it's just grown.
JSON is a protocol? I'm not sure I follow. That said, JSON is still an interesting study. Basically, "take the object literal syntax of javascript, get rid of functions, require double quotes, don't recognize comments." It is good to get folks to stop using 'eval' to pull some data into the browser, though it is a shame that couldn't have been preserved a bit more safely. And, of course, json-lines and then the stead…
Douglas Crockford on JavaScript
121–130 of 202 posts
Re: Douglas Crockford on JavaScript
#122He 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…
This seems like the key thing. We've gone through something similar with operating systems where there hasn't been a ton of change for a very long time now. It seems like we've just hit the same part of the lifecycle with programming languages where change happens much more slowly.
Re: Douglas Crockford on JavaScript
#123JS 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 Brainfuck would be the dominant language with that feature set.
So long as that remains the case, as it will in my lifetime, nothing will change.
Re: Douglas Crockford on JavaScript
#124As 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…
My understanding is that the main limitation is technical. WASM doens't do GC or the host system calling conventions and cannot interact directly with object from Javascript because of this. However, this is being worked[0] on and will be solved eventually. Even without this, the performance overhead of bridging to JS is low enough that WASM frameworks can beat out React. 0: https://github.com/WebAssembly/gc/blob/mai…
Re: Douglas Crockford on JavaScript
#125Earlier 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.
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 also has a bunch of inconsistencies in the way it works. I work on a JS implementation every day and I’m always referring to the spec to double check odd corner cases.
I think the choice of double as the only original numeric type has caused a lot of confusion too, even though I’m not in the camp that says you should never use floats.
Re: Douglas Crockford on JavaScript
#126> 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…
TypeScript and WASM have both been developed in the last decade.
The former is amazingly successfully, and the later is seeing increasing adoption.
Re: Douglas Crockford on JavaScript
#127Earlier quoted context omitted.
I disagree. I'd take JS-style promises over trying to manage Futures in ForkJoinPools or thread pools any day. Being able to write async expressions in parallel by default means even junior devs take advantage of parallelism. I've seen plenty of code written in Java and Ruby where multiple network and DB requests are made in serial despite having no dependency on each other. The usual reason is that there's just a lo…
I have also found Promises very hard to reason about at times: "okay, so I have some code here, and when exactly is this run?" can be a difficult question to answer with Promises. Part of that is inherent in async code, but part of that is also because IMHO Promises make it harder than it needs to be. I never really used Java, but I have used Ruby and Python (IIRC Python's APIs were modelled on the Java ones) and I a…
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?
Re: Douglas Crockford on JavaScript
#128Earlier quoted context omitted.
JSON is a protocol? I'm not sure I follow. That said, JSON is still an interesting study. Basically, "take the object literal syntax of javascript, get rid of functions, require double quotes, don't recognize comments." It is good to get folks to stop using 'eval' to pull some data into the browser, though it is a shame that couldn't have been preserved a bit more safely. And, of course, json-lines and then the stead…
You should have a look at JSON-LD: a major part of it is adding namespaces ("prefixes") and a default namespace ("@vocab") to JSON: https://www.w3.org/TR/json-ld11/#compact-iris
Re: Douglas Crockford on JavaScript
#129Is 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.
Nope, most of these have made the language better. Optional chaining is better than a litany of `&&`, `...` is generally better than `Object.assign` or `concat`, `async/await` are generally better than callbacks... The list goes on. Rejecting these new features wouldn't have magically improved the foundation.
Re: Douglas Crockford on JavaScript
#130Trying 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…
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 JavaScript, how to avoid common pitfalls, how to reason about JS object model, DOM APIs and build larger systems.
John Resig was doing lord's work with jQuery, but his JavaScript book came out way too late to make a big difference. "Good Parts" on the other hand helped growing a whole generation of JS engineers. There were other books, too, that helped immensely, including John's book and especially Marijn Haverbeke's book, which eventually became a somewhat spiritual successor, and was "The Book" for JavaScript for about a decade.
2. He created the first linter for JavaScript and popularized the notion of using static analysis as part of JavaScript development process. For many years JSLint was the only game in town. And, on a larger level, JSLint introduced the whole notion of having a build / release process to JavaScript world. People joke about node_modules a lot, but before JSLint most teams simply FTP-ed sources to servers or were editing them live over SSH. Web programming was not a "real" programming, and Crockford helped change this perception.
3. Same goes to minification - he was the first one to talk about JavaScript execution as part of browser performance story, and created JSMin - the first minifier.
4. JSON format was largely responsible for ending XML dominance and let adopting new languages for server side development easier. I still remember times when I've been forced to only use Java because "the project required XML".
5. There's an argument that his "sticking to good parts" idea was harmful. He almost single-handedly killed ES4 proposal that would have add classes, modules, and other cool additions to JavaScript in around 2006-2009. But here's a thing: ES4 was a hot mess of seemingly unrelated proposals and features that played poorly together. Instead we spent extra years making the foundation of the language better, and then we still got all these and many other features through ES6 and further standards. Like many, I was pissed about ES4 at the time, but seeing where we are now with the language I believe he and Chris Wilson of IE did the right thing with "Harmony".
He was at the right place at the right time. Yahoo circa 2005-2010 did ground breaking job at making frontend development a separate proper discipline. They _invented_ the term "Frontend Development", they build tools for analyzing JS performance, they talked about coordinating work in larger teams and structuring large projects. Before them there were individual groups at a few large companies that were building large web applications (Gmail and Google Maps were the primary examples at the time), but the knowledge of how to do that remained hidden, tribal, and fragmented. YUI group aggregated it, published it and promoted it, making it available to a larger developer community.
They had a messy transition from YUI2 to 3 but the later was way ahead of its time. Crockford was not the primary author of the library, btw. The team was led by Eric Miraglia with significant contributions from Nate Koechley, Dad Glass, Ryan Grove, Nicholas C. Zakas etc. For many years it was one of the most popular libraries for building web applications in larger teams. It was eventually superseded by the arrival of frameworks like Backbone, Angular, React, etc. but for a period between 2006 and 2010 YUI along with Dojo were essentially acting as frameworks for us.
I agree, Crockford tends to sound like a naysayer, partially because his other ideas about compartmentalizing code, building more robust security into the language didn't pan out as he wanted, and things like Content Security Policy largely remain underutilized. But his work was important, his accomplishments are undeniable, his contributions were beneficial for JavaScript community at large.