11 ms·

Making Web Components Work

159 points by tdumitrescu 8y ago

dsschnau 8y ago
web components are never happening
- lintroller 8y ago
  That seems like a rather bold statement without much reasoning behind it. What in particular makes you think that web components are "never happening"?
  - ropeadopepope 8y ago
    This looks less than promising: https://caniuse.com/#feat=custom-elements https://caniuse.com/#feat=custom-elements
    - tdumitrescu 8y ago
      That's the deprecated v0 spec, fyi.
      - ropeadopepope 8y ago
        https://caniuse.com/#feat=custom-elementsv1 https://caniuse.com/#feat=custom-elementsv1 doesn't look much better.
        yesimahuman 8y ago
        It's unflagged in firefox nightlies. Edge needs to get with the picture but really they are the only one out at this point. The polyfils, while not ideal, work great and shouldn't be needed much longer. The mobile story here is actually quite strong, since all major mobile platforms have full support for it.
        Klathmon 8y ago
        Out of the 4 major browsers, 2 major browser vendors have support for the base stuff, 1 has it behind a flag being tested ready to be turned on, and 1 doesn't have any support yet... That's pretty far from "not happening"
  - madeuptempacct 8y ago
    I have been using Web Components on and off for about a year. They are a pain in the ass. Require polyfills, large file sizes makes me write hacks to load it conditionally, etc. Angular Elements just came out - they don't work as expected as well.
  - dmitriid 8y ago
    Easy: web components have not implemented a single part of the original promise [1]. It's not Web Components that are happening, it's the dozens of frameworks required to make them work that are happening. Even mixpanel's library "does so by providing an easy-to-use state management and rendering layer built on Virtual DOM (the basis of the core rendering technology of React). Through use of the Snabbdom Virtual DOM library and first-class support for multiple templating formats" [2] Web Components are a very low-level extremely limited crummy DOM-based API that no one in their right mind wants to use. They are not happening. --- [1] https://fronteers.nl/congres/2011/sessions/web-components-and-model-driven-views-alex-russell https://fronteers.nl/congres/2011/sessions/web-components-an... [2] https://github.com/mixpanel/panel https://github.com/mixpanel/panel
- yesimahuman 8y ago
  That's ridiculous. One counter point: Ionic is going to ship web components to many thousands of app store and web apps shortly. A lot of people won't even know they are there, since they look and feel like any other framework component (if they are using Angular, for example). It's happening whether you realize it or not.
  - deleted 8y ago
    [deleted]
- watty 8y ago
  That's like saying "electric cars are never happening". Both already are happening.
- dang 8y ago
  Maybe not, but please don't post unsubstantive comments to Hacker News. Edit: looks like you've been doing this a lot, and it's really not what the site is for. Would you mind reading https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and using HN as intended? The idea is: if you have a substantive point to make, make it thoughtfully; if you don't, please don't comment until you do.
- deleted 8y ago
  [deleted]
k__ 8y ago
I read Polymer is switching to JS modules with 3.0, sounds like a right step for Web Components :)
- spankalee 8y ago
  We already did :)
russellbeattie 8y ago
I just started using Web Components, and in my opinion, their future is definitely very bright. Now that HTML imports have been squashed, they're basically just standard JavaScript objects imported as modules, as they should be. Before, you created a class/object that had a property like foo.el which was the element it was associated with, but the link was tenuous, and required a bunch of code to keep things in sync, and various component styles could easily clash. Extending native elements and the Shadow DOM is a great way to contain everything. Wiring them up to something like Redux or MobX is trivial. The only real missing piece is the concept of props over attributes. If I want to pass an array of ids to a sub-component declaratively, there's not really an easy way to do it. Hopefully there will be some consensus about this soon. The best thing is that this is all part of modern browsers without libraries, or even precompilation. Not every web app needs massive libraries, so having web components as a built-in, light-weight component system is fantastic.
- spankalee 8y ago
  > The only real missing piece is the concept of props over attributes Plenty of HTML templating languages allow for setting properties declaratively. Polymer, lit-html, Vue, Angular, all do. For instance, in lit-extended (an extension of core lit-html), properties are set by default, attributes have a '$' suffix, and event handlers have an 'on-' prefix: html` <my-element aProp=${foo} an-attribute$="${}" on-click=${clickHandler}> </my-element> `;
  - russellbeattie 8y ago
    You're right, but because it's not part of the standard, there's various implementations. This is what I meant about consensus.
    - spankalee 8y ago
      The standard side of things is just that DOM Elements have a JS interface with properties. That there are many ways to set properties on JS objects, with template systems being just one of many. I'm not sure that HTML itself will get a standard way to set properties, even with the Template Instantiation proposal. Encoding the intent to set a property is hard given that all valid attribute names are already valid attribute names, and could have current semantics. Adding new support for currently invalid attribute names sounds like a very difficult thing to do. This can stay at the level of opinionated libraries. You learn how to use that library and it's method for setting properties, and you don't have to worry about other components choices for templating.
