LWC vs SKUID

  • 1
  • Question
  • Updated 4 weeks ago
  • Answered
Salesforce is going to introduce LWC i.e. Lightning Web Component in next couple of months? Is that going to be the end for SKUID?
Photo of Anand M

Anand M

  • 140 Points 100 badge 2x thumb

Posted 4 weeks ago

  • 1
Photo of Louis Skelton

Louis Skelton

  • 5,102 Points 5k badge 2x thumb
I'm really excited for Lightning Web Components - I enjoy writing and working in javascript and I'm glad Salesforce are moving in this direction.

But Skuid's a very different product. Skuid allows administrators and developers to quickly build and, importantly, quickly evolve applications using a no-code point and click interface. That a user can use the action framework, components, models, data sources, etc. to build enterprise-grade applications just by clicking their mouse and dragging things around the screen is as much of a game-changer today as it was five years ago when we first started using it. It's yet to be bettered! What's best though is that you can do stuff like this to get you 95% of the way to building your perfect app and then, for those who like to tinker under the hood, you can use Skuid's (under-valued) api, snippets, etc. to do some wizzy stuff to allow you to produce ANYTHING you want. Code and no-code all under one roof! Being able to sit in a room with a new client and just confidently say "yes" to every feature request is something we can do because of Skuid and, crucially, we can do it without needing an army of developers behind us writing code and introducing ever-growing technical debt.

Comparing LWC with Skuid is like comparing Lightning Components with Salesforce's page layouts. They're different tools performing different jobs. I'm just so excited to have so many great tools!

That said, if Skuid could introduce a way of easily updating a counter in a tab that would be fab. Ta.

Photo of Gregg Baxter

Gregg Baxter, Official Rep

  • 3,132 Points 3k badge 2x thumb
Couldn’t agree more ‘Being able to sit in a room with a new client and just confidently say "yes" to every feature request is something we can do because of Skuid and, crucially, we can do it without needing an army of developers behind us writing code and introducing ever-growing technical debt.’ Well said Louis!
Photo of Zach McElrath

Zach McElrath, Employee

  • 49,556 Points 20k badge 2x thumb
Anand,

Louis is spot-on. 

Just want to add a little more perspective as someone who has worked in the Salesforce ecosystem for 10+ years.

LWC is the 4th framework that Salesforce has released for writing code to create custom user interfaces on the Salesforce platform.

- ~2005: Salesforce releases S-Controls, a framework that lets you use HTML, JavaScript, and CSS, in conjunction with SF's AJAX API, to create custom user interfaces. No prebuilt components to leverage, but you have fairly full control of customizing with web standard technologies.
- 2008: Salesforce releases Visualforce, a framework that provides an XML-based markup language (that also lets you use HTML) for coding custom components and assembling them into pages. Standard Controllers available for simple single record server logic, and StandardSetControllers for simple multi-record/list logic, but in many cases it is necessary to write custom Apex controllers performing more complex server-side logic. JavaScript Remoting available for communicating with Apex from JavaScript.
- 2014: Salesforce releases Aura / Lightning V1, a framework that provides a JavaScript-based framework (that lets you use HTML and XML for layout) for coding custom components, which can be assembled into pages using Flexipages and eventually via the Lightning App Builder. Key features include 2-way data binding and use of JavaScript to define client-side component logic and to initiate server communication, as well as an eventing framework to facilitate inter-component communication. Lightning Data Service available for providing simple, single-record CRUD functionality --- basically, the equivalent of StandardControllers. No equivalent of StandardSetControllers or anything. Custom Apex controllers heavily needed for doing any server-side logic for fetching multiple records or anything more complex.
- 2018: Salesforce releases LWC / Lightning V2, a framework that lets you use HTML, JavaScript (ES7), and CSS for coding custom components. Functionally, LWC is very similar to Aura, it just enables use of ES7 features for coding JavaScript and provides a different syntax for including other related components.

Every 4-5 years, Salesforce introduces yet another user interface framework. Each new framework looks more like the other common web coding frameworks of the year in which it was released, but fundamentally, each of these is yet another coding framework.

I thought it was a bit misleading for the LWC intro blog post to try to position LWC as a way to not have to write much code to get things done. Yes, LWC has some prebuilt components that you can use, but the real question is, how far can you go with these before you have to start coding your own components from scratch? The answer: not very far. And once you do start coding your own components from scratch, or coding your own controllers and inter-component interaction and communication and server-side logic to get / modify data that you need, then you're maintaining all of this investment, you're responsible for owning it, testing it, making it stable --- just like you were in S-Controls, Visualforce, Aura.

