6:15 p.m.
As AeroGear.js gets larger and more complex, it makes sense to revisit our build strategy
as well as our dependency management strategy since that affects the build.
I was thinking, and after discussing with Luke I believe he agrees, that we should
investigate the use of AMD (Asynchronous Module Definition). What this provides for us
is:
Better modularization between the pieces of code in AeroGear.js
Better dependency management by specifically defining those dependencies in each module
A better base for our custom build process
I think all of those reasons point to the need for this implementation. That being said,
it doesn't come without a cost. We would need to reorganize the repo and modify each
file to make it a proper AMD module. This will take time but I think it is time well
spent.
I would be glad to hear if anyone has any thoughts or concerns around this.
7:47 p.m.
On 08/20/2013 12:15 PM, Kris Borchers wrote:
As AeroGear.js gets larger and more complex, it makes sense to
revisit
our build strategy as well as our dependency management strategy since
that affects the build.
I was thinking, and after discussing with Luke I believe he agrees,
that we should investigate the use of AMD (Asynchronous Module
Definition). What this provides for us is:
1. Better modularization between the pieces of code in AeroGear.js
2. Better dependency management by specifically defining those
dependencies in each module
3. A better base for our custom build process
I think all of those reasons point to the need for this
implementation. That being said, it doesn't come without a cost. We
would need to reorganize the repo and modify each file to make it a
proper AMD module. This will take time but I think it is time well spent.
I would be glad to hear if anyone has any thoughts or concerns around
this.
Any recommended reading?
What will the end user experience look like and how is it different than
the way aerogear.js is used now?
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
7:57 p.m.
On Aug 20, 2013, at 12:47 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 08/20/2013 12:15 PM, Kris Borchers wrote:
> As AeroGear.js gets larger and more complex, it makes sense to revisit our build
strategy as well as our dependency management strategy since that affects the build.
>
> I was thinking, and after discussing with Luke I believe he agrees, that we should
investigate the use of AMD (Asynchronous Module Definition). What this provides for us
is:
>
> Better modularization between the pieces of code in AeroGear.js
> Better dependency management by specifically defining those dependencies in each
module
> A better base for our custom build process
>
> I think all of those reasons point to the need for this implementation. That being
said, it doesn't come without a cost. We would need to reorganize the repo and modify
each file to make it a proper AMD module. This will take time but I think it is time well
spent.
>
> I would be glad to hear if anyone has any thoughts or concerns around this.
Any recommended reading?
Sure. I would take a look at this. Hopefully that would give some insight into AMD.
http://requirejs.org/docs/whyamd.html
What will the end user experience look like and how is it different than the way
aerogear.js is used now?
End-user experience should not change unless they want it to. The custom builder would
still give them the pieces they want via point-and-click or they can download the full
build just like they can now. However, this would also offer another option in that people
could include just the pieces of the library they want via require.js or similar build
tools/processes.
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:16 p.m.
I think that's a great idea. +1
Kris Borchers wrote:
As AeroGear.js gets larger and more complex, it makes sense to
revisit
our build strategy as well as our dependency management strategy since
that affects the build.
I was thinking, and after discussing with Luke I believe he agrees, that
we should investigate the use of AMD (Asynchronous Module Definition).
What this provides for us is:
1. Better modularization between the pieces of code in AeroGear.js
2. Better dependency management by specifically defining those
dependencies in each module
3. A better base for our custom build process
I think all of those reasons point to the need for this implementation.
That being said, it doesn't come without a cost. We would need to
reorganize the repo and modify each file to make it a proper AMD module.
This will take time but I think it is time well spent.
I would be glad to hear if anyone has any thoughts or concerns around this.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
11:17 p.m.
On Aug 20, 2013, at 16:03, Douglas Campos <qmx(a)qmx.me> wrote:
On Tue, Aug 20, 2013 at 11:15:05AM -0500, Kris Borchers wrote:
> I would be glad to hear if anyone has any thoughts or concerns around
> this.
So for me as an end user nothing changes right?
Like I said to Summers, only if they want it to. Everything can stay the same or if they
want to do the AMD thing as part of their process that's fine too.
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:03 a.m.
I like the idea, so +1.
On Tue, 20 Aug 2013 11:15:05 -0500
Kris Borchers <kris(a)redhat.com> wrote:
As AeroGear.js gets larger and more complex, it makes sense to
revisit our
build strategy as well as our dependency management strategy since that
affects the build.
I was thinking, and after discussing with Luke I believe he agrees, that we
should investigate the use of AMD (Asynchronous Module Definition). What this
provides for us is:
Better modularization between the pieces of code in AeroGear.js
Better dependency management by specifically defining those dependencies in
each module A better base for our custom build process
I think all of those reasons point to the need for this implementation. That
being said, it doesn't come without a cost. We would need to reorganize the
repo and modify each file to make it a proper AMD module. This will take time
but I think it is time well spent.
I would be glad to hear if anyone has any thoughts or concerns around this.
3909
days inactive
3910
days old
6 comments
6 participants
participants (6)
-
Bruno Oliveira -
Douglas Campos -
Karel Piwko -
Kris Borchers -
Kris Borchers -
Summers Pittman