Smalltalk › Amber Smalltalk

require.js shims: are they necessary?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Jeremy Shute-2

require.js shims: are they necessary?

Hi,

I have a skeletal require.js project that imports Amber through bower and demonstrates the following abilities:

It lets you hack on your module(s) with Helios via a development configuration.
It lets you try out the resulting Javascript (without a compilation step) via a deployment configuration.
It lets you compile and minify the deployment configuration and load it with almond; in other words it lets you package the entire system as one script.

The working example is here:

https://github.com/shutej/amber-example

I am now in the process of trying to figure out how to load this stuff via a bookmarklet (just to muddy the waters a bit more). The following code doesn't work:

http://pastebin.com/1bgedRHw

...because when support/amber.js loads, it finds the script tag I'm loading AFTER it support/amber.js, and computes relative paths from that instead of itself.

Also note that my example had to repeat much of the configuration in support/amber.js within the Gruntfile. As this is not kept in sync with the main repository, this method will be very fragile as Amber continues to develop.

This leads me to wonder whether all this shimming and configuring is necessary at all? If I went about creating relative path configurations, would something in the Smalltalk compiler need to be changed as well?

I think this is a major barrier to entry for new developers, especially developers who want to interoperate with the existing ecosystem of Bower modules.

Jeremy

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Herby Vojčík

Re: require.js shims: are they necessary?

Hi,

amber.js is not needed at all. You can load amber piece by piece, every part is AMD module with well-known path (so just map the virtual folders and go).

But it is much easier to use amber.js to do the these amber-related mappings for you. It is its only role.

It uses the 'find the last script tag' method to find out its path, which is AFAIK pretty known trick. Yes, for it to work, amber.js must not be loaded asynchronously (all the rest can). So just don't load it asynchronously, I would say.

Or issue a patch which tries different methods of looking for itself. It looks for itself to be able to 1. find data-libs, 2. do the mappings relatively to its own position (which is exactly to support bower deployments).

Herby

P.S.: What is the problem with shims?

Jeremy Shute wrote:
> Hi,
>
> I have a skeletal require.js project that imports Amber through bower
> and demonstrates the following abilities:
>
> 1. It lets you hack on your module(s) with Helios via a developm
ent

> configuration.
> 2. It lets you try out the resulting Javascript (without a
> compilation step) via a deployment configuration.
> 3. It lets you compile and minify the deployment configuration and
> load it with almond; in other words it lets you package the entire
> system as one script.
>
> The working example is here:
>
> https://github.com/shutej/amber-example
>
> I am now in the process of trying to figure out how to load this stuff
> via a bookmarklet (just to muddy the waters a bit more). The
> following code doesn't work:
>
> http://pastebin.com/1bgedRHw
>
> ...because when support/amber.js loads, it finds the script tag I'm
> loading AFTER it support/amber.js, and computes relative paths from
> that instead of itself.
>
> Also note that my example had to repeat much of the configuration in
> support/amber.js within the Gruntfile. As this is not kept in sync
> with the main repository, this method will be very fragile as Amber
> contin

ues to develop.

>
> This leads me to wonder whether all this shimming and configuring is
> necessary at all? If I went about creating relative path
> configurations, would something in the Smalltalk compiler need to be
> changed as well?
>
> I think this is a major barrier to entry for new developers,
> especially developers who want to interoperate with the existing
> ecosystem of Bower modules.
>
> Jeremy
>
> --
> You received this message because you are subscribed to the Google
> Groups "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email].
> For more options, visit https://groups.google.com/groups/opt_out.

Jeremy Shute-2

Re: require.js shims: are they necessary?

I should be more specific. I am concerned mostly about the number of virtual folders. It'd be nice if your Gruntfile.js could map amber with the confidence that everything amber-internal uses references therein.

Also, this leads to a question of how you guys see people deploying with Amber.

Do you expect that they will fork the repo and add their edits, then periodically rebase on origin/master?

Or do you expect that they will write a bower configuration and a Gruntfile.js that refers to Amber?

