Echo JS 0.11.0

I hardly understand the point of this article. Methods like forEach and map have a great value when it comes to readability and maintainability. But if you need performances, you don't use a callback function, period: you use a good-ol' for loop, because function calls are expensive.

But then again, if you need performances you might not want to do that in JavaScript to begin with. At most, you do that in C++ and convert it with Emscripten.

I think every article/news about Angular 1.x should have the version explicitely mentioned in the title to avoid confusion about Angular 2+, which is simply called "Angular".

That's cool, but I'm waiting for the Atom version.

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.