Paid plugins in a tutorial repo, possible solutions?

[Artur]

Hi everyone,

 

recently I gave a short talk (around 10 minutes long) introducing GSAP and showing how nice it works with package bundlers (like Browserify, Webpack, etc.). I created accompanying intro animation for it so people would get better understanding of GSAP's capabilities and I could reference code chunks from it in my slides.The talk was in Polish but I'm going to re-record it in English and post on YT. Additionally I'd like to share the intro animation on GH in an open repo so people could examine and learn from it.

 

Note that I wouldn't like to use Codepen or a similar service as one of the main points is showing how to split large animations into smaller parts using timelines and Browserify.

 

Although the repo probably won't be open source (or at least – doesn't have to be), it doesn't make much difference in one regard: I've used 2 paid plugins (morphSVG + SplitText) and they would be publicly available this way. I'm well aware that I shouldn't do that.

 

2 solutions come to my mind now:

1. Share the repo but exclude plugins from it. It would still serve as a nice example but the obvious drawback would be the fact that the animation couldn't be built and played in a local environment.
2. Use basic substitutes. For example I could hardcode some <span> elements and use them instead of SplitText (easy and quick solution) and use frame-by-frame instead of morphSVG (not so elegant but would just work).

Currently I lean more towards the second solution unless... You've got some better ideas?

 

Please let me know your thoughts!

 

Thanks,

 

Artur

 

PS.

 

I'll post links for both the talk and animation once they'll be ready.

[GreenSock]

Thanks for helping to spread the word about GSAP. I also appreciate your sensitivity with the bonus plugins and not sharing them in your github repo. It's so nice to have customers like you who respect the work of other developers.

 

It's totally up to you, but I'd probably lean slightly toward option #1 as it keeps the fidelity to what you originally created and demonstrates the "real" code that accomplished what you were showcasing. Option #2 seems kinda like "look what these tools can do!...but I'll rework it in a less elegant, more verbose way and share that version with you"  

 

Actually, a 3rd option (my favorite) would be to share codepen versions of your demo(s) that use the codepen-specific bonus plugins (which only work on codepen). The URLs for those can be found here: http://codepen.io/GreenSock/pen/OPqpRJ. That way, they can see everything working and inspect the code and even play with it live in the browser. Gotta love codepen. 

 

Thanks again for the sensitivity. Lookin' forward to seeing your English version of the talk on YouTube. Please swing back here and share it when it's ready. 

 

Happy tweening!

[Artur]

Hello Jack,

 

thanks for answering! You gave me an idea of how to deal with the public repo. I figured out that it's possible to deploy the code to GH pages and load all the required content from

See the Pen akRKVm by arturkot (@arturkot) on CodePen

. What's even better people can clone the repo, build it locally, add some changes, and preview them on Codepen. By default assets are pulled from localhost:3000 and if that doesn't work, the web version is loaded.

 

Now, I'm going to add some updates to the repo (a link – https://github.com/arturkot/gsap-intro):

• Add some more information to the readme file (describe the directories, why Browserify is used, and so on).
• Sync the audio with animation. It's all good when you just play it. Try to pause and rewind, though.
• Figure out if there's a way to add live reload for the localhost.

And the talk... I'll attempt to publish it next week.

 

Cheers,

 

Artur

[nextindex]

Hey Artur,

 

can I ask you, how you got the paid plugins working?

I have also a setup with gulp and rollup. However I could not get the paid plugins working with rollup in a bundled environment.
So I thought I switch to browserify and browserify-shim.

However, I still could not manage to get them working. And due to lack of any error handling in gasp / plugins, I also don't know really why.

 

Heres the part of my package.json

 "browser": {
    "DrawSVGPlugin": "./src/assets/scripts/vendor/DrawSVGPlugin.js"
  },
  "browserify-shim": {
    "DrawSVGPlugin": "DrawSVGPlugin"
  },
  "browserify": {
    "transform": [
      "browserify-shim"
    ]
  }

And my animation goes like this

const tlPath = new TimelineMax()
tlPath
  .add(TweenMax.fromTo("#line1", 1, {drawSVG:"0%"}, {drawSVG:"100%"}));

On codepen its working but not local.

[Artur]

