21 ms·

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 ha

• dosy 8y ago
  what about slots?
  • lstamour 8y 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 8y ago
      :part and :theme CSS puesdo-selectors will help address these issues
      • no_wizard 8y 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.).
    • gedy 8y ago
      This. I feel like an old man yelling at a cloud, but while everyone seems to focus on how awesome shadow DOM and isolated CSS is, I need to deal with using a global theme and styles.
      • ww520 8y ago
        I have the same problem with global styles when using Web Components. Using @import in the components to include the shared style files solve the problem.
    • spankalee 8y ago
      Performance issues? Native Shadow DOM, especially with Constructible Stylesheets, is a perf boost. Limiting style resolution to smaller scopes and less rules is good.
      • dfabulich 8y ago
        Perf boost compared to what? It can't be a FCP perf boost relative to server-side rendered plain old CSS and HTML, because shadow DOM requires client-side JavaScript. Plain old CSS is able to parse and render before the JS required to launch web components has even finished.
        • lowkeyokay 8y ago
          It can be a performance boost because it only updates the part of the DOM tree that has changed. Not completely unlike React’s virtual DOM
      • lstamour 8y ago
        True, I don’t have benchmarks, but there was a time period where shadow DOM was popularly disabled due to performance hits, but perhaps it was all the performance hit of polyfills and less efficient implementations in browsers. https://github.com/WICG/construct-stylesheets/blob/gh-pages/explainer.md https://github.com/WICG/construct-stylesheets/blob/gh-pages/... is interesting, though Sass still looks unlikely to be added to the browser so we’ll always need some amount of CSS compilation if you want CSS nesting the way you expect it in Sass. Here’s more documentation on constructible stylesheets: https://developers.google.com/web/updates/2019/02/constructable-stylesheets https://developers.google.com/web/updates/2019/02/constructa... I wasn’t aware of this because this stuff is being developed and released so dang quickly! (I do worry that APIs developed in relative haste might be replaced or iterated on in relative haste, especially if they aren’t adopted widely first...)
        • dosy 8y ago
          :is() can make concise CSS of some of what nesting does in Sass https://developer.mozilla.org/en-US/docs/Web/CSS/:is https://developer.mozilla.org/en-US/docs/Web/CSS/:is there's a lot New coming into web all the time. I watch chrome status for drops. https://www.chromestatus.com/features https://www.chromestatus.com/features
    • ww520 8y ago
      Shared CSS can be dealt with using @import.
