[aerogear-dev] Concern with es6 modules and AeroGear.js

[Lukáš Fryč]

TL;DR: agree with keeping the ES6 on the branch

---

Keeping aside the personal preference, I believe that ES6 modules have huge
potential in mobile applications space
since they are bringing so-needed structure and thus allow for compile-time
optimizations (that are even more crucial on mobile than on desktop).


But as Luke said, this is not feature that would talk to everyone.

What we got in ES6 branch is a solution that works for:
* global namespace users
* people preferring browser modules (AMD, but CommonJS is possible)
* people looking into the future with ES6

But how many people preferring one or another form of modules we can find?
I would agree with Luke's 10% of users considering the use of modules, and
fraction of it using in current projects.


Unless we won't be proved to be wrong and we find a community members
really trying the ES6 branch,
I would stay aside of it as suggested.

Our research definitely helped to prepare a path and if nothing else, it
helped me understand deeply both, the Aerogear.js code and its build
process.

On Tue, Jan 6, 2015 at 3:52 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Tue, Jan 6, 2015 at 3:37 PM, Lucas Holmquist <lholmqui at redhat.com>
> wrote:
>
>> for those of you don’t use http based email, i’m looking at you qmx and
>> abstractj,  this might be a little ugly
>>
>>
>>
>> I want to start off by saying that i think ES6 modules are cool and that
>> i like them.
>>
>> I think the concern that i have in their current state is that there is
>> to much "processesing" that needs to be done to make them work with
>> existing browsers.
>>
>> While this processing is done with automated grunt tasks, i feel that it
>> puts to much "extra" code in the library for not that much reward.
>>
>
> and therefore being slower than it should be right? legacy browsers ftw :)
>
>
>
>
>> Another concern with the processing is that it adds lots more development
>> dependecies. One of which is upgrading to npm 2.0, which wasn't as
>> straightforward as i was thinking.
>>
>
> ouch
>
>
>> I do want to commend Lukas, for all his hard work on the es6 modules
>> branch, Good Work My Friend!!
>>
>> As "developers on the edge"™ we are exposed to new shiny tech that we
>> want to use right away like modules, AMD, browserfy, etc...
>>
>> But i wonder about the other 90% and what they are looking for. Do they
>> even care about AMD, etc...
>>
> perhaps not, or not yet - especially when coming from "web development"
> for intranet apps, in traditional shops
>
>
>
>> I think as a mobile library, we need to not add extra overhead.
>>
>
> +9001
>
>
>
>> But i think we should keep working on the ES6-modules branch and keep it
>> up to date and direct people to that if they would like to try it.
>>
>
> I fully agree - also this is not throwing away work. This was a needed
> research, we came to a conclusion: not yet ready; but that does not mean,
> we won't be looking at it again, let's say in two years or so. times are
> changing fast.
>
> great job, Luke and Lucas!
>
>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150106/4768090a/attachment-0001.html