kruhft 8y ago
Web Components were interesting but too complicated and never gained traction at Autodesk (my former employer) where we just ended up going with React, which is actually a pretty good solution to the crappy ecosystem that browser based programming has become.
aphextron 8y ago
I've been using web components in production for a while now and it's great. Our front end "stack" consists of a single polyfill and Webpack. Use template literals for templating, so you don't even need handlebars/mustache anymore. Webpack lets you write SASS that is compiled directly to CSS and inserted in your shadow DOM with an ES6 import, so no more style sheets for anything but high level page layout. Everything is standards based web components written in vanilla ES6, transpiled for browser compatibility down to IE10. One major issue we've had though, which wasn't touched in this article, is inter-component communication among siblings. Sure you can just do a global event bus, and that works, but I've yet to see an elegant solution for this yet.
- yesimahuman 8y ago
  For inter-component communication, sounds like redux would be a big help for you. Polymer has a mixin you could use: https://github.com/Polymer/pwa-helpers/blob/master/connect-mixin.js https://github.com/Polymer/pwa-helpers/blob/master/connect-m.... You're not using Stencil, but if others do, it has a redux connector or a simpler state tunnel system for passing state to child components (https://stenciljs.com/ https://stenciljs.com/).
  - interlocutor 8y ago
    No, don't use Redux everywhere. Most applications don't need to manage client-side state. State lives on the server. If your application lets the user edit stuff without immediately sending the update to the server then you may have state, otherwise you don't and you don't need a state manager.
    - mieseratte 8y ago
      Perhaps if your app is just a series of request-response style CRUD forms, at which point why bother using a front-end framework in favor of server-side templates / forms. Toss in jQuery if you want some AJAX. Tossing in Redux (or whatever Flux-like flavor of the day) is a low-effort, high-value add on top of React and obviates the possibility of some bat-shit data-passing situation that would make an OO inheritance junkie blush. If you're the sensitive to boilerplate type, there are some simple libraries to solve that issue. Unless you're tossing together a three component TODO list demo, not using Redux will just bite you in the ass a year down the line in maintenance costs as your application grows. This is really starting to remind me of the "Don't worry about the data model, just toss it in Mongo!" all over again.
jacob019 8y ago
Just started using Vue.js and the components approach makes a lot of sense. Web Components is a not-quite-ready pure JS approach? Vue, polymer, react native... I feel confused every time I read "Web Components" because it means something different depending on context.
- spankalee 8y ago
  Web Components means the standards of <template>, Custom Elements, and Shadow DOM. There's an overview here: https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components Polymer has always been a set of helpers for making Web Components. There are others like SkateJS and Stencil. Vue is not normally Web Components, but they have an option in CLI 3 to compile to Web Components. React and React native have basically nothing to do with Web Components, though React can use Web Components because Web Components are just HTML elements.
  - dmitriid 8y ago
    > Web Components are just HTML elements. Yup. And you can't use Polymer elements in React because React passes data as attributes whereas Polymer expects properties. And then there's the issue of event handlers etc. etc. etc. "Web Components" are now a largely non-intersecting collection of mutually incompatible frameworks and libs: https://custom-elements-everywhere.com https://custom-elements-everywhere.com Good luck using Polymer's <custom-element binding="{{a.b}}"> anywhere
    - spankalee 8y ago
      > And you can't use Polymer elements in React because React passes data as attributes whereas Polymer expects properties This is mostly React's existing opinion that elements don't even need properties set, and is not the fault of Polymer or Web Components. Most Polymer elements are fine with simple types like strings or numbers being set as properties or attributes. > "Web Components" are now a largely non-intersecting collection of mutually incompatible frameworks and libs: https://custom-elements-everywhere.com https://custom-elements-everywhere.com That is a site that says how well _frameworks_ work with Custom Elements, ie do they make closed-world assumptions about HTML that interfere with using Custom Elements. It says nothing much about what a Web Component is, so I'm not sure how Web Components could be "non-intersecting". > Good luck using Polymer's <custom-element binding="{{a.b}}"> anywhere I know you troll every Web Components and Polymer discussion you can now, but this is just a non-sequitur. Polymer's template syntax is only used to implement elements with Polymer. `<custom-element binding="{{a.b}}">` would only ever occur in a Polymer template and is not intended to be used "everywhere", so no luck is needed, thank you.
