Echo JS 0.11.0

I see your point. Thankfully, as you mentioned, Yarn solved quite a bit of problems with depenencies - that's why I started using it in production right after a short testing period.

Dependencies - even dev ones - still have to be updated, but in my experience Gulp has never been a problem. On the plus side, I have a simple and standardized way to define and run tasks, with hooks for errors and a simplified help page. Teammates have little problem understanding Gulp tasks, rather than inspecting a custom made script: that would be my main concern about the "npm script" approach.

Gulp works well in my general development workflow - which involves watchers for the most part (that start other tasks that finish in a blink), and a couple of less used tasks for which I can afford to wait a couple of seconds more.

But I guess in the end, one should use what's more comfortable for them.

Happy new year!

And what has that to do with JavaScript?!

"task runners like Grunt and Gulp are just wrappers for existing CLIs"

I can't say I agree with this. Actually, all the arguments about replacing task runners with npm always failed to convince me.

There are several plugins that simply don't even have a CLI, to begin with. Basically, your suggestion is to write a js file to replace their behaviour and run node on them. You ended up writing 27 lines of code to do something that gulp.watch does in a couple, and better. Without spawning new processes, either.

The argument "npm vs. task runners" works better against Grunt, anyway. We know that Grunt is slow, is verbose, has a config system that quickly becomes unmanageable.

Gulp, on the other hand, does not. Gulp has a declarative approach for its tasks, and a procedural one inside them. It's clear and works beautifully. Moreover, the adoption of vinyl files has great advantages in terms of speed (since all operations happen in memory, and don't write a temp file each time) and it's also great for mocking files. And while it's true that streaming mode doesn't work for all plugins, at least it does for some.

The procedural style allows me to do some computations, if necessary, even if it's a simple `if`. Doing the same with a npm script ranges from being impossible to being awkward.
Setting the configuration for a plugin can usually be done with a POJO that I can indent as I wish; doing the same with the CL is ugly, as I have to do it in a single line (thanks Crockford that didn't allow multiline strings in JSON).
Piping results to another operation is damn simple with Gulp, while I have to append everything in the same line with && using commands. "pre-" and "post-" scripts mitigate the problem only partially (basically it's splitting the command in 3 parts).
Error handling can be better, but at least is there and it's flexible.

I tried the "npm scripts" approach in the past. It started nice, it ended up an unmaintainable mess. Maybe it's because I'm kind of used to Gulp, who knows. But once I had a task that sounded like: "Take the images in that folder, create multiple versions of them according to the spec in that json file, optimize the results and put them in their correct folder." I have no idea how to do this in a command, except for creating a js file for it - something that I did NOT want to do.

I fail to see what's the problem in including Gulp in the build workflow. It's a dev dependency, it won't bloat your final result. It's also relatively small - I'm way more worried about the size of Angular 2, for instance.

Hm... no.
It's pretty clear that the strongest point of JavaScript isn't being an OO language, but still... classes in JavaScript have always been there and this hasn't prevented us creating excellent things with JavaScript.

Rather than avoiding classes at all costs, it's better to find a way to use them properly. For example, I think React's usage of classes makes perfect sense (although some purists push for stateless components and thus can be represented by the sole render function). Not to mention, in some cases we're actually forced to use classes (when defining custom elements, for example).

I've always found the argument "`class` is syntactic sugar that confuses us" pretty weak. Yes, `class` still yields prototypal inheritance. Yes, there are some quirks behind. But, as professionals, we're to learn all of this and take advantage of it. It's not like we can't call functions like that because they're first class objects while in Java they aren't. JavaScript classes are different, so what?

Moreover, we're not done with syntax in JavaScript: more things are yet to come, and they'll be about classes too. Creation and composition of classes. This means things might change in the near future.

In conclusion, while I share the sentiment that, nowadays, in everyday coding in JavaScript you probably shouldn't define classes (except for React or similar), I refuse any dogmatic approach when it comes to getting things done. Let's keep an open mind about it.

I thought we could have learnt something about how toxic saying "X is horrible/terrible/awful" could be. Things can be improved, but this disposition doesn't help at all.

Moreover, I don't feel EchoJS is the right place for linking a rant on GitHub issues. You can do that on a comment here instead: http://www.echojs.com/news/21298

Have a merry Christmas!

It's ngrx/store, it's NOT Redux: similar but not the same thing.

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