Open-sourcing the Lightning Web Components framework

One of the bigger mistakes Salesforce made with Lightning is moving from purely transactional model to default-cached-no-way-to-purge model. Without letting a single developer to know that they did it, what are the pitfalls or how to disable it (you can't).

WRT Lightning motivation, sounds like a much better option would've been supplement older server-rendered pages with some JS, update the stylesheets and make server language more useable. In fact server language is still there, still heavily used and still lacking expressiveness so badly that it's 10x slower to prototype on it rather than client side JS...

I was using SFDC extensively when the Lightning experience first arrived, and my experience tallies with yours. I ended up switching back to the old experience to get my day to day work done.

The vast majority of Salesforce code is "legacy", so you don't get a lot of people sticking around that know modern web stuff.

I saw the same thing happen at a previous employer. Nobody that knew modern web development would stick around and let their skills rot, so our "new SPA" interface was build by a team that only knows jQuery

This was also my experience with lighting components

At its core, Salesforce is a platform. As such, our customers expect their code to work for the long run (and backwards compatibility forever). Not owning the framework fundamentally means jeopardizing our business and our customers, since we can't control our future.

We believe the best way to future-proof our platform is to align with standards and help push the web platform forward, hence our sugar and take on top of Web Components.

Also to your comment about using different frameworks, again as a platform, allowing our customers to trivially include their framework choice of the day, will mean that we might end up having to load seven versions of react, five of Vue, 2 Embers .... You get the idea :) Outside the platform we love all the other frameworks (hence other properties might choose what it fits their use cases) and we had a lot of good discussions with framework owners about how to keep improving things over the last two years.

Our goal is to keep contributing to the standards and push all the things to be implemented natively on the platform so we all get faster and better.

I guess because React insists on going against WebComponents, while everyone else is adopting them.

At least that is my understanding from Angular, Vue, Ionic, Svelte and plain VanilaJS point of view.

Same here... I actually put maintain a starter project for react + VF: https://github.com/ChuckJonas/bad-ass-salesforce-stack

I don't see this changing much. Salesforce has a serious follow through problem. They tend to half-a$$ good ideas and then once they get the press for them, they stop investing in them.

Just tried the create-lwc-app and it didn't build finish properly

The honest truth is that Lightning Components are just vendor lock-in. Once you buy into lightning, you wind up using their proprietary communication channels and their proprietary component library (which this press release makes clear isn't open sourced).

If you want to change backends to something better, you can't because while the backend will port rather directly, the front-end will not.

Then there's also the fact (unless things have changed dramatically in the past few months) that writing your front-end in Vue or React will result in much faster UI experiences and finding developers to maintain it will be easier and cheaper (Salesforce devs are generally a bit more expensive).

> live-updating ... as opposed to ... whole page refresh

Does that mean that changes in data on the server are automatically pushed to the client, i.e. if you're viewing a customer and someone else is editing that customer, you will see the data in your view change in real time?

Or is it just using AJAX instead of traditional server-side rendering?

I used it quite a bit for a 3 year period from 2011-2014 or so. I imagine it's changed a bit since then (but it didn't really change that much in that time period, so I wouldn't imagine that it's completely different since the last 5 years). Overall it had an old VB5 feel: you could do simple things _really_ simply, but difficult things were more or less impossible, and even if you wanted to step out of the infrastructure and do the difficult things somewhere else, integrating back into Salesforce was still a major hassle and often not worth the effort.

At its core, it's sort of a dynamic form builder: you design your data model and Salesforce creates input/entry forms for the data objects in the model. If there's a one-to-many relationship between two objects, when you edit one, you see a list of the related objects, and you can do bulk operations on the list in place. You have some customization options but for the most part, Salesforce creates all the UI for you and because it's uniform, it's easy for users to work with.

The two biggest problems were limits and opacity. Salesforce imposes limits on how many operations per second you can perform like reads or writes, and its not usually easy or even possible to predict what limits you're going to bump against, so you end up discovering them through trial and error (in production!). The other problem is the opacity of the platform - it's working a lot of magic under the covers and you have no visibility into what it's doing and definitely no control over it. If you thought Ruby on Rails was hard to reason about, just wait until you meet Salesforce!

All in all, I'd recommend doing as little "in Salesforce" as you can realistically get away with - your users might demand it because they know it, but Salesforce makes you feel like you can run your entire business in there, but those are murkier waters than you would imagine.

I work for a small business(~50 people) and we use Salesforce more or less across all business functions. I've been with the company for nearly 4 years,so I witnessed a lot. Salesforce is a fantastic platform,if used correctly. It's worth it. It does make sense to use it for a small business. Salesforce can be as big or as small as you want it to be.If you are small business with small needs,keep it simple and use it to track sales.If you are business with complex needs, do tons of customisation, integrations and etc.

I work for the federal government. Another team in my organization is using it for contact management and some other CRM tasks. They are very happy with it. My team is developing a custom dashboard prototype for leadership. Our results are mixed. Please note that I've only been working on this project part time for about 4.5 months, so I'm far from an expert.