la_fayette 8y ago
i use stenciljs web component compiler. it is not a framework... it is great as it lets you do things without having to worry about browser support.
dmitriid 8y ago
The lib "does so by providing an easy-to-use state management and rendering layer built on Virtual DOM (the basis of the core rendering technology of React). Through use of the Snabbdom Virtual DOM library and first-class support for multiple templating formats". How is this "making web components work" any different from making DOM work via snabbdom or React?
stupidcar 8y ago
For me, the biggest plus of web components is the potential simplicity of unifying the document's object model with that of your application. Every JS framework, like React, Angular, Vue, etc. seems to have a parallel OM that either wraps or renders into the DOM (Angular seems to have about 5 of them). The result is your can never just use the basic DOM APIs and devtools to inspect and interact with your application's components. Instead, you always have to get at them through some other API, and understand how the UI and state you see in the DOM is produced and updated by some mediating layer (virtual DOM, view hierarchy, etc.). It feels like trying to get at the truth by talking with two different people, who each only possess a subset of the facts.
- derefr 8y ago
  These layers were created for efficiency, not for their own sake; there’s no “DOM transaction API”, so every DOM mutation causes a reflow. Thus, you mutate a virtual DOM, render the resulting changes to a new subdocument, and then replace an existing DOM node with that new subdocument.
  - EvilTerran 8y ago
    > there’s no “DOM transaction API”, so every DOM mutation causes a reflow Perhaps there should be. Has there been any discussion on standardizing such a thing?
  - stupidcar 8y ago
    Incorrect. This idea was a result of some early React users misunderstanding the purpose of the virtual DOM, and has unfortunately been thoughtlessly repeated ever since. In reality, browser engineers are not that stupid. Mutating the DOM will queue a layout operation, but it will not actually occur until the current JS task has finished executing. Within a JS task, such as an event handler, an XHR completion, or a setTimeout, you can mutate the DOM as many times as you like, and it will only result in a single layout pass. (The exception is if you try to read back some measurement from the DOM, such as an element's bounding box, after mutating it. In this case, the browser does have to block while it performs layout, but that is not something can be solved with virtual DOM). So, what is the purpose of the virtual DOM? It was invented to allow React to provide the illusion of full re-rendering. React's authors wanted to a provide an experience similar to that found on the server, where an entire HTML page is re-rendered from scratch for every load. In that way, there is never any possibility of part of the HTML becoming stale, as it all gets recreated from scratch each time. However, the browser DOM is not designed to be blown away and recreated from scratch all the time. Nodes are expensive objects, spanning the JS and C++ worlds. Recreating the whole DOM tree each time any part of it needed updating would be too slow. So, instead, they created the virtual DOM as an intermediate data structure. React renders the virtual DOM. The virtual DOM is diffed against its previous state, and then the changes are applied to the actual DOM tree. In that way, every component's render() method can be executed, but only those parts of the DOM that have actually changed will be updated. It's a nifty optimisation, but it's not about avoiding reflow, it's just another method of dirty checking, similar to that done in other frameworks like Angular or Ember. It's just that React chooses to diff the data structure produced by render(), rather than diffing the model data that is later used for rendering.
mikece 8y ago
I think the next major leap forward in HTML app development will happen when Web Components are portable across client framework types so it's not necessary to rewrite every visual element when switching from Angular6 to Vue or even something compiled to WASM in a few years.
- spankalee 8y ago
  This is exactly what Web Components already do. Web Components are just HTML elements, and generally usable in any framework or with no framework.
  - mikece 8y ago
    Oh -- awesome! I've been focused on back-end and mobile the past few years. I guess it's time to dive into Web Components!
    - themacguffinman 8y ago
      Check out https://www.webcomponents.org/ https://www.webcomponents.org/
  - mikece 8y ago
    Except: https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/ https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-...
    - dmitriid 8y ago
      I'll need to update that with recent developments like: no one uses vanilla WebComponents, as they are unusable. Everybody uses any number of layers on top of them: Polymer, Angular, Stencil, whatever.
      - littlethrowaway 8y ago
        I've been trying to understand why I would use WebComponents over vue/react. Like, if you're going to use a layer on top of WebComponents, why not use something like Vue anyway. Their single file components allow you to compose your templates together <my-widget>Some slot content</my-widget> etc.. I'm struggling to see the use of Web Components. And how easily it's going to be to compose WebComponents in with your custom frameworks' components, I wonder how easy that is going to be (e.g. passing props down to a web component). It seems that you'll still be better off just picking a framework for the next wee while anyway. Still, I'll look forward to your updated article ;)
justrobert 8y ago
One thing their example doesn't handle is browser location history on clicking elements in their UI. Maybe it was due to how simple the example was, but having to click back many times based on how many times a user used the interface is just bad design.
- tdumitrescu 8y ago
  Sorry about that, the example was developed as a standalone SPA with history for the routing. But since we decided to embed it into the blog post itself, the pushState routing doesn't make a lot of sense in that context.
  - justrobert 8y ago
    Ah I figured it'd be something like that. I'm looking forward to a future where we use web components.
westoque 8y ago
Off topic. Not to be harse. But for a company as big as Mixpanel, the blog UI is terrible. No branding at all and seems unprofessional. Even more ironic is they say this as the first line in the post: "Clean, attractive user interfaces and effective user experience have always been pillars of Mixpanel’s products." They should look at companies like GitHub, Facebook, Twitter, and the likes for an example.
- polartx 8y ago
  You are looking at the engineering blog, which--judging by the rest of the mixpanel.com site, probably isn't borrowing much from the marketing/ux side of the company. Check the Mixpanel blog (https://mixpanel.com/blog/ https://mixpanel.com/blog/) and you'll find it the brand consistency more similar to the other tech companies you mentioned. I'm actually okay with engineers spending less time on shiny css and more time on the content of their posts.
beders 8y ago
I still find it bizarre that no one has stated the obvious yet: Having a component tree (because the rendering model of a browser requires it) does not mean state management needs to be cramped into the same tree or use a tree in the first place! A DOM tree itself doesn't do any kind of binding and it doesn't do inter-component communication. (it merely offers events) Why should web components? Keep them as dumb as DOM nodes please. A lone H1 element doesn't register itself on some event bus, doesn't observe attribute changes and doesn't create odd 'actions' tied to some obscure state management system. And it shouldn't.
- lhorie 8y ago
  I was with you until the second paragraph, but DOM elements do sometimes have non-dumb semantics (e.g. <label for="foo">, or <a href="#foo">). There's also a very good reason we have templating languages to loop over table rows.
- yayana 8y ago
  I only recently started looking at upgrading from angularjs to angular and web components were one of the things that made me question the emporer's clothes.. Zone js implements zones and by that they apparently mean exactly 1 zone.. making a supposed abstraction where you can't safely add 2 implementations of web components (or apps?) to 1 page without planning for that with 1 global setup for them.. My initial impression of shadow DOM is that I would get the same scope separation as iframes with a nicer method of passing data and describing the layout.. Then I assumed web components were this missing piece finally implemented.. now I'm wondering if I completely misjudged and everyone else really wanted a complicated footgun where seeming builtins are colliding with your namespace?
- themacguffinman 8y ago
  You don't have to do state management this way, sure, but this functional reactive style of state management has its own set of compelling benefits, like making it easier to reason about side effects and complicated state.
ch3ster 8y ago
A few months ago Mixpanel notified me that they had been accidentally transmitting and storing passwords for some customers due to a UI issue. I wonder if the re-architecting had something to do with that or if it was the resolution.
victor106 8y ago
Web Components are awesome. They will be the future. That said, I feel React has good future just because of React Native. It’s amazing that you can develop highly performant applications and target multiple platforms
- RobertRoberts 8y ago
  Didn't Facebook stop using React Native in their own app (or part of it) because it's performance was poor? Or the file size was gigantic, there was something wrong...
daxfohl 8y ago
They remind me too much of WPF (.net ux tech) which I never cared for. Once I moved to web dev with React I found that much simpler. Web Components seems like a step backwards to me.
ausjke 8y ago
while web components are interesting, how can you do native apps on top of it when needed? e.g. vue-native, react-native etc, or at least support by something like Electron etc. or is it strictly a web-browser-only thing?
- ernsheong 8y ago
  It's a browser spec, so yeah browser-only. Electron is browser-based (Chrome), so web-components can be used there. Check out https://github.com/Polymer/pwa-starter-kit/wiki https://github.com/Polymer/pwa-starter-kit/wiki for concrete examples using LitElement (https://github.com/Polymer/lit-element https://github.com/Polymer/lit-element)
philip1209 8y ago
I'm surprised that the Mixpanel engineering blog is hosted on Wordpress with the default theme. The default theme doesn't align with their designed brand, and it makes me suspicious of whether they have taken steps to secure the installation. For this low-effort of a blog, I would have expected them to use Medium.

159 points by tdumitrescu 8y ago

dsschnau 8y ago

web components are never happening

lintroller 8y ago
That seems like a rather bold statement without much reasoning behind it. What in particular makes you think that web components are "never happening"?
- ropeadopepope 8y ago
  This looks less than promising: https://caniuse.com/#feat=custom-elements https://caniuse.com/#feat=custom-elements
  - tdumitrescu 8y ago
    That's the deprecated v0 spec, fyi.
    - ropeadopepope 8y ago
      https://caniuse.com/#feat=custom-elementsv1 https://caniuse.com/#feat=custom-elementsv1 doesn't look much better.
      - yesimahuman 8y ago
        It's unflagged in firefox nightlies. Edge needs to get with the picture but really they are the only one out at this point. The polyfils, while not ideal, work great and shouldn't be needed much longer. The mobile story here is actually quite strong, since all major mobile platforms have full support for it.
      - Klathmon 8y ago
        Out of the 4 major browsers, 2 major browser vendors have support for the base stuff, 1 has it behind a flag being tested ready to be turned on, and 1 doesn't have any support yet... That's pretty far from "not happening"
- madeuptempacct 8y ago
  I have been using Web Components on and off for about a year. They are a pain in the ass. Require polyfills, large file sizes makes me write hacks to load it conditionally, etc. Angular Elements just came out - they don't work as expected as well.
- dmitriid 8y ago
  Easy: web components have not implemented a single part of the original promise [1]. It's not Web Components that are happening, it's the dozens of frameworks required to make them work that are happening. Even mixpanel's library "does so by providing an easy-to-use state management and rendering layer built on Virtual DOM (the basis of the core rendering technology of React). Through use of the Snabbdom Virtual DOM library and first-class support for multiple templating formats" [2] Web Components are a very low-level extremely limited crummy DOM-based API that no one in their right mind wants to use. They are not happening. --- [1] https://fronteers.nl/congres/2011/sessions/web-components-and-model-driven-views-alex-russell https://fronteers.nl/congres/2011/sessions/web-components-an... [2] https://github.com/mixpanel/panel https://github.com/mixpanel/panel
yesimahuman 8y ago
That's ridiculous. One counter point: Ionic is going to ship web components to many thousands of app store and web apps shortly. A lot of people won't even know they are there, since they look and feel like any other framework component (if they are using Angular, for example). It's happening whether you realize it or not.
- deleted 8y ago
  [deleted]
watty 8y ago
That's like saying "electric cars are never happening". Both already are happening.
dang 8y ago
Maybe not, but please don't post unsubstantive comments to Hacker News. Edit: looks like you've been doing this a lot, and it's really not what the site is for. Would you mind reading https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and using HN as intended? The idea is: if you have a substantive point to make, make it thoughtfully; if you don't, please don't comment until you do.
deleted 8y ago
[deleted]

k__ 8y ago

I read Polymer is switching to JS modules with 3.0, sounds like a right step for Web Components :)

