Jump to content
Search Community

Webpack issue with *club greensock* plugins

ad_bel test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

@OSUblake - well you can use tokens - I have used this in a production app: https://github.com/auth0/node-jsonwebtoken but that's assuming you have a backend system that already does the authentication. In my case it was used to secure the client since the single page app was stateless.


You probably should look at: https://auth0.com/ and would have to run one of their packages like: https://github.com/auth0/node-auth0


I think what you would probably do is generate a token when someone subscribes (or renews) and then set the expiry 1 year from then. They would just use that token and you would write a bit of code to validate it before serving up the files. You can then manage all the users manually in the Auth0 dashboard. As far as pricing, I don't know how many users you have but it looks like the first 7000 are free: https://auth0.com/pricing

  • Like 1
Link to comment
Share on other sites





Well I can honestly say I know zero about writing high performance based animation libraries :) But I'm not sure why a packaging system would hurt that? End of the day its still javascript and your code is not changed




This is a different conversation. It really depends on who your customers are. TBH when you do a new release, your features are pretty much irrelevant to me because I don't even know how to use probably 10% of what you already have lol. I mainly upgrade for bug fixes and performance enhancements (that may or may not be documented). Out of curiosity who are the primary greensock users? Animators I would assume? Are there many UX developers? 


Remember this conversation? 

This is what *I* really want greensock to be i.e. and animation library for UX developers (what Flash was). There are tons of animation libraries out there i.e. velocity, anime etc... but none of them do this. If you are successful, then I could live with manually putting everything together because it is a game changer. Now if your customers don't need this and that's not your target market then fair enough but I can assure you there is a demand for this. When someone eventually does this I will move to that product.   




Yep it changes and it changes fast. Just the nature of the business we are in ...but I think that's a good thing because we have lots of options and our products get better if you are willing to embrace change of course. As far as the technologies you mentioned: You can omit Angular/React/Vue because they can write wrappers to use your code. In the future you should have official support for those however, because you will see new customers come in droves. That can come down the road. Webpack is to packaging what jquery was to javascription dom manipulation. It's dominant and good at what it does. Will it change... it's inevitable but so will all web based technology.


As far as the big companies coming in, I agree you shouldn't operate in fear rather focus on making your product better. If it's the best then people will use it (word gets out fast on this internet thing! ;) )


@danehansen mentioned some good points about the code quality. If you are going to upgrade it, then you have an opportunity to go to es6 modules. Although this is a painful hit up front it will make life so much easier down the road. Also he also pointed out, the better the code is at understanding/reading the more you can have the community help make it better (especially true of the public components). This is more important that adding another *wiggle* effect... although those are very cool :)




Totally different approach but maybe another option is to completely skip the paid thing and move to a patron model? Many open source libraries that have strong followings are successfully doing this now . Having said this it may not make sense for you with an already strong customer base but just throwing it out there. The patrons would get perks like you get now, plus priority support, chat channels etc..





  • Like 3
Link to comment
Share on other sites

i think the performance concerns are probably related to the babel side of things? those are definitely to be considered. babel does not always convert stuff into vanilla js in the most efficient manner. but utilizing webpack does not mean having to use babel. you can still write vanilla js that wont be touched. in this case webpack would only be adding a very thin wrapper to handle the imports/exports. also as far as moving to new build systems (browserify to webpack etc...) if you had jumped on browserify, you wouldn't need to rewrite any code, with the possible exceptions of the import/export statements. if/when webpack goes anywhere, it will be because something else solves that problem better and you will still be able to leave almost all code untouched. the rewriting would just be in config files for the build process.

  • Like 1
Link to comment
Share on other sites

@danehansen yep, the concern was primarily about transpiling, like Babel, spitting out inefficient/bloated code. When I work close to the metal, I have much better control of that. But it's good to know that I can just go with ES6 modules in plain JS and leverage Webpack without doing transpiling. 



Who are our customers? 

It's all over the map, of course, but I'd say we cater primarily to the elite, top-notch animators out there who build crazy stuff that wins awards. GSAP solves a ton of problems that the average jQuery.animate() user would never even know about because they only do rollovers and simple stuff. When folks outgrow Velocity/jQuery/Anime/CSS, they realize how valuable GSAP is. But it ain't a perfect fit for everyone, and that's okay. 


Animation library for UX developers

I kinda thought that's what GSAP already is, although not so much in a cookie-cutter "slap this CSS in your stuff and it'll magically apply this canned effect" way. We try to build our tools in a way that allows for a ton of flexibility. After all, that's what the top animators tend to prefer. They don't want canned effects. They wanna be able to be super artistic. 


Can you elaborate a bit on what would be different about GSAP if it suddenly became the "animation library for UX developers"? Are you looking for a set of widget-like tools that'd let you quickly, for example, flip between pages, drag-n-drop lists, deliver wiz-bang hamburger menus with morphing, etc., all with just a few lines of code? 



It's a cool idea, to be sure, and it's a great fit for many projects. Not ours, though. There are some liabilities that make it pretty unattractive for what we're aiming to do. I'm sure you've seen this: https://greensock.com/why-license/ which explains some of our thinking (though not specifically about the patron model). I really do appreciate the suggestions, though. 


Oh, and that auto0.com stuff looks interesting, though it'd be pretty expensive for us. We'd need to look more into how exactly it could be integrated with our existing system. Very well  may be a good option once 2.0.0 is ready. 

  • Like 1
Link to comment
Share on other sites

  • 3 months later...

Hi, I am new to GreenSock, to be honest integrating your library and your extra plugins in a nextjs setup or even a standard npm/react/webpack environment seems a bit scary.

It is a pity because your library and your community are great.

Private npm repo cost very little (7$) they even are free when self hosting (verdaccio). We can even depends on local modules with npm. So it would be great to package club greensock plugins as npm module ready to depend on (locally or self hosted or private hosted somewhere).

  • For you: it is little to zero extra work (you already maintain a npm package for GreenSock "core")
  • It would be better for handling compatibility issues between plugins/core
  • For us: we would have one single repo to maintain/upgrade with your new releases
  • It would be better than putting all GreenSock stuff in src (where babel compilation occur) or node_modules (which can be cleaned and regenerated) 

(Off-topic) about reactjs, the integration seems feasible, some threads on this forum are very interesting on the topic. But the lack of an official integration guide or official wrapper (there is an unmaintained attempt) is a bit scary, and requires from your user a deep understanding of react internals to make it work.

Link to comment
Share on other sites

@littlegreengeek welcome to the forums!


A private NPM repo wouldn't solve the problem. How could we manage access? When someone's membership expires, would we have to manually update credentials? Yikes. And establishing the flow of user info in and out of that system seems pretty daunting (if it's even possible). See what I mean? 


Thanks for the feedback/suggestion about the React integration stuff. Fair point. We'll look for ways to shore that up, though we're pretty focused elsewhere at the moment.


Happy tweening! Let us know if you run into any other issues. 

  • Like 1
Link to comment
Share on other sites

  • 2 years later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...