Basic entry and view forms are very easy to create; Basic reporting is very easy, as well as basic charting. But the provided charting components can only be customized up to a point. For example, you can set the color of chart segments by value for pick-list fields, but not for calculated fields, and only for certain types of charts.

Salesforce is a big, complicated system and it takes a while to learn. If your needs can be met by their built-in Sales or Service modules then it may be a great choice. If your needs can be met by a 3rd-party add-on, and you're willing to pay extra for that, it may also be a good choice. If you want to recreate your custom business logic in Salesforce then you may want to hire a consultant.

Salesforce also has a lot of pricing and licensing options, so you would need to be careful about making a purchase before you know all of your needs and understand the different license types and pricing tiers.

Salesforce has been a terrible experience with our company. I'll focus on the customer support / service module since as a sales platform, it definitely shines, but as everything else it falters. Lightning, the "new" experience that kept being touted as the solution to our existing problems, has been even worse -- it is incredibly slow and bloated. I have to restart my browser periodically since it starts taking up 2-4 gigabytes of memory in Chrome. The interface feels like it is stuck in the past, being unable to use native tabs in your browser and forced to use their tab implementation. Everything feels clunky and slow. The API to use things is pretty awful and obtuse; the code for custom components is insanely verbose for the simplest things.

The marketplace is insanely expensive to add simple features or tools that many other platforms have built in -- or, if not built in, easily developed with a sane API. Look at this sample project for a session timer to get a feel for the insanity: https://github.com/SalesforceLabs/CaseTimer and things like a command line interface and source control for your sites are either nonexistent or poorly supported or documented.

The only reason we use it is because the directive came from above; Salesforce feels like Oracle to me in that it gets sold to the higher level execs who never actually use it, and it gets forced on everyone else.

I know there are some good Salesforce sites around somewhere.. but those seem to be the ones where they've replaced all the Salesforce stuff with their own UI and simply use it as a backend database.

I highly recommend avoiding it like the plague.

I work for a marketing agency that is also a Salesforce partner. However, I only do Salesforce Commerce Cloud. Or is it B2C Cloud nowadays? There's been a few rebrandings since I started using it. It was originally Demandware, and we liked it that way!

We have a handful of clients we build and maintain sites for. Some older, some newer. I don't have exact numbers, but if a vendor isn't pushing $5 million+ annual sales, Commerce Cloud doesn't make sense.

When I started, code was tied together with "pipelines", which were basically flowcharts[0]. (Newer sites use a controller model.) Later on, new sites had a modularized JS and SASS system held together by node.js scripts, along with tightening PCI requirements (TLS 1.1/1.2+, 2 factor auth required for code and asset uploads (client side certs with WebDAV)).

The front ends are tied into Cloudflare automatically, and the back end has always been through a highly restricted ORM. The whole platform is laser focused on e-commerce, and as soon as you step away from the strict add-to-cart/wishlist and checkout model, the platform is horribly suited. It doesn't do newsletter management, reviews, or address deduplication well (better to integrate with external services), and file/image uploads are a pain in the ass. It only has enough CMS features to sell things; you can use it as a corporate blog, but it's not that well suited if you have a marketing department that changes everything and wants something "completely new" on a weekly basis.

I've had a good experience. For the times we've needed it, Salesforce support has been effective.

[0] an article today eerily reminded me of it, though I don't agree with the premise https://news.ycombinator.com/item?id=20037962

I've never used it myself (edit: oh, wait, that's not actually true, though it was years ago), so I can't answer some of your questions. However, I have done a fair amount of Salesforce consulting and can give you that perspective. I'll speak in absolutes but I'm sure things are more nuanced.

For established companies of a certain size, Salesforce is usually just assumed to be present, kind of like IBM in a previous era. This is mostly because everything integrates with Salesforce, and all salespeople know how to use it.

For smaller companies, particularly startups, the ROI isn't as clear. Salesforce is expensive. The CRM that most startups need is marketing-focused, and you probably get one for free with whatever marketing automation tool you use. It's worth it for smaller outfits only if they have a long and involved sales process (say, institutional sales primarily), and perhaps if you are involved in education or a non-profit, since they have programs that reduce the cost in that case.

Salesforce out of the box isn't particularly enjoyable to use, but it's learnable and usable. A lot of companies add on cut-rate customizations that end up making things a mess, but that's more a commentary on change management at large organizations than the platform itself.

