How important is ES2015 (ES6) support?

[cb1kenobi]

Should the next Titanium be built on ES6? In other words, should Titanium APIs, code examples, docs, tutorials, etc use ES6?

Should Alloy v2 be redesigned to be built on top of ES6?

How concerned should we be about forcing Titanium devs to learn ES6? If we start introducing ES6 into Titanium APIs, developers will need to learn ES6. For example, I could easily see Alloy controllers being ES6 classes. Extending the base controller will require knowledge of ES6.

Should ES6 support be mandatory for v1?

What ES6 features are most important?

Are you worried about JavaScriptCore's lack of ES6 implementation? It's currently about 35% coverage: https://kangax.github.io/compat-table/es6/#webkit. Firefox's Spidermonkey JS engine is almost double the support.

Are you OK with ES6 code being transcompiled down to ES5? (presumably via Babel: https://babeljs.io) Are you concerned about performance of the generated ES5 code?

[mattapperson]

@cb1kenobi lots of thoughts here, no real answer to your question(s) though :)

• I think JSCore is the right option as a default engine for v1 because it can be the same engine everywhere. This makes HAL and Hyperloop easier for new core community devs to help build and maintain
• I think longer term, being able to move between cores is important (compile more with hyperloop and use a lighter JS engine like ducktape. Or perhaps android one day releases a built in V8 engine making binaries MUCH smaller... we need to be able to move fast on that without a 100% core rewrite)
• ES6 is great, and I am not worried about nevs needing to learn it. The best JS devs what to and should learn it if they dont already.
• ES6 is not do or die for writing new code, as its not a new language or tool... its still just JS
• Using JSCore > a JS engine that supports es6 (again, for now)
• Having a transpile step I am normally not a fan of, but ES6 is just allowing us to compile code that will one day run as-is. This is a foregone conclusion. Perhaps this is a very good idea then? Not really sure.
• I am a fan of anything that makes Alloys controllers true classes/modules from a JS standpoint, not just a "its a module because we treat it as one".
• I am a fan of anything that lets us more easily extend a class in JS.Again ES6 allows this to be done in a language supported way. This is a major win vs a "Ti way" of doing this. In native development this is needed FAR more then web, it is invaluable. It is a must have IMHO

[yuchi]

I still have to catch up to the conversation here, but I placed both ti.current and ti.next labels because I think that’s a discussion relevant today.

[yuchi]

One question at a time!

Should the next Titanium be built on ES6? In other words, should Titanium APIs, code examples, docs, tutorials, etc use ES6?

IMHO yes. Thanks to Babel.js the future is now the present, and every major framework and community is jumping on it. We should embrace the future.

Should Alloy v2 be redesigned to be built on top of ES6?

Definitely yes. Even if it’s not a spec yet, using JSX would make the development of widgets way more clear. I’m not a proponent of the separation of the views in ‘too dumb’ template languages, and Alloy’s is a really dumb one.

How concerned should we be about forcing Titanium devs to learn ES6? If we start introducing ES6 into Titanium APIs, developers will need to learn ES6. For example, I could easily see Alloy controllers being ES6 classes. Extending the base controller will require knowledge of ES6.

We should not force them into ES6 for app code, but all the JS written in the core should be ES6.

Should ES6 support be mandatory for v1?

No, but transiplation must be supported, along with source maps for debugging and profiling.

What ES6 features are most important?

I don’t think that there are ES6 features we really need, a part for Promises and generators for better async code.

On the other side I’d be happy to import { Window } from 'titanium-core'.

Are you worried about JavaScriptCore's lack of ES6 implementation? […]

Yes. More precisely I’m worried about the terrible stric-mode implementation of JSC.

Are you OK with ES6 code being transcompiled down to ES5?

Not at all.

Are you concerned about performance of the generated ES5 code?

Yes and no. In Babel.js, for example, you can always opt out from a for of to a for (;;).

[yuchi]

Ti.Current developers can enjoy ES2015 (ES6) now with two different flavours:

• for Alloy there’s @dbankier’s JAST
• for Classic there’s @smclab’s Titaniumifier in host-mode

[yuchi]

To extend the list there’s also:

• for Classic there’s an experiment from @rblalock called es6_titanium_classic
• for Classic there’s also the experimental ti.babel from @dawsontoth

[yuchi]

Small note: all of those above depend on Babel.js.

Also none of those support debugging/profiling. I’m sure we can solve this in Ti.Current.

What are your thoughts on this, @cb1kenobi?