spankalee 8y ago
We already did :)

russellbeattie 8y ago

I just started using Web Components, and in my opinion, their future is definitely very bright. Now that HTML imports have been squashed, they're basically just standard JavaScript objects imported as modules, as they should be. Before, you created a class/object that had a property like foo.el which was the element it was associated with, but the link was tenuous, and required a bunch of code to keep things in sync, and various component styles could easily clash. Extending native elements and the Shadow DOM is a great way to contain everything. Wiring them up to something like Redux or MobX is trivial. The only real missing piece is the concept of props over attributes. If I want to pass an array of ids to a sub-component declaratively, there's not really an easy way to do it. Hopefully there will be some consensus about this soon. The best thing is that this is all part of modern browsers without libraries, or even precompilation. Not every web app needs massive libraries, so having web components as a built-in, light-weight component system is fantastic.

spankalee 8y ago
> The only real missing piece is the concept of props over attributes Plenty of HTML templating languages allow for setting properties declaratively. Polymer, lit-html, Vue, Angular, all do. For instance, in lit-extended (an extension of core lit-html), properties are set by default, attributes have a '$' suffix, and event handlers have an 'on-' prefix: html` <my-element aProp=${foo} an-attribute$="${}" on-click=${clickHandler}> </my-element> `;
- russellbeattie 8y ago
  You're right, but because it's not part of the standard, there's various implementations. This is what I meant about consensus.
  - spankalee 8y ago
    The standard side of things is just that DOM Elements have a JS interface with properties. That there are many ways to set properties on JS objects, with template systems being just one of many. I'm not sure that HTML itself will get a standard way to set properties, even with the Template Instantiation proposal. Encoding the intent to set a property is hard given that all valid attribute names are already valid attribute names, and could have current semantics. Adding new support for currently invalid attribute names sounds like a very difficult thing to do. This can stay at the level of opinionated libraries. You learn how to use that library and it's method for setting properties, and you don't have to worry about other components choices for templating.

