32 ms·

Web Components could replace frontend frameworks?

450 points by technojunkie 7y ago

aphextron 7y ago
I love writing Web Components, but they're never going to really be a thing. The promise was that we could create native components without any dependencies at all but it just hasn't worked out that way. Shadow DOM support, the real killer feature, is patchy at best without polyfills. Orchestrating them into any kind of complex app still requires some kind of framework to handle things like passing down props and event binding, which at that point you might as well go full on (React/Angular/Vue) + Webpack/Babel. The dream of being able to share reusable components breaks down the moment your designer wants an extra 5 pixels of padding here or there. It's fun to use them for small things but it's just not viable as an alternative to frameworks.
- reustle 7y ago
  (sorry, I'm not well versed in some of these things) Would it make sense for React to start using this native web-component at some level moving forward, to improve efficiency ? Maybe another library will replicate most of Reacts features but is powered by this native (faster/cleaner) technology?
  - wwright 7y ago
    afaik web components are mostly about encapsulation and semantics; they let you box up arbitrary HTML, JS and CSS and put a little bow on top so that it looks like one “custom” HTML tag to the rest of the document. (I could be misremembering.) React is mostly about life cycles, propagation, and composition. The first two are orthogonal to web components afaik. The third has some overlap, but it’s mostly complementary with web components (once again, afaik.)
  - paulddraper 7y ago
    Angular has kept web component compatibility as a high priority. You can publish angular components as web components, and even leverage native functionality like shadow Dom.
- yesimahuman 7y ago
  Strongly disagree. We (Ionic) built our new version directly on top of Web Components and they are certainly a thing for us and our users building real apps on top. Plus, they are a huge reason why we now support React and Vue and plain JS. Frankly, this has been transformational for our project and for our business. I'm completely sold. One problem with the WC debate is people constantly compare the raw Web Component collection of APIs to a framework, when in reality, you'll add in libraries or extras on top of your Web Components to get similar functionality (like Stencil: http://stenciljs.com/ http://stenciljs.com/), but you'll likely not build apps with them as much as you'll build components to share with others. In that sense, the killer app for Web Components is actually Design Systems, not SPAs. I disagree with the idea that Web Components replace your framework, however. They solve different problems! For Ionic as a cross-platform Design System, they are a major asset.
  - benforreal 7y ago
    I'm glad to hear this take. I came from Angular v1 and got sick of the framework churn, so jumped over to Web Components around 2015/2016 instead of going React. I abandoned Polymer pretty quickly around v0.6 because things were changing too much and just went plain vanilla JS + Web Components. I've been building applications since then with just Web Components and couldn't be happier. Unfortunately I just don't have enough experience with React to debate any of these points - I guess I just have to leave it that React is a need I don't have.
  - KuhlMensch 7y ago
    > In that sense, the killer app for Web Components is actually Design Systems, not SPAs. My read too
- spankalee 7y ago
  > The promise was that we could create native components without any dependencies at all This isn't true at all, and it's a big misperception about web components. Web components are pretty low level APIs that expose a few abilities that the browser natively has: defining a tag name, hooking into element lifecycles, creating an encapsulate DOM subtree. Web commonness have no opinion on rendering, state management, etc. and leave other aspects, like responding to property changes, to existing features like JavaScript accessors. It's expected that developers will use libraries to help implement web components, but the libraries won't have to implement a component model, or DOM composition, or CSS scoping. So they'll be smaller and more focused, and the overall product will be faster have fewer proprietary parts.
- colordrops 7y ago
  Shadow DOM is now supported across all major browsers. Also, don't understand your padding comment. Web Components are style-able.
true_religion 7y ago
The shadow dom is just JavaScript, HTML and CSS. For any significantly sized component I would want a framework to wrangle all that.
- Spivak 7y ago
  I don't really think end-devs are the target audience for Web Components. I see two users that will benefit: * Framework/library authors that now have a higher-level and hopefully more performant primitives to build on. * Widget library authors that can now design component libraries that can used by any framework.
revskill 7y ago
It's not about implementation details, it's about programming paradigm. In the case of React, it's - Declarative, functional API to write reuseable UI. - REAL reusable business logic with React Hooks. - REAL universal data fetching with React Suspense. - REAL error boundary with Error Boundary. - Learn once, write everywhere! Do Web Components have the above benefits (yet) ?
- galaxyLogic 7y ago
  Of course not. But many smaller apps don't need all of those. Think about HTML how it started it was very rudimentary. At that point there was very many better "frameworks" for creating GUIs and applications. Yet HTML was in many cases good enough and since it was so simple it was able to evolve.
wokwokwok 7y ago
So I tried web components two years ago, and it was very painful, and I crawled back to react. Why should I invest my time in it now? IE support? Are you kidding me? I really wanted web components to take off, but they didn’t. Without a new compelling narrative, I fail to see how they are “the future” in any meaningful sense. Releasing an early version of something that is bad and doesn’t work (and let’s not pretend the shadow dom polyfill works, it doesn’t)... it’s just, not the right way to do this sort of stuff.
- boubiyeah 7y ago
  No more reason now than 2 years ago.
rovyko 7y ago
CSS is still a pain in Web Components. Constructable stylesheets solve that problem, but they're still in the "Worth Prototyping" stage for Firefox. https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/
jchw 7y ago
>Web Components will replace your frontend framework Yeah, I very much doubt that. Web Components is basically a suite of browser technologies. It's actually particularly heavy and I kind of hope it doesn't catch on personally, since it pushes so much to already giant monolithic web browsers. Frameworks and libraries like React and Angular are tools for developing applications first and foremost. The actual technologies they're backed by doesn't matter, but if you can't reimplement either of them using WebComponents it should probably tell you something about WebComponents: - It's very opinionated about a lot of things. - It disagrees with many of the (much more popular) frontend frameworks far too much. React does a whole lot of things right, and it does them right in a relatively small package with a relatively small API surface, and you can extract the essence into even smaller libraries. With functional components, you can even build React components that have almost no React in them at all, other than JSX. I don't think we need new complicated technologies to solve the kinds of problems React solves. If anything, we need less, like an alternative to the current DOM model. Most of the innovations in the frontend world don't seem like they can be cleanly applied to Web Components, or even layered on top of it. And if we want to update it down the road to a new major version, we have to wait for every major browser vendor to have a stable implementation and iron out edge cases/differences. That's not a good bet at all based on how it went with Web Components the first time. In other words, No Thanks, I'll take my framework.
- davidjnelson 7y ago
  Curious what you think about React Canvas https://github.com/Flipboard/react-canvas https://github.com/Flipboard/react-canvas
  - jchw 7y ago
    I don't necessarily think everything should be Canvas, but rethinking the way pages render wouldn't be a bad idea. The issue I take with Canvas in particular is that it's poor for accessibility, password managers, and other services. I think part of the reason why the DOM and layout engines are so slow and complicated is just because of years of cruft and whatnot. A minimal layout engine with most the abilities of Flex and Grid would be nice.
ssorallen 7y ago
Web Components don’t offer a declarative way of updating the DOM; it’s still `innerHTML` and using DOM APIs to edit the state of the live DOM. Backbone was a hassle to manage in any sizeable app because updating the view was left up to every dev to figure out themselves. React brought a declarative wrapper around the statefulness of the DOM, and that is the killer feature that Web Components does not offer at all. Vue adopted the declarative template approach as well. The Web Components spec was written before React and Vue were very mature, and it unfortunately shows. Web Components might offer a better primitive for higher level frameworks to build on, but I would not suggest to anyone to use barebones Web Components over React or Vue.
- dosy 7y ago
  what about slots?
  - lstamour 7y ago
    Slots require shadow DOM which means there can be performance and CSS issues on widgets designed for local use with shared CSS. But I agree they’re also an option. :)
    - FiddlyPack 7y ago
      :part and :theme CSS puesdo-selectors will help address these issues
      - no_wizard 7y ago
        you can also use :host, which target the custom element specifically (and using :host on custom-element children does not, from what I recall off hand, get broken when nesting) and then target its children. Also, css variables can be global and still enter into the shadow-dom unobtrusively (This is without using the polyfills, though, I believe this is a limitation in the polyfills currently, which might be why that part of it has been confusing in the past.).
    - 7y ago
AaronFriel 7y ago
The tooling is woefully inadequate, and the premiere Web Component tool is stringly typed to all heck which makes it a non-starter for me. I don't want giant blobs of runtime parsed text with no validation, syntax highlighting, and obviously no type checking. But yet, here's Polymer 3: static get template() { return html` <style> .response { margin-top: 10px; } </style> <paper-checkbox checked="{{liked}}">I like web components.</paper-checkbox> <div hidden$="[[!liked]]" class="response">Web components like you, too.</div> `; } Cool. What an enormous regression over TypeScript with React and Vue. My editor just sees components as enormous blobs of text, and what do you know, so does my build system.
- staticvar 7y ago
  Polymer is deprecated in favor of LitElement which comes with TypeScript decorators.
  - chmln 7y ago
    With LitElement you are still encoding markup in strings and only the interpolated expressions are typechecked [1]. Not to mention that LitElement is far more clunkier and tedious. [1] https://lit-element.polymer-project.org/guide/start#use-litelement-typescript-decorators https://lit-element.polymer-project.org/guide/start#use-lite...
    - spankalee 7y ago
      The lit-plugin VS Code extension provides type-checking and code-completion for lit-html temptlates. The approach can be adopted for a tsc plugin.
      - chmln 7y ago
        Looks like there is a typescript plugin already [1], meaning this is not restricted to VS Code and should theoretically work in any editor with LSP support. That's better than I thought. [1] https://www.npmjs.com/package/ts-lit-plugin https://www.npmjs.com/package/ts-lit-plugin
rhacker 7y ago
It's insane to me that everything Polymer was got reduced to LitElement which is basically a complete copy of React without React and without the immeasurable support of typescript, VSCode support IN the view and debugging directly in the TSX.
- staticvar 7y ago
  The lit-element package comes with typescript decorators.
- ernsheong 7y ago
  You can use Typescript with LitElement https://lit-element.polymer-project.org/guide/start#use-litelement-typescript-decorators https://lit-element.polymer-project.org/guide/start#use-lite...
- thosakwe 7y ago
  Yeah, I didn't really understand why there was a need for an overhaul like that. I honestly was hoping that there'd be a better story for databinding, types, etc. I just gave up and went back to React.
  - ernsheong 7y ago
    Polymer was trying to do too much (to be a framework), and the quality was average at best. LitElement is able to focus on providing the best base class to build a Web Component. I think it is almost there.
anthonyshort 7y ago
I don’t understand the push to make userland component abstractions into native primitives. It’s perfectly fine for the browser to just implement low level primitives for frameworks like React to build on top of. It allows the framework to develop much faster. Web components kind of miss a lot of the reasons why React has taken off. Encapsulation is one thing but it’s the declarative way of handling state, effects, and the DOM that make it powerful. Web components would need a framework on top of it to make it usable by developers building anything significant.
- yesimahuman 7y ago
  They aren't trying to solve the same problems. The main problem they solve, that no other userland framework solves, is that I can now share a collection of my rich JavaScript components with every single web developer in the world regardless of the technology they build web apps with.
  - anthonyshort 7y ago
    I can imagine a world where this would be useful, being able to drop something in as easy as a <select/> element seems fine. It seems useful for UI primitives, like a dialog, tooltip etc, that the browsers might not implement as native elements themselves. But as a building block for creating entire applications? I don’t think so. Which means they’re always going to need to hook into the framework that’s rendering them, either to connect state, managing effects, or for styling. I just don’t see sharing a component regardless of framework as a major problem worth solving right now. Buy into a framework and community like React and you can just drop components into your app. It’s not framework-agnostic but it works.
  - hesarenu 7y ago
    I would rather have browser provide rich components then rely on third party.
    - cletusw 7y ago
      That's one of the huge benefits of web components -- third parties can iterate quickly to find useful patterns, then browsers can just standardize the best/most popular ones. The old way of discussing ad nauseam in committee then implementing straight in the browser gave much less useful elements. (And it's much less straightforward to convert a popular React component into something browsers could implement natively.)