Whether or not the technique for "script" is well-known, it would be nice if you could simply "require" the things in Amber without a config (or with a minimal config that is unlikely to change over time as the number of virtual folders change).

Jeremy

On Tue, Dec 17, 2013 at 11:52 AM, Herby Vojčík <[hidden email]> wrote:

Hi,

amber.js is not needed at all. You can load amber piece by piece, every part is AMD module with well-known path (so just map the virtual folders and go).

But it is much easier to use amber.js to do the these amber-related mappings for you. It is its only role.

It uses the 'find the last script tag' method to find out its path, which is AFAIK pretty known trick. Yes, for it to work, amber.js must not be loaded asynchronously (all the rest can). So just don't load it asynchronously, I would say.

Or issue a patch which tries different methods of looking for itself. It looks for itself to be able to 1. find data-libs, 2. do the mappings relatively to its own position (which is exactly to support bower deployments).

Herby

P.S.: What is the problem with shims?

Jeremy Shute wrote:

Hi,

I have a skeletal require.js project that imports Amber through bower and demonstrates the following abilities:

1. It lets you hack on your module(s) with Helios via a developm

ent

configuration.
2. It lets you try out the resulting Javascript (without a

compilation step) via a deployment configuration.
3. It lets you compile and minify the deployment configuration and

load it with almond; in other words it lets you package the entire
system as one script.

The working example is here:

https://github.com/shutej/amber-example

I am now in the process of trying to figure out how to load this stuff via a bookmarklet (just to muddy the waters a bit more). The following code doesn't work:

http://pastebin.com/1bgedRHw

...because when support/amber.js loads, it finds the script tag I'm loading AFTER it support/amber.js, and computes relative paths from that instead of itself.

Also note that my example had to repeat much of the configuration in support/amber.js within the Gruntfile. As this is not kept in sync with the main repository, this method will be very fragile as Amber contin

ues to develop.

This leads me to wonder whether all this shimming and configuring is necessary at all? If I went about creating relative path configurations, would something in the Smalltalk compiler need to be changed as well?

I think this is a major barrier to entry for new developers, especially developers who want to interoperate with the existing ecosystem of Bower modules.

Jeremy

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Nicolas Petton

Re: require.js shims: are they necessary?

Hi!

Jeremy Shute writes:

> I should be more specific. I am concerned mostly about the number of
> virtual folders. It'd be nice if your Gruntfile.js could map amber with
> the confidence that everything amber-internal uses references therein.
>
> Also, this leads to a question of how you guys see people deploying with
> Amber.
>
> Do you expect that they will fork the repo and add their edits, then
> periodically rebase on origin/master?

Forking Amber to use it with your own packages is not a good idea.
Your packages should require amber and load it as a library. One of the
purposes of using AMD was to make it easier for user to use Amber as a
library, and not making people fork it.

Using bower is indeed the way to go.

Cheers,
Nico

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Herby Vojčík

Re: require.js shims: are they necessary?

In reply to this post by Jeremy Shute-2

Jeremy Shute wrote:
> I should be more specific. I am concerned mostly about the number of
> virtual folders. It'd be nice if your Gruntfile.js could map amber with
> the confidence that everything amber-internal uses references therein.
>
> Also, this leads to a question of how you guys see people deploying with
> Amber.
>
> Do you expect that they will fork the repo and add their edits, then
> periodically rebase on origin/master?

I have little problems deploying amber. My project uses bower, includes
amber as a dependency, and in the page (one-page app), amber.js is
loaded. It takes care of all the amber virtual folder and their
mappings, so I do not need to change anything in my project even if
internals of amber change (and they likely will).

The rest (amber itself, libraries, and code of the project itself) is
loaded with require.js.

Is this not applicable for you (if you really, really need to load
amber.js anychronously not by inlint <script>, I issued a pullreq that
allows it to load async, as well, I mentioned it on IRC if you were online)?

> Or do you expect that they will write a bower configuration and a
> Gruntfile.js that refers to Amber?

