Re:Open-sourcing the Lightning Web Components framework
by commandlinefan on Wednesday May 29, 2019 @12:27PM
(#20042194)
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.
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.