[ramblerman]

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 that was YUI at yahoo with the same enterprise patterns. When that failed he went right back to these types of doomsday messages in the media every few years calling for the end of Javascript.

Meanwhile we have seen ES6/typescript/react and countless other innovation take place.

He might be right on some fronts, but at some point its a case of put up or shut up imo. There are far better experts to talk to about the state of JS and its future.

[hajile]

If you think "The Good Parts" was a bad idea, I can only assume you didn't work on any large (or even small) coding projects before it was popular. It was the wild, wild west where everyone wrote JS without learning the language and abused/misused the worst features it had to offer (actually, that sounds like a lot of devs today. Somethings never change...)

> Crockford wrote his book "The good parts" that tried to write java in javascript.

This is particularly untrue. At that time (look up his talks), he was always vocal about JS prototypal design being bad BECAUSE it tried to be like Java. He pushed for things like `Object.create()` in ES5 (and opposed the ES6 Java-style class syntax) because it is much closer to how JS prototypes actually work.

He also pushed for closures and higher-order functions as the right way to code JS -- something Java wasn't even capable of. He was very much in favor of things like map/filter/reduce which are functional rather than class-oriented.

There's a LOT of stuff you can criticize about Crockford, but "The Good Parts" certainly isn't one of those things.

[dsego]

What? The man who created JSON was writing enterprise patterns? When, how?

This the same man who wrote this?

> JavaScript has a syntactic similarity to Java, much as Java has to C. But it is no more a subset of Java than Java is a subset of C. It is better than Java in the applications that Java (fka Oak) was originally intended for. ...

> This is misleading because JavaScript has more in common with functional languages like Lisp or Scheme than with C or Java.

https://www.crockford.com/javascript/javascript.html

> We would be making a tragic mistake if we didn’t retain the language’s simplicity. Most of the modifications I would like to make in the language would be to make it even simpler. There’s some cruft on it, and there are some attractive nuisances in it, which we don’t need but which people become dependent on. We’d be better off without that. https://www.sitepoint.com/interview-doug-crockford/

> A lot of JavaScript’s critics want to go back in the other direction, and make it more Java-like, but I think that would be a bad thing because it would alienate most web developers. So, I’d rather go in the other direction and train our web developers how to be programmers, how to be computer scientists, because you can in this language.

This the one? Writes Java in Javascript you say.

[toastercat]

> Crockford wrote his book "The good parts" that tried to write java in javascript

This is a weird statement because Crockford is known for actively recommending against writing JavaScript like Java, and goes as far as saying JS is best used when you avoid classes and `this`.

[emodendroket]

I think this must be a reaction to his generally conservative, “avoid using these features and write wordier code” views.

[lifthrasiir]

I do kinda see why Crockford does all of that. Crockford, before the JSON fame, worked on a distributed language E and believes that "the next paradigm will be globally distributed, secure, eventual programming" [1], so all existing languages are old and JS happened to be the best transitional language among them. Assuming this is a sincere belief, Crockford should've tried to steer JS to suit this vision, and if that's not possible, to throw JS away and recommend other languages or make a new one. Having yet to see the latter, I had a strong suspicion that Crockford is not as sincere as Crockford wants to be seen. Maybe Crockford also realized that or I was too premature to think that.

[1] https://howjavascriptworks.com/sample.html#0

[politelemon]

> Meanwhile we have seen ES6/typescript/react and countless other innovation take place.

I don't see these as innovations but workarounds to, or built upon, the poor foundations that the author mentions. They wouldn't need to exist if the foundations were solid, or at least not in the states they are in today

[hombre_fatal]

On the other hand, all the tools built on top of Javascript could just as easily be explained by solid foundations that are easily to target with higher levels of abstraction rather than symptoms of the foundation being rotten.

It makes more sense to ask "compared to what?" and look at what's going on in the lateral client application platform space.

On iOS, it's very hard to target the foundation with higher level competing abstractions not because the foundation nails it but because the foundation isn't built on simple primitives that area easy to target. You have one blessed way of building iOS apps (UIKit) that's then, over the period of a decade+, slowly replaced by the next blessed way to build iOS apps (SwiftUI). And you generally have to wait for Apple to build APIs that you need because you're not given solid building blocks to do things yourself.

