Here are some of my own impressions and observations, since I was not participating on forum at the time of its release.
My first thought was that this appeared more created for the forthcoming & delayed Pinegrow sibling for designers and rolled into Pinegrow as a plugin. Since everything is being dumped into and interpreted from data-attributes, instead of having transferability and actual editable human readable JS as output. Pinegrow itself has always been touted as open transferable with no abstraction. While this approach does not really follow with that ideal since the interactions output is not cleanly transferable from a code handoff standpoint. So to me it seems instead more aligned with the aforementioned design sibling product mindset, but a nice feature none the less.
Then I just kept re-reading this line:
“Due to recurring costs involved in licensing the best animation technology on the market, we’re unable to offer Interactions as a one-time purchase.”
A GSAP “Business Green License” of $150 year is all that is needed to offer or sell this plugin to your customers. At the $50 per sale to Pinegrow users, you would only need to sell 3 each year to cover the “recurring costs involved in licensing”. The Pinegrow team remains small so even 5 developers internally working on PGIA would be $500, equating to 10 sales a year to cover the “recurring costs involved in licensing”.
So I just kept looking at that word “unable” wondering about cost vs return when considering the vast benefits of associating Greensock with and into your products.
With that same mindset it seems Pinegrow could have chosen to just absorb this trivial cost of $150 a year to commercially offer this. Instead choosing to just roll the feature into the app as added value to increase overall app sales derived from this feature inclusion. The name association and recognition alone would bring potential users. So I don’t think the reason for recurring costs is necessarily justified definitively as “unable” considering the low yearly price of implementing GSAP commercially and how that benefits your own brand. Similar GSAP related examples below demonstrate lower priced one time payments with lifetime updates and the absence of subscriptions for users.
Here are a few some, a few having been sold for years with comparable features. Interestingly by comparison all are cheaper and none are subscription based. **
Scroll Magic WordPress – Scrolling Animation Builder Plugin
- $25 one time payment + lifetime updates
- GSAP + ScrollMagic + a pile of data-attributes
ScrollMagic for WordPress - WordPress Builder with Advanced Animations
- $25 one time payment + lifetime updates
- GSAP + ScrollMagic + a pile of data-attributes
- Visual timeline editor **
- $15 one time payment + lifetime updates
- GSAP + ScrollMonitor + fewer data-attributes
- Outputs actual GSAP JS logic, shows proof of concept of offering output as JS.
The same comprehensive features could have also been freely implemented by utilizing the MIT licensed Anime.js as an alternative.
With the release of GSAP 3 the syntax is now quite similar between these two libraries, which admittedly is indeed nice regarding a relatively easy and interchangeable development ability between the two. When it comes to core features both libraries are virtually interchangeable. With each being optimally performant in animating virtually anything un-opinionated. The easy difference being GSAP offering premium support and an amazing user forum, but neither of which apply to PGIA users.
By PGIA exclusively using data-attributes it seems to be a way to circumvent users and clients from directly editing the GSAP code from PGIA. Thus allowing users to commercially pass along “Pinegrow Interactions” GSAP related output without them or their clients needing to potentially buy a GSAP license. The only way a client or someone can edit things made by PGIA easily without reverse engineering a long string of data-attributes and rebuilding the needed GSAP logic in JS. Is by actually buying Pinegrow and the Pinegrow Interactions plugin. That seems like somewhat of a circumvention allowing Pinegrow to make more money but not Greensock? In that regard I assume you will also need to stick only to the core GSAP features and would be restricted from implementing the GSAP Bonus Plugins (DrawSVG, morphSVG, SplitText, etc.,) as that would then require users to buy their own GSAP license at additional cost to use those bonus plugins.
Of course the timing of PGIA using GSAP 2 upon its release when GSAP 3 had already been available was not optimal from a marketing standpoint or introduction opportunity for Pinegrow. It seems the GSAP 3 core features would have been more than battle tested when “Pinegrow Interactions” was released. Given the “PGIA” features offered to users are just GSAP core features and long standing properties offered within the core GSAP library. Especially since the Greensock team do a wonderful job listening to customer feedback and squashing any issues generally within hours or the same day in most cases when something is reported. You should have had access to the private beta releases and the private GSAP 3 forum before its release if you were running into any development related issues or logic errors with the framework. Perhaps the hold up is instead more related to the use of ScrollMagic (MIT license) and it not “officially” supporting GSAP 3 yet. Another option would be just using vanilla IntersectionObserver and lowering the overhead further, especially since ScrollMagic does not utilize that yet either.
Regardless I don’t think there were reason(s) to question the “stability” of GSAP 3 upon its release? Unless you didn’t participate or provide feedback during the beta period? Pinegrow Interactions released almost a month after GSAP 3 and people were eagerly releasing commercial work on (or before) day one of the GSAP 3 release.
Overall “Pinegrow Interactions” is a nice implementation of many of the core GSAP abilities into a comprehensive UI regarding what it intends to offer to Pinegrow users. I was not enthused to see it uses a pile of data-attributes but understand for certain features it may depend on it. Still it would be nice to have the additional option of outputing to a clean JS file of human readable code, given the nature of Pinegrow as an app but also frontend development in general. The need for a subscription based model is also not clearly proven as an absolute as various other tools have shown (a few shown above). Not using GSAP 3 from the onset seems easily disputable.
I did grab a copy of “Pinegrow Interactions” during the initial $25 release offering hoping to see what it might become. Though regardless I’ll certainly be keeping my “Shockingly Green” membership without question. 