Echo JS 0.11.0

Ok, three times and they still don't get that this aggregator is for English only news.
Time to ban?

This first part basically consists in setting up a development environment on Windows. Not a single line of JavaScript...

Also, I find the choice of Scoop as a package installer quite unusual, when alternatives like Chocolatey and NuGet are much more en vogue. But well, I guess avoiding a monoculture is good.

On the other hand, ConEmu is nice although I would have used Cmder (which is a wrapper for ConEmu).

What I'd *never* do is writing "jQuery" in all caps.

Uh, it also says "focused on JavaScript development, HTML5, and front-end news". That's a bit confusing.

Anyway, looks like it's a script quite web-development centric to me. In particular, it installs a decent node environment.

I can't even.

> Also, I count 4 dependencies, where dpicker has only 2.

I wouldn't count 3 of them, since they're packages by Bevacqua himself. The other is moment.js, which dpicker depends on too.
Rome *is* larger, though.

The video is about nothing new for a good part of the video.
But IMO the main topic if Mattias' rant on reducing the application's variable state to the minimum.

In fact, Chrome supports the `unhandledrejection` event:
http://www.2ality.com/2016/04/unhandled-rejections.html

This is basically Symfony/Laravel on NodeJS
Even the (overpowered) templating engine is Nunjucks, which is basically a JS version of Twig.

Should feel pretty familiar for who's used to those classic MVC frameworks, though.

I really don't like the idea of changing the extension as a way to discriminate between CommonJS and ES modules. Extensions don't pertain to a language like Javascript, which aims for maximum flexibility. What's the next step, a new content type for Javascript modules? Like "text/javascript-module"?
I should be able to load a module from a data URI if I really want to.

I still don't see the problem about AST inspection to determine what kind of module it is. Of course, there are modules that aren't meant to run in strict mode. But if we're talking about an external dependency, we have version numbers for that: let's find a way to specify the type of the module (Bower has dealt with this since long ago). Of course, it's the maintainer's duty to keep their code compatible.

If, on the other hand, we're dealing with an in-project module file, well, developer just have to fix their code if they want it to work with the newer syntax. It shouldn't be a hard work if they're used to put "use strict" at the top already.

Another edge case is when a module doesn't include `import` or `export`. In this case, it's a matter of loading the module, using `require` or `import`.

In the end, in times when the line between client and server side is getting thinner I see relying on file extensions as a relic of the past we shouldn't consider anymore.