I confess I am not using grunt in my project, I don't need to. Vut even
if I used it for something, this would IMO noi change the point - just
load amber.js and you're ok.

If it's problematic (even with the async-loadable patch), I'd like to
know what is really the problem.

> Whether or not the technique for "script" is well-known, it would be
> nice if you could simply "require" the things in Amber without a config
> (or with a minimal config that is unlikely to change over time as the
> number of virtual folders change).
>
> Jeremy

Herby

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Jeremy Shute-2

Re: require.js shims: are they necessary?

BTW, I really admire this system so far. I'm a Smalltalk fan, and Helios is just great so far. The keybindings are actually a big improvement over the Pharo UI, even. It feels good!

So don't think anything I've said is a criticism, I'm just approaching this as a n00b and trying to share my confusions with you guys so you have some of this perspective.

So, now we can asynchronously load amber.js, which is an improvement. Especially for me, because I'm embedding my app in a bookmarklet. So this is a step in the right direction and definitely helps (thank you).

However, now I've started using my own maps. So I'm using require-less to pull in styles that live alongside my saved packages. But require.js seems to only support one config ... or perhaps I don't understand it well enough to make it support more.

The idea is that Amber has one set of configuration that I shouldn't care about (which I agree with) ...

...and my app has a set of configuration that it's going to use in order to pull in Amber, my packages that extend Amber, my stylesheets, and compile the whole thing into a single file for deployment.

This is the piece I'm currently missing. And, if I get it, I'm happy to continue extending my own example documentation so that it can be explained to others, which I think would be really helpful.

Jeremy

On Fri, Dec 20, 2013 at 7:24 AM, Herby Vojčík <[hidden email]> wrote:

Jeremy Shute wrote:

I should be more specific. I am concerned mostly about the number of
virtual folders. It'd be nice if your Gruntfile.js could map amber with
the confidence that everything amber-internal uses references therein.

Also, this leads to a question of how you guys see people deploying with
Amber.

Do you expect that they will fork the repo and add their edits, then
periodically rebase on origin/master?

I have little problems deploying amber. My project uses bower, includes amber as a dependency, and in the page (one-page app), amber.js is loaded. It takes care of all the amber virtual folder and their mappings, so I do not need to change anything in my project even if internals of amber change (and they likely will).

The rest (amber itself, libraries, and code of the project itself) is loaded with require.js.

Is this not applicable for you (if you really, really need to load amber.js anychronously not by inlint <script>, I issued a pullreq that allows it to load async, as well, I mentioned it on IRC if you were online)?

Or do you expect that they will write a bower configuration and a
Gruntfile.js that refers to Amber?

I confess I am not using grunt in my project, I don't need to. Vut even if I used it for something, this would IMO noi change the point - just load amber.js and you're ok.

If it's problematic (even with the async-loadable patch), I'd like to know what is really the problem.

Whether or not the technique for "script" is well-known, it would be
nice if you could simply "require" the things in Amber without a config
(or with a minimal config that is unlikely to change over time as the
number of virtual folders change).

Jeremy

Herby

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

baulamon

Re: require.js shims: are they necessary?

In reply to this post by Jeremy Shute-2

Hello,
I think this is a major barrier to entry for new developers, especially developers who want to inter operate with the existing ecosystem of Bower modules.

Herby Vojčík

Re: require.js shims: are they necessary?

In reply to this post by Jeremy Shute-2

Jeremy Shute wrote:
> So, now we can asynchronously load amber.js, which is an improvement.
Well, I do not believe it is. It opens Pandora's box of race conditions. You must wait for it to load (and do the requirejs mapping) before you can load amber, so in fact it is the wisest to load it synchronously.

> Especially for me, because I'm embedding my app in a bookmarklet. So
> this is a step in the right direction and definitely helps (thank you).
>
> But require.js seems to only support one config ... or perhaps I
> don't understand it well enough to make it support more.
You can call require.config as many times as you wish and it gets merged.
That's what normally happens in all amber pages - amber.js does one part of config, inline <script> that loads amber and your packages, does another map (for your own code and for libraries), and then just happily calls require(['amber/devel', ...], function (smalltalk) { ... }) to load and start.

