I'd just like to point out this is like the fourth post in the last 24 hours in the front page to mention the babeljs transpiler.
While transpilation was possible with Traceur before - babel has made it really easy and the fact issues are addressed within a day and the author is an overall great guy really helps.
I've never been able to fully switch to Traceur - but ever since babel (used to be 6to5) came along I've made the switch and never looked back.
I like Traceur (at least with tools like System.js & jspm), especially with its support for optional typing and annotations, but for some apps, Babel makes a lot more sense.
I came across the difficulty of using jspm on the server and client for an isomorphic React app I am building for an online community I run, and I was advised to just use npm (& naturally Babel). Integrating browserify with babelify into the build process was a far easier task.
I do not use the Flux pattern currently, but I am only in the beginning stages of building out this app & am inexperienced with React, and I have to coordinate getting others in this community involved too (two beginner/junior developers & a mid-level/senior developer, and 2-3 artists/designers, none with web designing experience). I have not evaluated how I want to handle state changes yet - I may just go with the Flux pattern for practicality for the beginner/junior developers' benefit career-wise.
This app is being built on io.js with Sails.js, isomorphic React, and ES6 (server and client) - I went with React because of its ability to do client-side and server-side rendering for SEO purposes. I have a working isomorphic React foundation, and working testing solution for the React code, but I still have to get a server-side testing solution up, integrating optional Steam authentication via OpenID, and figuring out build & deploy tooling into separate environments. This is on top of gathering requirements from the community & organizing it into a nice functional spec for developers to consume...it is almost like creating a startup except that it will never be for money, only for the love of the community I created ~7 years ago as a part of a larger one.
Thank you very much for the detailed explanation. I once tried Sails and didn't find it easy (or was it even not possible at all) to configure relations for my models found on a PostgreSQL db. Do you have any plans to open-source the "foundation"? I'd be interested to see how you structured it.
Honestly, it wasn't all that bad - I had to do a little customization in the app.js script that gets generated on creation of a new Sails.js scaffold (added require('babel/register') before var sails = require('sails') ), and then created a simple browserify grunt task & inserted it into the pipeline. I hijacked the views folder for all of my React code, and exposed every React component via a top level script, including the router, so I could make use of all of them for custom code in both the server and client.
For the models with Sails, I haven't touched that yet - the plus side for me is that there is no schema yet, so I am still free to set everything up in the database as I wish. If you need to configure relations, there are details listed here: http://sailsjs.org/#!/documentation/concepts/ORM/Association... (check the types of associations listed in the sidebar on the left)
Traceur scared people away both because it was a build tool and had a runtime dependency. Now that tools like Webpack are common, introducing a build step at ay point in your workflow is trivial. Moreover, many of the JS Harmony improvements can be transpiled with a tool like Babel or jstransform without the need to introduce yet another library in your deployed code.
The thing that appealed to me about Babel back when it was still called 6to5 was the fact the output was far easier to read. If you compare the output of Traceur to Babel, the difference is night and day. Traceur isn't readable at all (at least not to me) which might not matter, but I think in some cases, Babel's output is closer to more traditional Javascript and more performant. Overall it is a much better transpiler than Traceur. Plus you're right, the author is a great guy and open to suggestions from the community, it definitely isn't a closed off effort.
Several ES6 features very much resemble the few ways coffeescript syntax differs from older versions of ecmascript. Arrow functions, destructured assignment, string templates.
In context, we were commenting on this:
.attr('transform', d => `translate(${d.x + 1} 0)`)
which looks pretty similar to the coffeescript counterpart:
Agree. It makes writing functional code (and functional-style code) much better looking.
Careful though: Libraries like jQuery and D3 can and/or do rebind `this` and that can be a gotcha in both TypeScript and straight ES6. You can end up having to mix both declaration styles, which is gross.
I really like destructuring, but I worry about arrays becoming popular for multiple returns. If I'm using some other module, I really don't want to have to remember the order in which the parameters come, or be forced to check documentation or implementation to know for sure.
With an object, I can use a console log or a debug break point and immediately see the key value pairs (hopefully well-named) without having to check the function implementation or docs to see in which order the authors decided to return (or yield, etc.) values.
Can we just agree now not to use array destructuring as an excuse for returning multiple disparate values in an array? Or at least in only some idiomatic form? [error, value] would actually make sense to me, as it follows popular Node conventions.
Yeah, that's definitely the alternative I'm advocating for.
I've seen many an ES6 blogger decide to use arrays in their examples. It's not quite so grievous in the context of a throwaway example, but for real world usage, it might be more costly to figure out a month or two down the road.
properties and methods, yes. But I am not familiar with any other object-oriented language (is JS one now?) where the names of local variables matter. I mean, is 'local' even the right word, when the names chosen as references have semantic impact outside the local scope?
Right, they don't, and they shouldn't. If I'm not mistaken, we already agree completely.
I'm saying that functions should return either primitives or objects that have properties (or keys, since in JS all objects are just hashmaps) that uphold some appropriate abstraction, completely separate from whatever the variables might have been called inside the function body.
For example, the return object from some function `getDate()` might have a .year property, or .toUnix method, etc.
If all I'm given is an array of arbitrarily typed values, I have solely the array indexes and values (or to go to the docs or implementation) to clue me into the semantic meaning of what was returned.
Coming from Common Lisp multiple value return is usually used when there are some non essential values to return in addition to a primary value. Unless you specifically bind those non essential values are discarded.
For those of you who want some longer read on ES6 there's a work-in-progress (but already quite informative) book from Nicholas C. Zakas, available for free on github:
I've been writing most of my Javascript in ES6 recently and I agree that it's simply fantastic and still has a lot of potential to be explored when it comes to creating modern apps and frameworks. My main problem is that we're going to be stuck using transpilers for quite a while as by the time all of the browsers finally[1] catch up to ES6, ES7 will be released. Unfortunately, there's not much we can do about slow vendors.
I wouldn't be quite so pessimistic. ES6 isn't finished yet- and I'd say it would be expected for some vendors to take another 6-12 months to add all new features after a finished spec is published.
This is pretty much what happened with ES5, right?
> and I'd say it would be expected for some vendors to take another 6-12 months to add all new features after a finished spec is published.
And what happens with browsers on older mobile phones that cant be upgraded ? you let your scripts stop working ?
If you think you can switch to ES6 in 6 month without any kind of transpilation, while keeping a good browser compatibility good luck ...
> This is pretty much what happened with ES5, right?
No,5 years after the launch of ES5 some browsers like Safari still didn't support some ES5 features. And some browsers on handsets will never support ES6.
6-12 months was a bit optimistic (I thought ES5 was released in 2011, in fact ES5 was released in 2009 and ES5.1 in 2001) for vendor adoption I'll admit. Still, I can't imagine waiting more than 2-2.5 years for perhaps 80-90% of browsers supporting virtually all of ES6.
> And what happens with browsers on older mobile phones that cant be upgraded ? you let your scripts stop working ?
If I was absolutely worried about browser support on older mobile phones, I'd be still writing vanilla JavaScript with no features that aren't in Ecmascript 3. You'll have to drop support eventually. Plus, it's very likely a good chunk of the ES6 I'll be writing will only ever be intended for running in browsers that support other cutting-edge features like WebGL, Web Workers and WebRTC, or on a fairly up to date environment like iojs or node.js.
> No,5 years after the launch of ES5 some browsers like Safari still didn't support some ES5 features.
I'm not sure which features Safari is missing that you're referring to. Safari on both iOS and OS X are missing a lot of Javascript APIs, but both have fully supported ES5 since at least 2011 [0], and my old Macbook with Safari 5.1 has no problems running modern websites.
> If you think you can switch to ES6 in 6 month without any kind of transpilation, while keeping a good browser compatibility good luck ...
A lot of ES6 features are already being polyfilled (Typed Arrays have been polyfilled for years), plus you can use try/catch to support new syntax whilst also supplying some sort of fallback.
You can't deny that ECMAScript 6 has given some much needed CPR to the Javascript language, but I think we have yet to see the true potential of Javascript discovered. I love the addition of modules, classes and all of the other new additions to the spec including my favourite => arrow functions. Small steps towards being a half-decent language.
I am already thinking ahead, ES7 is definitely going to be the pinnacle of the language I think. The implementation of a native Object.observe() means we will not have to worry about poor implementations in SPA frameworks like Angular that currently use dirty checking and other hacks to make up for the lack of native object observing. Lets hope the yearly release cycle proposed for Javascript specifications means ES7 happens sooner rather than later.
We have classes in ES6 (which is great), but they are currently nothing more than syntactic sugar over the old tried and tested prototypical inheritance. There are plans to add statics, private/public variables and classes to further extend them beyond just eye candy which they currently are. Plus Async/Await, Typed Objects, etc. There are also plans to better supported multithreading without the need to use WebWorkers which are pretty limited in their use.
Get excited. ES6 is only the beginning of a great suite of changes coming to Javascript. We'll eventually weed out the hacks and non-pretty parts of Javascript one specification at a time.
JS5 was nice, but the ES6 direction is increasingly driven by people who come from the C#/Typescript and Java compiler front. Was it really necessary to add "class" syntactic sugar? Some of the new ES6 and new Rust1.0 syntax additions seem to be driven by the Ruby/Python/Scala front and don't look like proper C/C++/JS/PHP syntax. Hopefully ES7 doesn't get the verbose syntax of Java/C#. If people want syntax XY they should use a transpiler to JS or emscripten & asm.js.
A good example is Facebook's Hack language that improve PHP in a sensible way and adds optional typing - something that would be great for ES6/7.
> Was it really necessary to add "class" syntactic sugar?
Necessary? No. But look around at Javascript projects, and see how many "reinventions" of simple inheritance you see. Often poorly done and/or buggy. Even more often they're hopelessly inconsistent.
What a lot of the ES6 changes does is codify ways of doing what "everyone" has been doing in mutually inconsistent ways.
> Was it really necessary to add "class" syntactic sugar?
I think it was. Using the class syntax gives a semantic meaning to the code that propotype wasn't. And if you think it was, then what was the point of typing again and again MyClass.prototype.<> ?
Refactoring Javascript code was a pain, and an excessive identifier redundancy was part of it.
> Was it really necessary to add "class" syntactic sugar?
Yes. Now your editor/IDE knows that that thing is supposed to be a class. The doc generator also knows that it's a class. Furthermore, this makes things more compatible since framework A and library B use the same kind of classes.
Finally, it means that you won't have to waste time with evaluating a dozen semi-popular options to handle classes/inheritance.
It does of course also make your code a lot easier to read and it makes it easier for new developers who used some other language with classes before.
> Hopefully ES7 doesn't get the verbose syntax of Java/C#.
I recommend to take a look at TypeScript and Dart. Optional types aren't verbose. You just add some types to the surface area, which, compared to JSDoc, is drastically less verbose. Inside functions, you can generally omit the types.
It's a pity that optional types are still missing in ES6. As I wrote:
A good example is Facebook's Hack language that improve PHP in a sensible way and adds optional typing - something that would be great for ES6/7.
In comparision the Java/C# type is static at compile time. Newer C# version have like e.g. Visual Basic 6 a variant type that is a tradeoff (as wasteful as a "union struct" in C).
The class syntax in ES6 is just syntactic sugar. JS IDEs like WebStorm/PHPStorm/IDEA already can parse "classes" with JS5 syntax .
But what about the arrow syntax:
var odds = evens.map(v => v + 1);
Or the iterator syntax that ES6 got from TypeScript:
Agreed. It goes against the current shift from OO programming to functional programming. I hope Javascript remains a somewhat simple language which syntax can be easily memorized.
Can anyone explain the forwards compatibility plan for es6? I get we can transpile, but that's not a gradual strategy for converting code. Since you can't polyfill syntax, are we just supposed to all transpile until some far flung day when browsers without es6 support finally reach some tiny percentage?
Is the assumption now that browsers largely auto-update that it won't be so long before that happens? Why are breaking syntax changes not a big deal, whereas "use strict" was done as a string so older browsers would ignore it?
The only backwards compatibility breaking change I know of is that function declarations are scoped block level in EcmaScript 6 (which I think has been renamed to EcmaScript 2015), not function scope which is what they have been since the beginning, but they're only block level if you use "use strict"; for the foreseeable future and if this change breaks things for you you were writing really terrible JavaScript to begin with.
Firstly, JS isn't just about browsers anymore. Developers using node.js and io.js can use new syntax as soon as their platform of choice supports it.
For browsers, yes, compatibility means we have to transpile. But the day you need not isn't necessarily so far-flung. Like you say, browsers largely auto-update and, after a slow start, they are implementing ES6 features at a good pace. The ES6 compatibility table[1] shows the progress already made. Only WebKit is really lagging. IE.next/Spartan is actually leading the pack, and coupled with Microsoft's plan to give away Windows 10 free to Windows 7 and 8 users, it gives good hope for the future.
Also, transpilation can be a gradual strategy for converting code. The Babel (née 6to5) authors have stated their intention to keep supporting new JS features as they are added to future versions of the EcmaScript standard. I think we'll soon see Babel able to be used like Autoprefixer, which selectively adds vendor prefixes to CSS based on browser support statistics and a developer-specified target configuration like "last 2 versions" or "> 5%".
I think that it's outlandish and silly that ES6 doesn't have a safer, more sound philosophy about type systems, e.g. like the elegant and rational one in TypeScript today.
The web needs increased consistency and cohesion in the HTML/CSS/JS triumvirate.
ES6 seems like a grab-bag of neat and fun new features that end up doing a whole lot of nothing for large projects that have to care about more tangible concerns than nicer ways to create anonymous objects.
Some of the new features of ES6 - Symbols, proxies, Object.observe, et cetera - seem to make it downright easier to write even more confusing code. Instead of increased rigor and tools for building better software, we get stuff like this:
> Some of the new features of ES6 - Symbols, proxies, Object.observe, et cetera - seem to make it downright easier to write even more confusing code.
Actually, they're things that actual users of javascript have been asking for (and implementing hacked-up solutions for) for a long time. There's a reason Coffeescript is often referred to as "a better javascript" and Typescript is considered its own thing.
Javascript is a dynamic language, and will never make the transition to a static one. Its users don't want a static language - the people who want a static language are using things like TypeScript.
> Javascript is a dynamic language, and will never make the transition to a static one
Never say never. Typed structures are a proposal, and what make you think that we'll never see flow types in the standard someday ? Javascript will always give the upper hand to dynamic typing, but I can see it becoming a kind of hybrid language, where both dynamic and static codes can coexist.
I somewhat agree and consider moving to TypeScript a bit risky as it seems like it'll end up a niche but I do think sensibly added typing code improve JavaScript. I want better tooling support, refactoring support, intellisense...and languages like Dart/TS seem to me to have shown its possible to do this without throwing out the dynamic aspects.
72 comments
[ 2.2 ms ] story [ 145 ms ] threadWhile transpilation was possible with Traceur before - babel has made it really easy and the fact issues are addressed within a day and the author is an overall great guy really helps.
I've never been able to fully switch to Traceur - but ever since babel (used to be 6to5) came along I've made the switch and never looked back.
I came across the difficulty of using jspm on the server and client for an isomorphic React app I am building for an online community I run, and I was advised to just use npm (& naturally Babel). Integrating browserify with babelify into the build process was a far easier task.
I do not use the Flux pattern currently, but I am only in the beginning stages of building out this app & am inexperienced with React, and I have to coordinate getting others in this community involved too (two beginner/junior developers & a mid-level/senior developer, and 2-3 artists/designers, none with web designing experience). I have not evaluated how I want to handle state changes yet - I may just go with the Flux pattern for practicality for the beginner/junior developers' benefit career-wise.
This app is being built on io.js with Sails.js, isomorphic React, and ES6 (server and client) - I went with React because of its ability to do client-side and server-side rendering for SEO purposes. I have a working isomorphic React foundation, and working testing solution for the React code, but I still have to get a server-side testing solution up, integrating optional Steam authentication via OpenID, and figuring out build & deploy tooling into separate environments. This is on top of gathering requirements from the community & organizing it into a nice functional spec for developers to consume...it is almost like creating a startup except that it will never be for money, only for the love of the community I created ~7 years ago as a part of a larger one.
For the models with Sails, I haven't touched that yet - the plus side for me is that there is no schema yet, so I am still free to set everything up in the database as I wish. If you need to configure relations, there are details listed here: http://sailsjs.org/#!/documentation/concepts/ORM/Association... (check the types of associations listed in the sidebar on the left)
It uses a serviceworker in the background to transpile es6-js requests into es5 transparently.
You don't really have to be a designer to see that it's an awful choice of color.
In context, we were commenting on this:
which looks pretty similar to the coffeescript counterpart: Five subtle differences, but it shows how the things that are new/different about ES6 are more similar to typescript and coffeescript than ES5.Careful though: Libraries like jQuery and D3 can and/or do rebind `this` and that can be a gotcha in both TypeScript and straight ES6. You can end up having to mix both declaration styles, which is gross.
With an object, I can use a console log or a debug break point and immediately see the key value pairs (hopefully well-named) without having to check the function implementation or docs to see in which order the authors decided to return (or yield, etc.) values.
Can we just agree now not to use array destructuring as an excuse for returning multiple disparate values in an array? Or at least in only some idiomatic form? [error, value] would actually make sense to me, as it follows popular Node conventions.
The solution is the same: named return values, with object restructuring.
I've seen many an ES6 blogger decide to use arrays in their examples. It's not quite so grievous in the context of a throwaway example, but for real world usage, it might be more costly to figure out a month or two down the road.
Otherwise, we fall into exactly the "boolean trap" that the author links away to. [1]
[1] http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-t...
I'm saying that functions should return either primitives or objects that have properties (or keys, since in JS all objects are just hashmaps) that uphold some appropriate abstraction, completely separate from whatever the variables might have been called inside the function body.
For example, the return object from some function `getDate()` might have a .year property, or .toUnix method, etc.
If all I'm given is an array of arbitrarily typed values, I have solely the array indexes and values (or to go to the docs or implementation) to clue me into the semantic meaning of what was returned.
What's happening is that this expresion:
where obj is an object will assign obj.error to error and obj.value to value.You could name your locals something else if you wanted, of course:
will assign obj.error to myError and obj.value to myValue. There just happens to be a shorter syntax for the common case.(defun foo () (values 1 :quux))
(+ (foo) (foo)) => 2
(multiple-value-bind (x y) (foo) (print y)) => :foo
If you are returning an explicit aggregation like an array then it's not true multiple value return in my opinion.
https://github.com/nzakas/understandinges6
1 - http://kangax.github.io/compat-table/es6/ (Note: Opera, Safari, and iOS8)
This is pretty much what happened with ES5, right?
And what happens with browsers on older mobile phones that cant be upgraded ? you let your scripts stop working ?
If you think you can switch to ES6 in 6 month without any kind of transpilation, while keeping a good browser compatibility good luck ...
> This is pretty much what happened with ES5, right?
No,5 years after the launch of ES5 some browsers like Safari still didn't support some ES5 features. And some browsers on handsets will never support ES6.
> And what happens with browsers on older mobile phones that cant be upgraded ? you let your scripts stop working ?
If I was absolutely worried about browser support on older mobile phones, I'd be still writing vanilla JavaScript with no features that aren't in Ecmascript 3. You'll have to drop support eventually. Plus, it's very likely a good chunk of the ES6 I'll be writing will only ever be intended for running in browsers that support other cutting-edge features like WebGL, Web Workers and WebRTC, or on a fairly up to date environment like iojs or node.js.
> No,5 years after the launch of ES5 some browsers like Safari still didn't support some ES5 features.
I'm not sure which features Safari is missing that you're referring to. Safari on both iOS and OS X are missing a lot of Javascript APIs, but both have fully supported ES5 since at least 2011 [0], and my old Macbook with Safari 5.1 has no problems running modern websites.
> If you think you can switch to ES6 in 6 month without any kind of transpilation, while keeping a good browser compatibility good luck ...
A lot of ES6 features are already being polyfilled (Typed Arrays have been polyfilled for years), plus you can use try/catch to support new syntax whilst also supplying some sort of fallback.
[0] http://kangax.github.io/compat-table/es5/
I am already thinking ahead, ES7 is definitely going to be the pinnacle of the language I think. The implementation of a native Object.observe() means we will not have to worry about poor implementations in SPA frameworks like Angular that currently use dirty checking and other hacks to make up for the lack of native object observing. Lets hope the yearly release cycle proposed for Javascript specifications means ES7 happens sooner rather than later.
We have classes in ES6 (which is great), but they are currently nothing more than syntactic sugar over the old tried and tested prototypical inheritance. There are plans to add statics, private/public variables and classes to further extend them beyond just eye candy which they currently are. Plus Async/Await, Typed Objects, etc. There are also plans to better supported multithreading without the need to use WebWorkers which are pretty limited in their use.
Get excited. ES6 is only the beginning of a great suite of changes coming to Javascript. We'll eventually weed out the hacks and non-pretty parts of Javascript one specification at a time.
A good example is Facebook's Hack language that improve PHP in a sensible way and adds optional typing - something that would be great for ES6/7.
Necessary? No. But look around at Javascript projects, and see how many "reinventions" of simple inheritance you see. Often poorly done and/or buggy. Even more often they're hopelessly inconsistent.
What a lot of the ES6 changes does is codify ways of doing what "everyone" has been doing in mutually inconsistent ways.
I think it was. Using the class syntax gives a semantic meaning to the code that propotype wasn't. And if you think it was, then what was the point of typing again and again MyClass.prototype.<> ?
Refactoring Javascript code was a pain, and an excessive identifier redundancy was part of it.
Yes. Now your editor/IDE knows that that thing is supposed to be a class. The doc generator also knows that it's a class. Furthermore, this makes things more compatible since framework A and library B use the same kind of classes.
Finally, it means that you won't have to waste time with evaluating a dozen semi-popular options to handle classes/inheritance.
It does of course also make your code a lot easier to read and it makes it easier for new developers who used some other language with classes before.
> Hopefully ES7 doesn't get the verbose syntax of Java/C#.
I recommend to take a look at TypeScript and Dart. Optional types aren't verbose. You just add some types to the surface area, which, compared to JSDoc, is drastically less verbose. Inside functions, you can generally omit the types.
A good example is Facebook's Hack language that improve PHP in a sensible way and adds optional typing - something that would be great for ES6/7.
In comparision the Java/C# type is static at compile time. Newer C# version have like e.g. Visual Basic 6 a variant type that is a tradeoff (as wasteful as a "union struct" in C).
The class syntax in ES6 is just syntactic sugar. JS IDEs like WebStorm/PHPStorm/IDEA already can parse "classes" with JS5 syntax .
But what about the arrow syntax:
Or the iterator syntax that ES6 got from TypeScript:Is the assumption now that browsers largely auto-update that it won't be so long before that happens? Why are breaking syntax changes not a big deal, whereas "use strict" was done as a string so older browsers would ignore it?
Edit: backwards compatibility -> forwards
For browsers, yes, compatibility means we have to transpile. But the day you need not isn't necessarily so far-flung. Like you say, browsers largely auto-update and, after a slow start, they are implementing ES6 features at a good pace. The ES6 compatibility table[1] shows the progress already made. Only WebKit is really lagging. IE.next/Spartan is actually leading the pack, and coupled with Microsoft's plan to give away Windows 10 free to Windows 7 and 8 users, it gives good hope for the future.
Also, transpilation can be a gradual strategy for converting code. The Babel (née 6to5) authors have stated their intention to keep supporting new JS features as they are added to future versions of the EcmaScript standard. I think we'll soon see Babel able to be used like Autoprefixer, which selectively adds vendor prefixes to CSS based on browser support statistics and a developer-specified target configuration like "last 2 versions" or "> 5%".
[1] http://kangax.github.io/compat-table/es6/
New syntax, on the other hand, can be added without breaking existing code. These new constructs would have been syntax errors beforehand.
The web needs increased consistency and cohesion in the HTML/CSS/JS triumvirate.
ES6 seems like a grab-bag of neat and fun new features that end up doing a whole lot of nothing for large projects that have to care about more tangible concerns than nicer ways to create anonymous objects.
Some of the new features of ES6 - Symbols, proxies, Object.observe, et cetera - seem to make it downright easier to write even more confusing code. Instead of increased rigor and tools for building better software, we get stuff like this:
While I think it makes sense to stick with TypeScript for the foreseeable future, I do look forward to The Next JavaScript.However, I can't help but wonder if that's due to a mild case of Stockholm Syndrome setting in.
Actually, they're things that actual users of javascript have been asking for (and implementing hacked-up solutions for) for a long time. There's a reason Coffeescript is often referred to as "a better javascript" and Typescript is considered its own thing.
Javascript is a dynamic language, and will never make the transition to a static one. Its users don't want a static language - the people who want a static language are using things like TypeScript.
Never say never. Typed structures are a proposal, and what make you think that we'll never see flow types in the standard someday ? Javascript will always give the upper hand to dynamic typing, but I can see it becoming a kind of hybrid language, where both dynamic and static codes can coexist.
...or use a better language.