ecmascript-harmony

I have a website that uses a large typescript code base. All clases as in their own files, and wrapped with an internal module like so: file BaseClass.ts module my.module { export class BaseClass { } } file ChildClass.ts module my.module { export ChildClass extends my.module.BaseClass { } } All file are included globally with script tags, in the appropriate order (using ASP.NET Bundling). I would like to move to a more modern setup and use webpack. I would like my module syntax to use whatever the new ECMASCRIPT module standard is. But there is much code using the existing "module namespaces"

Even though all major operating systems and programming languages/APIs have had locale support for at least a couple of decades, it seems that JavaScript still does not! With JavaScript becoming more and more of a full application programming language both in the browser and on the server, the lack of real locale support is becoming a real problem. Are there any proposals to add locale support as it exists in other languages to the EcmaScript standard? As part of the "harmony" project or anywhere else? I'd like to support and evangelize any such proposal. (This is a followup to my previous

I've tried looking in the ES6 draft myself, but I'm not sure where to look: Can someone tell me if this in ES6 necessarily refers to the global object? Also, will this object have same members as the global scope? If you could answer for ES5 that would be helpful as well. I know this in global scope refers to the global object in the browser and in most other ES environments, like Node. I just want to know if that's the defined behavior by the spec or if that's extended behavior that implementers have added (and if this behavior will continue in ES6 implementations). In addition, is the global

I'm using grunt-express to do local development. here is my GruntFile.js var path = require('path'); module.exports = function(grunt){ grunt.initConfig({ pkg: grunt.file.readJSON('package.json'), uglify:{ options:{ banner:'/*! <%= pkg.name %> <%= grunt.template.today("yyyy-mm-dd") %> */\n' } }, express:{ server:{ options:{ debug:true, server: path.resolve('app.js') } } }, env : { options:{ }, dev : { NODE_ENV : 'development' }, prod : { NODE_ENV : 'production' } }, mochaTest:{ test:{ options:{ reporter:'spec' }, src:['tests/*.js'] } } }); grunt.loadNpmTasks('grunt-contrib-uglify'); grunt

I was reading over the draft for ES6, and I noticed this note in the Object.prototype.toString section: Historically, this function was occasionally used to access the string value of the [[Class]] internal property that was used in previous editions of this specification as a nominal type tag for various built-in objects. This definition of toString preserves the ability to use it as a reliable test for those specific kinds of built-in objects but it does not provide a reliable type testing mechanism for other kinds of built-in or program defined objects. From reading this thread on es