revvx 7y ago
I strongly believe Web Components will catch on, but not in its vanilla form. Writing code for them is a pain in the ass for non-trivial stuff. They're too low level compared to modern frameworks. IMO the future of the web will be about compiling React, Vue, Svelte, to Web Components, for interoperability reasons. And nope, Polymer isn't as good as any of those.
Aeolun 7y ago
Given that they were introduced in 2011, and in regards to their usage you hear... well crickets I think we can safely say that web components have failed. It doesn’t look similar to React at all, and still suffers from the same issues that jQuery does.
- hyperpress 7y ago
  > Given that they were introduced in 2011, and in regards to their usage you hear... well crickets > I think we can safely say that web components have failed. > It doesn’t look similar to React at all, and still suffers from the same issues that jQuery does. jQuery? I think your just making up nonsense there. Fully ten percent of the web is using web components at this typing, and it's continued growth is steady as more and more libraries and frameworks, excepting those least able to easily leverage them, bring them into the their own projects. YouTube, ING, McDonald's, and other adopters are some pretty loud crickets.
  - Aeolun 7y ago
    Nope, no nonsense, but the issue has already been repeated in a bunch of comments here, so I don’t really need to any more. > Fully ten percent Citation needed. I’m sure it could be true, but it seems a high number for something that I’ve literally heard about for the first time today.
    - hyperpress 7y ago
      Repeating what? The same outdated, misrepresented arguments mainly relied on by react fandom? It's simple, lot's of options out there. If comfort and loyalty clearly takes precedence over best solutions, you've already made the decision. The problem isn't that web components failed, or you can't pass objects via props, or that you think you need polymer, or their not browser supported, or they actually adapt in most existing Frameworks. The problem is turf, and react loves its turf. Just point out that arguing from a position of 5 year old specs, adoption, and knowledge isn't, IMO, very wise. Rather a self inflicted lost opportunity.
ricardobeat 7y ago
As expected, no mention of server-side rendering.
- westbrookjo 7y ago
  You can server side render a `video` element just the same way you would a `custom-element`. We've been doing it for years and there's no reason to think anything about that has changed. If you're looking to deep SSR which is arguable as far as benefit, check out approaches like https://github.com/ionic-team/stencil-ssr-starter https://github.com/ionic-team/stencil-ssr-starter
  - georgecalm 7y ago
    I think the difference is that the browser already contains the shadow dom needed to render the video tag. But for a custom tag it would need to fetch, parse and execute your component code before it can begin to render.
    - westbrookjo 7y ago
      That's an interesting read. I'm thinking on whether the real question is what is the declarative difference between the video tag, which by normal application lets everyone feel find about that content hidden by the shadow DOM vs the APIs we're developing for our custom elements. There seems to be an important piece of learning, not just for SSR, but for custom element development in general, that I think we can build off of.
- JackuB 7y ago
  This was exactly the reason I’ve abandoned them. As mentioned in other comments, they look like a good way to create a design/component system in them, because of the interop with any frontend JS framework (who doesn’t want that?!). So you deal with clunky CSS sharing and theming capabilities and there might be some solutions on the horizon. But now you want to build a static website with it (landing page, docs, blog…) and you can’t pre-render them, because there is no declarative Shadow DOM element https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Declarative-Shadow-DOM.md https://github.com/w3c/webcomponents/blob/gh-pages/proposals... (rejected https://github.com/whatwg/dom/issues/510 https://github.com/whatwg/dom/issues/510). Yeah, you can pre-render them without the Shadow DOM. Then if you want to make those chunks of HTML into WCT on load (sort of rehydration), it will trigger repaints, as you have to remove the chunk of HTML, put it into WCT and parse everything again. Or you don’t put it into Shadow Root, to prevent repaint - but at that point, if your components can work this way, why even use WCT?
pier25 7y ago
No. WCs can only replace one aspect of React or Vue. You still need a better way to manipulate the dom and react to data changes than pure vanilla.
bandy008 7y ago
It's a good development but this article is misleading and ignorant. Web Components cannot replace web frameworks like ReactJs, Angular or Vue. At least not yet. Im not sure if this guy have used any of these frameworks before.
deleted 7y ago
[deleted]
jaunkst 7y ago
Ploymer was a crapshow and HTML import a nightmare for load times. Unless some sort of topology bundling is provided for web components I'm out. We tried to do generic components for multiple frameworks based in webcomponets and it was an utter failure in practice especially for low band networks.
- zarzz 7y ago
  Allow me to float ZephJS at you as an example of a Web Component framework with a bundling tool to do what you describe. Simplifies everything about building Web Components. Introduction: https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3e https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3... Bundling specifically: https://github.com/awesomeeng/zephjs/blob/master/docs/ComponentBundling.md https://github.com/awesomeeng/zephjs/blob/master/docs/Compon...
  - IggleSniggle 7y ago
    This looks pretty cool, thanks for sharing.
- rossy 7y ago
  To be fair, HTML imports is deprecated and won't be standardised. The recommended way to package web components now is with ES modules, and they can be bundled (with eg. Rollup or Webpack.)
  - jaunkst 7y ago
    That is great, but I am still 100% sceptical of a web component intergration with any given framework. Is the integration point opinounated? Is it reactive, callbacks? Two way bindings? What does the application lifecycle look like? Would it be just opiononated sets of components? I just don't know... If I'm wrapping web components to meet our design patterns then why bother at all? I feel like the entire web component concept from an API level is a great concept but just not there for real world at scale consumption. I may just be not optimistic about it all.
threeaccents 7y ago
Web components are awesome I've been using them in production using StencilJS for a pretty large app for about a year now. Even though browser support is widely available there are still a few gotchas with web components, specially Shadow DOM. Not all community tools have caught up as well. For example you can't use Stripe v3 with Shadow DOM. Most analytics tools also cannot access the Shadow DOM. We had to remove Shadow DOM from all our components that were using it. In my opinion Web Components are definitely the future but there's still some catching up to do before we can claim it can replace frameworks.
- westbrookjo 7y ago
  You might be interested in https://github.com/bennypowers/stripe-elements https://github.com/bennypowers/stripe-elements Stripe v3 with Shadow DOM.
  - threeaccents 7y ago
    Thanks I had actually seen this while looking into a workaround for us. However I thought that LitHTML elements only worked with other LitHTML elements since you need the correct bundler for it. StencilJS projects don't have any bundling system.
    - westbrookjo 7y ago
      LitHTML and LitElement don't need a specific bundler, they work with whatever tools (or not) you'd like. You might want to get them another look!
zarzz 7y ago
The reality of Web Components is that it was never intend to take share away from the large frameworks. Instead Web Components is intended to fill the middle ground between a simple web page and a full blown web application. There is a real need for web page developers to be able to just drop in a prebuilt web component and go without having to reach for the 10,000 pound gorilla of frameworks. That’s where Web Components can have real value, real benefit. Is Web Components flawless, hardly. While the APIs are accepted standards and implemented in most browsers there are still a few holdouts, and to be sure there are still edges to iron out. No technology is without it warts, its awkward teen years. But Web Components is maturing and the tooling around it is maturing as well and Web Components most definitely has a place and is most definitely here to stay. Also it is worth keeping in mind that the Web Component APIs are specifically written as low level APIs and intend to be built upon by libraries and frameworks to simplify and aid the process. Libraries like the one I am currently pitching, ZephJS [1], which aims at making writing and distributing web components mind numbingly simple to do. ZephJS is a perfect example of the new generation of Web Component libraries to facilitate answering the need I espouse above: the middle ground between basic and beast that so many web developers live in. [1] Introducing ZephJS: https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3e https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3...
- Vinnl 7y ago
  > The reality of Web Components is that it was never intend to take share away from the large frameworks. Instead Web Components is intended to fill the middle ground between a simple web page and a full blown web application. Exactly. More specifically, it was created in response to the years-long hiatus in development of the HTML spec, when we were still waiting for a date picker element (heck, we still are!). With Web Components, we might all use the same widely supported and actively maintained emoji picker regardless of the framework we're using. But they do not solve the problems that framework solves.
