Okay, you can draw „pretty“ UML diagrams for your code. But that makes it even more effort to maintain.
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
It's easy to just point and say "look, bad", while others are building the modern web as we know it with the specs we got.
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.
No they couldn't. There were two options for the web, build on js or find a different job.
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.
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
> 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-...
That said, synonyms all over the place. So, I can see it. I think I would avoid it here, as this would also make "mp3" a protocol. Data format already covers that, though. Whereas something like WebRTC seems more in the protocol vein.
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`.
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.
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.
> 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.
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.
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.
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.
> 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.
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.
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.
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.