• lstamour 8y ago
  There is lit-html and lit-element, though you can get tripped up by the difference between props and attributes coming from React JSX where everything is props because it’s all native JS until the DOM render... It’s tricky to recommend them because I’m using web components at work and find the transition from React especially rocky. But they are native and standard, and other frameworks are slowly moving in that direction... I expect React will be the last to adopt them, or they’ll push for spec changes before they do... open-wc is also worth a mention: https://dev.to/thepassle/announcing-open-web-components-5h7 https://dev.to/thepassle/announcing-open-web-components-5h7 - their guide and setup for using web components is over here: https://open-wc.org/guide/#quickstart https://open-wc.org/guide/#quickstart You can also technically start using native es modules in browsers, either localhost in Chrome 74+ or via origin whitelist with Google. Or use a polyfill such as Guy Bedford’s https://github.com/systemjs/systemjs/blob/master/docs/import-maps.md https://github.com/systemjs/systemjs/blob/master/docs/import... or https://github.com/guybedford/es-module-shims https://github.com/guybedford/es-module-shims — but you’ll have to consider solutions for custom syntax, scss or non-es module dependencies. I personally think there’s a gap in the npm ecosystem which is building “source packages” that are native single-file es modules you can easily import or compile from with a native JS module system...
  • cynx 8y ago
    And, there is Stencil JS (https://stenciljs.com/ https://stenciljs.com/) which in my opinion offers a neat API to create Web Components.
  • Vinnl 8y ago
    But at that point the headline is "framework x could replace framework y"? Web Components are great for reusable components like date pickers that you might want to re-use regardless of framework. If they're just the technology backing the implementation of some framework, than that framework is only worth switching to if it provides something fundamentally better than the framework you and many others already know, because the mere fact that it's built on Web Components no longer provides a significant advantage...
    • 8y ago
• austincheney 8y ago
  > Web Components don’t offer a declarative way of updating the DOM; What does that mean? The methods provided by the web components spec appear declarative as do the methods provided by the DOM spec. Declarative example with nothing like innerHTML: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow https://developer.mozilla.org/en-US/docs/Web/API/Element/att... Either way this discussion is stupid as updating the DOM is stupid simple even without a framework. The DOM is neither stateful or stateless, but rather that describes the implementation of your application logic. * DOM - https://prettydiff.com/2/guide/unrelated_dom.xhtml https://prettydiff.com/2/guide/unrelated_dom.xhtml * state - https://en.m.wikipedia.org/wiki/State_(computer_science) https://en.m.wikipedia.org/wiki/State_(computer_science) * stupid - https://github.com/prettydiff/wisdom/blob/master/Delusional_Developers.md#common-developer-delusions https://github.com/prettydiff/wisdom/blob/master/Delusional_...
  • Jasper_ 8y ago
    > The DOM is neither stateful or stateless, but rather that describes the implementation of your application logic. One of the bizarre realities with those forced to write their own "virtual DOM" library, as I have done, is to deal with all the so-called hidden state. Form field values, the user's current text selection, scrolling position. Without a virtual DOM, simply replacing existing nodes with innerHTML or replaceChild will stomp this away. I'm not of the opinion that you need a full framework to handle this state (I wrote my own 10-line helper function which works in most cases I care about [0]), but you do need something more structured than just replacing nodes wholesale. [0] https://github.com/magcius/noclip.website/blob/master/src/ui.ts#L24-L49 https://github.com/magcius/noclip.website/blob/master/src/ui...
    • austincheney 8y ago
      What about with using appendChild or insertBefore instead of innerHTML?
      • deleted 8y ago
        [deleted]
• spankalee 8y ago
  There's nothing wrong with using a DOM templating library to give you declarative DOM updating. There are a number of solutions, many even JSX-based, and this is also why I created lit-html, which offers extremely light weight template expressions, similar to JSX but in standard syntax, and very fast updates. There's no requirement that you use web components without helper libraries. That was never their intent.
  • dmitriid 8y ago
    > That was never their intent. No one remembers what the intent was. Just two years ago the whole narrative from the proponents of web components was “the future is here, no need for frameworks, get rid of your reacts and angulars and... and...” But then people actually tried using them. So, curiously, the narrative quickly shifted to “oh, these are just primitive APIs never intended for direct use, and only intended for library and framework authors”. Curiously, at the same time the narrative usually keeps going “react is crap, you should drop it in favor of web components”. A nice recap from Dan Abramov: https://dev.to/dan_abramov/comment/6kh1 https://dev.to/dan_abramov/comment/6kh1 and more in the discussion here: https://dev.to/ben/why-the-react-community-is-missing-the-point-about-web-components-1ic3 https://dev.to/ben/why-the-react-community-is-missing-the-po... And we are in yhe comments to an article that literally argues that Web Components will replace frameworks. While half of the people in the comments say “yeah, the intent is for them to be used only by library and framework authors”. There’s a certain hint of schizophrenia in how Web Components are described by their proponents.
    • dfabulich 8y ago
      Amen! The core problem now is that Web Components aren't any faster than userland frameworks like Preact. Specifically: 1) First Contentful Paint: Web Components require client-side JS to render, which guarantees that their FCP numbers will be slower than React/Preact server-side rendering solutions, which can render without client-side JS. 2) Time to Interactive: LitElement + lit-html at 4KB is smaller than React (but not if you include WC polyfills), though it's not smaller than Preact (3KB). 3) Efficient Updates: lit-html might be able to beat out React/Preact here if you have a large page and you don't use shouldComponentUpdate or React.memo, but lit-html doesn't use Web Components (custom elements, shadow DOM). Haunted "virtual components" (lit-html + React-ish hooks) look pretty cool, but that's still not WC. Without a credible performance advantage, Web Components are a zombie standard, walking dead.
• deleted 8y ago
  [deleted]
• jbwyme 8y ago
  We have been using a small bit of glue code to write Web Components declaratively with Snabbdom for a couple of years at Mixpanel: https://github.com/mixpanel/panel https://github.com/mixpanel/panel. Happy to talk further about our experience!
  • plopz 8y ago
    Thats what lichess uses as well.
• roguecoder 8y ago
  (For security purposes, in vanilla js we should all be using textContent, not innerHTML, and creating dom nodes directly.)
  • kccqzy 8y ago
    When you control the data, innerHTML is fine. It's only untrusted data coming from the user that's the problem.
    • nitrogen 8y ago
      innerHTML has to parse the html, so won't it be a bit slower?
      • kccqzy 8y ago
        Wouldn't the JavaScript engine need to parse your long and complicated chains of `document.createTextNode(blah)` or `parent.appendChild(foo)`?
    • roguecoder 8y ago
      Only if you can, with absolute certainty, keep track of which of those is which, and never have it change, or have some offline process polute data that was supposed to be clean. There is almost never a reason to use innerHTML, and by avoiding it you reduce the surface that could be attacked.
      • algesten 8y ago
        apart from where you actually have html formatted text. not plain text.
      • kccqzy 8y ago
        You are just making things extreme without giving your fellow software engineers some confidence that they won't screw up. Plenty of variables are string constants, or numbers coerced into strings or some such. A good type system will always help though.