kruhft 8y ago

Web Components were interesting but too complicated and never gained traction at Autodesk (my former employer) where we just ended up going with React, which is actually a pretty good solution to the crappy ecosystem that browser based programming has become.

aphextron 8y ago

I've been using web components in production for a while now and it's great. Our front end "stack" consists of a single polyfill and Webpack. Use template literals for templating, so you don't even need handlebars/mustache anymore. Webpack lets you write SASS that is compiled directly to CSS and inserted in your shadow DOM with an ES6 import, so no more style sheets for anything but high level page layout. Everything is standards based web components written in vanilla ES6, transpiled for browser compatibility down to IE10. One major issue we've had though, which wasn't touched in this article, is inter-component communication among siblings. Sure you can just do a global event bus, and that works, but I've yet to see an elegant solution for this yet.

yesimahuman 8y ago
For inter-component communication, sounds like redux would be a big help for you. Polymer has a mixin you could use: https://github.com/Polymer/pwa-helpers/blob/master/connect-mixin.js https://github.com/Polymer/pwa-helpers/blob/master/connect-m.... You're not using Stencil, but if others do, it has a redux connector or a simpler state tunnel system for passing state to child components (https://stenciljs.com/ https://stenciljs.com/).
- interlocutor 8y ago
  No, don't use Redux everywhere. Most applications don't need to manage client-side state. State lives on the server. If your application lets the user edit stuff without immediately sending the update to the server then you may have state, otherwise you don't and you don't need a state manager.
  - mieseratte 8y ago
    Perhaps if your app is just a series of request-response style CRUD forms, at which point why bother using a front-end framework in favor of server-side templates / forms. Toss in jQuery if you want some AJAX. Tossing in Redux (or whatever Flux-like flavor of the day) is a low-effort, high-value add on top of React and obviates the possibility of some bat-shit data-passing situation that would make an OO inheritance junkie blush. If you're the sensitive to boilerplate type, there are some simple libraries to solve that issue. Unless you're tossing together a three component TODO list demo, not using Redux will just bite you in the ass a year down the line in maintenance costs as your application grows. This is really starting to remind me of the "Don't worry about the data model, just toss it in Mongo!" all over again.