iliaznk 7y ago
That's the case when a title is enough to see the author has no idea what he's talking about, that's convenient!
ramon 7y ago
A couple of days ago I saw a project here called pika which is any npm package it seems running in the browser, it's interesting to have the web components + pika where we can bring in different modules from npm and combine that with the power of web components then there really is no need for other frameworks but.. it brings that problem we used to have with JQuery which is lack of standards.. it seems we keep on going around in circles but web components are a lot faster and easier then React or Preact.. and the routing thing just makes everything fat for the bundles... then you have to worry about bundle splitting... the main/core bundle... pika is a good one because it takes the bundling off the bat and makes everything easier without the routing.. I now wish for a standard with web components and pika and doing the polyfilling... and ... material framework... and.. some coding standards just so we don't get a mix of Jquery and react and preact and a lot more in one single page load.
sergiotapia 7y ago
Being native to the browser, how fast is it compared to React? It is 10x faster because it's native? Is it on par, with room for browsers to improve it's performance even further? I'm all for something that's native to the browser. Right now you write a `<p>` tag for a paragraph element. No question about it. Imagine if you needed to use a P-tag library just to render a paragraph tag? Of course not right, you would just use the native browser `<p>` tag. I think that React is a P-tag library in essence. I would go all-in for a native version of "frontend framework".
- VvR-Ox 7y ago
  I totally agree - we need "one framework to rule them all". I don't want to learn another 10 technologies we won't use anymore in 5-10 years.
irenkai 7y ago
You are only thinking of one frontend, React allows a multitude of renderers, even the command line [0]. It has great tooling, awesome community, and it's pushed the boundaries of how we thought frontend development. https://github.com/Yomguithereal/react-blessed https://github.com/Yomguithereal/react-blessed
Andrex 7y ago
I argued for a similar case last year[1], however the missing piece right now is updating state in a clean way. Web Components definitely won't replace current front-end frameworks, but combined with ES Modules the web is getting to a good place for resuable primitives. :) [1] https://andrewrabon.com/the-case-for-react-like-web-components-63887335fe41 https://andrewrabon.com/the-case-for-react-like-web-componen...
- westbrookjo 7y ago
  Be sure to checkout lit-html and LitElement (https://lit-html.polymer-project.org https://lit-html.polymer-project.org & https://lit-element.polymer-project.org https://lit-element.polymer-project.org)...what you've written about here already exists!
  - threeaccents 7y ago
    Also give StencilJS a look. It's a compiler instead of a framework or library. The end result is pure vanilla components https://stenciljs.com/ https://stenciljs.com/
OnlyRepliesToBS 7y ago
great, more browser vendor lockin we've learned nothing from IE6 nor activex but 'trust us'
jasonkester 7y ago
I see a header and a footer and a big blank page. Whatever the author is using to replace his front end currently doesn't work on my iPad Air. But in answer to the question, no. I doubt it. I tried building a site using polymer when if first came out. It was harder than the in house thing I'd previously been using and after about a year, the spec had moved on and my site looked like this author's blog: a big white page and some JavaScript errors. I'm not the sort of person who enjoys rewriting my app every year to suit the whims of the framework it's on top of, so my plan is to emit boring HTML until something equally stable yet better comes along.
zachrose 7y ago
I wish the ideas of the Elm Architecture (or React/Redux) could be brought to the browser. Primarily, an atomic single source of truth (serializable data) for window.document and a way to connect that state to the DOM through pure functions so that we can avoid local component state that then has to be orchestrated with references, event buses, etc.
_the_inflator 7y ago
I think that the author misses the point. The question is how can we build better frontend apps and not should we use frameworks or not. In the end there are only tools for different purposes. Context and history are important to fully grasp WebComponents. WebComponents arose when there was jQuery and decoupling of CSS, HTML and JS. If you look back 10 years, there was no real separation of concern and Web purists like today always disliked the idea of mixing CSS in JS. Then came NodeJS and frontend build tools started to provide better tools (GruntJS etc.) for compile time checks. Encapsulating CSS in JS for example solved the problem of overuse of id selectors, greedy class selectors and namespace collisions - domains that WebComponents tries to solve with Shadow DOM etc. Todays frontend frameworks in combination with the underlying build tools provide a lot of the abstraction that WebComponents want to give developers. So I would rather say that WC are another tool which can be used by modern frameworks. It is like saying air pollution can be solved by driving slower on highways when there are only combustion engines. Why should teslas be punished for the wrong reasons? Same goes for WebComponents. Good idea, great abstraction but context is important.
deleted 7y ago
[deleted]
mmckelvy 7y ago
Web components will never take off because they are HTML-first and rely on DOM apis. The reason React is so popular and the reason it dethroned Angular, Backbone, etc. is because it is JavaScript-first. In other words, it gives you the power of a proper programming language to build UIs.
mikeytown2 7y ago
CMS static site builder based off of Web components https://github.com/elmsln/HAXcms https://github.com/elmsln/HAXcms
winterthedeep 7y ago
I worked with Polymer-based components ~2 years ago (an eternity in frontend-land), and I want to share my biggest pain point: you may want to integrate a `<cool-carousel>`, but it does not "look right" in your design (eg white website, but the carousel has a black background). If the author did not set up CSS variables, you have to either try overriding stuff, or fork it. This problem is why every organization (eg GE with Predix or Electronic Arts) had to create their own components, so they can share the same "art style"/design. Can you share your experience about that?
- boubiyeah 7y ago
  No matter the underlying technology, "lightweight, truly reusable UI components" is almost an ideologic dream, at the web scale. (some companies might achieve it on their own scale with a lot of effort, but not sure for how many years) As the maintainer, you don't want to cave in and add every possible configuration option people ask for so you have to decide what's a good, thin API for your component and it will never be enough for some usages. Styles are that much more subjective and even vary with design trends over the years! It might be possible for very, very simple components like text inputs but then again, those are also the simplest to code directly in your framework, so you could wonder, why bother with an inferior programming paradigm in the first place? The sweet spot for web components really seems tiny.
- fbn79 7y ago
  Web Components are an anti-pattern
  - EtienneK 7y ago
    Please expand on this point?
- benforreal 7y ago
  In the instance of Predix (I peripherally worked on that during my time at GE) and likely EA and every other large Web Component ecosystem you're thinking of, that's desired behavior. The real want is a design system such that things look consistent, but as design systems are CSS only, they aren't smart enough for interactions that require JS. So then the need for a design system becomes a need for components of some kind that include the design. You're looking for components with more adaptable design, but that's just not the intention of these ecosystems. If done with that goal, yes CSS vars take you a little bit of the way, but I think we'll see more power coming to help out soon with Shadow Parts/Theme, CSS Modules, and Scoped Stylesheets. But really, just styling a background? If the component author just left the background: none, you could do whatever you wanted from the outside. It just takes planning - even without the Shadow DOM you still need to plan for proper themeing.
ernsheong 7y ago
Web Components did replace frameworks for me. I built KanRails (https://www.kanrails.com/ https://www.kanrails.com/) with LitElement, without React/Vue/etc. The alpha is at https://app.kanrails.com/signup https://app.kanrails.com/signup. Again, it's in alpha. It is essentially a Trello + Google Forms + Workflow wannable. How? Stick to patterns, not libraries. Check out https://pwa-starter-kit.polymer-project.org/ https://pwa-starter-kit.polymer-project.org/ for LitElement starter kits. And just use Webpack, rip out the Polymer CLI. Oh, I also use Redux.
- benforreal 7y ago
  "Stick to patterns, not libraries" - Such a simple statement, but concise as hell. It's whats been my mindset, but I haven't put it to words. Like normal DOM event bubbling is going to cover lots of use cases. When it doesn't, an event bus is crazy simple to write. A centralized data model can just be a static module. Need observables? Easy to write a simple one - otherwise there's likely a bazillion of them on npm. Not that I've used it, but it's not like Redux or MobX are restricted to React either
- ernsheong 7y ago
  Just to elaborate a bit further to help fellow sojourners: 1) I use Webpack to bundle, still practically indispensable. 2) Redux state management. I use Redux-ORM to denormalize data but it has its own quirks. 3) Shadow DOM is on by default (both a curse and a great thing), which can be a problem with styling because your global CSS can't penetrate everywhere. What I do is have lots of CSS utils files (ala TailwindCSS), and import the utils as I need on demand. Drawback: Browser is parsing a lot more CSS than it needs to, as each component imports it's own CSS utils. Happy to hear about other approaches, but the browser really didn't break a sweat. 4) With Shadow DOM, you can use <slot></slot> to compose components. 5) Routing, see the starter kit for patterns, essentially it's a router pattern, not a router library. 6) DOM event bubbling is very useful (CustomEvent), I even threw in a small Pub/Sub library somewhere for sibling communication 7) You could use some sort of DI (dependency injection), currently using di-ninja which seems a bit overkill Essentially, nothing much changed. Use the browser. Use JS. Use patterns. Use libraries as you see fit (watch that bloat).
