_getify

There's just one thread, one event loop, for all of JavaScript... so we're not talking about true thread-level race conditions.

> strongly implying that it takes unusual conditions for events to lag significantly

As far as expectations of software running inside of web pages, it is in fact quite exceptional for there to be significant delays between when you expect for something to happen and when it actually happens.

For example, if I set up a timer for 953ms from now, and it actually runs at 3953ms from now, that extra 3 seconds is extremely uncommon for the UX expected on the web.

I think the disconnect here is that you're really asserting things about what happens at the OS level, where multiple threads and real I/O are happening, etc.

I'm entirely talking about JavaScript, which is single-threaded, and where asynchrony is just simple event-loop concurrency (interleaving actions). It means that two timers should, in simplest terms, order themselves according to normal expectations. It'd be unusual for there to be significant deviations.

https://github.com/getify/You-Dont-Know-JS/blob/master/READM...

Also, the "Up & Going" title, Chapter 3, has descriptions about the titles and the narrative/story arc being told across them, which helps understand the intended order as well:

https://github.com/getify/You-Dont-Know-JS/blob/master/up%20...

Rather than most books which gloss over the "bad parts", which prevents people from fuller learning and leaves them to their own devices when they run across that stuff in the real world, YDKJS covers all the parts, and tries to use the deeper understanding as a tool and guide to making better-informed decisions about how to effectively write JS.

I think it's entirely unfair to suggest that covering "technical arcana" is the same thing as endorsing it.

I did have lengthy discussions with my book editor about the title and its potential to be off-putting to some. We wrangled with the decision awhile, but ultimately came to the conclusion that most would find it a mix/balance of playful, attention grabbing (in a sea of "JS: The Handy Guide" type titles), and challenging.

The title itself is supposed to be equal parts a joke and a serious commentary on what I consider to be a disturbing trend in JS specifically, which is either a false sense of confidence or (worse) an apathy to not care about what is not known.

Again, thank you for your thoughtful response and your feedback. I do regret that it's hit you the way it has. Perhaps at some point you may give it another shot.

These are what the covers of all the books in the series look like:

http://shop.oreilly.com/product/0636920026327.do

------

side note: my kickstarter for the books, 2 years ago, playfully used the bald head image to catch people's attention (never the intended branding). I soon afer got a friendly lawyer takedown notice from the folks who own the game. We worked it out, and the new branding was born. :)

I'm trying to work with O'Reilly to bring down the prices on the books a little bit. I always wanted them to be priced so that price wasn't a barrier to entry. As you can imagine, there's lots of intricate details which restrict what I can do with pricing.

> none of them that big

Hmmm...

Page counts on the titles (so far) are: 65, 98, 176, 189, 296. The last book isn't finished yet, but I'm projecting it to be somewhere around the 150-200 mark.

I can appreciate that $20 for a 100pg book may feel "excessive", but what about $26 for a 296 page book?

Moreover, I'm working (still) on getting O'Reilly to release a box set for a flat price that will be much more reasonable than buying each book individually, so that if you want the whole series you'll have an affordable option for that.

And you'll of course still have the option to buy just one or two of the books if that's your fancy.

There are some edits and refinements that happen to the content during the publishing/production phase at O'Reilly that aren't necessarily appropriate to back-port to the repo. But I do try to get most of the main substance stuff sync'd.

The free GitHub repo versions of this content represents the drafts of the books in the mostly complete stage, whereas the published books (digital or print) are the final, final versions.

If you're going to make JS your primary language that you write on a daily basis, doesn't it make sense to invest more time into learning it than just whatever you might accidentally pick up through trial-and-error?

Most developers in most other languages do tend to take formal learning of the language, to a deep extent often, a more serious task, but with JS it seems many developers just kinda get whatever they get along the way.

I have found that approach to be good at getting and keeping yourself employed, but bad at giving you any confidence that you actually know what's going on. If you aren't really sure exactly why your code works, my theory is that you'll never know exactly why your code doesn't work either.

I'm just trying to provide resources for developers who want to take learning JS seriously, and challenge "all" of us to ask, "just how much DO I know JS?" The rest is up to you. :)

Just curious what parts you looked at? Did you glance at the table of contents, or did you read full chapters? I certainly tried to reveal in every chapter several different things that, in my professional experience teaching JS to teams of developers, are commonly misunderstood or under-understood.

If you had any specific feedback on what I could have done better to live up to the title, tone, and mission of the book series, I'd be appreciative of it.

> very early draft

Depends on which book(s) you looked at. The series is 18 months old by now, with 6 titles. 5 of them are already "complete".

3 of them have already been edited and published (though publisher edits didn't necessarily all make it back into the free repo versions).

2 of them are in final editing and production stages, so they're still being cleaned up. The sixth one is still a very early and partial draft, so it's quite rough.

https://github.com/getify/You-Dont-Know-JS/blob/master/prefa...

The truth is, we all don't really fully know JS, and we all need to work on knowing it better. The books are my way of learning it, and hoping that others can learn along with me. :)

But that doesn't mean we have to just accept it'll never change.

I take a sense of pride and ownership in the web, and I have big hopes for its future. That means I have to want to try to make it better, not just keep it afloat. I just hope I can inspire others to do the same.

Now it's time for maturity, in my opinion. I just think this is one way of going about shuffling off some of the old baggage (that admittedly got us here).

Of course they are objectively "better" (by almost any measure) than the mixed old-and-new-that-conflict crap we have.

Is the "new new" we have bettter than the "old new" we had back then? Who cares? That's an institutional question about standards in general.

I'm focused on a very different problem: how we as an industry react to the standards. Currently, we always pile up extra tech debt and almost never (not never, but very rarely) accept the pain of kicking out the really old.

> This whole 'effort' is moot since web practice veers so quickly

I'm not suggesting it's a one-time fix. It might have to happen once a decade, or once every 20 years.

BUT, I think there's a good amount of evidence to suggest this idea could achieve more positive forward motion than it might've in years' past.

Namely, the fact that all modern desktop browsers are on a drastically more rapid update cycle than we were in back when much of this tech debt was accrued (circa 2005). The quicker browsers auto-upgrade, the less likely we are to have widespread "adoption" of bugginess that sets in and becomes permafrost on our industry.

If we fix mistakes quickly, and often, it continues to spur companies to keep their apps fresh and updated.

Is it a perfect solution? Hell no. But I think it's better than what we've got now, which is to say, "approximately nothing."

> Is it really worth breaking all legacy websites?

In any organization, this question gets asked of their product's technical debt, many times over, and gets many "no" answers, until finally there's too much, and their "technical bankruptcy" is unavoidable. They suffer the (temporary) pains to deal with some or all of that debt, and get back on track.

I'm just wishing we could treat our industry that way. I think we're "there" at that point of decision. I just want to tip us over the edge into admitting it.