Echo JS 0.11.0

"Also, you don’t need any other tools to manage dependencies."

That's funny, it's also the main reason why Bower is being replaced by npm.

Even if you don't use a bundler, you can still load scripts from node_modules. If you don't like the folder name, you can use a symlink or switch to Yarn.

"Using Bower separates the front-end dependencies from the others"

Does it even still make sense? And why should I care? Where should I put Lodash, among front-end or back-end dependencies? There's a lot of isomorphic/universal JavaScript around, it's not like it's still Angular here and Express there.
And what if I *do* use a bundler for the front-end? Would I be stuck with debowerify?


No, I don't think Bower is still relevant at all. The only thing I liked is that you can state the type of module you're creating (AMD, ES6, CJS...), but that's pretty much all.

The publishing workflow is quite awkward and too tied to cloud Git hosts like GitHub. You also have to tag your releases. What if I don't want to, or if I use Mercurial, or I don't use *anything at all* - just my bare hard disk?

I've published some of my packages to Bower too - the ones that make sense on the front-end, anyway - the it always felt like a chore to me more than actually giving a solid contribution.

Well, as I said, you don't have to *switch* - you can use them both, like you can do in Angular 2.

The odd thing is that we've been using "observables" since, like, forever. Of course not of the kind we have in RxJS, but we have events (the "observables") and listeners (the "subscribers"), and we lacked all the semantic syntax ofr transformation and manipulation such as map, forEach and so on. So, theoretically, it *shouldn't* be that hard to grok Observables.

But it kind of is, because of the mentioned sematic syntax which could be quite jarring from the usual procedural style.

But yes, Observables are somewhat needed. Maybe not in this form, but the concept behind them is necessary because, as I said, not everything could be achieved with a Promise.

The proposal is interesting, but:

* while a scientific article can be ojectively verified in its experiments, bibliography and whatever material, how can you do that for JavaScript libraries?
* scientific peer review is an activity performed among universities, but there's no "JavaScript university" or anything with similar authority;
* who's going to actually pay the reviewers? And how? Will we expect their efforts to be like OSS?
* who's going to review the work of reviewers? Who's going to decide who can be a reviewer?
* who, and how, are going to write down a code of conduct for reviewers?

And so on. Not to mention that peer review in the scientific community can suffer of one or more of the following problems:

* absence of a second opinion;
* impracticability of appealing a rejection;
* university feuds;
* nationalistic pressure (!);
* inability to get in from outside the academic community.

Don't mistake me, it's still the best thing we have. But it has its flaws.

It's not like one excludes the other, as they have different purposes. Promises are good for one-time events, while observables are meant for streams of events. It becomes problematic when we try to bend one to do the job of the other.

For example, right now we have a nice `fetch` API that *seems* to be perfect for promises (we've been using them since jQuery implemented `done` and `fail`), but now we've not only lost the ability to cancel a request, but also to watch for the progress in uploading the request and downloading the response.

You wouldn't use a Promise to listen to a click event, either.

Conversely, using observables for simple tasks (for example, getting a Blob out of a <canvas>) introduces unnecessary syntactic clutter.

The problem now is that we have native Promises, but still no native Observables.

Sad news, but cancelable promises have always been on a problematic path. To be honest, the whole "promise" thing, while having some undeniable advantages, has some quirks that prevent a really good coding experience.

The inability to cancel a promise with a meaningful outcome is one of those things. We adopted promises and build a whole new syntax (async/await) around it, without thinking about future developments.

The fact is that promises are meant to be a simple tool to organize our code flow, and yet under - and even over - the hood they're not.

We'll have to wait for Observables to solve out control flow problems (hopefully). They're not simple, but at least they don't pretend to be.

Anyway, thank you Domenic Denicola for your effort. I don't think it's been in vain, for the whole community.

I'll tell you what: we still have to wait several months to use it reliably, because it's only available in TP. Because Safari still has an old-school update cycle, when even Microsoft has learnt the lesson.

Well, a bit, yes. Sometimes you get thrown off by some mistake that in the best case makes you stutter and distracts you, and in the worst it makes you misunderstand the meaning. As chris-l pointed out, the title itself suffers from this problem, as it sounds like you think *closures* are wrong!

I bet that's why you got 4 downvotes here, even though your article has good points.

As a non-native English speaker myself - and coming from a Romance language, too - I understand the difficulties of being fluent in English, as that's something that could be achieved with a lot of practice. Just like any other language, after all.

You write in English to make your content accessible to an international public, so it's better to get some proofreading help until you're confident to do that on your own.

Wave was a disaster in terms of presentation :) and now it's dead. The products I mentioned still exist.

I'm not sure if you actually meant they're "wrong" when in your post you mainly rant about how they're often wrongly explained - which could be generally agreeable.

But surely they don't feel anything like "miraculous" once you grasp the basic concepts - and you have them right in example 2. Why should example 3 feel different?

You should also mention - in 2016 - that using `let` instead of `var` in the last example completely changes the outcome.

On a side note, take care of your English grammar.

It's a demo - let us decide if it's cool or not.