- 7y ago
founderling 7y ago
I wonder why HTML never got includes. It would be so nice to just write: <include src="footer.html"> On Hacker News, for the first pageview, this would load the whole "Guidelines | FAQ | Support ..." section. On all other pageloads, the browser would already have it in the cache. So it does not have to be loaded again. Building complex websites would become so much nicer. Because each part of a page would be an include.
- tobyhinloopen 7y ago
  Frameset / iframe?
  - galaxyLogic 7y ago
    You are right. IFrame creates an almost but not totally isolated page-environment. So in a sense IFrames are 'web-components". So what can Web-components offer over that? A simpler way of including them on a page with a single tag. Well, you must load the js-file too but a single js-file could contain multiple web-components I assume. The whole (?) point of components is isolating the interface from implementation, encapsulation, which WebComponents does nicely by providing a standard way of writing methods of the underlying ES6 class. We could say that WebComponents are smarter IFrames with a cleaner way to declare their interface. Another great thing about WebComponents is extending existing tags which makes it easy to prototype improvements to existing tags. For instance I wonder if IFrame could be made better by creating a web-component that extends them?
- colordrops 7y ago
  There are html "includes" in Chrome, used as such: <link rel="import" href="/path/to/file.html"> But alas, Google was not able to convince other browser vendors to adopt them, and they will be removed from Chrome 75.
- zarzz 7y ago
  If you are looking for just a simple load some html and replace this where my <include> tag is kind of thing you are right, nothing does that because it’s more complicated then that... what about the styles of the included html? What about the behaviors (JavaScript) for it. How does that translate with the include? But, if you use Web Components, organize your code, and plan ahead, this is very doable today with Web Components. You just create say a <reddit-footer> component complete with style and behavior, and then drop that into your page html along with an import of the component definition. It’s clean and simple and the encapsulation of all your footer needs in one place is really nice. ZephJS, the library I am promoting, or another Web Component engine, makes this even easier and allows your components to be bundle yup really nicely. ZephJS, for example, offers a cli bundler command that does this (via rollup) and it makes for a really clean component experience. https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3e https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3... B
deleted 7y ago
[deleted]
namelosw 7y ago
At least for current Web Component API, no. Html is good because it's declarative, but it's not good since it lack abstraction. So React combine JSX template and lambda as declarative component. Means you have parametrized template and loop etc. Vanilla and jQuery is not so good because it's not reactive by default, which means you're not always describing things you want, instead you have to update something. Eventually you will forget some. It's called imperative. Current Web Components spec include attribute changed hooks but it's far from React since most of the APIs are imperative. But why declarity matters? Because it turns out front-end world is totally different from request-response backend programming. Because in front-end you're dealing with continuous sequence of signals instead of one off requests. Declarative style makes you describe the relation between model, views and derived values, not how to update or maintain those relations.
sbhn 7y ago
When i download static html from a webserver, it just draws it straight to the screen
deanclatworthy 7y ago
I think a lot of you are missing the point of Web Components here. They're not going to replace React et. al for huge frontend applications. But they are a great solution to drop in for a lot of projects where you need things like: - Sliders - Lazy loading images - Complex select dropdowns Rather than having to import a js file, css file, and use some weird wrapper around the existing DOM we have, we can import one file and be done with it.
- ssorallen 7y ago
  I agree, your examples seem to be prime use cases of Web Components. The original post though makes the claim that WCs are ready to replace your entire framework.
sbhn 7y ago
I see a lot of anger directed at the innerHTML command for various reasons. Then i think, what about the html <script> tag, why isn’t that illegal yet, you know, the one that imports your latest fancy framework into the dom, surely thats an antipattern and a code smell.
k_bx 7y ago
Web Components are an ideal complement to pure statically typed languages like Elm, where it's a bit of a hassle to implement simple, isolated components. An example would be: a text paragraph which has "read more" button, when clicked, expands. Or an info popup with a "close" button. No need to put its state in your model and forward its messages.
johankmagnusson 7y ago
I've written a couple of smaller and larger apps in Angular 1 and 2, Vue, React, Polymer and recently trying out lit-element and it solves pretty much all my needs. I like the typescript decorators for properties and elements and that is the only reason for which I need Webpack. Redux, the part of it I need which is updating from a central store, I replaced with about 20 lines of javascript. Because of how good web components in their current state are my very personal opinion is that the other frameworks I have written code in solve yesterday's problems and are very likely to become the future jQuerys.
k__ 7y ago
No. But they could make frameworks like Bootstrap much easier to use. CSS is the top. WC are the bottom. React, Angular, Vue and company are the "between".
westbrookjo 7y ago
One thing that is particularly important to take into account when comparing web components to framework is that they can and should work together. If indeed "web components" replace your "framework" it will most likely be because a new framework that takes advantage of web components and all that the web is now replaces your old framework. Already libraries that combine popular concepts like hooks from React with web components (https://github.com/matthewp/haunted https://github.com/matthewp/haunted) are pointing the way to a more powerful future for both site that need just that little extra something via a stand alone web component or a whole family of components wedded to a framework into a rich application. That being said, don't get confused by people on either side being overly defensive of their place in the web ecosystem things are they are now will change. Techniques will grow and merge and there will be something else that is "the thing" before too long. Web components will likely be as much a part of that as the elements who's shoulders they stand on (e.g. <select/> and <video/>). That's the power of the web.
- galaxyLogic 7y ago
  True. One more thing about web-components is that they are a standard. Vue, React, JQuery are not.
Blackthorn 7y ago
I don't get the hate for web components. I think they are amazing. A number of times I just wanted a damn date picker, not a framework that changes how I'm making my website! Web components provide exactly that.
- galaxyLogic 7y ago
  I agree. But there's always "hatred" for anything new which requires people yet again to learn new ways. I understand that. But there's nothing more difficult to stop than an idea whose time has come. I think that was from a Funkadelic LP-cover :-)
Const-me 7y ago
The page renders as a big white nothing in Edge and IE. Works in Firefox. I wonder does it use web components the article is about?
greenyouse 7y ago
Browser specifications are not nearly as transient as proprietary frameworks. Web components will be here next year, five years from now, ten, and thirty years from now. We should focus on how we can take advantage of the new spec to enhance existing frameworks. Popular projects like React use templates but require you to bundle the entire framework and the speed of the vDOM diffing happens at the speed of JS. What if it could take advantage of HTML templates to work at the speed of C++ by leveraging built-in browser support? One of my hopes is that we can stop the bad trend of rewriting the same front-end components over and over again. Instead there could be a set of canonical components that people use for different web site types. If you're building an e-commerce checkout system, you could pull in the email address input built by Twitter, Stripe's credit card input, and the address input built by some person on GitHub that has 5,000 stars. Authors could leverage CSS properties and ShadowDOM for nice style hooks so developers could customize the branding. The job of web frameworks could shift from "how do people build UI components" to "how do people build SPAs with routing, cookie auth, service worker caching, etc.". Not that current frameworks don't try to handle app level things but there is a lot more that could be done to make this easy for developers. It would be nice to see web components as orthogonal to framework UI styling. We should be able to pull in web components from anywhere and frameworks should be smart enough to co-opt the components by treating them as native DOM elements (like div or span). Sorry if this was sort of a rant I didn't have much time before work...
- spronkey 7y ago
  Forms are where web standards are most lacking. HTML5 took us from the stone age to the bronze age by adding some still-basically-useless inputs for e.g. colours and dates. Everyone is reinventing the wheel over and over here and it's infuriating. I recently tried to find a good component to provide an internationalised currency input - it's incredibly difficult to find a quality implementation for this, yet it's something that the vast majority of web applications will need to use at least once. Same goes for phone numbers. It would be nice to see web components take these roles away from frameworks. It would be nicer to see web standards identify the importance of many of these inputs in the first place.
bobske4 7y ago
wasm and wasi will eventually take over enabling higher level languages such as C#, Java and Python to be used at frontend (Blazor project is an example). As Mr. Bernhardt says: JavaScript had to be bad for the evolution to happen. (https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...)
ravenstine 7y ago
This article, the HN comments here, as well as comments on /r/javascript, are helping to solidify my view that way too many frontend developers don't know enough about what they're talking about. I really don't get the disdain against Web Components and their related APIs. Why even fewer people are excited about custom elements alone sort of baffles me. WC's aren't intended to replace frameworks and libraries. It's there to provide some universal primitives for writing components, and a lot of components aren't actually complex enough to warrant all the heavy lifting that comes with things like React and Vue. Those tools are great, but I also really love the idea that I can write useful components without having to import a bunch of extras(eventually the polyfills will be obsolete). The innerHTML function can be slow if your code is sloppy and you're applying it to the wrong problem. Yes, you might need a data-aware renderer like the one in React, but often times you might not. For a lot of simple things, you can render elements without it by using createElement(), append(), insertBefore(), insertAdjacentElement(), cloneNode(), etc. They're not hard to use, but they're not pretty like a templating language, and they're not going to surround you in bubble wrap. I'm not saying that those tools scale for bigger projects, but there are plenty of small things you could write using Web Component technology. It has its place. If you do things like call innerHTML multiple times in a loop, when you really could concatenate your HTML and call innerHTML once, is fundamentally going to perform badly, but web developers seem to write that kind of terribly-performing code in all sorts of cases and when it runs like crap they just assume that they need to import a library that will use tricks to cover up their lousy code. It reminds me of how folks will write a pile of garbage with Rails, switch to Phoenix because their Rails app is slow, and then claim that Rails sucks at performance. That's not to say that Phoenix doesn't have clear performance advantages, but the claim that Rails is slow often comes from a place of ignorance. A lot of jobs warrant useful tools like Vue, but then again, maybe your code just isn't very good. It's really embarrassing how many of us don't write code to be efficient, opting to always stand on the shoulders of giants who do the hard work to make our lousy code appear to run fast.
galaxyLogic 7y ago
I think this is an excellent thorough presentation of WebComponents. One think I didn't quite understand was the first example about which it is said: "I have created a web component which lazily loads an image once it is fully visible in the browser's viewport" Once the image is "fully visible", what's the point of "loading it"? Doesn't it go the other way first you load it then it becomes visible?
kentbrew 7y ago
When you write something like this please include a date of publication.