jacob019 8y ago

Just started using Vue.js and the components approach makes a lot of sense. Web Components is a not-quite-ready pure JS approach? Vue, polymer, react native... I feel confused every time I read "Web Components" because it means something different depending on context.

spankalee 8y ago
Web Components means the standards of <template>, Custom Elements, and Shadow DOM. There's an overview here: https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components Polymer has always been a set of helpers for making Web Components. There are others like SkateJS and Stencil. Vue is not normally Web Components, but they have an option in CLI 3 to compile to Web Components. React and React native have basically nothing to do with Web Components, though React can use Web Components because Web Components are just HTML elements.
- dmitriid 8y ago
  > Web Components are just HTML elements. Yup. And you can't use Polymer elements in React because React passes data as attributes whereas Polymer expects properties. And then there's the issue of event handlers etc. etc. etc. "Web Components" are now a largely non-intersecting collection of mutually incompatible frameworks and libs: https://custom-elements-everywhere.com https://custom-elements-everywhere.com Good luck using Polymer's <custom-element binding="{{a.b}}"> anywhere
  - spankalee 8y ago
    > And you can't use Polymer elements in React because React passes data as attributes whereas Polymer expects properties This is mostly React's existing opinion that elements don't even need properties set, and is not the fault of Polymer or Web Components. Most Polymer elements are fine with simple types like strings or numbers being set as properties or attributes. > "Web Components" are now a largely non-intersecting collection of mutually incompatible frameworks and libs: https://custom-elements-everywhere.com https://custom-elements-everywhere.com That is a site that says how well _frameworks_ work with Custom Elements, ie do they make closed-world assumptions about HTML that interfere with using Custom Elements. It says nothing much about what a Web Component is, so I'm not sure how Web Components could be "non-intersecting". > Good luck using Polymer's <custom-element binding="{{a.b}}"> anywhere I know you troll every Web Components and Polymer discussion you can now, but this is just a non-sequitur. Polymer's template syntax is only used to implement elements with Polymer. `<custom-element binding="{{a.b}}">` would only ever occur in a Polymer template and is not intended to be used "everywhere", so no luck is needed, thank you.