Most discussion around web client development takes place in a vacuum where we look at it and go "well it could be better" (or "it's a dumpster fire"). But that's either a trivial or meaningless statement in isolation. It's more interesting to at least compare the state of web clients with what is the cutting edge state of the art across all client development. When you do that, I don't see how most HN claims about the dire state of JS actually hold up.

[pessimizer]

> could just as easily be explained by solid foundations

No they couldn't. There were two options for the web, build on js or find a different job.

[jancsika]

> Crockford wrote his book "The good parts" that tried to write java in javascript

Oh wow, five different people have already responded to challenge and correct this misapprehension.

What made you write this particular point? Crockford has consistently criticized Java for its boilerplate as well as criticizing the Java-isms in Javascript like the Math namespace/object.

[gausswho]

In what way was The Good Parts trying to write Java in JavaScript?

[yakshaving_jgt]

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

[taeric]

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 steady expanse of json-schema is looking to be hilarious. How long until we add in namespaces to the idea? :D

[yakshaving_jgt]

Ok, perhaps not strictly a protocol, but a data format. I'm using the word a little more loosely than some dictionaries suggest, though it appears to comport with this definition published on Cloudflare.

> In networking, a protocol is a set of rules for formatting and processing data. Network protocols are like a common language for computers. The computers within a network may use vastly different software and hardware; however, the use of protocols enables them to communicate with each other regardless.

https://www.cloudflare.com/learning/network-layer/what-is-a-...

[tuukkah]

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

[taeric]

Oh wow. At what point do we just switch back to XML?

[Solvency]

Oh wow. This is the guy who did YUI? That was the most abjectly horrifying thing I've ever been forced to deal with (on one random client project) in the history of web development. Just the utter peak of esoteric artificially complex inelegant developer slop.

[gmoot]

YUI 2 was very bad and java-like.

But YUI 3 was ahead of its time. The dependency management and lazy loading in YUI 3 would not make it to the mainstream for another 10 years.

[ecshafer]

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

[andrewl-hn]

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

[DanielHB]

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

[andix]

I never really understood the need for „enterprise patterns“. Usually it’s the same spaghetti code than without them, just wrapped in „pretty“ patterns, with a lot of boilerplate code. In the end you have just more code, and more code to maintain. Which is usually more effort.

Okay, you can draw „pretty“ UML diagrams for your code. But that makes it even more effort to maintain.

[bourneavent]

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

[hajile]

TS is literally JS with a few unsound type hints. If you're writing TS, you are already writing JS.

[incrudible]

> a few unsound type hints

Which turns out to be exactly what you need to be productive writing software. People who obsess about type systems and try to solve everything within them create a whole new bag of problems.

[hajile]

StandardML is a counter-example. It has sound types but keeps them utilitarian and simple enough so people can’t easily overdo the typing. I’ve become very sick of the “type palaces” people construct (they remind me of “enterprise java” where people do stupidly complex stuff because they can).

[bourneavent]

I mean I could say C++ is just python with memory management macros.

We're getting into the domain of opinion here. I would say TS is different enough such that it's two different languages.

Programming with type checking and programming with plain JS is really different. A programmer without experience in types (ie plain JS) won't be able to pick up types that that quickly on average. Things like enums, Generics, sum types, product types, recursive types, really change the game by restricting what functions can do.

[hajile]

Typescript's devs define it as simply JS with types to the point that they even have a proposal to add those type constructs into JS at which point the syntactic difference would be very small indeed.

> Things like enums, Generics, sum types, product types, recursive types, really change the game by restricting what functions can do.

If only that were true. The reality is that if you can write it in JS, you can add TS types no matter how horrible or anti-pattern the code happens to be. The constructs you mention don't restrict what functions can do in any way at all.

> A programmer without experience in types (ie plain JS) won't be able to pick up types that that quickly on average.

The average JS dev seems to have a Java/C# background where types exist. Further, they seem bent on slowly transforming JS into one of those languages.