450 points by technojunkie 7y ago

I love writing Web Components, but they're never going to really be a thing. The promise was that we could create native components without any dependencies at all but it just hasn't worked out that way. Shadow DOM support, the real killer feature, is patchy at best without polyfills. Orchestrating them into any kind of complex app still requires some kind of framework to handle things like passing down props and event binding, which at that point you might as well go full on (React/Angular/Vue) + Webpack/Babel. The dream of being able to share reusable components breaks down the moment your designer wants an extra 5 pixels of padding here or there. It's fun to use them for small things but it's just not viable as an alternative to frameworks.

reustle 7y ago
(sorry, I'm not well versed in some of these things) Would it make sense for React to start using this native web-component at some level moving forward, to improve efficiency ? Maybe another library will replicate most of Reacts features but is powered by this native (faster/cleaner) technology?
- wwright 7y ago
  afaik web components are mostly about encapsulation and semantics; they let you box up arbitrary HTML, JS and CSS and put a little bow on top so that it looks like one “custom” HTML tag to the rest of the document. (I could be misremembering.) React is mostly about life cycles, propagation, and composition. The first two are orthogonal to web components afaik. The third has some overlap, but it’s mostly complementary with web components (once again, afaik.)
- paulddraper 7y ago
  Angular has kept web component compatibility as a high priority. You can publish angular components as web components, and even leverage native functionality like shadow Dom.
yesimahuman 7y ago
Strongly disagree. We (Ionic) built our new version directly on top of Web Components and they are certainly a thing for us and our users building real apps on top. Plus, they are a huge reason why we now support React and Vue and plain JS. Frankly, this has been transformational for our project and for our business. I'm completely sold. One problem with the WC debate is people constantly compare the raw Web Component collection of APIs to a framework, when in reality, you'll add in libraries or extras on top of your Web Components to get similar functionality (like Stencil: http://stenciljs.com/ http://stenciljs.com/), but you'll likely not build apps with them as much as you'll build components to share with others. In that sense, the killer app for Web Components is actually Design Systems, not SPAs. I disagree with the idea that Web Components replace your framework, however. They solve different problems! For Ionic as a cross-platform Design System, they are a major asset.
- benforreal 7y ago
  I'm glad to hear this take. I came from Angular v1 and got sick of the framework churn, so jumped over to Web Components around 2015/2016 instead of going React. I abandoned Polymer pretty quickly around v0.6 because things were changing too much and just went plain vanilla JS + Web Components. I've been building applications since then with just Web Components and couldn't be happier. Unfortunately I just don't have enough experience with React to debate any of these points - I guess I just have to leave it that React is a need I don't have.
- KuhlMensch 7y ago
  > In that sense, the killer app for Web Components is actually Design Systems, not SPAs. My read too
spankalee 7y ago
> The promise was that we could create native components without any dependencies at all This isn't true at all, and it's a big misperception about web components. Web components are pretty low level APIs that expose a few abilities that the browser natively has: defining a tag name, hooking into element lifecycles, creating an encapsulate DOM subtree. Web commonness have no opinion on rendering, state management, etc. and leave other aspects, like responding to property changes, to existing features like JavaScript accessors. It's expected that developers will use libraries to help implement web components, but the libraries won't have to implement a component model, or DOM composition, or CSS scoping. So they'll be smaller and more focused, and the overall product will be faster have fewer proprietary parts.
colordrops 7y ago
Shadow DOM is now supported across all major browsers. Also, don't understand your padding comment. Web Components are style-able.

true_religion 7y ago

The shadow dom is just JavaScript, HTML and CSS. For any significantly sized component I would want a framework to wrangle all that.

Spivak 7y ago
I don't really think end-devs are the target audience for Web Components. I see two users that will benefit: * Framework/library authors that now have a higher-level and hopefully more performant primitives to build on. * Widget library authors that can now design component libraries that can used by any framework.

revskill 7y ago

It's not about implementation details, it's about programming paradigm. In the case of React, it's - Declarative, functional API to write reuseable UI. - REAL reusable business logic with React Hooks. - REAL universal data fetching with React Suspense. - REAL error boundary with Error Boundary. - Learn once, write everywhere! Do Web Components have the above benefits (yet) ?

galaxyLogic 7y ago
Of course not. But many smaller apps don't need all of those. Think about HTML how it started it was very rudimentary. At that point there was very many better "frameworks" for creating GUIs and applications. Yet HTML was in many cases good enough and since it was so simple it was able to evolve.

wokwokwok 7y ago

So I tried web components two years ago, and it was very painful, and I crawled back to react. Why should I invest my time in it now? IE support? Are you kidding me? I really wanted web components to take off, but they didn’t. Without a new compelling narrative, I fail to see how they are “the future” in any meaningful sense. Releasing an early version of something that is bad and doesn’t work (and let’s not pretend the shadow dom polyfill works, it doesn’t)... it’s just, not the right way to do this sort of stuff.

boubiyeah 7y ago
No more reason now than 2 years ago.

rovyko 7y ago

CSS is still a pain in Web Components. Constructable stylesheets solve that problem, but they're still in the "Worth Prototyping" stage for Firefox. https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/

jchw 7y ago

>Web Components will replace your frontend framework Yeah, I very much doubt that. Web Components is basically a suite of browser technologies. It's actually particularly heavy and I kind of hope it doesn't catch on personally, since it pushes so much to already giant monolithic web browsers. Frameworks and libraries like React and Angular are tools for developing applications first and foremost. The actual technologies they're backed by doesn't matter, but if you can't reimplement either of them using WebComponents it should probably tell you something about WebComponents: - It's very opinionated about a lot of things. - It disagrees with many of the (much more popular) frontend frameworks far too much. React does a whole lot of things right, and it does them right in a relatively small package with a relatively small API surface, and you can extract the essence into even smaller libraries. With functional components, you can even build React components that have almost no React in them at all, other than JSX. I don't think we need new complicated technologies to solve the kinds of problems React solves. If anything, we need less, like an alternative to the current DOM model. Most of the innovations in the frontend world don't seem like they can be cleanly applied to Web Components, or even layered on top of it. And if we want to update it down the road to a new major version, we have to wait for every major browser vendor to have a stable implementation and iron out edge cases/differences. That's not a good bet at all based on how it went with Web Components the first time. In other words, No Thanks, I'll take my framework.

davidjnelson 7y ago
Curious what you think about React Canvas https://github.com/Flipboard/react-canvas https://github.com/Flipboard/react-canvas
- jchw 7y ago
  I don't necessarily think everything should be Canvas, but rethinking the way pages render wouldn't be a bad idea. The issue I take with Canvas in particular is that it's poor for accessibility, password managers, and other services. I think part of the reason why the DOM and layout engines are so slow and complicated is just because of years of cruft and whatnot. A minimal layout engine with most the abilities of Flex and Grid would be nice.

ssorallen 7y ago

Web Components don’t offer a declarative way of updating the DOM; it’s still `innerHTML` and using DOM APIs to edit the state of the live DOM. Backbone was a hassle to manage in any sizeable app because updating the view was left up to every dev to figure out themselves. React brought a declarative wrapper around the statefulness of the DOM, and that is the killer feature that Web Components does not offer at all. Vue adopted the declarative template approach as well. The Web Components spec was written before React and Vue were very mature, and it unfortunately shows. Web Components might offer a better primitive for higher level frameworks to build on, but I would not suggest to anyone to use barebones Web Components over React or Vue.

dosy 7y ago
what about slots?
- lstamour 7y ago
  Slots require shadow DOM which means there can be performance and CSS issues on widgets designed for local use with shared CSS. But I agree they’re also an option. :)
  - FiddlyPack 7y ago
    :part and :theme CSS puesdo-selectors will help address these issues
    - no_wizard 7y ago
      you can also use :host, which target the custom element specifically (and using :host on custom-element children does not, from what I recall off hand, get broken when nesting) and then target its children. Also, css variables can be global and still enter into the shadow-dom unobtrusively (This is without using the polyfills, though, I believe this is a limitation in the polyfills currently, which might be why that part of it has been confusing in the past.).
  - 7y ago

AaronFriel 7y ago

The tooling is woefully inadequate, and the premiere Web Component tool is stringly typed to all heck which makes it a non-starter for me. I don't want giant blobs of runtime parsed text with no validation, syntax highlighting, and obviously no type checking. But yet, here's Polymer 3: static get template() { return html` <style> .response { margin-top: 10px; } </style> <paper-checkbox checked="{{liked}}">I like web components.</paper-checkbox> <div hidden$="[[!liked]]" class="response">Web components like you, too.</div> `; } Cool. What an enormous regression over TypeScript with React and Vue. My editor just sees components as enormous blobs of text, and what do you know, so does my build system.

staticvar 7y ago
Polymer is deprecated in favor of LitElement which comes with TypeScript decorators.
- chmln 7y ago
  With LitElement you are still encoding markup in strings and only the interpolated expressions are typechecked [1]. Not to mention that LitElement is far more clunkier and tedious. [1] https://lit-element.polymer-project.org/guide/start#use-litelement-typescript-decorators https://lit-element.polymer-project.org/guide/start#use-lite...
  - spankalee 7y ago
    The lit-plugin VS Code extension provides type-checking and code-completion for lit-html temptlates. The approach can be adopted for a tsc plugin.
    - chmln 7y ago
      Looks like there is a typescript plugin already [1], meaning this is not restricted to VS Code and should theoretically work in any editor with LSP support. That's better than I thought. [1] https://www.npmjs.com/package/ts-lit-plugin https://www.npmjs.com/package/ts-lit-plugin

rhacker 7y ago

It's insane to me that everything Polymer was got reduced to LitElement which is basically a complete copy of React without React and without the immeasurable support of typescript, VSCode support IN the view and debugging directly in the TSX.

staticvar 7y ago
The lit-element package comes with typescript decorators.
ernsheong 7y ago
You can use Typescript with LitElement https://lit-element.polymer-project.org/guide/start#use-litelement-typescript-decorators https://lit-element.polymer-project.org/guide/start#use-lite...
thosakwe 7y ago
Yeah, I didn't really understand why there was a need for an overhaul like that. I honestly was hoping that there'd be a better story for databinding, types, etc. I just gave up and went back to React.
- ernsheong 7y ago
  Polymer was trying to do too much (to be a framework), and the quality was average at best. LitElement is able to focus on providing the best base class to build a Web Component. I think it is almost there.

anthonyshort 7y ago

I don’t understand the push to make userland component abstractions into native primitives. It’s perfectly fine for the browser to just implement low level primitives for frameworks like React to build on top of. It allows the framework to develop much faster. Web components kind of miss a lot of the reasons why React has taken off. Encapsulation is one thing but it’s the declarative way of handling state, effects, and the DOM that make it powerful. Web components would need a framework on top of it to make it usable by developers building anything significant.

yesimahuman 7y ago
They aren't trying to solve the same problems. The main problem they solve, that no other userland framework solves, is that I can now share a collection of my rich JavaScript components with every single web developer in the world regardless of the technology they build web apps with.
- anthonyshort 7y ago
  I can imagine a world where this would be useful, being able to drop something in as easy as a <select/> element seems fine. It seems useful for UI primitives, like a dialog, tooltip etc, that the browsers might not implement as native elements themselves. But as a building block for creating entire applications? I don’t think so. Which means they’re always going to need to hook into the framework that’s rendering them, either to connect state, managing effects, or for styling. I just don’t see sharing a component regardless of framework as a major problem worth solving right now. Buy into a framework and community like React and you can just drop components into your app. It’s not framework-agnostic but it works.
- hesarenu 7y ago
  I would rather have browser provide rich components then rely on third party.
  - cletusw 7y ago
    That's one of the huge benefits of web components -- third parties can iterate quickly to find useful patterns, then browsers can just standardize the best/most popular ones. The old way of discussing ad nauseam in committee then implementing straight in the browser gave much less useful elements. (And it's much less straightforward to convert a popular React component into something browsers could implement natively.)

