So you just heard about this thing called web components and you did a quick google search. apart from a few tutorials and some github pages you al...
For further actions, you may consider blocking this person and/or reporting abuse
Frameworks are not the language!
One of the points why I am so strongly inclined to use Web Components is because they are part of the web standard, while frameworks like React try to create their own standard, they also damage the opportunity to adopt tested and well developed standards.
I use Web components because specially at a large organization it simplifies the delivery of consistent design systems and solidifies the way we work in large teams, that is not to say I don’t use React, I do; but when it comes to delivering a set of components that can be shared and used across multiple fev experiences, web components provide a solid and standard set of tools that go directly to the browser instead of going through the build system.
One of the reasons why I believe developers are affraid of web components is because some of them are not consumed as dev/build time dependencies but as runtime dependencies, but this is the way javascript really works, in the window you are not working with your framework of choice anymore, you have left that nice IDE world and now you are working with the browser’s operation.
I think it is of most importance to know the platform you are working with before even knowing the ways to simplify development on it. Web components are a great native way to encapsulate logic, style and markup within a container that is standardized and unified across (most) browsers. Give them a try
PS: of you do miss react, Stencil’s dev experience is ~95% the same
Yes, but style encapsulation is also presented as its biggest con. but that is not true. developers dont have to use Each and Every technologies of the web component suite. if you dont want style encapsulation then just dont use Shadow DOM at all! and if you are following BEM methodology, you will not see any side-effects. Shadow DOM is just for heavy, self-dependent Web Components. and yes Stencil's DX is almost the same as React. and there are also Hybrids.js and Switzerland.js if you want to write functional web components that are quite similar to the React ones.
Agreed!
Most of thetime I don’t use shadow on my web components but for enclosed design systems I would argue that style encapsulation is really good it does prevent major style collision problems when working at larger scales
Do you think that web components is ready? i mean do they have what is required to make whatever a dev might need. or they still need impovments?
Short Answer: Yes! Web Components are ready for production.
Long Answer: it really depends on what kind of project you are working on. for a small to medium size product web components are perfect. but if it is going to be a big project, then due to lack of resources and support, you will have to build many things on your own which are readily available in other frameworks.
The closer you are to the metal the longer you will survive without learning something new.for me that is the gut of web components.
This is the driving force behind the development of Web Components API. Frameworks come and go and because most of them force you to learn their way of programming and tools, which may first seem to be easy and pleasing but later when these frameworks die or become less popular you are forced to abandone it and learn a new framework that is currently trending in the market and the cycle goes on. Web Components are here to save us from this vicious cycle. what it needs is a series of some minor and major improvements and some good tutorials. I am thinking about starting a series of tutorials on Web Components.
That would be very nice. I've read up a lot on what web components can technically do, but I don't have a clear image of how they would ideally be used for anything bigger than a basic hello-world-component.
I started a series of Dev.to posts last week; based on real world Web Components
That's really awesome pal. i will surely check em out.
I think one of the things that hold web components back is the lack of declarative programming.
Most frontend devs learned components through some UI framework or library that is declarative. Having components in Vanilla DOM but having to code them in an imperative style might feel like a step backwards for some people.
Also, some JS devs don't like using classes, and that's a problem because Custom Elements requires using them.
Yeah i agree that Web Components API needs improvement but you can already use libraries like Hybrids.js or Switzerland.js for creating web components in "functional" way and completely avoid the use of classes.
The collection of APIs we often call "web components" aren't really supposed to be a finished product; they provide low-level access to browser features that let you do almost everything you need, but at the expense of making the most common cases more cumbersome than necessary.
The point is that these APIs make it much easier to build your own declarative systems without having to bother re-implementing too many of the same features every time.
I personally don't even like frameworks like Vue or Svelte too much, because they're a bit too declarative for my taste, meaning I give up control over how data flows through the application. With web components I can build my own micro-framework with like 50 lines of code and continue building stuff on top of that instead.
Yes Web Components were meant to be used in that way. You can either write your web components using vanilla js or you can use a collection of tiny helper libraries for performing different functions like routing and state management. and its not like there are no libraries available out there. there are over a dozen libraries just for adding the routing functionality in web components, but they are all either badly documented or lack any support from the community. i urge the Web Component community to come forward and start helping the newcommers and do more than being a Symbolic entity.
Honestly, what we need is a standard for web components that allow it to interact with the various frameworks out there, specifically, it should be able to react to changes in attributes, and emit events back to a state manager. I wonder if there's a simple HOF that can make this simple enough.
The reason why this would be a game changer is because every company seems to have it's own branded UI library, making components for React, Vue, or whatever they're using. What would be a game changer is if you could write those components as web components so that each team can choose whether to use them in React OR Vue or whatever framework, essentially allowing companies to avoid vendor lock-in for front-end frameworks.
Everything you mentioned above is already implemented in Web Components.
static get observedAttributesmethod inside the class and a method calledattributeChangedCallbackwill be invoked every time the attribute changes which will provide you with both its previous and current value so you can compare the changesOne point to add.
Web Component technology is older and more used than most people know.
The
<video>, <audio>, <textarea>, <input>and many more complex HTML tagsare implemented in each Browser with Web Component technology.
In Chromium you can tell by the user-agent (= tech term for Browser) label on the shadow-root:
Us mortal developers can not access the HTML elements inside user-agent shadow-root.
Also see: javascript.info/shadow-dom
But... that technology was not available to us 3rd party developers
What we now call "Web Components" (Custom Elements API, Templates, shadowDOM)
IS that very same technology available to us all
But we can't access user-agent managed shadowDOM!
So everyone who claims Web Components is young, not yet fleshed out, bare metal, hardly used, technology...
Does not understand how the Browser works.
I don't hate the idea of web components. As a matter of fact, on every project I've worked on we've created reusable components in different frameworks (good code practices, yadah, yadah, yadah). I've never worked with them directly, so I can't say more, until I try.
I always been using web components above any framework, and that too a custom tiny concept. Main reason it is fast, no compiler complaints, I know how the engine works and only js knowledge is required. This blog tells how to create one, or just search this form,
creativebloq.com/features/web-comp...
Thank you for the article, we should have more of those!
Web components are not a replacement for [your favourite library], they can be used alongside any. And that's the main aim: reusability across all different frameworks and lack of thereof. In other words, web components are tiny building blocks and the glue is not included.
What's for their popularity, it's worth mentioning AMP framework, that is based on web components and used wildly.
I accept that Web Components are not a replacement for any full fledged framework. but even React is just view library which depends on other packages and libraries for making a fully functional website. In the same fashion we can use various tiny libraries for performing different functions required to make a full fledged website. like for routing we can use the Vaadin router or Slick Router and we can use Rxjs, Valtio or Akita for state management. but due to lack of tutorials and experience, new developers get scared by the fact that they will have to learn to bind all this pieces together on their own.
Why do I need a programming language to make web-components work? I think HTML tags should be the only thing needed to work with web-components
The Answer lies in your question. You need a PROGRAMMING LANGUAGE to create web components cause you cant write LOGIC using HTML. HTML is a markup language, not a programming language. and a custom element without logic will be nothing but a generic div tag you can apply styles to.
Correct but what bothers me JS is the only one why not ship HTML/CSS as a framework in the future? Sounds crazy but I mean the whole rendering engine as a installable framework wasm could do this maybe so the browser could be just a wasm runtime that way other languages can maybe have DOM integrations to not only JS.
That's a good idea. but i doubt that this idea can be materialized anytime soon due to the reasons pointed out in this thread Why Wasm cant replace JS. plus Javascript is a language that was designed just for making websites interactive while wasm is a general purpose programming language. so you will still have to use some kind of framework for DOM interactions.
I hope that one day we can do this because that would catapult HTML/CSS development and no one need to worry about compatibility because the developer decides which version of HTML and CSS he will use in a project and he can be sure it looks everywhere the same.
I personally think web component is the future.
I have created bloc (business logic component) based framework : npmjs.com/package/bloc-them
And have created component library built on top of it.
npmjs.com/package/use-them
For a more objective discussion, read about the advantages and best practices concerning Web Components: devopedia.org/web-components