la_fayette 8y ago

i use stenciljs web component compiler. it is not a framework... it is great as it lets you do things without having to worry about browser support.

dmitriid 8y ago

The lib "does so by providing an easy-to-use state management and rendering layer built on Virtual DOM (the basis of the core rendering technology of React). Through use of the Snabbdom Virtual DOM library and first-class support for multiple templating formats". How is this "making web components work" any different from making DOM work via snabbdom or React?

stupidcar 8y ago

For me, the biggest plus of web components is the potential simplicity of unifying the document's object model with that of your application. Every JS framework, like React, Angular, Vue, etc. seems to have a parallel OM that either wraps or renders into the DOM (Angular seems to have about 5 of them). The result is your can never just use the basic DOM APIs and devtools to inspect and interact with your application's components. Instead, you always have to get at them through some other API, and understand how the UI and state you see in the DOM is produced and updated by some mediating layer (virtual DOM, view hierarchy, etc.). It feels like trying to get at the truth by talking with two different people, who each only possess a subset of the facts.

derefr 8y ago
These layers were created for efficiency, not for their own sake; there’s no “DOM transaction API”, so every DOM mutation causes a reflow. Thus, you mutate a virtual DOM, render the resulting changes to a new subdocument, and then replace an existing DOM node with that new subdocument.
- EvilTerran 8y ago
  > there’s no “DOM transaction API”, so every DOM mutation causes a reflow Perhaps there should be. Has there been any discussion on standardizing such a thing?