revvx 7y ago

I strongly believe Web Components will catch on, but not in its vanilla form. Writing code for them is a pain in the ass for non-trivial stuff. They're too low level compared to modern frameworks. IMO the future of the web will be about compiling React, Vue, Svelte, to Web Components, for interoperability reasons. And nope, Polymer isn't as good as any of those.

Aeolun 7y ago

Given that they were introduced in 2011, and in regards to their usage you hear... well crickets I think we can safely say that web components have failed. It doesn’t look similar to React at all, and still suffers from the same issues that jQuery does.

hyperpress 7y ago
> Given that they were introduced in 2011, and in regards to their usage you hear... well crickets > I think we can safely say that web components have failed. > It doesn’t look similar to React at all, and still suffers from the same issues that jQuery does. jQuery? I think your just making up nonsense there. Fully ten percent of the web is using web components at this typing, and it's continued growth is steady as more and more libraries and frameworks, excepting those least able to easily leverage them, bring them into the their own projects. YouTube, ING, McDonald's, and other adopters are some pretty loud crickets.
- Aeolun 7y ago
  Nope, no nonsense, but the issue has already been repeated in a bunch of comments here, so I don’t really need to any more. > Fully ten percent Citation needed. I’m sure it could be true, but it seems a high number for something that I’ve literally heard about for the first time today.
  - hyperpress 7y ago
    Repeating what? The same outdated, misrepresented arguments mainly relied on by react fandom? It's simple, lot's of options out there. If comfort and loyalty clearly takes precedence over best solutions, you've already made the decision. The problem isn't that web components failed, or you can't pass objects via props, or that you think you need polymer, or their not browser supported, or they actually adapt in most existing Frameworks. The problem is turf, and react loves its turf. Just point out that arguing from a position of 5 year old specs, adoption, and knowledge isn't, IMO, very wise. Rather a self inflicted lost opportunity.

ricardobeat 7y ago

As expected, no mention of server-side rendering.

westbrookjo 7y ago
You can server side render a `video` element just the same way you would a `custom-element`. We've been doing it for years and there's no reason to think anything about that has changed. If you're looking to deep SSR which is arguable as far as benefit, check out approaches like https://github.com/ionic-team/stencil-ssr-starter https://github.com/ionic-team/stencil-ssr-starter
- georgecalm 7y ago
  I think the difference is that the browser already contains the shadow dom needed to render the video tag. But for a custom tag it would need to fetch, parse and execute your component code before it can begin to render.
  - westbrookjo 7y ago
    That's an interesting read. I'm thinking on whether the real question is what is the declarative difference between the video tag, which by normal application lets everyone feel find about that content hidden by the shadow DOM vs the APIs we're developing for our custom elements. There seems to be an important piece of learning, not just for SSR, but for custom element development in general, that I think we can build off of.
JackuB 7y ago
This was exactly the reason I’ve abandoned them. As mentioned in other comments, they look like a good way to create a design/component system in them, because of the interop with any frontend JS framework (who doesn’t want that?!). So you deal with clunky CSS sharing and theming capabilities and there might be some solutions on the horizon. But now you want to build a static website with it (landing page, docs, blog…) and you can’t pre-render them, because there is no declarative Shadow DOM element https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Declarative-Shadow-DOM.md https://github.com/w3c/webcomponents/blob/gh-pages/proposals... (rejected https://github.com/whatwg/dom/issues/510 https://github.com/whatwg/dom/issues/510). Yeah, you can pre-render them without the Shadow DOM. Then if you want to make those chunks of HTML into WCT on load (sort of rehydration), it will trigger repaints, as you have to remove the chunk of HTML, put it into WCT and parse everything again. Or you don’t put it into Shadow Root, to prevent repaint - but at that point, if your components can work this way, why even use WCT?

pier25 7y ago

No. WCs can only replace one aspect of React or Vue. You still need a better way to manipulate the dom and react to data changes than pure vanilla.

bandy008 7y ago

It's a good development but this article is misleading and ignorant. Web Components cannot replace web frameworks like ReactJs, Angular or Vue. At least not yet. Im not sure if this guy have used any of these frameworks before.

deleted 7y ago

[deleted]

jaunkst 7y ago

Ploymer was a crapshow and HTML import a nightmare for load times. Unless some sort of topology bundling is provided for web components I'm out. We tried to do generic components for multiple frameworks based in webcomponets and it was an utter failure in practice especially for low band networks.

zarzz 7y ago
Allow me to float ZephJS at you as an example of a Web Component framework with a bundling tool to do what you describe. Simplifies everything about building Web Components. Introduction: https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3e https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3... Bundling specifically: https://github.com/awesomeeng/zephjs/blob/master/docs/ComponentBundling.md https://github.com/awesomeeng/zephjs/blob/master/docs/Compon...
- IggleSniggle 7y ago
  This looks pretty cool, thanks for sharing.
rossy 7y ago
To be fair, HTML imports is deprecated and won't be standardised. The recommended way to package web components now is with ES modules, and they can be bundled (with eg. Rollup or Webpack.)
- jaunkst 7y ago
  That is great, but I am still 100% sceptical of a web component intergration with any given framework. Is the integration point opinounated? Is it reactive, callbacks? Two way bindings? What does the application lifecycle look like? Would it be just opiononated sets of components? I just don't know... If I'm wrapping web components to meet our design patterns then why bother at all? I feel like the entire web component concept from an API level is a great concept but just not there for real world at scale consumption. I may just be not optimistic about it all.

threeaccents 7y ago

Web components are awesome I've been using them in production using StencilJS for a pretty large app for about a year now. Even though browser support is widely available there are still a few gotchas with web components, specially Shadow DOM. Not all community tools have caught up as well. For example you can't use Stripe v3 with Shadow DOM. Most analytics tools also cannot access the Shadow DOM. We had to remove Shadow DOM from all our components that were using it. In my opinion Web Components are definitely the future but there's still some catching up to do before we can claim it can replace frameworks.

westbrookjo 7y ago
You might be interested in https://github.com/bennypowers/stripe-elements https://github.com/bennypowers/stripe-elements Stripe v3 with Shadow DOM.
- threeaccents 7y ago
  Thanks I had actually seen this while looking into a workaround for us. However I thought that LitHTML elements only worked with other LitHTML elements since you need the correct bundler for it. StencilJS projects don't have any bundling system.
  - westbrookjo 7y ago
    LitHTML and LitElement don't need a specific bundler, they work with whatever tools (or not) you'd like. You might want to get them another look!

zarzz 7y ago

The reality of Web Components is that it was never intend to take share away from the large frameworks. Instead Web Components is intended to fill the middle ground between a simple web page and a full blown web application. There is a real need for web page developers to be able to just drop in a prebuilt web component and go without having to reach for the 10,000 pound gorilla of frameworks. That’s where Web Components can have real value, real benefit. Is Web Components flawless, hardly. While the APIs are accepted standards and implemented in most browsers there are still a few holdouts, and to be sure there are still edges to iron out. No technology is without it warts, its awkward teen years. But Web Components is maturing and the tooling around it is maturing as well and Web Components most definitely has a place and is most definitely here to stay. Also it is worth keeping in mind that the Web Component APIs are specifically written as low level APIs and intend to be built upon by libraries and frameworks to simplify and aid the process. Libraries like the one I am currently pitching, ZephJS [1], which aims at making writing and distributing web components mind numbingly simple to do. ZephJS is a perfect example of the new generation of Web Component libraries to facilitate answering the need I espouse above: the middle ground between basic and beast that so many web developers live in. [1] Introducing ZephJS: https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3e https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3...

