8:37 a.m.
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.
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.
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...
I think as a mobile library, we need to not add extra overhead.
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.
8:52 a.m.
On Tue, Jan 6, 2015 at 3:37 PM, Lucas Holmquist <lholmqui(a)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(a)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
9:45 a.m.
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(a)apache.org>
wrote:
On Tue, Jan 6, 2015 at 3:37 PM, Lucas Holmquist <lholmqui(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3639
days inactive
3639
days old
2 comments
3 participants
participants (3)
-
Lucas Holmquist -
Lukáš Fryč -
Matthias Wessendorf