For example, the LWC blog post gives an example showing how much code it takes to create an Contact detail form, using their standard component. This is not realistic --- this is a component that you wouldn't need to write code for! You could use the Page Layout Editor or Lightning App Builder to get the same result! Even still, just want to give a small comparison of how much code it takes to do this in LWC vs Visualforce:

LWC:

import { LightningElement, api, track } from 'lwc';

export default class ContactForm extends LightningElement {

@api recordId;
@api objectApiName;
@track fields = ['Name', 'Title', 'Phone', 'Email'];  
}


Visualforce:



<apex:page standardController="Account">
   <apex:detail subject="{!account.ownerId}" relatedList="false" title="false"/>  
</apex:page>



For even this simple example --- Visualforce was actually less code than LWC.

That being said, I still agree with Louis, and I think that LWC will ultimately be more intuitive for developers to use to write Lightning code. It will at least be more in line with what web developers are used to in 2018.

But let's consider the impact of this on Salesforce developers and customers.

Looking to 2019, it's now very likely that many Salesforce customers will have a combination of Visualforce, Aura, and LWC code running in their orgs. For large customers who have invested heavily in custom code on Salesforce, that means that there is now a mixture of code written with 3 different user interface coding frameworks living in the same environment. This represents not just an administrative and knowledge burden for IT to maintain (having developers on staff able to support 3 different Salesforce user interface coding frameworks, in addition to backend Apex support), but also represents a lot of potential cost for IT, who will be motivated to "convert" or "migrate" code written in one framework to another --- potentially without any change in functionality or net benefit to the end user. 

I've seen this pattern play out not just in Salesforce, but throughout enterprise IT --- roughly every 3-5, previous user interface code that developers wrote is thrown out and replaced with new code in a new framework. This also applies to other IT paradigms, such as the "lift and shift" from on-premise to the cloud, where companies have moved their existing systems to a new "location" but haven't changed what the systems do, i.e. they've spent millions moving things around but haven't actually improved the experience for actual users).

Skuid was created to turn this model on its head. Skuid is a declarative framework, where what you build is stored as metadata, not code, which gets interpreted by the Skuid runtime. So the apps that you build with Skuid can be refined, extended, improved, and reshaped with you, over time, as the needs of businesses and users change --- in hours or days instead of weeks or months, without having to incur the massive investment of learning a new coding framework every few years and having to rewrite everything just because the old coding framework is no longer being supported. 

Skuid has also invested heavily in "API Versioning". With our recent Spark release, we unveiled a new API Version, which allows your existing pages you've built with Skuid to continue to run as they always have, while allowing you to built net-new capabilities using our new Design System. More to the point, we're working to release a "Migrate" capability which allows you to, with the click of a button, move pages you've already built to the new API version. No full code rewrites in a new framework, but rather a button click. And the core concepts of Skuid are all still there --- Skuid Models are still Models, Components are still Components, etc. --- you don't have to learn a completely new framework. Yes, we're adding new capabilities, but it's not a completely new paradigm. 

This is what a declarative framework can provide that a coding framework does not.

This is why Skuid is still relevant, and, I'll go out on a limb to guess, still will be 5 years from now when Salesforce releases their next user interface coding framework.

(Also, side note: you can also use Skuid outside of the Salesforce ecosystem ---with Skuid Platform: https://www.skuid.com/platform/skuid-... )
(Edited)
Photo of Conlan O'Rourke

Conlan O'Rourke

  • 3,632 Points 3k badge 2x thumb
Zach, this is a great insight! Your sales and marketing team should really take this and put it into some kind of bullet point one-sheet. 

Along with providing a declarative UI framework, I also feel that Skuid's Action Framework is vastly underestimated. It is by far my favorite business process automation tool, much preferred over all of Salesforce's numerous tools (e.g. process builder, flows, approval processes, workflows, quick actions, macros, and apex). SF's own process automation tools often must be cobbled together, they don't always play nicely together, and can often produce inconsistent and less than ideal solutions. 

Skuid Action Framework is a declarative business process automation tool that can single-handedly replace all of SF tools, it's easier to learn, easier to build with, and easier to maintain over the long-term.
Photo of Anand M

Anand M

  • 140 Points 100 badge 2x thumb
thank you for the inputs, SKUID  provides the benefits without having to write the code! Whereas LWC you would still be required to write the code, and then the implementation is as good as the design hence risks with the technical debt can go very high!