Vinnl 7y ago
> The reality of Web Components is that it was never intend to take share away from the large frameworks. Instead Web Components is intended to fill the middle ground between a simple web page and a full blown web application. Exactly. More specifically, it was created in response to the years-long hiatus in development of the HTML spec, when we were still waiting for a date picker element (heck, we still are!). With Web Components, we might all use the same widely supported and actively maintained emoji picker regardless of the framework we're using. But they do not solve the problems that framework solves.

iliaznk 7y ago

That's the case when a title is enough to see the author has no idea what he's talking about, that's convenient!

ramon 7y ago

A couple of days ago I saw a project here called pika which is any npm package it seems running in the browser, it's interesting to have the web components + pika where we can bring in different modules from npm and combine that with the power of web components then there really is no need for other frameworks but.. it brings that problem we used to have with JQuery which is lack of standards.. it seems we keep on going around in circles but web components are a lot faster and easier then React or Preact.. and the routing thing just makes everything fat for the bundles... then you have to worry about bundle splitting... the main/core bundle... pika is a good one because it takes the bundling off the bat and makes everything easier without the routing.. I now wish for a standard with web components and pika and doing the polyfilling... and ... material framework... and.. some coding standards just so we don't get a mix of Jquery and react and preact and a lot more in one single page load.

sergiotapia 7y ago

Being native to the browser, how fast is it compared to React? It is 10x faster because it's native? Is it on par, with room for browsers to improve it's performance even further? I'm all for something that's native to the browser. Right now you write a `<p>` tag for a paragraph element. No question about it. Imagine if you needed to use a P-tag library just to render a paragraph tag? Of course not right, you would just use the native browser `<p>` tag. I think that React is a P-tag library in essence. I would go all-in for a native version of "frontend framework".

VvR-Ox 7y ago
I totally agree - we need "one framework to rule them all". I don't want to learn another 10 technologies we won't use anymore in 5-10 years.

irenkai 7y ago

You are only thinking of one frontend, React allows a multitude of renderers, even the command line [0]. It has great tooling, awesome community, and it's pushed the boundaries of how we thought frontend development. https://github.com/Yomguithereal/react-blessed https://github.com/Yomguithereal/react-blessed

Andrex 7y ago

I argued for a similar case last year[1], however the missing piece right now is updating state in a clean way. Web Components definitely won't replace current front-end frameworks, but combined with ES Modules the web is getting to a good place for resuable primitives. :) [1] https://andrewrabon.com/the-case-for-react-like-web-components-63887335fe41 https://andrewrabon.com/the-case-for-react-like-web-componen...

westbrookjo 7y ago
Be sure to checkout lit-html and LitElement (https://lit-html.polymer-project.org https://lit-html.polymer-project.org & https://lit-element.polymer-project.org https://lit-element.polymer-project.org)...what you've written about here already exists!
- threeaccents 7y ago
  Also give StencilJS a look. It's a compiler instead of a framework or library. The end result is pure vanilla components https://stenciljs.com/ https://stenciljs.com/

OnlyRepliesToBS 7y ago

great, more browser vendor lockin we've learned nothing from IE6 nor activex but 'trust us'

jasonkester 7y ago

I see a header and a footer and a big blank page. Whatever the author is using to replace his front end currently doesn't work on my iPad Air. But in answer to the question, no. I doubt it. I tried building a site using polymer when if first came out. It was harder than the in house thing I'd previously been using and after about a year, the spec had moved on and my site looked like this author's blog: a big white page and some JavaScript errors. I'm not the sort of person who enjoys rewriting my app every year to suit the whims of the framework it's on top of, so my plan is to emit boring HTML until something equally stable yet better comes along.

zachrose 7y ago

I wish the ideas of the Elm Architecture (or React/Redux) could be brought to the browser. Primarily, an atomic single source of truth (serializable data) for window.document and a way to connect that state to the DOM through pure functions so that we can avoid local component state that then has to be orchestrated with references, event buses, etc.

_the_inflator 7y ago

I think that the author misses the point. The question is how can we build better frontend apps and not should we use frameworks or not. In the end there are only tools for different purposes. Context and history are important to fully grasp WebComponents. WebComponents arose when there was jQuery and decoupling of CSS, HTML and JS. If you look back 10 years, there was no real separation of concern and Web purists like today always disliked the idea of mixing CSS in JS. Then came NodeJS and frontend build tools started to provide better tools (GruntJS etc.) for compile time checks. Encapsulating CSS in JS for example solved the problem of overuse of id selectors, greedy class selectors and namespace collisions - domains that WebComponents tries to solve with Shadow DOM etc. Todays frontend frameworks in combination with the underlying build tools provide a lot of the abstraction that WebComponents want to give developers. So I would rather say that WC are another tool which can be used by modern frameworks. It is like saying air pollution can be solved by driving slower on highways when there are only combustion engines. Why should teslas be punished for the wrong reasons? Same goes for WebComponents. Good idea, great abstraction but context is important.

deleted 7y ago

[deleted]

mmckelvy 7y ago

Web components will never take off because they are HTML-first and rely on DOM apis. The reason React is so popular and the reason it dethroned Angular, Backbone, etc. is because it is JavaScript-first. In other words, it gives you the power of a proper programming language to build UIs.

mikeytown2 7y ago

CMS static site builder based off of Web components https://github.com/elmsln/HAXcms https://github.com/elmsln/HAXcms

winterthedeep 7y ago

I worked with Polymer-based components ~2 years ago (an eternity in frontend-land), and I want to share my biggest pain point: you may want to integrate a `<cool-carousel>`, but it does not "look right" in your design (eg white website, but the carousel has a black background). If the author did not set up CSS variables, you have to either try overriding stuff, or fork it. This problem is why every organization (eg GE with Predix or Electronic Arts) had to create their own components, so they can share the same "art style"/design. Can you share your experience about that?

boubiyeah 7y ago
No matter the underlying technology, "lightweight, truly reusable UI components" is almost an ideologic dream, at the web scale. (some companies might achieve it on their own scale with a lot of effort, but not sure for how many years) As the maintainer, you don't want to cave in and add every possible configuration option people ask for so you have to decide what's a good, thin API for your component and it will never be enough for some usages. Styles are that much more subjective and even vary with design trends over the years! It might be possible for very, very simple components like text inputs but then again, those are also the simplest to code directly in your framework, so you could wonder, why bother with an inferior programming paradigm in the first place? The sweet spot for web components really seems tiny.
fbn79 7y ago
Web Components are an anti-pattern
- EtienneK 7y ago
  Please expand on this point?
benforreal 7y ago
In the instance of Predix (I peripherally worked on that during my time at GE) and likely EA and every other large Web Component ecosystem you're thinking of, that's desired behavior. The real want is a design system such that things look consistent, but as design systems are CSS only, they aren't smart enough for interactions that require JS. So then the need for a design system becomes a need for components of some kind that include the design. You're looking for components with more adaptable design, but that's just not the intention of these ecosystems. If done with that goal, yes CSS vars take you a little bit of the way, but I think we'll see more power coming to help out soon with Shadow Parts/Theme, CSS Modules, and Scoped Stylesheets. But really, just styling a background? If the component author just left the background: none, you could do whatever you wanted from the outside. It just takes planning - even without the Shadow DOM you still need to plan for proper themeing.

ernsheong 7y ago

Web Components did replace frameworks for me. I built KanRails (https://www.kanrails.com/ https://www.kanrails.com/) with LitElement, without React/Vue/etc. The alpha is at https://app.kanrails.com/signup https://app.kanrails.com/signup. Again, it's in alpha. It is essentially a Trello + Google Forms + Workflow wannable. How? Stick to patterns, not libraries. Check out https://pwa-starter-kit.polymer-project.org/ https://pwa-starter-kit.polymer-project.org/ for LitElement starter kits. And just use Webpack, rip out the Polymer CLI. Oh, I also use Redux.

benforreal 7y ago
"Stick to patterns, not libraries" - Such a simple statement, but concise as hell. It's whats been my mindset, but I haven't put it to words. Like normal DOM event bubbling is going to cover lots of use cases. When it doesn't, an event bus is crazy simple to write. A centralized data model can just be a static module. Need observables? Easy to write a simple one - otherwise there's likely a bazillion of them on npm. Not that I've used it, but it's not like Redux or MobX are restricted to React either
ernsheong 7y ago
Just to elaborate a bit further to help fellow sojourners: 1) I use Webpack to bundle, still practically indispensable. 2) Redux state management. I use Redux-ORM to denormalize data but it has its own quirks. 3) Shadow DOM is on by default (both a curse and a great thing), which can be a problem with styling because your global CSS can't penetrate everywhere. What I do is have lots of CSS utils files (ala TailwindCSS), and import the utils as I need on demand. Drawback: Browser is parsing a lot more CSS than it needs to, as each component imports it's own CSS utils. Happy to hear about other approaches, but the browser really didn't break a sweat. 4) With Shadow DOM, you can use <slot></slot> to compose components. 5) Routing, see the starter kit for patterns, essentially it's a router pattern, not a router library. 6) DOM event bubbling is very useful (CustomEvent), I even threw in a small Pub/Sub library somewhere for sibling communication 7) You could use some sort of DI (dependency injection), currently using di-ninja which seems a bit overkill Essentially, nothing much changed. Use the browser. Use JS. Use patterns. Use libraries as you see fit (watch that bloat).
7y ago

founderling 7y ago

I wonder why HTML never got includes. It would be so nice to just write: <include src="footer.html"> On Hacker News, for the first pageview, this would load the whole "Guidelines | FAQ | Support ..." section. On all other pageloads, the browser would already have it in the cache. So it does not have to be loaded again. Building complex websites would become so much nicer. Because each part of a page would be an include.

