LWC vs SKUID

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.

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!

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&#46;ownerId}" relatedList="false" title="false"/>  <br /></apex:page>

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!

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.