GSAP ES06 / ES2020 Modules

[iDad5]

I started using ES06 modules in one or the other project some time ago but in most of my cases and with the way I work and tick it wasn't really a great improvement so I didn't make it my 'default'.

With the possibility of dynamic imports in ES2020 (https://caniuse.com/?search=dynamic import()) I think I want to make it my 'default' now.
With the help of the Install Page (https://greensock.com/docs/v3/Installation) I'm sure I can/will figure out how to do it, I already can see however that the import statements in a pure ES Module setup without build tools will have to have the '.js' extension in from, which I couldn't see mentioned at the install page...

 

Would others also  be interested in a dedicated  description on how to use GSAP with pure JS ESModules without the use of a build system? And would the team consider adding such a description to the install page?

I am a big fan of working as close a possible with the 'pure' standards and hate to rely on to many tools that I have to keep track of etc. and I know, that I'm a bit odd that way. But I feel it is a good thing to move forward as standards and browser support evolves.

And I think "promoting" that proved to be a good thing in the past, even if it requires some getting used to. 


 

[SteveS]

Do you mean this?

 

<script type="module">
	import {gsap} from "<url>/gsap.min.js"
</script>

Just make sure you are using files from the ESM folder in the GSAP download.

I'm not sure what you mean about having the .js extension. I'm under the impression it is necessary.

[iDad5]

That is what I meant. and yes it is necessary - it's jut not mentioned (as far as I could find it) at the install page.

 

It's probably just me, but I guess that a lot of younger (?) programmers just go through all the trouble of npm packaging and what-not, partly because the web is so full of examples and use cases.
Oftentimes I feel it ist totally unnecessary to go down that road (nowadays at least). If you look around the forum a lot of questions are being asked, because those 'magic'-tools in the don't work as expected.
Going the road of native JS modules (and promoting it) can be a way of giving back some control and help to understand that no magic is needed.

[Cassie]

Hmm. I'm interested to hear other people's input here. IE was always the big drawback to using modules like this, but I guess now it's dead it seems like a valid approach, at least according to caniuse?

People do already get confused enough with all the ways to install GSAP, I'm cautious to add another to the mix unless it's genuinely going to be widely used and help people. Currently most people tend to either use script tags or build tools. I'm not sure how many people are actually using modules out in the wild like this at the moment.

[iDad5]

I know, I know...

 

But it's a bit of a 'chicken or the egg' thing. As long as it's hard to use - aka: not easy to google - the interest will be slow to build.

 

But I try to tamper down my missionary tendencies. *ohhhhmmmm* 

[GreenSock]

5 hours ago, Cassie said:

People do already get confused enough with all the ways to install GSAP, I'm cautious to add another to the mix unless it's genuinely going to be widely used and help people. Currently most people tend to either use script tags or build tools. I'm not sure how many people are actually using modules out in the wild like this at the moment.

I couldn't agree more. 

 

@iDad5 I use the approach locally myself (loading module files directly in a <script type="module"> tag with no build tool) but...

• Usually people want minified files to deploy but the standard module files are not minified, thus they're bigger.
• It's highly unusual (from my read on things at least) for developers to use GSAP in isolation, at least in module environments where people are using "import" statements. It's almost always in a context like React, Vue, Angular, Nuxt, Next, Three.js or other tool. I'm not confident that they all offer easy module files to consume in the way you're suggesting here, so a build tool is likely needed anyway (in those contexts). So it just doesn't seem very likely that many people would use GSAP the way you're suggesting. It'd be weird to have one way of importing GSAP and a totally different way for all the other JS dependencies.
• Build tools are often leveraged to ensure that everything is compiled down to a particular browser target level compatibility-wise. There may be ES7+ features, for example, that don't have great browser support which the transpiler smooths over. GSAP doesn't use any crazy newfangled syntax or features, but I can't say that for sure with other libraries that may be used in conjunction so I just don't feel super confident recommending this "directly load the raw ES Modules into the browser" approach. 
• Most importantly, as Cassie said, adding yet another [relatively uncommon] way of installing GSAP on a page that already seems overwhelming for people...well, that sounds like it may hurt more than it helps. 

My assumption is that guys like you who may want to use it this way already know how to do it and don't need to be hand-held on the installation page. 

 

My 2 cents.