Add a wiki page to track differences between OSS and Salesforce version

[Bartheleway]

Is your feature request related to a problem? Please describe.
There is no way to find which features are implemented in OSS and not yet available in Salesforce LWC.

Describe the solution you'd like
A simple wiki page (or Salesforce documentation) that track which feature are not yet in Salesforce LWC and give a due date on implementation.

Describe alternatives you've considered
Some features are protected by an activation (experimental feature), give the ability to activate them in Salesforce context.

[pmdartus]

The only differences between on platform and OSS are at the compiler level:

• None of the experimental LWC APIs are exposed on the platform
• All the code pushed to the platform is compiled down to ES6 (and ES5 for older browsers)
• Some extra restrictions are applied as well:
  • No access to dynamic imports
  • All the @salesforce/* import are validated against metadata already present on the platform: eg. Apex, Labels

The LWC engine is identical between the OSS and on Salesforce. At runtime, Lightning Locker is used to evaluate the code which adds another set of restrictions unrelated to LWC per-say.

@jbleyleSF I think that would be a great addition to Salesforce documentation.

[Bartheleway]

Okay, could we then have a page that enumerate experimental features not available in Salesforce and when they are planned to be generally available ?
Do we have the possibility to make things move quicker if an experimental feature is really needed (lwc:dynamic for example) ?

[pmdartus]

Based on internal usage feedback, the lwc:dynamic has to be redesigned. We are not happy with the way lwc:dynamic works today. There is no timeline to enable this on the platform.

/cc @gregwhitworth

[Bartheleway]

I will open another post to discuss lwc:dynamic. Is there any reason we can't activate experimental feature on Salesforce ?

[pmdartus]

Is there any reason we can't activate experimental feature on Salesforce ?

Some issues have been raised regarding lwc:dynamic ergonomics. Because of this, we don't feel confident opening this API on the platform and maintaining it on the long run.

---

Regarding the original question, I am actively working with @jbleyleSF on updating the LWC documentation on developer.salesforce.com with a list of differences between LWC OSS and LWC on the Salesforce platform.

[gregwhitworth]

@pmdartus I was actually just discussing this with @kevinv11n I think a solid enumeration would be good for a potentially longer term consideration for tooling. Since we're seeing more and more utilization off platform (which is good) we should ensure that an author can opt-in to having platform analysis as well.

I'll save comments for lwc:dynamic for the other issue.

[Bartheleway]

Is there any reason we can't activate experimental feature on Salesforce ?

Some issues have been raised regarding lwc:dynamic ergonomics. Because of this, we don't feel confident opening this API on the platform and maintaining it on the long run.

I understand and I know that Salesforce has been on a add only model for years and deprecating / retiring features seems painful (probably because of the wide community of users). For this kind of feature which are tagged with an experimental flag, I would find normal to this it available and maybe retired before accessing the GA state.
Salesforce already has this kind of process for pilot feature which then move to beta then to GA and it's well written that things might change a lot (or disappear) when moving to GA.

Why can't we have such flexibility with LWC ? I find it so frustrating to know that the framework has a feature I can't even test because it's still in experimental state.

[diervo]

@Bartheleway I agree with your sentiment, let me explain you more in detail the technical and business reasons:

Let's say we introduce a feature like lwc:dynamic as pilot or beta (the name is irrelevant).
You and 3 more customers build some components and then push them to production.

Let's say next release we decide it was terrible and we want to remove it. The problem is 4 customers already have it in production, and if we remove it your components will stop working (your org will be malfunctioning), and we can't just do that (legally we have to go though a deprecation process, warnings, etc...). Even if we do API versioning we will be bound to support it until every customer has stopped using it. Which means that so long as 1 customer is using it we will never be able to take it back if they don't change their components. Thats is the painful reality we live in :)

The model we are exploring is that instead of having a feature for all at once, advanced developers/ISVS like yourself can opt into it, so 1) we have more control over 2) we know exactly which components 3) we know who is the developer/isv 4) and how widespread, so we can potentially really deprecate and kill a feature.

The premise we make our customers is that we will never break them, which is a blessing, and a curse :)

Feel free to give feedback to @Gr8Gatsby (he has office hours) as he is the one exploring the model of how to allow advanced features to be enabled.

[Gr8Gatsby]

@Bartheleway if you want to have a more in-depth conversation you can book office hours with me: https://calendly.com/kevinjhill/office-hours, I'll invite @gregwhitworth too!

[Bartheleway]

@Gr8Gatsby thanks for sharing this opportunity, I can't find a proper time to book as we live in different timezone area. Is it okay for you to continue the discussion here or by private message ?

@diervo thanks for this explanation it makes a lot of sense.

I acknowledge that deprecation process can be a long journey. As experimental feature are subject to change or might never goes live, it seems indeed difficult to add it even for tests in Salesforce orgs. I was first thinking that enabling experimental feature would be a sandbox only feature and then realize that a sandbox can live for a very long time and is subject to automatic version upgrade. Because of this it is irrelevant to add support for experimental features in such environment.

Thinking now about scratch org, because of their limited lifetime, they might be better candidate for experimental feature enablement. Let say we have a way in the scratch org config file to enable LWC experimental feature (or other Salesforce features). During the scratch org creation, Salesforce would be able to check if the setted experimental flags are still supported and even give additional information about deprecation / replacement. This would allow developers to test early some features and would allow easy removal if they don't make it to GA state. What do you think ?

I'm really happy to finally be able to contact some kind of dev team and be able to argue about features. Not being able to have that kind of conversation with Salesforce is something that has been frustrating me for years now.

[nolanlawson]

This would be difficult to enumerate comprehensively. Sometimes we do a phased rollout, or a pilot program, or another system where only some % of usecases on the Salesforce platform actually have a given feature. That said, it would certainly be useful to have some docs at lwc.dev that could tell you, at a glance, which features are available or not.