Hi @nextindex,

 

I basically used a "global" label as the plugins are always loaded before my scripts (see package.json) for the animation on Codepen. Now, for the local plugins I used something like this:

• package.json snippet: (the same to what you've shown above). Note that "browserify-shim" parts aren't required as GSAP supports both CommonJS and AMD out of the box. You just need to tell Browserify where the plugins are located (in "browser") and they will work.
• animation.js snippet:  Here I depend on ES6 imports (as I use Babel to compile the newer version of JS to ES5).

I'm not sure what could be the actual problem but the JS you posted suggests that you haven't imported the plugin you'd like to use in your module. It works on Codepen because, most likely, DrawSVGPlugin is loaded before you scripts and is accessible in the global scope (so you don't have to import it as a module).

[Guest Vic_]

Why not use some heavy duty uglify to obfuscate all the combined libs?

[OSUblake]

Why not use some heavy duty uglify to obfuscate all the combined libs?

 

Why would you try to obfuscate it? You can pretty-print everything in the Sources tab of your dev tools. And if that's not pretty enough, you can use this to get nicer variable names complete with JSDoc comments.

http://jsnice.org/

[Guest Vic_]

If there is a way to obfuscate, then would that be an option? In general as well.

I think so.

 

 

If you deep google, there are some things that are non-trivial to de-obfuscate. 

I think some front web dev is proprietary and should not be open source.

Myabe OT.

[OSUblake]

A little OT, but other people have asked about this before. There's no way to protect client side code, and obfuscators can introduce bugs and slow down your code. Here's an interesting topic about this.

http://programmers.stackexchange.com/questions/129296/the-case-for-code-obfuscation
 

Then finally, there is that question of code privacy. This is a lost cause. There is no transformation that will keep a determined hacker from understanding your program. This turns out to be true for all programs in all languages, it is just more obviously true with JavaScript because it is delivered in source form. The privacy benefit provided by obfuscation is an illusion. If you don’t want people to see your programs, unplug your server.

 

 

But here's the shocker, your source code is most likely not worth stealing (not my words).

http://stackoverflow.com/a/29471

 

FWIW, if you really want to hide your code, you can do what spies do and embed it inside an image. That's really hard to crack. The output is kind of ridiculous, but it will run. 

http://javascript2img.com/

[Guest Vic_]

Hi Blake,

re: 'There's no way to protect client side code, and obfuscators can introduce bugs and slow down your code. '.

I don't agree with that and more: this should be possible. 

If you deep google for more than a few minutes, there are pro tools that make this much much better.

 

When I do a mobile app/Android, it is ALWAYS obfuscated by ProGuard - but not for web?

To me, better is 'apk' level: When a user downloads apk app, they can de-compile it, nothing can stop them. But it's PITA. So I think html5 should get to that level, and I plan to work on it some. I will at some point obfuscate my html5/gsap/sass/pug site and issue a challenge of source, as an experiment.  

The motivation is that there are times people invest a lot in a project; and they should have option to keep their 'magic' proprietary.
They also have option to open source it, but that is the call of the people that invested in their project. To the .apk level.

Also, there are client side apis such as firebase API and more 'static' type sites where the keys are client side and that is growing - server side is shrinking.

Someone has to pay the bills, and pro web dev is a good thing: 'if you want to know how I did that, hire me' should be an option. The paid bills then enable open source.

.V

 

[OSUblake]

Compiled code is a little different. Remember Flash? And I understand the motivation. This thread was about protecting GSAP's IP in a public repo.
 
Obfuscators are great for reducing your file size, but not so much for protecting your code. I'm sure there are some really solid ones out there. After all, that's how a lot of malicious code spreads. But every tool I've seen that tries to protect your code suffers from file size bloat and poor performance because they usually wrap everything in a closure or use eval(). And that really doesn't do much to hide your code. All I have to do to deobfuscate your code is set some break points in the debugger, step through your code, and it will show me how it's being interpreted.

 

And what's going to stop somebody from just copying and pasting your code? They might not care about the inner workings of it. They just want what it does. How are you going to prevent your code from running in their app? You'd have to setup some sort of public api key like Firebase or have the code connect to some server to phone home. Sounds like a lot of work. I think it's better to focus more on the things you can control, like improving your product/service, instead of worrying about things you can't control like a few dishonest developers.

 

 

