skuid native vs skuid salesforce

Pat, in general, yes, there will be some capabilities of Skuid-on-Salesforce that will not be present on Skuid Native, but you’ll see that we have tried to keep the feature set and functionality as close as is possible and reasonable.

Regarding your specific questions:
1. Right now, Lightning Components are not available in Skuid Native — no plans right now to change this.
2. Invocable Apex — also not available right now, but may very well change in the future.
3. Salesforce Buttons — no plans to add this, doesn’t really make sense on Skuid Native.
4. Global Merge Variables — virtually all Global Merge Variables available in Skuid-on-Salesforce have direct correspondents in Skuid Native. $Label, $User, $Site.CurrentSiteUrl, $Site.Prefix, etc. all work in Skuid Native.

There are of course other capabilities that you did not mention, such as calling Visualforce Remoting and executing Apex, which naturally don’t make sense on Skuid Native because it’s not on Salesforce anymore.

But, there are things that you have to do on Skuid-on-Salesforce right now which are much easier on Skuid-Native.

For example, deployment of Pages.

In, Skuid Native, you have Apps and Routes. Routes basically let you say, “when Users go to this URL, show them this Page”, and Apps are bundles / groupings of Routes, accomplishing much of the functionality of Salesforce Communities and Apps all in one. Apps and Routes are so simple to use, you’ll probably catch yourself thinking “Wait, that’s it?” And yes, it is that simple. No Visualforce Override pages, no overriding of Object Actions, no Page Assignments ---- just Routes. 

Can’t wait to get beta access for sure.

I remember talking to Ken about how cool it would be have Skuid for other systems a couple years back. The opportunities seem endless. Looking forward to seeing can be done.

Any news on Lightning Components on Skuid-on-Salesforce?

Re: Lightning Components, the short story is that Salesforce’s “Component Metadata” API’s around Lightning Components are basically nonexistent, and that hasn’t changed a bit since Lightning Components were released 2 years ago, so Skuid’s “Lightning” Component has always had a very non-ideal Composer experience, diminishing the apparent quality of our own product — so we’ve cut it from the list of components visible through the Composer. Technically you can still use it as before, and configure it via XML, but that’s the extent of our support for it going forward until Salesforce releases some “Component Metadata” API’s that we can actually use. We have asked the Lightning Product Managers about this repeatedly and they have told us that it is not strategic to them and there is not indication that this position will ever shift. 

That makes sense. I buy that for sure. Unfortunate for Salesforce if you ask me.

Thanks for clearing that up.

That said, I’m hoping to hear more about how Skuid will make building and collaborating with partners on components. I’ve got a couple in the pipeline that complement the current set quite nicely.

Zach, your comment about how in Skuid Native " Apps are bundles / groupings of Routes, accomplishing much of the functionality of Salesforce Communities and Apps all in one." - It got me thinking… Does this mean we’ll be able to build/scale standalone Apps built on the Skuid Platform using AWS Elastic Beanstalk, for example?

+1 to Roman’s question – would love more info on building standalone Apps on Skuid Platform that could be deployed for different clients, while still allowing for customizability for each individual client.