10

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?

Danilo Puric
  • 779
  • 2
  • 13
  • 23
  • 10
    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 Mar 19 '19 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 https://github.com/Polymer/polymer/issues/5240#issuecomment-391337152 – Danilo Puric Mar 19 '19 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 Mar 19 '19 at 21:40
  • Yes you are right! Web components do not need a framework to be built. Those three listed only make it easier by abstracting some of the boilerplate, such as templating, managing state, and updating DOM. I'd add that lit-element provides more freedom of options. Your not coupled so tightly to a framework's methods. LitElement is tiny in size, very fast atop lit-html. – Danilo Puric Mar 20 '19 at 08:08
  • 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 Mar 21 '19 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 Mar 21 '19 at 14:41
  • @Intervalia, cool... we share the same TRS-80 history. I use the 4K memory of the Model-I I started on in 79 as reference for WCs.. although at the moment I struggle to get 52 playing cardts into one WC – Danny '365CSI' Engelman Mar 21 '19 at 14:53
  • for anyone coming here from google search, this article done a pretty good comparison between the vanilla-js, lit-element, stencil https://thangman22.medium.com/stencil-js-vs-lit-element-vs-vanilla-vs-shadow-dom-vs-vue-js-5d2ade971183 – mehrdad May 07 '21 at 18:20

2 Answers2

9

If you want to build:

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

web components you could also consider using VanillaJS framework :

http://vanilla-js.com/

Supersharp
  • 29,002
  • 9
  • 92
  • 134
  • 2
    `Vanilla-js` the only way to go for easy to write, easy to debug and easy to maintain web components and it even works to entire applications. – Intervalia Mar 29 '19 at 00:04
  • I read about vannila js but it seems it is quite old fashioned. Recently I discovered that https://storybook.js.org/ is getting very popular. What do youthink about this? – Danilo Puric Apr 05 '19 at 13:24
  • storybook is another thing. It just helps you to expose and document your components, despite you use react, vue, angular, lit or whatever to write them. But is not a framework to write webcomponents – David Feb 27 '20 at 10:28
  • This seems re-inventing the wheel to me. after all, you have to write all the necessary codes and setup the project and there are lots of people who done it previously and they are actually good. "People think that computer science is the art of geniuses but the actual reality is the opposite, just many people doing things that build on each other, like a wall of mini stones." - Donald Knuth – mehrdad May 07 '21 at 18:01
  • "Easy-to-debug"... As long as it is an hello-wold project maybe – EuberDeveloper Jul 22 '21 at 14:47
  • 1
    @EuberDeveloper When I write Easy-to-debug it's because you can use the embedded dev tools or connect Javascript debugger. When you use a framework you need additional components – Supersharp Sep 15 '21 at 15:24
6

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:

enter image description here

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:

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

connexo
  • 53,704
  • 14
  • 91
  • 128