tobyhinloopen 7y ago
Frameset / iframe?
- galaxyLogic 7y ago
  You are right. IFrame creates an almost but not totally isolated page-environment. So in a sense IFrames are 'web-components". So what can Web-components offer over that? A simpler way of including them on a page with a single tag. Well, you must load the js-file too but a single js-file could contain multiple web-components I assume. The whole (?) point of components is isolating the interface from implementation, encapsulation, which WebComponents does nicely by providing a standard way of writing methods of the underlying ES6 class. We could say that WebComponents are smarter IFrames with a cleaner way to declare their interface. Another great thing about WebComponents is extending existing tags which makes it easy to prototype improvements to existing tags. For instance I wonder if IFrame could be made better by creating a web-component that extends them?
colordrops 7y ago
There are html "includes" in Chrome, used as such: <link rel="import" href="/path/to/file.html"> But alas, Google was not able to convince other browser vendors to adopt them, and they will be removed from Chrome 75.
zarzz 7y ago
If you are looking for just a simple load some html and replace this where my <include> tag is kind of thing you are right, nothing does that because it’s more complicated then that... what about the styles of the included html? What about the behaviors (JavaScript) for it. How does that translate with the include? But, if you use Web Components, organize your code, and plan ahead, this is very doable today with Web Components. You just create say a <reddit-footer> component complete with style and behavior, and then drop that into your page html along with an import of the component definition. It’s clean and simple and the encapsulation of all your footer needs in one place is really nice. ZephJS, the library I am promoting, or another Web Component engine, makes this even easier and allows your components to be bundle yup really nicely. ZephJS, for example, offers a cli bundler command that does this (via rollup) and it makes for a really clean component experience. https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3e https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3... B

deleted 7y ago

[deleted]

namelosw 7y ago

At least for current Web Component API, no. Html is good because it's declarative, but it's not good since it lack abstraction. So React combine JSX template and lambda as declarative component. Means you have parametrized template and loop etc. Vanilla and jQuery is not so good because it's not reactive by default, which means you're not always describing things you want, instead you have to update something. Eventually you will forget some. It's called imperative. Current Web Components spec include attribute changed hooks but it's far from React since most of the APIs are imperative. But why declarity matters? Because it turns out front-end world is totally different from request-response backend programming. Because in front-end you're dealing with continuous sequence of signals instead of one off requests. Declarative style makes you describe the relation between model, views and derived values, not how to update or maintain those relations.

sbhn 7y ago

When i download static html from a webserver, it just draws it straight to the screen

deanclatworthy 7y ago

I think a lot of you are missing the point of Web Components here. They're not going to replace React et. al for huge frontend applications. But they are a great solution to drop in for a lot of projects where you need things like: - Sliders - Lazy loading images - Complex select dropdowns Rather than having to import a js file, css file, and use some weird wrapper around the existing DOM we have, we can import one file and be done with it.

ssorallen 7y ago
I agree, your examples seem to be prime use cases of Web Components. The original post though makes the claim that WCs are ready to replace your entire framework.

sbhn 7y ago

I see a lot of anger directed at the innerHTML command for various reasons. Then i think, what about the html <script> tag, why isn’t that illegal yet, you know, the one that imports your latest fancy framework into the dom, surely thats an antipattern and a code smell.

k_bx 7y ago

Web Components are an ideal complement to pure statically typed languages like Elm, where it's a bit of a hassle to implement simple, isolated components. An example would be: a text paragraph which has "read more" button, when clicked, expands. Or an info popup with a "close" button. No need to put its state in your model and forward its messages.

johankmagnusson 7y ago

I've written a couple of smaller and larger apps in Angular 1 and 2, Vue, React, Polymer and recently trying out lit-element and it solves pretty much all my needs. I like the typescript decorators for properties and elements and that is the only reason for which I need Webpack. Redux, the part of it I need which is updating from a central store, I replaced with about 20 lines of javascript. Because of how good web components in their current state are my very personal opinion is that the other frameworks I have written code in solve yesterday's problems and are very likely to become the future jQuerys.

k__ 7y ago

No. But they could make frameworks like Bootstrap much easier to use. CSS is the top. WC are the bottom. React, Angular, Vue and company are the "between".

westbrookjo 7y ago

One thing that is particularly important to take into account when comparing web components to framework is that they can and should work together. If indeed "web components" replace your "framework" it will most likely be because a new framework that takes advantage of web components and all that the web is now replaces your old framework. Already libraries that combine popular concepts like hooks from React with web components (https://github.com/matthewp/haunted https://github.com/matthewp/haunted) are pointing the way to a more powerful future for both site that need just that little extra something via a stand alone web component or a whole family of components wedded to a framework into a rich application. That being said, don't get confused by people on either side being overly defensive of their place in the web ecosystem things are they are now will change. Techniques will grow and merge and there will be something else that is "the thing" before too long. Web components will likely be as much a part of that as the elements who's shoulders they stand on (e.g. <select/> and <video/>). That's the power of the web.

galaxyLogic 7y ago
True. One more thing about web-components is that they are a standard. Vue, React, JQuery are not.

Blackthorn 7y ago

I don't get the hate for web components. I think they are amazing. A number of times I just wanted a damn date picker, not a framework that changes how I'm making my website! Web components provide exactly that.

galaxyLogic 7y ago
I agree. But there's always "hatred" for anything new which requires people yet again to learn new ways. I understand that. But there's nothing more difficult to stop than an idea whose time has come. I think that was from a Funkadelic LP-cover :-)

Const-me 7y ago

The page renders as a big white nothing in Edge and IE. Works in Firefox. I wonder does it use web components the article is about?

greenyouse 7y ago

Browser specifications are not nearly as transient as proprietary frameworks. Web components will be here next year, five years from now, ten, and thirty years from now. We should focus on how we can take advantage of the new spec to enhance existing frameworks. Popular projects like React use templates but require you to bundle the entire framework and the speed of the vDOM diffing happens at the speed of JS. What if it could take advantage of HTML templates to work at the speed of C++ by leveraging built-in browser support? One of my hopes is that we can stop the bad trend of rewriting the same front-end components over and over again. Instead there could be a set of canonical components that people use for different web site types. If you're building an e-commerce checkout system, you could pull in the email address input built by Twitter, Stripe's credit card input, and the address input built by some person on GitHub that has 5,000 stars. Authors could leverage CSS properties and ShadowDOM for nice style hooks so developers could customize the branding. The job of web frameworks could shift from "how do people build UI components" to "how do people build SPAs with routing, cookie auth, service worker caching, etc.". Not that current frameworks don't try to handle app level things but there is a lot more that could be done to make this easy for developers. It would be nice to see web components as orthogonal to framework UI styling. We should be able to pull in web components from anywhere and frameworks should be smart enough to co-opt the components by treating them as native DOM elements (like div or span). Sorry if this was sort of a rant I didn't have much time before work...

spronkey 7y ago
Forms are where web standards are most lacking. HTML5 took us from the stone age to the bronze age by adding some still-basically-useless inputs for e.g. colours and dates. Everyone is reinventing the wheel over and over here and it's infuriating. I recently tried to find a good component to provide an internationalised currency input - it's incredibly difficult to find a quality implementation for this, yet it's something that the vast majority of web applications will need to use at least once. Same goes for phone numbers. It would be nice to see web components take these roles away from frameworks. It would be nicer to see web standards identify the importance of many of these inputs in the first place.

bobske4 7y ago

wasm and wasi will eventually take over enabling higher level languages such as C#, Java and Python to be used at frontend (Blazor project is an example). As Mr. Bernhardt says: JavaScript had to be bad for the evolution to happen. (https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...)

ravenstine 7y ago

This article, the HN comments here, as well as comments on /r/javascript, are helping to solidify my view that way too many frontend developers don't know enough about what they're talking about. I really don't get the disdain against Web Components and their related APIs. Why even fewer people are excited about custom elements alone sort of baffles me. WC's aren't intended to replace frameworks and libraries. It's there to provide some universal primitives for writing components, and a lot of components aren't actually complex enough to warrant all the heavy lifting that comes with things like React and Vue. Those tools are great, but I also really love the idea that I can write useful components without having to import a bunch of extras(eventually the polyfills will be obsolete). The innerHTML function can be slow if your code is sloppy and you're applying it to the wrong problem. Yes, you might need a data-aware renderer like the one in React, but often times you might not. For a lot of simple things, you can render elements without it by using createElement(), append(), insertBefore(), insertAdjacentElement(), cloneNode(), etc. They're not hard to use, but they're not pretty like a templating language, and they're not going to surround you in bubble wrap. I'm not saying that those tools scale for bigger projects, but there are plenty of small things you could write using Web Component technology. It has its place. If you do things like call innerHTML multiple times in a loop, when you really could concatenate your HTML and call innerHTML once, is fundamentally going to perform badly, but web developers seem to write that kind of terribly-performing code in all sorts of cases and when it runs like crap they just assume that they need to import a library that will use tricks to cover up their lousy code. It reminds me of how folks will write a pile of garbage with Rails, switch to Phoenix because their Rails app is slow, and then claim that Rails sucks at performance. That's not to say that Phoenix doesn't have clear performance advantages, but the claim that Rails is slow often comes from a place of ignorance. A lot of jobs warrant useful tools like Vue, but then again, maybe your code just isn't very good. It's really embarrassing how many of us don't write code to be efficient, opting to always stand on the shoulders of giants who do the hard work to make our lousy code appear to run fast.

galaxyLogic 7y ago

I think this is an excellent thorough presentation of WebComponents. One think I didn't quite understand was the first example about which it is said: "I have created a web component which lazily loads an image once it is fully visible in the browser's viewport" Once the image is "fully visible", what's the point of "loading it"? Doesn't it go the other way first you load it then it becomes visible?

kentbrew 7y ago

When you write something like this please include a date of publication.