If you are considering this and it’s a small business, please consider Retool (https://tryretool.com) or something similar. The thing with SF is that it’s way too big for starting small and it’s hard to customize when you start getting bigger. You don’t need more than a couple of SQL tables to have a basic, simple, CRM and you own the data that you would be able to easily analyze in your favorite dashboard tool.

We used it for some years in a startup as a sales tool but it was very very slow and the UI and flow was too complicated for our needs. So we switched to Pipedrive which did the job, was a great success and for our usecase was much easier too use.

I worked for a roughly ~80 person B2B SaaS startup whose primary product was a Salesforce managed package tailored to a specific industry. We had around 8000 customers at the time I left the company.

Salesforce as an internal sales-team-management tool is a very different beast than Salesforce as a product delivery platform, so I'll try to address both.

As an internal tool to manage a sales team, Salesforce shines. It provides a simple, extensible UI for sales reps of all skill levels to coordinate their activities, and provides lots of hooks for integrations of various other products. For example, our marketing team generated leads using other software, and could easily pipe their lead data into Salesforce, where it was easily acted upon by sales reps. Salesforce quickly became _the_ source of truth for the reporting activities of the sales department as a result of the ease of getting data into it. Additionally, Salesforce's customizability was a huge asset - when the sales team wanted to add fields to their core CRM data tables (Leads, Opportunities, Contacts, etc.) - they could do it themselves without involving the engineering team at all, because Salesforce's configuration-first interface enabled them to do so. Eventually it got complex enough that a full-time Salesforce admin was hired, but for smaller teams that might not ever be necessary. Salesforce can do a lot more advanced things if you add custom code to it, too.

As a platform for delivering products, it has a whole litany of problems that make it difficult to work with, so I wouldn't recommend using it for that purpose unless you have someone around who has adequate experience to avoid the pitfalls. Salesforce "orgs" are essentially primitive containers - they're instances of the Salesforce core product that are isolated from one another on a multitenant cluster infrastructure. A managed package is essentially a custom configuration for the Salesforce core product - including database schemas, permission assignments, custom code, and more. When you sell a managed package, it is installed in your customers' orgs and all custom code is obfuscated from their view. This is a neat solution for preserving IP, but it can cause huge headaches when your customer base grows. Without adequate preventive measures, customers (used to the customizability of Salesforce) might build their own org-specific customizations that rely on functionality in a specific version of your managed package, and then downstream changes to your managed package can break their custom functionality, leading to angry phone calls and support nightmares. Because of this, we had to be extremely judicious with our update pushing, which slowed down development progress substantially. Until very recently with the advent of Salesforce DX, local development was extremely difficult as well - we essentially had to provision many sandbox orgs for our developers, and the always-running nature of those orgs, combined with the limited number of allowed sandbox refreshes, led to lots of problems with unwanted data artifacts hanging around. This made bugs quite hard to reproduce in some cases.

Since Salesforce has evolved as a platform for roughly 20 years, there's a lot to learn. Salesforce's whole ecosystem at this point probably has a similar complexity to AWS (as a whole). As such, if you ever want to do really advanced stuff with Salesforce, I cannot understate how important it is to bring someone on board that has lots of tribal knowledge of the platform before trying to implement it. You're probably fine without such a person if your need is for a simple internal sales CRM, but if you're trying to go beyond that niche, a good Salesforce admin, developer, or architect is worth their weight in gold. There's a reason the big consulting companies make tons of money selling Salesforce implementations - it's hard to do it right the first time, and an improperly managed implementation can spiral out of control really quickly. Fortunately, Salesforce's docs have gotten way better in recent years with the advent of Trailhead, and they've made strides to improve the developer experience as well.

I've done this with the older lightning CSS based toolkit and it was great.

The front end was React/Redux and we just wrapped the bits of markup we needed into React components.

I think LWC has been GA for ~6 months. It is leagues better than the old Aura components.

Yeah, that is where they went after Google lost interest in GWT.

It looks like it is a set of components and helpers for building components of your own.

The good thing about Web Components is that they are reusable across frameworks. You don't need jQuery-picker, react-datepicker, and vue-datepicker just <my-datepicker /> and its reusable anywhere.

I work in an org that is looking to provide a lot of the same experiences both within salesforce and outside of it, and I'm looking at this make sharing those components easier. Imagine if you have a calculator and it could be used by both your client relations team (working in salesforce) and on your retail-facing web site.

right now we write two UIs and hook them up the same service. now maybe we get to write one UI.

Certainly Yehuda from Ember had some influence on us :), so as many others like Richard from Svelte or Evan from VueJs.

A lot of good conversations happen within the last two years to be where we are today!

Hopefully some of our solutions and ideas will help improve the ecosystem.

Their home page says:

> Lightning web components are custom elements built using HTML and modern JavaScript.

> The Lightning Web Components UI framework uses core Web Components standards and provides only what’s necessary to perform well in browsers. Because it’s built on code that runs natively in browsers, the framework is lightweight and delivers exceptional performance. Most of the code you write is standard JavaScript and HTML.

> Build apps anywhere, any way. You can build an app with your favorite tools, like Webpack, TypeScript, and Babel, and run it on Heroku, Google, or anywhere else. You can also package an app to create a desktop experience in Electron.

Which I think is equivalent to just saying this:

> Lightning Web Components is a lightweight, cross platform, and framework-independent web components library that builds on the native Web Components standards to add some convenient functionality.

The main website is here: http://lwc.dev Some examples here: https://github.com/trailheadapps/lwc-recipes-oss

More coming soon :)

I only know because I happened to be looking at this yesterday, but stopped since it wasn't open source. https://developer.salesforce.com/docs/component-library/over...

Updated from “Lightning Web Components Open Source”. Thanks!

I couldn't believe my eyes but you are right.