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

111–120 of 202 posts

Re: Douglas Crockford on JavaScript

#111

Post by canadianfella »

andix wrote: post #53
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…

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.

[dead]

Re: Douglas Crockford on JavaScript

#112

Post by taeric »

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…

Adoption of new languages stalled out with the proliferation of installed base attached to a language. Specifically, if you are deploying anything consumer facing, it makes little sense to consider anything other than javascript for web. If you have more of a budget, you will target whatever iOS supports nowadays. Even more budget, whatever the current Android stack is.

There is some nuance, of course. But, at large, those are your options.

Similarly, if you are writing a game, whatever dev kit your target of choice supports. With a heavy bias to the asset pipeline.

So called "backend" programming is, perhaps, different. That said, you are almost certainly best to pick whatever is close to "native" where you are deploying.

Re: Douglas Crockford on JavaScript

#113

Post by bilalq »

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…

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 lot more friction to have it be parallel there.

Re: Douglas Crockford on JavaScript

#114

Post by bilalq »

benrutter wrote: post #98
horsawlarway wrote: post #74

Earlier quoted context omitted.

> All of this has made the language worse. Just accreting features doesn't make the foundation less broken. I see this view a lot - what I rarely ever see is a concrete discussion about what exactly is wrong with the "foundation" of javascript. Because to me... Javascript is actually a decent-ish solution to the UI space (it nicely balances reactivity and code complexity by presenting an event driven, single threaded…

I might not have the best take since don't have a huge grudge against javascript but I definitely think there are some concrete problems in its foundations. Specifically js has very unusual attitudes to basic syntax operations that are at this stage undoable without breaking an insane amount of existing code. For some examples: - Use of == does not do what it does in almost every other language, but won't flag an err…

These are problems easily solved with tooling today. ESLint + TypeScript literally addresses every example you raised. Static analysis works pretty well these days.

Re: Douglas Crockford on JavaScript

#115

Post by arp242 »

bilalq wrote: post #113
arp242 wrote: post #99

Earlier quoted context omitted.

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…

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 agree it can be painful. The thing is, even with an awkward async implementation it's something you have to deal with relatively infrequently when synchronous is the default (as it is in most languages). When you do it can be a pain, but I'd rather have this "occasional pain" vs. "pain every time I want to do any I/O operation".

Personally I like how Go does things.

Re: Douglas Crockford on JavaScript

#116

Post by benrutter »

bilalq wrote: post #114
benrutter wrote: post #98

Earlier quoted context omitted.

I might not have the best take since don't have a huge grudge against javascript but I definitely think there are some concrete problems in its foundations. Specifically js has very unusual attitudes to basic syntax operations that are at this stage undoable without breaking an insane amount of existing code. For some examples: - Use of == does not do what it does in almost every other language, but won't flag an err…

These are problems easily solved with tooling today. ESLint + TypeScript literally addresses every example you raised. Static analysis works pretty well these days.

I agree but I guess we differ in that I wouldn't consider Typescript JavaScript but instead a very closely coupled but different language.

Re: Douglas Crockford on JavaScript

#117

Post by jancsika »

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…

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

Re: Douglas Crockford on JavaScript

#119

Post by paulgb »

yxre wrote: post #106
paulgb wrote: post #73

Earlier quoted context omitted.

> A problem is that the 3 problems that the articles highlights have been fixed with incremental fixes. (author here) - I disagree. If V8 solved performance, we wouldn't see so much of the JS tooling stack being rewritten in Rust. Modern JS runtimes are fast because they are tuned for the types of workloads that are common on the web. This is great for the performance of a virtual DOM, but if you go off the beaten pa…

Javascript is optimized for workloads to keep latency low and maximize concurrency while constraining itself for resources. This is pretty ideal for a GUI scripting language, and covers most use cases for the web. It is hard to get performance perfect in all workloads. I have always been able to optimize my scripts to get the responsiveness that I need.

> This is pretty ideal for a GUI scripting language, and covers most use cases for the web.

Yep, fully agreed. This is why I say in the article that JavaScript hasn’t been and won’t be replaced for those use cases.

> It is hard to get performance perfect in all workloads.

The way languages do this in practice is by giving developers the ability to drop down to lower levels of abstraction if they want to. With modern JavaScript you don’t have any levers to pull, you have to hope that a runtime optimized for the GUI use cases you mentioned happens to also take a happy-path for whatever non-GUI code you write.

For example, AFAIK the JS spec doesn’t provide runtime bounds. Array.shift() could be O(N) depending on the runtime. At my company we spend way more cycles than I’d like trying to figure out why some code happy-paths on Chrome but not Firefox or vice versa.

Re: Douglas Crockford on JavaScript

#120

Post by hajile »

bourneavent wrote: post #110
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…

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

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