I want to start leveraging W3C standard which is now supported by all major web browsers.

I researched the internet and so far I found following frameworks:

1. Stencil - Created by ionic. All ionic components use this framework/compiler in order to build native supported web components.

2. lit-element - Created by Google and is part of Polymer framework.

3. SkateJS - Don't know how is behind this but it is in top 3 popular web components framework.

Can someone give me advice or opinion which framework is best?

I want to start leveraging http://webcomponents.me W3C standard which is now supported by all major web browsers.

I researched the internet and so far I found following frameworks:

1. Stencil - Created by ionic. All ionic components use this framework/compiler in order to build native supported web components.

2. lit-element - Created by Google and is part of Polymer framework.

3. SkateJS - Don't know how is behind this but it is in top 3 popular web components framework.

Can someone give me advice or opinion which framework is best?

• javascript
• web-component
• stenciljs
• lit-element
• native-web-component

• 11 While this is an opinion question and will likely be removed I will chime in to say that I only write native elements with no framework. I use these elements in any framework. I wish more people would work like this. Anything that can be shared should be written in 100% pure JS and then used wherever needed and in whatever framework needed. That way you are not forcing someone else to use an additional framework if they don't want to. – Intervalia Commented Mar 19, 2019 at 20:33
• 1 Web frameworks like stenciljs and lit-element are very small and very helpful. They can help a lot in building web components by providing utils and environment to build components faster. Last year google decided to stop developing Polymer framework in favour of LitElement. Take a look at following link github.com/Polymer/polymer/issues/5240#issuecomment-391337152 – Danilo Puric Commented Mar 19, 2019 at 21:03
• 1 In my mind any framework larger then about 2K is too much for shared components. This is my opinion. While others may not share it I think it would make for better re-usability if developers were to stop depending on frameworks for shared components and just write native components. – Intervalia Commented Mar 19, 2019 at 21:40
• 4 There is no "best".. 13 years ago we had Yui and MooTools and 15 other libraries that did the same as jQuery.... and where is jQuery now?? Frameworks and libraries are like the canned and packed ingredients you buy in the supermarket. Sure you get a meal on the table. But go buy groceries, taste spices, learn how to cut, bake and grill and you will be a Chef. ► Learn the W3C standard way of Custom Elements/Web Components. – Danny '365CSI' Engelman Commented Mar 21, 2019 at 14:34
• 3 And Lit is definitely not freedom. Same as ReactJS it uses the Virtual-DOM approach, which means you must do ALL DOM operations through Lit... You can no longer do direct DOM updates yourself anymore because if you do... Lit has no clue whatsoever what happened. So you can forget about Client Side thinkering in F12 Developer Tools. Like React or Angular you need to go through your whole Build process again. – Danny '365CSI' Engelman Commented Mar 21, 2019 at 14:41

2 Answers 2

If you want to build:

• Fast
• Easy-to-debug
• Cross-browser
• Framework-agnostic

web components you could also consider using framework :

http://vanilla-js.com/

As I've been working with native vanilla JS web components for the past 4.5 years as my main subject, I would like to add my opinion as a seasoned web developer with almost 30 years of experience.

As with all development tooling, these tools share a common problem. Either they

• evolve - forcing you into an undesirable update loop, keeping you busy with stuff that's long-finished just to keep the tooling fresh and secure,
• or they just "die" - check SkateJS e.g. The last commit on that repo is now 3 years old and open issues from 2019 exist that haven't even been commented on. The latest release is from 2017!!

This is not only true for authoring tools like the three suggestions you mentioned - this is also true for the whole build stack tooling.

Last year I took a dive to see what kind of modern build tools would be nice to work with for authoring web component libs. When doing the research, I stumbled upon Snowpack and Vite.js. We started out with Snowpack, but at the time it still seemed to have a number of stability issues, so we decided to switch to Vite.js. Last week I decided to give Snowpack another shot, only to find it deprecated in favor of Vite.js:

Stuff like this happens way too often, and while tooling should help you get stuff done faster and better, more often than not you find yourself dealing with the shortcomings of the tooling, incompatibilities with addons when updating the main library, security issues... rather than focussing on doing your business coding.

This is also true for popular tools like Storybook.

Once you start relying only on ECMAScript itself, and the browser API, you'll learn that most things like e.g. routing for SPAs are quite easy to develop yourself.

You probably won't need a build stack any more very soon. We have widespread support for HTTP/2, making bundling undesirable anyway, so just work with native ES modules. Not using a build tool and not bundling also has the huge benefit of not having to generate and rely on maps any more; let alone the fact that it immensely improves the development experience by keeping turnaround times in no-matter-how-complex projects in the ms realm. Code-you-write-is-code-that-runs - how amazing is that? No third-party-black boxes when your debugging leads you into code that would take you years to understand.

Instead of CSS preprocessors, work with native CSS and custom properties - native CSS nesting is coming to browsers as well.

To go fully build-less, there's unfortunately still some bits and pieces missing, but those are in progress. The most important ones are:

• CSS Module Scripts <- We have these now. HURRAY :)
• HTML modules
• JSON modules (Stage 3)

Some libraries are already picking up on this, e.g. ficus.js.