DCoder

A better way would be to do like Arnavion said, for really global libraries you should create a .d.ts file and put this line in it:

    declare var somelib: any;

Done. Now the compiler and everything else will know that there's a global variable called `somelib` that does not have a specific type, and no matter how you use that variable, it's ok, you know what you're doing.

It would not be an error if not for `addToList(cats, new Dog())`. Based on that call, Flow infers that `cats` has to be a `Dog[]`, not `Cat[]`.

The old plan was to enable it in Fx 44 (the one that was just released). But a couple of bugs caused a delay and it was pushed back. It was just enabled in nightly/dev builds [0], so Fx 46 will probably have it.

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1221206#c10

That's all true. It's a chicken-and-egg problem there, though. I've seen several arguments that the language is not worth looking into until more typings become available, and of course those naysayers are not going to write the missing typings.

TypeScript is very nice. The one main problem it has is lack of type definitions for third-party modules, some developers find having to "waste time" writing those defs themselves to be quite bothersome.

You might find Robert Wachter's The Digital Doctor interesting, although it focuses on the big picture more than specific examples: http://www.amazon.com/dp/B00TT5I9A0/

Random data point: last time I checked, the AWS management console web interface was built in Angular.

One thing worth noting: MooTools, Prototype.js and some other libraries were fond of extending built-in object prototypes. jQuery wasn't.

ES7 wanted to introduce an Array#contains method. But due to prototype extension issues like https://esdiscuss.org/topic/having-a-non-enumerable-array-pr... , they had to rename it to Array#includes ...

> Promises

Careful with that axe... Before jQuery 3.0, its promises API is not compatible with the Promises/A+ spec: http://stackoverflow.com/q/23744612/1233508

If you're used to jQuery's promises, you can be in for a few surprises when trying to use other libraries (or even when updating to jQuery 3).

And Red Alert 2: YR fans might find Ares [1] interesting: it's an engine-enhancement that fixes a ton of funky bugs [2] and enables loads of new functionality, and popular mods like Mental Omega and D-Day take advantage of that functionality in interesting ways.

(I used to be the lead developer of Ares for several years, the amount of reverse-engineering and C++ voodoo involved was awesome.)

1: http://ares.strategy-x.com/

2: https://ares-developers.github.io/Ares-docs/bugfixes/type1/i...

> Who, with a lot of money, would want to hurt Linode's business in this way? This isn't just a "script kiddie" having fun. It's a very well planned and powerful attack requiring buying large botnet capacity for an extensive amount of time.

Serious question: how much is "a lot of money' in this case? How much does an attack like this cost?

With that approach, the module loader needs to know which version of a module to load for you when you require() something - in the general case that can't be done without parsing your package.json . This would require changes to node itself, not just npm, as well as all the external tools that implemented node's current require algorithm.

> Watch any React tutorial and the first thing they have you do is set up a Webpack config that gives you a live-reloading build system with ES2015.

To be honest, I prefer learning by reading specs/documentation, tinkering and Google-ing specific bits, not by watching tutorials, so I did not know this. That's not ideal conceptually, but it does mean one less tool in the pipeline, which is not a bad thing for beginners.

> it would be nice for web development to grow out of its "oooh shiny" phase.

Absolutely. Just as long as it doesn't swing to the other extreme, like PHP does, where 12-year-old and deprecated techniques are still entrenched at the top of Google... :)

> It's relative to the location of the executable, not the current working directory.

It actually searches both the location of the executable and the CWD: https://support.microsoft.com/en-us/kb/2389418#mt1

Nitpick - Grunt is a task runner, Gulp and Brunch are build tools, Webpack is just a module bundler, it's not a full build tool - it's more a replacement for r.js than for Gulp (and it's remarkably faster than r.js).

After trying out Grunt and Gulp, I found Gulp to be more to my liking because the tasks are written as actual JS code, not as a pile of configuration. Plus, it runs the tasks in parallel if they don't depend on each other, whereas Grunt defaults to running them sequentially.

React can do strongly-typed views. I use Typescript, and I can build the DOM either in JSX or by nesting React.DOM.div() and friends, and the Typescript compiler will yell at me if I use an event handler/variable/etc. that does not exist in the code. Why would I go back to an opaque templating language after that?

In a fairly simple project, I have these:

    gulp-autoprefixer -- CSS vendor prefixes
    gulp-concat -- concatenates multiple files into one
    gulp-cssmin -- CSS minifier
    gulp-imagemin -- image optimizer/minifier
    gulp-rename -- renames files produced by other streams
    gulp-ruby-sass -- transpiles SASS to CSS
    gulp-template -- interpolates some variables, e.g. environment settings or external dependency URLs, into a file (basically lodash's .template )
    gulp-typescript -- transpiles TypeScript to JS
    gulp-uglify -- JS minifier
    gulp-util -- provides things like access to environment variables, console.log replacement, Gulp-specific throwable errors
    gulp-watch -- automatically recompiles when source files change
    gulp.spritesmith -- converts images to CSS sprites

That's a valid approach, but "Good old Make" is only good if you are already familiar with it (and its quirks). If you're a new-ish web developer, "learning Make" and "learning Gulp" are two equally foreign tasks.

You can write a replacement for gulp in Perl 6, but if it doesn't have the plugins, who will use it?

Grunt and gulp have huge plugin ecosystems, which is both a blessing (you can find ready-made plugins for a lot of tasks) and a curse (everything moves very rapidly, plugins get abandoned, blacklisted and superseded all the time - if you want to compile TypeScript files, half the blogposts will recommend gulp-tsc .. but wait, it's been blacklisted, you should use gulp-typescript instead ).

Grunt: ~5400 plugins: http://gruntjs.com/plugins

Gulp: ~2000 plugins: http://gulpjs.com/plugins/

Gulp's list of blacklisted plugins: https://github.com/gulpjs/plugins/blob/master/src/blackList....

Yes, it is, but that doesn't excuse doing it here.

Note that this approach can expose the user entered password in application debug logs, MySQL's slow queries log (if you're not using bind variables), etc.

There was also https://lwn.net/Articles/57135/

The short lived "Team Knight Rider" series had a somewhat similar moment - the mechanic was working on the team's AI-equipped cars and talking to them, when the cars stopped talking back. [1]

Mechanic: "Why won't you answer me?"

Terrorist appears next to him: "Because it's just a car, you freak."

[1]: https://youtu.be/xOv1-GiWSh0?t=7m15s

Interesting, I honestly don't know if that makes a difference.

There are some subtle behavioural differences between the Language Service and the regular compiler, for example: https://github.com/Microsoft/TypeScript/issues/5243

swax is probably referring to the compiler option "noImplicitAny", which can literally turn variables whose type is not explicitly specified and cannot be inferred from their declaration as errors, instead of assuming they have the transparent `any` type.

The code insight is one of the many reasons I switched from plain JavaScript to TypeScript and will not go back.

Would that make https://www.flightradar24.com/ a much bigger concern?

Vilnius, Lithuania: http://stops.lt/vilnius/#vilnius/map/en (click "Show vehicles").