- stupidcar 8y ago
  Incorrect. This idea was a result of some early React users misunderstanding the purpose of the virtual DOM, and has unfortunately been thoughtlessly repeated ever since. In reality, browser engineers are not that stupid. Mutating the DOM will queue a layout operation, but it will not actually occur until the current JS task has finished executing. Within a JS task, such as an event handler, an XHR completion, or a setTimeout, you can mutate the DOM as many times as you like, and it will only result in a single layout pass. (The exception is if you try to read back some measurement from the DOM, such as an element's bounding box, after mutating it. In this case, the browser does have to block while it performs layout, but that is not something can be solved with virtual DOM). So, what is the purpose of the virtual DOM? It was invented to allow React to provide the illusion of full re-rendering. React's authors wanted to a provide an experience similar to that found on the server, where an entire HTML page is re-rendered from scratch for every load. In that way, there is never any possibility of part of the HTML becoming stale, as it all gets recreated from scratch each time. However, the browser DOM is not designed to be blown away and recreated from scratch all the time. Nodes are expensive objects, spanning the JS and C++ worlds. Recreating the whole DOM tree each time any part of it needed updating would be too slow. So, instead, they created the virtual DOM as an intermediate data structure. React renders the virtual DOM. The virtual DOM is diffed against its previous state, and then the changes are applied to the actual DOM tree. In that way, every component's render() method can be executed, but only those parts of the DOM that have actually changed will be updated. It's a nifty optimisation, but it's not about avoiding reflow, it's just another method of dirty checking, similar to that done in other frameworks like Angular or Ember. It's just that React chooses to diff the data structure produced by render(), rather than diffing the model data that is later used for rendering.

mikece 8y ago

I think the next major leap forward in HTML app development will happen when Web Components are portable across client framework types so it's not necessary to rewrite every visual element when switching from Angular6 to Vue or even something compiled to WASM in a few years.

spankalee 8y ago
This is exactly what Web Components already do. Web Components are just HTML elements, and generally usable in any framework or with no framework.
- mikece 8y ago
  Oh -- awesome! I've been focused on back-end and mobile the past few years. I guess it's time to dive into Web Components!
  - themacguffinman 8y ago
    Check out https://www.webcomponents.org/ https://www.webcomponents.org/
- mikece 8y ago
  Except: https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/ https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-...
  - dmitriid 8y ago
    I'll need to update that with recent developments like: no one uses vanilla WebComponents, as they are unusable. Everybody uses any number of layers on top of them: Polymer, Angular, Stencil, whatever.
    - littlethrowaway 8y ago
      I've been trying to understand why I would use WebComponents over vue/react. Like, if you're going to use a layer on top of WebComponents, why not use something like Vue anyway. Their single file components allow you to compose your templates together <my-widget>Some slot content</my-widget> etc.. I'm struggling to see the use of Web Components. And how easily it's going to be to compose WebComponents in with your custom frameworks' components, I wonder how easy that is going to be (e.g. passing props down to a web component). It seems that you'll still be better off just picking a framework for the next wee while anyway. Still, I'll look forward to your updated article ;)

justrobert 8y ago

One thing their example doesn't handle is browser location history on clicking elements in their UI. Maybe it was due to how simple the example was, but having to click back many times based on how many times a user used the interface is just bad design.

tdumitrescu 8y ago
Sorry about that, the example was developed as a standalone SPA with history for the routing. But since we decided to embed it into the blog post itself, the pushState routing doesn't make a lot of sense in that context.
- justrobert 8y ago
  Ah I figured it'd be something like that. I'm looking forward to a future where we use web components.

westoque 8y ago

Off topic. Not to be harse. But for a company as big as Mixpanel, the blog UI is terrible. No branding at all and seems unprofessional. Even more ironic is they say this as the first line in the post: "Clean, attractive user interfaces and effective user experience have always been pillars of Mixpanel’s products." They should look at companies like GitHub, Facebook, Twitter, and the likes for an example.

polartx 8y ago
You are looking at the engineering blog, which--judging by the rest of the mixpanel.com site, probably isn't borrowing much from the marketing/ux side of the company. Check the Mixpanel blog (https://mixpanel.com/blog/ https://mixpanel.com/blog/) and you'll find it the brand consistency more similar to the other tech companies you mentioned. I'm actually okay with engineers spending less time on shiny css and more time on the content of their posts.

beders 8y ago

I still find it bizarre that no one has stated the obvious yet: Having a component tree (because the rendering model of a browser requires it) does not mean state management needs to be cramped into the same tree or use a tree in the first place! A DOM tree itself doesn't do any kind of binding and it doesn't do inter-component communication. (it merely offers events) Why should web components? Keep them as dumb as DOM nodes please. A lone H1 element doesn't register itself on some event bus, doesn't observe attribute changes and doesn't create odd 'actions' tied to some obscure state management system. And it shouldn't.

lhorie 8y ago
I was with you until the second paragraph, but DOM elements do sometimes have non-dumb semantics (e.g. <label for="foo">, or <a href="#foo">). There's also a very good reason we have templating languages to loop over table rows.
yayana 8y ago
I only recently started looking at upgrading from angularjs to angular and web components were one of the things that made me question the emporer's clothes.. Zone js implements zones and by that they apparently mean exactly 1 zone.. making a supposed abstraction where you can't safely add 2 implementations of web components (or apps?) to 1 page without planning for that with 1 global setup for them.. My initial impression of shadow DOM is that I would get the same scope separation as iframes with a nicer method of passing data and describing the layout.. Then I assumed web components were this missing piece finally implemented.. now I'm wondering if I completely misjudged and everyone else really wanted a complicated footgun where seeming builtins are colliding with your namespace?
themacguffinman 8y ago
You don't have to do state management this way, sure, but this functional reactive style of state management has its own set of compelling benefits, like making it easier to reason about side effects and complicated state.

ch3ster 8y ago

A few months ago Mixpanel notified me that they had been accidentally transmitting and storing passwords for some customers due to a UI issue. I wonder if the re-architecting had something to do with that or if it was the resolution.

victor106 8y ago

Web Components are awesome. They will be the future. That said, I feel React has good future just because of React Native. It’s amazing that you can develop highly performant applications and target multiple platforms

RobertRoberts 8y ago
Didn't Facebook stop using React Native in their own app (or part of it) because it's performance was poor? Or the file size was gigantic, there was something wrong...

daxfohl 8y ago

They remind me too much of WPF (.net ux tech) which I never cared for. Once I moved to web dev with React I found that much simpler. Web Components seems like a step backwards to me.

ausjke 8y ago

while web components are interesting, how can you do native apps on top of it when needed? e.g. vue-native, react-native etc, or at least support by something like Electron etc. or is it strictly a web-browser-only thing?

ernsheong 8y ago
It's a browser spec, so yeah browser-only. Electron is browser-based (Chrome), so web-components can be used there. Check out https://github.com/Polymer/pwa-starter-kit/wiki https://github.com/Polymer/pwa-starter-kit/wiki for concrete examples using LitElement (https://github.com/Polymer/lit-element https://github.com/Polymer/lit-element)

philip1209 8y ago

I'm surprised that the Mixpanel engineering blog is hosted on Wordpress with the default theme. The default theme doesn't align with their designed brand, and it makes me suspicious of whether they have taken steps to secure the installation. For this low-effort of a blog, I would have expected them to use Medium.