> The idea is that Amber has
one set of configuration that I shouldn't

> care about (which I agree with) ...
>
> ...and my app has a set of configuration that it's going to use in
> order to pull in Amber, my packages that extend Amber, my stylesheets,
> and compile the whole thing into a single file for deployment.
>
> This is the piece I'm currently missing. And, if I get it, I'm happy
> to continue extending my own example documentation so that it can be
> explained to others, which I think would be really helpful.
>
> Jeremy

Herby

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Manfred Kröhnert

Re: require.js shims: are they necessary?

In reply to this post by Jeremy Shute-2

Hi Jeremy,

On Tue, Dec 17, 2013 at 6:30 PM, Jeremy Shute <[hidden email]> wrote:

I should be more specific. I am concerned mostly about the number of virtual folders. It'd be nice if your Gruntfile.js could map amber with the confidence that everything amber-internal uses references therein.

Also, this leads to a question of how you guys see people deploying with Amber.

Do you expect that they will fork the repo and add their edits, then periodically rebase on origin/master?

as Nico and Herby already said, people should use Amber release versions through bower packages.

Forking Amber to include it in your project is not a good idea.

But only since the introduction of require and bower components it is truly possible to add Amber as a real dependency to your projects.

Or do you expect that they will write a bower configuration and a Gruntfile.js that refers to Amber?

You do not need to use Grunt at all to write Amber applications.

Therefore, the Gruntfile.js and the 'npm install' step is not required in your example application.

You only need a Gruntfile.js if you want to recompile the .st files to .js files on the commandline.

This can also be achieved by using amberc directly but the Gruntfile.js can be regarded as a 'Makefile' in this case.

Maybe we need to clarify this even better since there is a tendency to confuse the differences between using Amber with bower or npm.

Best,

Manfred

Whether or not the technique for "script" is well-known, it would be nice if you could simply "require" the things in Amber without a config (or with a minimal config that is unlikely to change over time as the number of virtual folders change).

Jeremy

On Tue, Dec 17, 2013 at 11:52 AM, Herby Vojčík <[hidden email]> wrote:

Hi,

amber.js is not needed at all. You can load amber piece by piece, every part is AMD module with well-known path (so just map the virtual folders and go).

But it is much easier to use amber.js to do the these amber-related mappings for you. It is its only role.

It uses the 'find the last script tag' method to find out its path, which is AFAIK pretty known trick. Yes, for it to work, amber.js must not be loaded asynchronously (all the rest can). So just don't load it asynchronously, I would say.

Or issue a patch which tries different methods of looking for itself. It looks for itself to be able to 1. find data-libs, 2. do the mappings relatively to its own position (which is exactly to support bower deployments).

Herby

P.S.: What is the problem with shims?

Jeremy Shute wrote:

Hi,

I have a skeletal require.js project that imports Amber through bower and demonstrates the following abilities:

1. It lets you hack on your module(s) with Helios via a developm

ent

configuration.
2. It lets you try out the resulting Javascript (without a

compilation step) via a deployment configuration.
3. It lets you compile and minify the deployment configuration and

load it with almond; in other words it lets you package the entire
system as one script.

The working example is here:

https://github.com/shutej/amber-example

I am now in the process of trying to figure out how to load this stuff via a bookmarklet (just to muddy the waters a bit more). The following code doesn't work:

http://pastebin.com/1bgedRHw

...because when support/amber.js loads, it finds the script tag I'm loading AFTER it support/amber.js, and computes relative paths from that instead of itself.

Also note that my example had to repeat much of the configuration in support/amber.js within the Gruntfile. As this is not kept in sync with the main repository, this method will be very fragile as Amber contin

ues to develop.

This leads me to wonder whether all this shimming and configuring is necessary at all? If I went about creating relative path configurations, would something in the Smalltalk compiler need to be changed as well?

I think this is a major barrier to entry for new developers, especially developers who want to interoperate with the existing ecosystem of Bower modules.

Jeremy