Sp-dev-docs: SPFx and/vs WebComponents?

Created on 29 Oct 2016  路  8Comments  路  Source: SharePoint/sp-dev-docs

Category

  • [X] Question

3 years ago I was excited to see HTML evolve: https://www.youtube.com/watch?v=fqULJBBEVQE&feature=youtu.be

Note: It is not so much about the technology perse,
it is about the concept that the Client(Browser) is 100% in control,
and the Back-end is only a data container.

Which makes me think, what if we could do:

<WEBPART [property=value]*></WEBPART>

Store Components/Widgets/Webparts as files in a Library,
SharePoint would be a container only.

Would be a whole lot simpler for Generation J (query) than the current SPFx stack
Which still relies on SharePoint (Back-end) being in control.

Is this the CEWP on steroids?

Thoughts?

Most helpful comment

We looked into web components when we started planning SPFx and we did not go that route just because it is not yet ready for prime time. Instead, we chose to build a system that is agnostic of framework and can also be used to also load web components if developers wish to do so.

Not to mention that there is complexity if you specifically want to use Shadow DOMs yet get the same capabilities that web parts offer like page interactions, web part to web part communication etc.,

From where it is today, web components will certainly play a role in web parts in the future. However, it may not be the only thing, rather an option, that developers can choose (which I believe you can do it today too).

All 8 comments

For context to the rest of the group, this is coming from a discussion on stackexchange here - http://sharepoint.stackexchange.com/questions/197612/content-editor-webpart-vs-spfx

I'm not exactly sure what you are referring to though. Do you mean that you want people to write arbitrary javascript code anywhere?

@patmill He is refering to Ploymer or the Microsoft sponsored X-Tag or whatever you use to write web components. It's not again another framework. It is a web standard document on the following page.
W3C Spec on GitHub
While Chrome is currently the only browser that full supports web components, this will take some time to be supported in the current browsers.

Definitly a hot topic for the future but for now React, Angular2 and others follow some similar approaches.

Not sure it will take that much time for web components to take hold. Web components is a collection of 4 specs... Chrome & Opera implement all four, but all browser manufacturers (Apple / Mozilla / Microsoft / Google) have all stated they will support web components. My understanding (as of a month ago) is that MSFT is the only one that doesn't have active dev working on it now for Edge / IE. The http://webcomponents.org/ site has two blocks on the homepage that do a great job showing what's supported today & what the specs are.

IMHO, web components are the ideal solution for web parts as everything about that component is 100% isolated from the rest of the page thanks to the shadow DOM thus neither external nor its resources (JS, CSS, HTML) can mutate the rest of the page or be mutated by something else on the page. Thus, no need for random CSS class suffixes.

It all depends on how long it takes to get the other three specification out of the draft status.
Internet Explorer team is betting on this as well and already have implemented the <template> part.
Currently the only one that is not draft anymore.
There was a good article by the IE Team on web components but it is from July 2015.

The only browser that fully supports this nativly, according to caniuse, is Chrome because it was their idea.

We looked into web components when we started planning SPFx and we did not go that route just because it is not yet ready for prime time. Instead, we chose to build a system that is agnostic of framework and can also be used to also load web components if developers wish to do so.

Not to mention that there is complexity if you specifically want to use Shadow DOMs yet get the same capabilities that web parts offer like page interactions, web part to web part communication etc.,

From where it is today, web components will certainly play a role in web parts in the future. However, it may not be the only thing, rather an option, that developers can choose (which I believe you can do it today too).

Just wanted to add here that my pubsec customers are very slow to update to the latest browser. So whatever it is we do, it should be addititive if possible.

I'm going to close this down for now. We're not saying No to the future, just not in the next while.

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues

Was this page helpful?
0 / 5 - 0 ratings

Related issues

StfBauer picture StfBauer  路  3Comments

nanddeepn picture nanddeepn  路  3Comments

karishmaTCS picture karishmaTCS  路  3Comments

mikeparkie picture mikeparkie  路  3Comments

patrick-rodgers picture patrick-rodgers  路  3Comments