ES2015+?

[johnd0e]

It's 2019, and ES2015+ features supports is getting better among modern browsers.
Several patches from #2 already using some (mostly let/const).

So it would be great if we decide which of the features are 'safe' to use in whole project.
But to select particular features we need to consider target platforms of IITC, as some of them could be limited.

Perhaps most universal approach would be to:

• Include some transpilling tool in our build chain.

[modos189]

Babel requires a node.js, which I would like to avoid.

I found a project that implements the Javascript interpreter on Python. As stated, he is not production ready, but it works.

And if there were no problems with connecting DukPy, I would prefer to choose TypeScript, not Babel. Because he too implements the capabilities of the new ES, but it also supports types.

[modos189]

https://github.com/amol-/dukpy

[johnd0e]

requires a node.js, which I would like to avoid.

I'm curious: why?
As we possibly also need other node.js-powered tools (such eslint, jslint, jshint, JSCS, webpack,...)

I would prefer to choose TypeScript.

Well, TypeScript may be excellent, but it is not subset of ES*, and there is no any direct browser support of it (and possible never be).
But option for using TypeScript would be great, as well as CoffeeScript (just example).

[johnd0e]

Anyway (whatever tool is finally chosen), I want to know if you are actually going to implement it in build chain soon?
Could I start using some of ES2015 features now, or better to wait when build chain get ready?

[modos189]

I don't want to use nodejs and npm because it's a huge additional dependency for the sake of just supporting the JS transpiler.

I tested DukPy and it doesn't suit us because of too low speed. At the same time, I really want to use at least ES2015. This standard is supported by all devices except Android < 5.0.

What if we use ES2015 for project, and for Android < 5.0 connect the browser version of Babel?

[johnd0e]

for the sake of just supporting the JS transpiler.

May be not just transpiler, but some other tools.

This standard is supported by all devices except Android < 5.0.

As far as I know not all the features of the standard is equally supported, so we should choose carefully...

What if we use ES2015 for project, and for Android < 5.0 connect the browser version of Babel?

Well, we should try.

P.S.
As for node.js.
Actually I do not think that this dependency is so bad, if it'll be optional.

I mean if the project could be built as is, and only with some additional flags building script will try to call node.js-related tools.

[johnd0e]

ingress-intel-total-conversion/external/Leaflet.GoogleMutant.js

Line 29 in 953519d

this._GAPIPromise = this._ready ? Promise.resolve(window.google) : new Promise(function (resolve, reject) {

[1valdis]

It's painful to see those vars already, I write all my code with let/const only even without usage of transpilers. I think you should consider versions of browsers you want to support and, as a result, the list of features that you'd allow to use. Also, I think it's better to still switch to Node with Babel. As @johnd0e suggested, it'd be possible to use linters and static code analyze tools like sonarjs, which can greatly improve code quality.

[modos189]

Which of the new JS features may we want to use that are not supported in all modern browsers? Now support for old standards we need only for Android before 5.0, such devices we have about 2%. So I want to know if it's better to dynamically connect babel only in old browsers, or better to transpile all iitc code with plugins? But if second, what to do with third-party plugins?

[johnd0e]

better to transpile all iitc code with plugins?

I'd prefer this option.
And I suppose that it can be supplementary 'compatibility' release.

(But honestly, this is not main problem of current iitc codebase)

[1valdis]

Dynamically adding Babel will add a lot of overhead to process and transpile all the scripts every time. In-browser Babel is mostly for prototyping. Production builds should be precompiled.

[johnd0e]

One more question: JS Promise vs jQuery.Deferred().

Promise is not part of ES5, that's why we begin to use jQuery.Deferred (iitc-project/ingress-intel-total-conversion#1163).

But refactoring of game_status.js/map_data_request.js/redeeming.js/request_handling.js/search.js/send_request.js/... will demand more extensive promises using, so we should decide whether to stick to jQuery's implementation, or switch to native JS's.