Echo JS 0.11.0

That's very nice, Nicolás, thanks! I was thinking about a scraper myself.
I think it would be a nice addition to Todd Motto's list of public APIs: https://github.com/toddmotto/public-apis

Now how about an RSS feed about changes on proposals?

The grammar in the article is kind of bad, which makes it difficult to read. This could also be the cause of not-so-well expressed concepts.

> 1 Node.js is Asynchronous

It's not. Code can be asynchronous, while the environment can support asynchronous code. Node does.

The article correctly mentions that Node is single-threaded, so when dealing with multiple tasks the developers are more or less forced to adopt an asynchronous style. It's common when building a web application, for example.

But when Node is used to just run an unparallelized JS script, it's fine to use synchronous methods. That's why they're there: you don't *always* need to be asynchronous.

> 2 Is it possible to handle Callback Hell?

Yes, but that's more related to JavaScript in general rather than Node. It's also worth mentioning that Node supports Promises since version 0.12, rather than just suggesting external libraries.

> It is definitely necessary to split codes because you'll have to work with many tables.

Eh, uhm, what? The author takes for granted that everything you do with Node should have some kind of persistence in relational databases, I guess?

Well, even if it was true (and it's not, of course, starting with the fact that you don't always have to work with relational entities), that's not why you should split your code into several modules.


The tips per se aren't wrong, but in the end the article lacks meaningful examples, and the nature of the hints varies a lot, making it difficult to follow the overall argument.

> vim package.json

Can't I just use the editor of my choice? What if I'm on Windows?

What I actually mean is that if you want to write a tutorial like that, you can (and preferably should) leave thid kind of details to the reader. You can just say: "Create the package.json file and put in the following content: ..."

You know what, I could give it a try. I still am unconvinced by npm's decision to flatten the dependency tree, so I guess anothr approach is welcome.

Do you plan to support yarn.lock files as well?

It's just you.

Also, this one doesn't bash Webpack.

Looks interesting, but I don't know if it belongs to EchoJS.

Again, you really need to make npm packages out of these modules. It'd be great if you get along with the Node ecosystem.

I still think === is the way to go in most of the cases. Object.is has an advantage when dealing with some numeric edge cases, but that's pretty much all. For the est, it's more verbose and less readable.

Sheesh, we really don't need to become as toxic as Reddit.

Can we please have this topic deleted? EchoJS isn't the place for developer feuds.

Why would someone in their right mind post something like that here?!