[Guest Vic_]

'Obfuscators are great for reducing your file size, but not so much for protecting your code' 

I disagree.

' I think it's better to focus more on the things you can control, like improving your product/service'

That sounds not right, it seems better to just copy and remove attribution.

What I want is better paid original development.  Like actionscript, it can be decompiled, but I want to make it hard. Java/Android, C, all of this can be decompiled - but it's PITA. I plan to investigate way to get HTML/js to that level. 
Anyway, we have 2 different goals on this point, I think obfuscation should be an option, plagiarism is bad, removing attribution is bad, software is not free.

V

[Artur]

HI all,

 

just wanted to post a link to a talk which I finally managed to record & edit: https://www.dropbox.com/s/h43x4whptpcg9y1/GSAP%20presentation%20%2B%20slides.mp4.mp4?dl=0  It's on Dropbox but I'm going to post it on YT.
 

In short:

• It's around 10 minutes long.
• It's not in-depth, detailed talk, more something like an introduction.
• Focuses on showing GSAP as a performant tool able to handle complex/ambitious animations.

It would be great to hear some of your (GSAP users!) feedback!

 

Cheers,

 

Artur

[GreenSock]

Thanks for sharing this, and for putting it together. You touched on some important considerations, and it was nice to hear what you personally use (and like) the most. 

 

I appreciated the fact that you touched on the licensing issue, and I totally understand why you'd position it as a "negative", but I actually think it's more of a feature because it's the very thing that has allowed GSAP to thrive in the marketplace for a decade. Look at how many other libraries/tools have come and gone. In my [totally biased] opinion, as a developer that would be a BIG deal because I would feel weird about building on a foundation that might be abandoned in 6 months or a year. http://greensock.com/why-license/ explains it better. 

 

Anyway, thanks again for sharing. 

[velshnia]

Obfuscating your code is short-sighted. If you think you need to do this for the Web, you're missing the point.

 

If you've programmed something so wonderful that you deserve all the credit for it, first of all, congratulations! Secondly, put it on GitHub or a Version Control system, and share it with the world. You'll never advance in the programming world by obsessively hiding your code, you'll waste 20% of your time obfuscating, and for what? So you can get paid more? Good luck with that, man.

 

Computer Science majors used to obsessively compete to see who could make a script as concise as possible. JavaScript programmers in GreenSock are dependent on the Web, which is based on open source technologies. I hated the CS approach, as it presented programming as an individual exercise in problem-solving. If you've ever programmed in a business environment, you probably know that working on your own is very rare. 

 

My point is that, in addition to all of the code used to make the Web being open-source, Web programmers enjoy and support a community of sharing that negates the old approach of individual competition. If you want to obfuscate your code, go learn C++ or something that uses a compiler. Go dust off a ****** old Flash project. But don't try to obfuscate your Web code. And please don't use an open Web forum, where programmers share coding techniques, to argue for code obfuscation. So you can make more money. This is a space for sharing code, not obfuscating.

[Carl]

HI Velshnia,

 

Could you please clarify who you are addressing? What is the open Web forum you are referring to? Also, what prompted you to revive this thread from last year? Having trouble discerning the context and intent here.

 

 

 

 

 

[velshnia]

Hi Carl,

I was addressing the topic of obfuscating code, which 'Vic_' raised September of last year. The Web forum I was referring to was *this forum*. 

I wouldn't say that this is a dead thread, by any means - 9 months? But you're right, I didn't make it clear who / what I was responding to. 

It's not matter - in fact, I should have just not posted. But I really benefit from code forums like these - as well as code sharing sites like codepen and github - and got defensive at the idea, which I had to deal with in the past all the time, that obfuscating code has some sort of personal benefit (in Vic_'s case, the idea that he'd get more money) that outweighs the huge benefits of working collaboratively. I'll let the thread die now. It's certainly better handled on a site like stackoverflow than it is here! 

[Carl]

Velshnia, 

 

Thanks for clarifying. Very helpful. I understand that folks can be very passionate about these issues and both sides have valid points. Thanks for sharing.

[velshnia]

Thanks for moderating! Y'all are super helpful.