• tflinton 8y ago
  "declarative way of updating the DOM" Updating is not declarative.
  • Vinnl 8y ago
    It's React that does the updating, the programmer only writes declarative code.
• z3t4 8y ago
  Never use .innerHTML! Instead use .appendChild, .removeChild, and .innerText. Using .innerHTML is like having a program patch itself during runtime.
  • adrianhel 8y ago
    textContent is usually better than innerText.
  • ravenstine 8y ago
    While I know what you're getting at, the word "never" really isn't helpful or useful. There are certain times where innerHTML(or insertAdjacentHTML) is the best approach. It's really not that slow that it can't be the most clear and concise solution.
    • z3t4 8y ago
      Its not about performance. innerHTML is actually fast. Its about security and maintainability. InnerHTML makes it easy not only for the developer but also an hacker to inject code into a web page/app. innerHTML is like a global missile satellite network that can fire anywhere at any time. Instead you want to design like a plumber, where data flows via a pipe to the database, then back again in another pipe which change the state of the view. You should not have a single HTML tag in your single page application!
• _bxg1 8y ago
  What I don't get is why there isn't a native, declarative DOM templating API yet. It would be so much faster and would mostly eliminate the need for React and the like. Instead of a "virtual dom", a native "dom buffer".
  • augustl 8y ago
    I have high hopes for Flutter/Hummingbird in that regard. When their renderer is implemented using web APIs, this is basically what we'll be getting.
    • madeofpalk 8y ago
      this is just replacing framework a with framework b. It's not a "native, declarative DOM templating API yet"
      • augustl 8y ago
        Well, yes and no. They are implementing a rendering engine that supports things the web famously doesn't support, which includes fundamentals like UITableView from iOS. They are doing this by leveraging new APIs to access what browser layout engines do under the hood. So in that way, it generates native browser elements, and their API is declarative. So it's at least one abstraction layer below React and friends.
        • madeofpalk 8y ago
          ....no and no. The call was for a declarative interface to the DOM, like React, built into the browser. Flutter, being not built into the browser, is not that.
        • _bxg1 8y ago
          There are a million things that do this already - including Qt, which already works in WebGL. The point is to leverage the rest of the web's existing features while also getting declarative templates, not to create another Flash.
• robrez 8y ago
  You might be interested in this: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/w3c/webcomponents/blob/gh-pages/proposals...
• fergie 8y ago
  "React brought a declarative wrapper around the statefulness of the DOM, and that is the killer feature"... Yes, If there was a native standard for watching and manipulating state then frontend frameworks would be largely unnecessary.
• mscasts 8y ago
  I use lit-html and it is more than enough for our needs!
• Vinnl 8y ago
  Yeah, articles that proclaim the end of frameworks due to Web Components always revolve around a misunderstanding of what those frameworks bring. This article, likewise, starts out on the same incorrect premise: > [Frameworks like Angular and React] have enabled us to do what we always wanted but never were able to: creating reusable autonomous frontend components That's not what we always wanted to do, and not why people are using these frameworks. How often do you re-use your Angular and React application?
  • supermatt 8y ago
    I reuse react components ALL the time. I think the problem with the article is that it is just looking at components (as a developer I have wanted the encapsulation this methodology brings), whereas react offers more than that - the virtual DOM, for example.
    • Vinnl 8y ago
      Ah, yes - within the same applications, components are often re-used. Still, it's a stretch to say code re-use is the main reason people are using React. Rather, its advantage lies in its composability and how easy it makes it to separate view logic from other logic. And probably a few other reasons that other people would name as well; in any case, it's not just the ability to re-use components, and an alternative only providing that part is not going to replace React in my applications any time soon.
      • supermatt 8y ago
        I reuse components in different applications. There are also popular third-party components (and even whole libraries) to be found on github and elsewhere. I don't think web components will replace react, simply because they do different things. You can write web components in react which gives you the best of both worlds.
  • pjmlp 8y ago
    > How often do you re-use your Angular and React application? A lot, our Angular components are re-usable across projects.
• deleted 8y ago
  [deleted]