Live data from Hacker News

Douglas Crockford on JavaScript

digest.browsertech.com

51–60 of 202 posts

Re: Douglas Crockford on JavaScript

#51

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…

> 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

Re: Douglas Crockford on JavaScript

#52

> "[...] we are crushing ourselves with the accumulated complexity we’ve piled on top of bad foundations [...]" The same could be said about plain HTML/CSS though. I think the author is correct overall and I don't really see improvement on the horizon. WebAssembly, while great that it exists, can morph browsers into some poor mans virtual operating system and this can lead to a less open web. We already see more clos…

> The same could be said about plain HTML/CSS though. Genuine question: How much of the complexity of working with HTML/CSS is unnecessary and how much is inherent to the problem they solve? Is it as bad as with Javascript? I would say that we, for the most part, have a very clear idea of how we could (theoretically) replace Javascript with something much better. I don't know of alternative layout languages, so I don…

I believe the complexity often stems from historical development as well. There are often multiple ways to achieve the same thing or workarounds for specific browser. Either you have HTML tags to format something or you can do it with CSS. CSS is difficult, because there are obtuse rules. The order of CSS-rules is relevant as well as the specificity (which is hell in my opinion).

You can write an extremely clean and awesome HTML/CSS document. But you very rarely find that kind on the web.

I think we neglected being more careful here because browsers became more and more forgiving. So they often render as intended, but not really like it is stated in the often invalid document. That made browser insanely complex as well. No new browser will ever be successful if it would be parsing strictly. More than half of all websites would probably stop working correctly.

I believe you could replace both HTML/CSS with something much more clear and as capable. But on the other hand we should be glad that we have standards like this and perhaps we shouldn't let perfect be the enemy of good.

Perhaps JS doesn't qualify as good, but on the other hand I think its success speaks for itself. It even grew beyond the browser and some electron apps are extremely well received (apart perhaps by your system memory). Despite that, it is a scripting language and it should mostly be used as that. Since every browser comes with a parser, it is a quite mighty tool to have.

Python is a similar contender. It is the ultimate choice for certain domains and I don't see that changing any time soon, even if python isn't perfect itself.

Re: Douglas Crockford on JavaScript

#53

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…

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.

Re: Douglas Crockford on JavaScript

#54

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…

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

Re: Douglas Crockford on JavaScript

#55
post #11

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.

Typescript is very nice, just need to get rid of the javascript underneath.

Deno?

Re: Douglas Crockford on JavaScript

#56

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…

> 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

[deleted]

Re: Douglas Crockford on JavaScript

#57

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…

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

Re: Douglas Crockford on JavaScript

#58
post #9

> "[...] we are crushing ourselves with the accumulated complexity we’ve piled on top of bad foundations [...]" The same could be said about plain HTML/CSS though. I think the author is correct overall and I don't really see improvement on the horizon. WebAssembly, while great that it exists, can morph browsers into some poor mans virtual operating system and this can lead to a less open web. We already see more clos…

> [closed platforms] will increase and which could be accelerated with different approaches to languages. the business incentive is towards such closed platforms - data and platform ownership has value after all. It makes zero sense for a business to keep a platform open and potentially help a competitor.

I disagree, it would be in their interest to somehow gap that border in the long run, although I wouldn't know an easy way to achieve this. Its users often tend to not understand the repercussions in my opinion and that is true even for software developers.

Sure, an exchange on Discord is easy and personal, you get ample support from your supporters and that can really propel projects to the next level. But as I said, all the knowledge from these exchanges is lost for the net. The user that comes 2 years later won't see these exchanges and not even you product in some cases. I would always suggest to also use some kind of forum or knowledge base.

Discord has APIs to make such content discoverable as well in theory. I use the platform too, it shouldn't be seen as an indictment for the Discord developers at all. On the contrary they offer an extremely useful service and in most cases completely for free and it shows that they care for the platform. But just as things are, we have it as something separate to the usual web and I believe that some communities suffer if they do not provide alternative venues.

Re: Douglas Crockford on JavaScript

#59
JavaScript is fine, the real problem is HTML/CSS and the DOM.

We were so, so close to a semantic, reader-based web ~20 years ago.

The ad supported Internet killed it. Now that the ad supported Internet is dying, maybe we can get back to it.

Re: Douglas Crockford on JavaScript

#60

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…

> 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

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.

Post reply on HN