Introduction to HTML Components(blog.mecheye.net)
blog.mecheye.net
Introduction to HTML Components
http://blog.mecheye.net/2017/08/introduction-to-html-components/
144 comments
I think that people that disregard Polymer fail to understand that Web Components are already here.
They are fully supported on Chrome and Safari, and hopefully Firefox and EDGE will eventually catch up with them.
And they have to, because Chrome and Safari own the mobile web.
Polymer is transitioning to being a thin layer on top of what the browsers support, which basically means a Polyfill for Firefox and Edge, and utility classes to make writing components easier.
Web Components is what is making me finally get to love web development again.
If it is to make an application platform out of browsers, then give me a platform, not an application for doing hypertext documents that we try to bend for something else.
Chrome settings panel, the new You Tube, all new EA gaming portals are already using Web Components.
I look forward to have something like Blend for Web Components.
https://www.youtube.com/watch?v=otcmcNY-3pk&t=17s
EDIT: fixed a few grammar issues
They are fully supported on Chrome and Safari, and hopefully Firefox and EDGE will eventually catch up with them.
And they have to, because Chrome and Safari own the mobile web.
Polymer is transitioning to being a thin layer on top of what the browsers support, which basically means a Polyfill for Firefox and Edge, and utility classes to make writing components easier.
Web Components is what is making me finally get to love web development again.
If it is to make an application platform out of browsers, then give me a platform, not an application for doing hypertext documents that we try to bend for something else.
Chrome settings panel, the new You Tube, all new EA gaming portals are already using Web Components.
I look forward to have something like Blend for Web Components.
https://www.youtube.com/watch?v=otcmcNY-3pk&t=17s
EDIT: fixed a few grammar issues
>I think that people that disregard Polymer fail to understand that Web Components are already here.
XHTML was "already there" too.
>They are fully supported on Chrome and Safari, and hopefully Firefox and EDGE will eventually catch up with them.
With React, Vue etc going strong, I don't see them going anywhere even after that. They solve less problems in a messier way.
XHTML was "already there" too.
>They are fully supported on Chrome and Safari, and hopefully Firefox and EDGE will eventually catch up with them.
With React, Vue etc going strong, I don't see them going anywhere even after that. They solve less problems in a messier way.
The big benefit (once Firefox and EDGE support them) is in not needing to download 132K of Javascript for basic platform functionality.
It's much like JQuery. It was very much necessary when it came out in 2006. But then browsers got querySelectorAll, classList, uniform event handling, uniform dimensions, fetch, animations, transitions, data-attributes, and basically all the other functionality in JQuery.
The JQuery API is still more convenient in many cases, and several loyalists are still like "You'll pry JQuery out of my cold, dead fingers." But they build worse sites - for the same functionality, their sites are slower, take longer to load, and have more things that can go wrong. The market usually flushes such loyalists out eventually, and we may see a similar situation with React/Vue/Angular when components are standardized across browsers.
It's much like JQuery. It was very much necessary when it came out in 2006. But then browsers got querySelectorAll, classList, uniform event handling, uniform dimensions, fetch, animations, transitions, data-attributes, and basically all the other functionality in JQuery.
The JQuery API is still more convenient in many cases, and several loyalists are still like "You'll pry JQuery out of my cold, dead fingers." But they build worse sites - for the same functionality, their sites are slower, take longer to load, and have more things that can go wrong. The market usually flushes such loyalists out eventually, and we may see a similar situation with React/Vue/Angular when components are standardized across browsers.
>The big benefit (once Firefox and EDGE support them) is in not needing to download 132K of Javascript for basic platform functionality.
If that's the big benefit, then it will be increasingly irrelevant (assuming its not already), including on the mobile space.
Especially since those 132K (for React, Angular, and the like) are not "basic platform functionality" but give tons of things that Web Components do not.
If that's the big benefit, then it will be increasingly irrelevant (assuming its not already), including on the mobile space.
Especially since those 132K (for React, Angular, and the like) are not "basic platform functionality" but give tons of things that Web Components do not.
>> for the same functionality, their sites are slower, take longer to load, and have more things that can go wrong
I would like to see sources supporting these claims, please.
I would like to see sources supporting these claims, please.
I don't think I've ever seen a Polymer-powered page of any substance use less than 132kb of JavaScript. File size is really not a good reason to choose web components, especially when you consider the things you need to do to actually work efficiently with web components once you have them.
Custom elements is like an API of six methods `connectedCallback`, `disconnectedCallback`, attributeChangedCallback`, `adoptedCallback`, `attributes` and `register`. I don't see why this must nescessarily be compared with React or Vue any more than `appendChild` or `inserBefore` or any of the other DOM APIs. High level frameworks use the current DOM APIs now and they will surely use the new APIs in the future, but that doesn't mean that you have to use them, that's in fact the whole selling point of React and Vue.
You can use custom elements in React and you can even use React in custom elements, so they are not designed to be competing technologies. Quite the opposite.
You can use custom elements in React and you can even use React in custom elements, so they are not designed to be competing technologies. Quite the opposite.
In what messier way exactly? Do you have any specifics?
The component models are largely analogous. React and Vue could use custom elements if they chose to.
The component models are largely analogous. React and Vue could use custom elements if they chose to.
Developer usability: the fact that they're largely analogous is literally why the implementations that stick to one language, taking advantage of new language features as they pop up, and abstract away all the bindings, win out over something like Polymer, which sticks to the separation of HTML, CSS, and JS.
React, for instance, has changed a lot since its first release, mostly to do what devs need it to do with a bare minimum of coding on their part. That is in stark contrast to Polymer, which requires devs to write out a lot of the logic that you simply get "for free" with React. Writing a pure JS class that "just works" just because it has the two words "extends Component" is a hugely winning benefit, for example.
Take something like https://codelabs.developers.google.com/codelabs/polymer-firs... - it certainly does the job, the code is clean, and the separation of concern follows the traditional HTML/CSS/JS model. But as a developer, what I see is an inefficient implementation that requires me to put loads of stuff in that should be taken care of for me: "Why would you need to say what my component 'is'? Tooling should see that already.". Also, all browsers already handle arbitrary properties, so "Why would you need say which properties can be used, except for schema enforcement". (if I say <div cats="yes"> then every browser already sets that attribute key:value correctly). And of course: "Why would you need to specify which events to listen to instead of just implementing the relevant function hook? Tooling should take care of the rest".
So what I _want_ to write as a developer who's used to efficient web-component-like libraries is something like:
import { register, Component } from 'polymer' register('icon-toggle', class IconToggle extends Component { onAttributeChange(attr) { if (attr.name === 'toggleIcon') { ... } } onPressed(evt) { this.pressed = !this.pressed; } });
And we're done, that should tell the library everything it needs to know.
It really is just a matter of "what lets me do the most while saying the least". Polymer requires me to write a book where React or Vue let me write a memo. Does it make it harder for a search engine to index my site? Sure. But that's what seo/og is for. Does it make it harder for a user to inspect-element? Sure, but that's their problem, not mine. Does it make it harder for someone else to learn how I did something if I don't host the code on github or something? Sure, but I am under no obligation to write code that, in production, is easy to debug and replicate.
So while Polymer is super strong for all of those, realistically: I only care at the academic level, because that's not where my time and efforts lie.
React, for instance, has changed a lot since its first release, mostly to do what devs need it to do with a bare minimum of coding on their part. That is in stark contrast to Polymer, which requires devs to write out a lot of the logic that you simply get "for free" with React. Writing a pure JS class that "just works" just because it has the two words "extends Component" is a hugely winning benefit, for example.
Take something like https://codelabs.developers.google.com/codelabs/polymer-firs... - it certainly does the job, the code is clean, and the separation of concern follows the traditional HTML/CSS/JS model. But as a developer, what I see is an inefficient implementation that requires me to put loads of stuff in that should be taken care of for me: "Why would you need to say what my component 'is'? Tooling should see that already.". Also, all browsers already handle arbitrary properties, so "Why would you need say which properties can be used, except for schema enforcement". (if I say <div cats="yes"> then every browser already sets that attribute key:value correctly). And of course: "Why would you need to specify which events to listen to instead of just implementing the relevant function hook? Tooling should take care of the rest".
So what I _want_ to write as a developer who's used to efficient web-component-like libraries is something like:
import { register, Component } from 'polymer' register('icon-toggle', class IconToggle extends Component { onAttributeChange(attr) { if (attr.name === 'toggleIcon') { ... } } onPressed(evt) { this.pressed = !this.pressed; } });
And we're done, that should tell the library everything it needs to know.
It really is just a matter of "what lets me do the most while saying the least". Polymer requires me to write a book where React or Vue let me write a memo. Does it make it harder for a search engine to index my site? Sure. But that's what seo/og is for. Does it make it harder for a user to inspect-element? Sure, but that's their problem, not mine. Does it make it harder for someone else to learn how I did something if I don't host the code on github or something? Sure, but I am under no obligation to write code that, in production, is easy to debug and replicate.
So while Polymer is super strong for all of those, realistically: I only care at the academic level, because that's not where my time and efforts lie.
It seems as if you are a bit misguided about Polymer. I recommend that you take a look at a Polymer 2 element instead of a Polymer 1 element:
https://www.polymer-project.org/2.0/start/first-element/step...
The reason you have to define what an element 'is' is for backwards-compat reasons. Additionally, the properties definition block is there simply for attribute -> property serialization so that you can set properties declaratively in the HTML as attributes. The property declaration is also used for tooling schema enforcement just as you suggested it should really be there for. You do not need a properties block at all since Polymer uses webcomponents, and as you said, elements can handle arbitrary attributes (and attributes set in JS with the exception of the data- attributes [1]).
In Polymer 2, you simply set the function hook just like you wanted. Polymer 3 which is essentially just a refactoring of Polymer 2 introduces JS Modules. An example would be:
[1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...
[2] https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
[3] https://www.youtube.com/watch?v=ruql541T7gc
https://www.polymer-project.org/2.0/start/first-element/step...
The reason you have to define what an element 'is' is for backwards-compat reasons. Additionally, the properties definition block is there simply for attribute -> property serialization so that you can set properties declaratively in the HTML as attributes. The property declaration is also used for tooling schema enforcement just as you suggested it should really be there for. You do not need a properties block at all since Polymer uses webcomponents, and as you said, elements can handle arbitrary attributes (and attributes set in JS with the exception of the data- attributes [1]).
In Polymer 2, you simply set the function hook just like you wanted. Polymer 3 which is essentially just a refactoring of Polymer 2 introduces JS Modules. An example would be:
import {Polymer} from 'pathToPolymer';
export class IconToggle extends Polymer.Element {
static get is() { return 'icon-toggle' }
observedAttributes() { return ['toggleIcon'] }
attributeChangedCallback(name, old, new) { if(name === 'toggleIcon') {...} }
connectedCallback() { super.connectedCallback(); this.addEventListener('pressed', this.onPressed.bind(this)); }
onPressed(evt) { this.pressed = !this.pressed; }
}
customElements.define(IconToggle.is, IconToggle);
[1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...
[2] https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
[3] https://www.youtube.com/watch?v=ruql541T7gc
As a dev, comparing technologies given that I've already used Vue and React, I still see lots of code that I've become accustomed to not needing to specify, making even Polymer 2 still feel clunky and bloated: there is still no reason for that "is()" or "observedAttributes()" (tooling should take care of that), and the fact that you manually need to initiate the super chain in connectedCallback instead of having a side call to a function with a name that indicates what it's actually for, with the chain taken care of by the super class (if your callback function has the word "callback" in it, that's already a wasted 8 characters that could have been used to actually name the function after what it does) still makes me go "this is silly, why would I go back to such a verbose technology?".
Polymer 2 looks better than polymer 1 for sure, but if I'm comparing what I need to write in React vs. Polymer 2, the former still beats out the latter in terms of low effort, high productivity.
And to be clear: the reason I think (and the numbers bear out that) React and Vue etc. beat out Polymer still is because they can do the same things as polymer: the on-page result is identical. Except React and Vue offer a better dev experience... provided you buy into the development model, of course. But this is also true for people who first start with Polymer: they have to buy into the idea that the classic web stack is the best solution to the problem of needing custom components.
And that reveals the major difference, in turn revealing another reason why Polymer is not as popular as one might hope: Polymer is a web presentation and interaction technology, whereas for instance React is a universal UI technology. They're not even remotely the same thing: the latter is effectively a superclass of the former. For example, as long as you call the functions that React tells you need to be used to effect UI updates, you will never have to think about "where this code runs". Web? Mobile? Desktop? Someone's GTK+ application on embedded hardware with JS support? It literally doesn't matter: call the functions, and it will work. The fact that the DOM is used in the browser is pretty much irrelevant to React - it's only relevant to devs who want to explicitly tie their UI to APIs that are only available in a browser. Polymer takes an approach that is diametrically opposite to this: it keeps things as "webby" as possible, making you write DOM, and only DOM, elements.
So that is another reason for the difference in dev experience: React has abstracted as much as possible so as to only expose what you need because it wouldn't be able to do its job as UI technology if it kept exposing platform-specific construct, whereas Polymer can keep things explicitly tied to the browser stack, and thus never got pushed to be as self-contained as possible, with as high a productivity:effort ratio.
(and whether that's a good or bad decision is irrelevant when discussing 'why is one of these more/less popular than the other', even if I certainly have opinions there. I'd love for React to be more webby, like polymer, but if it was, it would be much clunkier)
Polymer 2 looks better than polymer 1 for sure, but if I'm comparing what I need to write in React vs. Polymer 2, the former still beats out the latter in terms of low effort, high productivity.
And to be clear: the reason I think (and the numbers bear out that) React and Vue etc. beat out Polymer still is because they can do the same things as polymer: the on-page result is identical. Except React and Vue offer a better dev experience... provided you buy into the development model, of course. But this is also true for people who first start with Polymer: they have to buy into the idea that the classic web stack is the best solution to the problem of needing custom components.
And that reveals the major difference, in turn revealing another reason why Polymer is not as popular as one might hope: Polymer is a web presentation and interaction technology, whereas for instance React is a universal UI technology. They're not even remotely the same thing: the latter is effectively a superclass of the former. For example, as long as you call the functions that React tells you need to be used to effect UI updates, you will never have to think about "where this code runs". Web? Mobile? Desktop? Someone's GTK+ application on embedded hardware with JS support? It literally doesn't matter: call the functions, and it will work. The fact that the DOM is used in the browser is pretty much irrelevant to React - it's only relevant to devs who want to explicitly tie their UI to APIs that are only available in a browser. Polymer takes an approach that is diametrically opposite to this: it keeps things as "webby" as possible, making you write DOM, and only DOM, elements.
So that is another reason for the difference in dev experience: React has abstracted as much as possible so as to only expose what you need because it wouldn't be able to do its job as UI technology if it kept exposing platform-specific construct, whereas Polymer can keep things explicitly tied to the browser stack, and thus never got pushed to be as self-contained as possible, with as high a productivity:effort ratio.
(and whether that's a good or bad decision is irrelevant when discussing 'why is one of these more/less popular than the other', even if I certainly have opinions there. I'd love for React to be more webby, like polymer, but if it was, it would be much clunkier)
> I think that people that disregard Polymer fail to understand that Web Components are already here.
No. Polymer is here. As Rob Dodson said, "Polymer is the jQuery of WebComponents".
No one in their right mind would even think about writing and using WebComponents in vanilla JS.
Hence we're coming back to the problem with WebComponents: they are a solution in search of a problem.
No. Polymer is here. As Rob Dodson said, "Polymer is the jQuery of WebComponents".
No one in their right mind would even think about writing and using WebComponents in vanilla JS.
Hence we're coming back to the problem with WebComponents: they are a solution in search of a problem.
> No one in their right mind would even think about writing and using WebComponents in vanilla JS.
Why not? I have written a complete widget toolkit [1] this way. With vanilla APIs the code is a bit more verbose and repetitive, but in turn you get more options for speed optimization and fine-tuning.
[1] https://github.com/jarek-foksa/xel
Why not? I have written a complete widget toolkit [1] this way. With vanilla APIs the code is a bit more verbose and repetitive, but in turn you get more options for speed optimization and fine-tuning.
[1] https://github.com/jarek-foksa/xel
You get a small set of APIs that allow you to encapsulate, so what, encapsulation never was the problem. Now how do you bind, how does the UI react to store changes, how do you bring state managers into this, etc. We'd be in 2010 fighting the naked dom all over again.
As for optimization, vanilla won't be faster than a framework unless you write one from scratch. That means having a scheduler in place that orders dom read/writes, pooled events listening from a single source (the main document), a prioritizer that can cull, something that diffs state in order to render the minimal set of components, etc. Many don't realize the effort that goes into these libs to render as efficient as possible. Even if some stuff is baked into the browser, the field is moving so fast that we get higher benefits from community driven optimizations. And that is an understatement if you look at things like React Fiber.
As for optimization, vanilla won't be faster than a framework unless you write one from scratch. That means having a scheduler in place that orders dom read/writes, pooled events listening from a single source (the main document), a prioritizer that can cull, something that diffs state in order to render the minimal set of components, etc. Many don't realize the effort that goes into these libs to render as efficient as possible. Even if some stuff is baked into the browser, the field is moving so fast that we get higher benefits from community driven optimizations. And that is an understatement if you look at things like React Fiber.
> With vanilla APIs the code is a bit more verbose and repetitive
Exactly. Just the code for syncing attributes and properties is enough to never ever use vanilla JS for WCs
Exactly. Just the code for syncing attributes and properties is enough to never ever use vanilla JS for WCs
They are not a solution in search of a problem. They have a very clear problem statement, it's hard to orchestrate reusable front-end code. React's problem statement is roughly the same, but react seeks to provide more structure and functionality to the foundation of web components. The WebComponent spec is just trying to formalise that foundation.
> They have a very clear problem statement, it's hard to orchestrate reusable front-end code.
I'd love to see that problem statement written anywhere in any of the webcomponent-related specs or sites.
If it were true, they would not have such cumbersome APIs, for example.
On the contrary, WebComponents, as they turn out to be, realise next to none of their original goals: https://fronteers.nl/congres/2011/sessions/web-components-an...
> but react seeks to provide more structure and functionality to the foundation of web components.
React has nothing to do with web components. Until less than a year ago React team was set against WebComponents in any shape or form: https://docs.google.com/document/d/1QZxArgMwidgCrAbuSikcB2iB...
What React was, and is, is a library with a specific goal that solved a specific problem, and it's basically this: "Build encapsulated components that manage their own state, then compose them to make complex UIs."
No one really knows what WebComponents are, and what problems they solve. I know what Polymer is and what it attempts to solve though.
I'd love to see that problem statement written anywhere in any of the webcomponent-related specs or sites.
If it were true, they would not have such cumbersome APIs, for example.
On the contrary, WebComponents, as they turn out to be, realise next to none of their original goals: https://fronteers.nl/congres/2011/sessions/web-components-an...
> but react seeks to provide more structure and functionality to the foundation of web components.
React has nothing to do with web components. Until less than a year ago React team was set against WebComponents in any shape or form: https://docs.google.com/document/d/1QZxArgMwidgCrAbuSikcB2iB...
What React was, and is, is a library with a specific goal that solved a specific problem, and it's basically this: "Build encapsulated components that manage their own state, then compose them to make complex UIs."
No one really knows what WebComponents are, and what problems they solve. I know what Polymer is and what it attempts to solve though.
> No one really knows what WebComponents are
That is ridiculous. They've come from some impetus, derived by some individuals, and they obviously had a goal in mind. They are in a spec, they're being implemented into browsers, they're emulated or polyfilled by various JS libraries, and they're being used by individuals around the web.
> I know what Polymer is and what it attempts to solve though.
The WebComponents spec is admittedly lacking a full feature set to truly enable "Encapsulated Components" but with really not very much work ( https://bitbucket.org/polylab/polyblocks ) you can get pretty close.
I guess I'm simply not understanding what all the fuss is about. I think those busy building with React and friends might see no point to it, because why not just build it in React right? But not everything needs to be a highly orchestrated complex UI, and in those circumstances I still want to be able to re-use my frontend code.
That is ridiculous. They've come from some impetus, derived by some individuals, and they obviously had a goal in mind. They are in a spec, they're being implemented into browsers, they're emulated or polyfilled by various JS libraries, and they're being used by individuals around the web.
> I know what Polymer is and what it attempts to solve though.
The WebComponents spec is admittedly lacking a full feature set to truly enable "Encapsulated Components" but with really not very much work ( https://bitbucket.org/polylab/polyblocks ) you can get pretty close.
I guess I'm simply not understanding what all the fuss is about. I think those busy building with React and friends might see no point to it, because why not just build it in React right? But not everything needs to be a highly orchestrated complex UI, and in those circumstances I still want to be able to re-use my frontend code.
> That is ridiculous. They've come from some impetus, derived by some individuals, and they obviously had a goal in mind. They are in a spec, they're being implemented into browsers, they're emulated or polyfilled by various JS libraries, and they're being used by individuals around the web.
Yeah, yeah, yeah. Snake oil is also used by many people who say they know what they are doing.
And then you get presentations like this: https://www.youtube.com/watch?v=sK1ODp0nDbM where you learn that:
- people who implement the spec in the browser don't even have reference components
- people who try to sell the vision of WebComponents have to use pseudocode in their presentations because the APIs are horrendous
- the very same people casually drop things like "if we could only agree on how webcomponents should behave"
etc. etc. etc.
> I guess I'm simply not understanding what all the fuss is about. I think those busy building with React and friends might see no point to it, because why not just build it in React right?
Kinda. As someone else put it in the comment here: WebComponents are solving a problem no one has had for at least five years now. They are a solution in search of the problem. Worse still, they are entirely highjacked by Polymer.
Yeah, yeah, yeah. Snake oil is also used by many people who say they know what they are doing.
And then you get presentations like this: https://www.youtube.com/watch?v=sK1ODp0nDbM where you learn that:
- people who implement the spec in the browser don't even have reference components
- people who try to sell the vision of WebComponents have to use pseudocode in their presentations because the APIs are horrendous
- the very same people casually drop things like "if we could only agree on how webcomponents should behave"
etc. etc. etc.
> I guess I'm simply not understanding what all the fuss is about. I think those busy building with React and friends might see no point to it, because why not just build it in React right?
Kinda. As someone else put it in the comment here: WebComponents are solving a problem no one has had for at least five years now. They are a solution in search of the problem. Worse still, they are entirely highjacked by Polymer.
> "Build encapsulated components that manage their own state, then compose them to make complex UIs."
uh, this applies to Web Components too. In what way do you think they're different?
uh, this applies to Web Components too. In what way do you think they're different?
I have no idea what the purpose of WebComponents is anymore. Any and all of their original goals [1] are either not there anymore or solved in much better ways than whatever specs have become.
Right now the narrative is "build reusable components that you can use anywhere regardless of library". We've been using jQuery components in our React projects for years, so the fuss is largely overrated.
And since the vast majority of components are extremely highly Polymer-specific, good luck figuring out how to work with their components, it's no better than figuring out how to hook up a jQuery component.
[1] https://fronteers.nl/congres/2011/sessions/web-components-an...
Right now the narrative is "build reusable components that you can use anywhere regardless of library". We've been using jQuery components in our React projects for years, so the fuss is largely overrated.
And since the vast majority of components are extremely highly Polymer-specific, good luck figuring out how to work with their components, it's no better than figuring out how to hook up a jQuery component.
[1] https://fronteers.nl/congres/2011/sessions/web-components-an...
FWIW a google search on that quote shows it was from Monica Dinculescu, if you don't mind updating that attribution. Thanks!
https://meowni.ca/posts/web-components-with-otters/
https://meowni.ca/posts/web-components-with-otters/
> As Rob Dodson said, "Polymer is the jQuery of WebComponents".
How about x-tag, a competing WP framework from Mozilla/Microsoft? I don't see any any mention of that.
How about x-tag, a competing WP framework from Mozilla/Microsoft? I don't see any any mention of that.
x-tag is mentioned on the WebComponents site--and it works with the same underlying technologies as Polymer: shadow dom, HTML imports, custom elements and templates: https://www.webcomponents.org/libraries
Because for all intents and purposes it's absolutely irrelevant.
If you go to webcomponents.org, you'll see that the overwhelming majority of components there are Polymer components.
If you go to webcomponents.org, you'll see that the overwhelming majority of components there are Polymer components.
Well, I think mainly it's because Google is behind webcomponents.org. It has ZERO mentioning on x-tag and other competing frameworks. Ironically, it is called "webcomponents.org".
It's like visiting a store called "phone" that sells iPhone exclusively. Google has definitely got own its down agenda with the so-called standards in this regard.
Unsurprisingly, a searching "x-tag" on webcomponents.org returns pathetically two components.
It's like visiting a store called "phone" that sells iPhone exclusively. Google has definitely got own its down agenda with the so-called standards in this regard.
Unsurprisingly, a searching "x-tag" on webcomponents.org returns pathetically two components.
> It's like visiting a store called "phone" that sells iPhone exclusively
Not really a fair analogy as anyone can submit elements to webcomponents.org: https://www.webcomponents.org/publish
Not really a fair analogy as anyone can submit elements to webcomponents.org: https://www.webcomponents.org/publish
Sure, but they could also add x-tag to their resource list.
It is in the resource list.
https://www.webcomponents.org/resources
https://www.webcomponents.org/resources
Not a word on Polyfills
https://www.webcomponents.org/polyfills
While this is true, it's also true that x-tags and whatever else that's not Polymer is entirely irrelevant in the context of WebComponents.
There's only Polymer.
It's gotten so bad that even the main proponents of WebComponents (working for Google, of course) cannot build proper WebComponents (and no one can): https://www.youtube.com/watch?v=sK1ODp0nDbM
There's only Polymer.
It's gotten so bad that even the main proponents of WebComponents (working for Google, of course) cannot build proper WebComponents (and no one can): https://www.youtube.com/watch?v=sK1ODp0nDbM
> main proponents of WebComponents cannot build proper WebComponents (and no one can):
I've a vested interest as I run the team that Rob is on, I feel like there is a lot being misconstrued here in this thread, x-tags is be on the list of supported resources on webcomponents.org. If there are only two elements on the list it's not because it's "polymer only" and run by the Chrome team. I've launched a couple of elements using plain JS and there are others on there too, it's just that many of the elements created use Polymer, and that is probably a good indicator of how popular the tooling is in the component ecosystem.
Rob didn't say no one can build proper web components, he was saying that to build great web components there is a lot of work that you have to do especially to make them accessible and good actors in the life-cycle of a page and that many of the spec authors hadn't seen them being built as a canonical reference set. Of course people can build proper web components, but it is on us to explain it clearly now that the browser support is mostly there.
I've a vested interest as I run the team that Rob is on, I feel like there is a lot being misconstrued here in this thread, x-tags is be on the list of supported resources on webcomponents.org. If there are only two elements on the list it's not because it's "polymer only" and run by the Chrome team. I've launched a couple of elements using plain JS and there are others on there too, it's just that many of the elements created use Polymer, and that is probably a good indicator of how popular the tooling is in the component ecosystem.
Rob didn't say no one can build proper web components, he was saying that to build great web components there is a lot of work that you have to do especially to make them accessible and good actors in the life-cycle of a page and that many of the spec authors hadn't seen them being built as a canonical reference set. Of course people can build proper web components, but it is on us to explain it clearly now that the browser support is mostly there.
> it's just that many of the elements created use Polymer, and that is probably a good indicator of how popular the tooling is in the component ecosystem.
That's exactly what I'm saying. There are no WebComponents. There is no x-tags or whatever. There is only Polymer. For many reasons. Chief among them: WebComponents suck. Polymer at least gives nice-ish APIs on top of that.
Rob did say something like "Polymer is the jQuery of WebComponents". And it's true.
One could argue that you can write your stuff in pure DOM APIs. Yet hardly enyone ever did that, because there was jQuery. All the handlebars and mustaches and other things of this world were largely irrelevant because of jQuery.
Now, jQuery solved a very pressing problem: it gave an easy, simple, extensible API that made working with the DOM a joy. It would be very nice if jQuery's approach was adopted by w3c, but that is really too much to ask for.
In 11 years since jQuery's original release w3c managed — barely! — to standardize on querySelector/querySelectorAll (already a much more cumbersome combination of APIs than jQuery's $).
Enter WebComponents. 6 years in development. Quite a few years of saying that they are the future. Let's do a reality check, shall we?
The APIs are horrible. None of the original promises are fulfilled. As Polymer 3 approaches someone suddenly starts asking "erm, guys, what are the best ways of creating WebComponents without Polymer".
- It turns out even people who implement the spec in the browser don't have reference components.
- It turns out the API is so bad, you have to use pseudocode in your presentation to sell people the idea[1].
- It turns out WebComponents are so effing great and can really be used to reimplement stuff in the browser, ... that you can't even implement a checkbox without reimplementing the checkbox label [2]
- It turns out people don't even know how WCs should work. Quote from [1]: "If we can generally agree on how Custom Elements should behave..."
- It turns out that actually implementing WCs in anything but Polymer is a royal pain in basically everywhere because w3c's goal was never to create a sane API for anything.
etc. etc. etc.
Therefore, forget selling people the idea of WebComponents. For all intents and purposes they do not exist. Only Polymer exists. Masochists can go and check out the underlying DOM APIs, of course.
[1] https://www.youtube.com/watch?v=sK1ODp0nDbM
[2] https://github.com/GoogleChrome/howto-components/issues/112
That's exactly what I'm saying. There are no WebComponents. There is no x-tags or whatever. There is only Polymer. For many reasons. Chief among them: WebComponents suck. Polymer at least gives nice-ish APIs on top of that.
Rob did say something like "Polymer is the jQuery of WebComponents". And it's true.
One could argue that you can write your stuff in pure DOM APIs. Yet hardly enyone ever did that, because there was jQuery. All the handlebars and mustaches and other things of this world were largely irrelevant because of jQuery.
Now, jQuery solved a very pressing problem: it gave an easy, simple, extensible API that made working with the DOM a joy. It would be very nice if jQuery's approach was adopted by w3c, but that is really too much to ask for.
In 11 years since jQuery's original release w3c managed — barely! — to standardize on querySelector/querySelectorAll (already a much more cumbersome combination of APIs than jQuery's $).
Enter WebComponents. 6 years in development. Quite a few years of saying that they are the future. Let's do a reality check, shall we?
The APIs are horrible. None of the original promises are fulfilled. As Polymer 3 approaches someone suddenly starts asking "erm, guys, what are the best ways of creating WebComponents without Polymer".
- It turns out even people who implement the spec in the browser don't have reference components.
- It turns out the API is so bad, you have to use pseudocode in your presentation to sell people the idea[1].
- It turns out WebComponents are so effing great and can really be used to reimplement stuff in the browser, ... that you can't even implement a checkbox without reimplementing the checkbox label [2]
- It turns out people don't even know how WCs should work. Quote from [1]: "If we can generally agree on how Custom Elements should behave..."
- It turns out that actually implementing WCs in anything but Polymer is a royal pain in basically everywhere because w3c's goal was never to create a sane API for anything.
etc. etc. etc.
Therefore, forget selling people the idea of WebComponents. For all intents and purposes they do not exist. Only Polymer exists. Masochists can go and check out the underlying DOM APIs, of course.
[1] https://www.youtube.com/watch?v=sK1ODp0nDbM
[2] https://github.com/GoogleChrome/howto-components/issues/112
I think web components are low level and non-opinionated to give you freedom of implementation for higher level things.
Thats what Polymer, Stencil, Svelte, SkateJS are for. Indeed WC API is not the nicest to work with to say the least, but thats not the problem, I write in python instead of Assembly, just user higher level stuff.
> Indeed WC API is not the nicest to work with to say the least, but thats not the problem
How is it not a problem?
> I write in python instead of Assembly, just user higher level stuff.
As with any analogies, it's a wrong one. You compare a low-level PL with a high level PL. WebComponents is not a programming language. It's a set of APIs for the most popular platform in the world
I wonder how far along iOS would get if all it provided for its UI libraries was just the UIView, and never anything else (no collection views, no table views, no content views etc.) That's exactly what w3c does, times and again.
How is it not a problem?
> I write in python instead of Assembly, just user higher level stuff.
As with any analogies, it's a wrong one. You compare a low-level PL with a high level PL. WebComponents is not a programming language. It's a set of APIs for the most popular platform in the world
I wonder how far along iOS would get if all it provided for its UI libraries was just the UIView, and never anything else (no collection views, no table views, no content views etc.) That's exactly what w3c does, times and again.
It is low level API to be non-opinionated. Or at least it makes sense for me to make it like that. Same as web assembly, service worksers and others - that is a step in right direction IMO.
Same as for example Python providing WSGI - you don't often use WSGI directly, you use a framework on top of it like Pyramid, Django or Flask.
Same as for example Python providing WSGI - you don't often use WSGI directly, you use a framework on top of it like Pyramid, Django or Flask.
>I think web components are low level and non-opinionated to give you freedom of implementation for higher level things.
Yeah, that worked so nice with X-Windows...
Yeah, that worked so nice with X-Windows...
Angular and React also have plans to eventually move into Web Components.
This isn't true https://facebook.github.io/react/docs/web-components.html
It's partly true, see https://custom-elements-everywhere.com and linked issues.
The main problem: when the framework makes the developer decide whether to pass attributes or properties to Custom Elements, it's mostly ok. The framework should also allow binding any events (which cna be named as onEvent, or on-event or...)
Frameworks that are trying to be clever and hide the complexities of DOM behind proper APIs, and that implement their own event systems suffer greatly because DOM APIs and WebComponent APIs are a pile of steaming crap.
The main problem: when the framework makes the developer decide whether to pass attributes or properties to Custom Elements, it's mostly ok. The framework should also allow binding any events (which cna be named as onEvent, or on-event or...)
Frameworks that are trying to be clever and hide the complexities of DOM behind proper APIs, and that implement their own event systems suffer greatly because DOM APIs and WebComponent APIs are a pile of steaming crap.
The site you linked to is about frameworks 'playing well with' custom elements. It says nothing to the assertion about React moving to web components.
Also it is not helpful to call standards 'a pile of steaming crap' without backing that up with something substantive, examples/alternatives etc.
Also it is not helpful to call standards 'a pile of steaming crap' without backing that up with something substantive, examples/alternatives etc.
Vue.js probably has a better chance for building true distributable componetns.
https://vuejs.org/v2/guide/components.html
https://vuejs.org/v2/guide/components.html
Aren't Angular directives more or less Web Components?
I wish people would stop saying "feature X is already here" when it is missing Edge and Firefox support. What projects are people working on where they can happily overlook the fact that something simply won't work in 2 out of 4 major browsers in use today?
I really tried with Polymer (for the last few months) but it was particularly verbose.
I remember implementing an "<iron-ajax>" tag, and thinking that this is so wild and "Out There" that I may simply never understand.
Annoyingly, there is a whole "Hybrid" mode as well. So there is no distinction between V1 and V2. If you are confused,you go to the docs, they aren't giving you what you need, so you go to one of the sample elements, and it is written in V1. So you have to read the migration guide to translate what is actually happening....
Then Polymer Summit happens, and now it is all JS based which, is far better for me but now it seems pointless to stay on Polymer 2.0, and Polymer 3 is a preview with no docs...
So I aborted this path, went to Angular and to be honest, it is beautiful. It is almost trivial compared to the bag of questions and confusion I had going on with Polymer.
I do look forward to going back there though when 3.0 is available.
I remember implementing an "<iron-ajax>" tag, and thinking that this is so wild and "Out There" that I may simply never understand.
Annoyingly, there is a whole "Hybrid" mode as well. So there is no distinction between V1 and V2. If you are confused,you go to the docs, they aren't giving you what you need, so you go to one of the sample elements, and it is written in V1. So you have to read the migration guide to translate what is actually happening....
Then Polymer Summit happens, and now it is all JS based which, is far better for me but now it seems pointless to stay on Polymer 2.0, and Polymer 3 is a preview with no docs...
So I aborted this path, went to Angular and to be honest, it is beautiful. It is almost trivial compared to the bag of questions and confusion I had going on with Polymer.
I do look forward to going back there though when 3.0 is available.
Angular is a front-end framework for general purpose. Polymer is the library specifically to facilitate Web Component development only. So I think you are comparing apple and orange here.
Both are basic front end frameworks. Polymer just happens to use a minor spec to encapsulate and expose, the smallest part of what it actually does.
Polymer of all the frameworks i've had to use has had the most breaking changes. That they're turning the ship for each and every major forcing you to rewrite the entire application is kind of ironic given that their motto is "use the platform" as if suggesting stability and standard behavior.
Polymer is not the standard, just another arbitrary driver (as in: their own syntax, their own structures, their own api) for a pretty harmless spec that sets out to solve issues we haven't faced for at least 5 years.
Polymer of all the frameworks i've had to use has had the most breaking changes. That they're turning the ship for each and every major forcing you to rewrite the entire application is kind of ironic given that their motto is "use the platform" as if suggesting stability and standard behavior.
Polymer is not the standard, just another arbitrary driver (as in: their own syntax, their own structures, their own api) for a pretty harmless spec that sets out to solve issues we haven't faced for at least 5 years.
Big corps like Google tend to over-engineer stuff. It's the very reason why Vue.js is so kicking ass due to its low learning curse and progressive approach. Why can't we do the same for WC standards?
I think the problem is more or less that we're at a breaking point where it's getting quite obvious that we should move away from higher-up standards. The browser should worry about low-level interfaces only, high level abstractions should never be cast in any standard and that is exactly what the extensible web manifesto said.
WC break this in half again and all of the sudden they're again trying to shovel more UI stuff into the dom. What they're trying to fix hasn't been a problem for years. Their entire spec was thought out in a meeting room maybe 10 years ago, but almost nothing of it has relevance today. It would simply make it harder again and block applications from leaving the browser behind.
WC break this in half again and all of the sudden they're again trying to shovel more UI stuff into the dom. What they're trying to fix hasn't been a problem for years. Their entire spec was thought out in a meeting room maybe 10 years ago, but almost nothing of it has relevance today. It would simply make it harder again and block applications from leaving the browser behind.
It's not like Vue has been implemented in Angular. All the ass-kicking frameworks are built on W3C standards.
For my sins, I look after a Polymer 0.8 based site left to me by a Chrome enthusiast. It is starting to break in mysterious ways. Not looking forward to the upgrade path...
"Third party widgets" was the use case. The idea was to build a marketplace for frontend components, much like existed for Visual Basic, eg. the average web developer would buy/download BobsTreeView.htc and bind an XML file and that would be it.
The actual issue was that very few people was doing any serious frontend development back then. Netscape and IE had completely different DOMs and the environments were not super stable. But there was an attitude that frontend was for designers and "real programmers" were backend-only.
So the real programmer found a backend component for ASP.NET or GWT and wasn't interested in the frontend sausage.
(This article reminded me of the DHTML Dude column[1], and yeah some of us unreal programmers were doing this bleeding edge IE-specific front-end stuff for clients. Then we spent many years atoning for our sins. However, I think 90% of "IE-only" apps never used this stuff, they just had the wrong box model or some dopey ActiveX upload component or something.)
[1] https://msdn.microsoft.com/en-us/library/bb263969(v=vs.85).a...
The actual issue was that very few people was doing any serious frontend development back then. Netscape and IE had completely different DOMs and the environments were not super stable. But there was an attitude that frontend was for designers and "real programmers" were backend-only.
So the real programmer found a backend component for ASP.NET or GWT and wasn't interested in the frontend sausage.
(This article reminded me of the DHTML Dude column[1], and yeah some of us unreal programmers were doing this bleeding edge IE-specific front-end stuff for clients. Then we spent many years atoning for our sins. However, I think 90% of "IE-only" apps never used this stuff, they just had the wrong box model or some dopey ActiveX upload component or something.)
[1] https://msdn.microsoft.com/en-us/library/bb263969(v=vs.85).a...
That frontend vs backend attitude exists to this day, although somewhat less so. To be fair, apps were basically just forms in the early days of the web with very little dynamic activity.
It's really interesting to see these comments when I feel the struggle of not having this on a daily basis.
I guess it's ultimately about how web development is actually two things: web pages (posters) and web apps ("software")
Maybe when you're working on some one-off pages you don't feel much need for encapsulation, and in the end it's more trouble than it's worth.
Let's say you are working on a social network though. You'll need to display a "person widget" a bunch, in different contexts. Of course you want to have it be consistent throughout your app. Of course you want it to look the same. Of course you want encapsulation!
When you're writing a web app, your HTML isn't just layout but the entire interface. You're usually working with a huge team and need consistency. You want to be DRY.
If you have a style guide, you probably could benefit some from this. The proof is that things like JQuery UI exist, even if it's activated more through JS.
HTML is basically unreadable in so many cases because you can't encapsulate layout code into widgets. Having these tools lets you stay a bit sane when you need to build out a lot of workflows in a consistent manner.
I guess it's ultimately about how web development is actually two things: web pages (posters) and web apps ("software")
Maybe when you're working on some one-off pages you don't feel much need for encapsulation, and in the end it's more trouble than it's worth.
Let's say you are working on a social network though. You'll need to display a "person widget" a bunch, in different contexts. Of course you want to have it be consistent throughout your app. Of course you want it to look the same. Of course you want encapsulation!
When you're writing a web app, your HTML isn't just layout but the entire interface. You're usually working with a huge team and need consistency. You want to be DRY.
If you have a style guide, you probably could benefit some from this. The proof is that things like JQuery UI exist, even if it's activated more through JS.
HTML is basically unreadable in so many cases because you can't encapsulate layout code into widgets. Having these tools lets you stay a bit sane when you need to build out a lot of workflows in a consistent manner.
> I guess it's ultimately about how web development is actually two things: web pages (posters) and web apps ("software")
This is what Progress Web Application tries[0](PWA https://en.wikipedia.org/wiki/Progressive_web_app), a fairly new spec, attempts to bridge the gap. Basically a normally web page will virtually be indistinguishable from a web app.
This is what Progress Web Application tries[0](PWA https://en.wikipedia.org/wiki/Progressive_web_app), a fairly new spec, attempts to bridge the gap. Basically a normally web page will virtually be indistinguishable from a web app.
I think the API actually does matter a lot.
I think jQuery's massive success was precisely because it was a simple and concise API on top of the verbose and confusing DOM API.
I think jQuery's massive success was precisely because it was a simple and concise API on top of the verbose and confusing DOM API.
I was a little bit disappointed to see that the plan for Polymer 3.0 is to leverage ES modules to handle all the asset loading. Maybe their hand has been forced here since browser vendors refused to implement http imports but if Polymer requires a fair bit of Javascript to do anything interesting then its advantage over something like React becomes a bit less clear-cut, IMO.
Yeah, its definitely been forced, you can see it in the team's faces (https://www.youtube.com/watch?v=0N-ldg1IPn4&t=1766s). Its possible that the HTML Modules spec will hit browsers in the next year or so (the fact that the ES Modules spec does nothing when the resource mimetype isn't JS means it'll be very easy to extend), in which case Polymer 3.0 will have just been a crash course in tagged template literals.
> Most people don't actually derive much benefit from writing custom UI widget primitives.
Bingo. Most won't and shouldn't. There's a different between building casual widgets for personal vs for business production use. jQuery UI got some widely popular components such as Select2 and jqGrid, Datatables etc. They will never be developed by non-developers or business users. The tool should be really reserved for code crafters.
Imagining those crafters started creating tools with WP that are modular and self-cotained, work across whatever browsers threw at them.
Bingo. Most won't and shouldn't. There's a different between building casual widgets for personal vs for business production use. jQuery UI got some widely popular components such as Select2 and jqGrid, Datatables etc. They will never be developed by non-developers or business users. The tool should be really reserved for code crafters.
Imagining those crafters started creating tools with WP that are modular and self-cotained, work across whatever browsers threw at them.
The main problems I have with Polymer:
* It's cumbersome to install. apt-get install npm && npm install bower && bower install ... this is about when I give up. Why not just include a 'polymer.js' file that just does all the work, no installs needed, no questions asked, CDN provided, batteries included, like every other client-side JavaScript library on the planet? Even the appropriate CSS can be loaded by the JavaScript itself, but it isn't.
* Bloated. You end up downloading several hundred kilobytes of JavaScript if your webapp uses more than a few different types of UI elements.
* Polymer components don't behave like native components. For example, you cannot swipe between tabs like a ViewPager does on Android. Implementing any kind of swipe-based feedback is hard, including pull-to-refresh. Back to native programming, I guess.
* For having so much marketing and PR and a camel-cased name "WebComponents", you would think it would be productized enough that it employ the appropriate native Android elements at least in Google Chrome on Android, and use the HTML5 substitutes on iOS and desktop. For example, you should replace the Polymer button with an actual styled Android button instead of a nested div hell. Chrome should have worked with the Polymer team on this. Not doing this has serious performance implications when you display thousands of items (e.g. lists of results, contact lists) each with their own nested div hell. Back to native programming, I guess.
* There is no framework to make apps look iOSish on iOS and Androidish on Android. Back to native programming, I guess.
* It's cumbersome to install. apt-get install npm && npm install bower && bower install ... this is about when I give up. Why not just include a 'polymer.js' file that just does all the work, no installs needed, no questions asked, CDN provided, batteries included, like every other client-side JavaScript library on the planet? Even the appropriate CSS can be loaded by the JavaScript itself, but it isn't.
* Bloated. You end up downloading several hundred kilobytes of JavaScript if your webapp uses more than a few different types of UI elements.
* Polymer components don't behave like native components. For example, you cannot swipe between tabs like a ViewPager does on Android. Implementing any kind of swipe-based feedback is hard, including pull-to-refresh. Back to native programming, I guess.
* For having so much marketing and PR and a camel-cased name "WebComponents", you would think it would be productized enough that it employ the appropriate native Android elements at least in Google Chrome on Android, and use the HTML5 substitutes on iOS and desktop. For example, you should replace the Polymer button with an actual styled Android button instead of a nested div hell. Chrome should have worked with the Polymer team on this. Not doing this has serious performance implications when you display thousands of items (e.g. lists of results, contact lists) each with their own nested div hell. Back to native programming, I guess.
* There is no framework to make apps look iOSish on iOS and Androidish on Android. Back to native programming, I guess.
Looks like they're working on moving away from bower: https://github.com/Polymer/polymer/issues/326#issuecomment-3...
A quick CDN get-started would be convenient I agree. There is Polymer-CDN for demos/code-pens: https://github.com/download/polymer-cdn
The 'native' stuff in your comment I don't agree with. You want browsers to start implementing native Android ListViews/Buttons etc? Browsers have a hard enough time implementing web standards.
A quick CDN get-started would be convenient I agree. There is Polymer-CDN for demos/code-pens: https://github.com/download/polymer-cdn
The 'native' stuff in your comment I don't agree with. You want browsers to start implementing native Android ListViews/Buttons etc? Browsers have a hard enough time implementing web standards.
There is no framework to make apps look iOSish on iOS and Androidish on Android. Back to native programming, I guess.
Google's Flutter certainly creates apps (using mostly web technologies) that have the correct look and feel for Android and iOS from the same codebase.
Keynote: Flutter (Dart Developer Summit 2016)»https://www.youtube.com/watch?v=Mx-AllVZ1VY
Google's Flutter certainly creates apps (using mostly web technologies) that have the correct look and feel for Android and iOS from the same codebase.
Keynote: Flutter (Dart Developer Summit 2016)»https://www.youtube.com/watch?v=Mx-AllVZ1VY
Flutter has nothing to do with web, it is native all the way down.
Some react native frameworks do just that. https://nativebase.io/
> It's cumbersome to install. apt-get install npm && npm install bower && bower install ... this is about when I give up
Half the things I've ever installed were far more complicated than that.
Half the things I've ever installed were far more complicated than that.
Honestly I never understand why they need to be so complicated. If you want people to use your product, why not make it easy to use it? This goes for developers too -- who should be spending their time coding their product, not dealing with how to install stuff.
If you wanted to, with WebComponents you could easily use an x-PageFoo tag as a parent tag that orchestrates other child components. Your WebComponent is just a bunch of HTML, Javascript and CSS, it can really do what ever you want it to. It isn't a framework though, so to suggest that it doesn't provide as much as React is being a bit disingenuous, as it's not trying to. It's trying to formalise some of the foundations for things like react.
Smaller scale but for fun, in vanilla WebComponents (as implemented in Chrome) I put together a Slider that can then accept and consume child elements that add behaviour, like this:
Smaller scale but for fun, in vanilla WebComponents (as implemented in Chrome) I put together a Slider that can then accept and consume child elements that add behaviour, like this:
<x-slider data-config="{autoplay:true}">
<img src="some.jpg" />
<img src="some.jpg" />
<x-slider-controls /> //Introduces left and right slider controls
<x-slider-dots /> //Introduces slider dots
</x-slider>Sure, certain concepts have been around and keep getting reimplemented but it's far too easy to confuse the old with the new.
One of the very real issues WebComponents solve is encapsulating the component functionality and styling away from everything else in a typical web page; you know, the basic separation of concerns stuff.
Certainly nothing that Microsoft proposed then has today's comparability and flexibility of today's offerings.
Microsoft didn't lack good ideas back then when they cared about the web; they were clueless about interoperability across devices and platforms. (IE for the Mac had a better but different rendering engine than IE for Windows did.) And because of their monopoly status then, they weren't to be trusted.
I also want to correct something the article mentioned, that Netscape was irrelevant back then due to Microsoft's cool features--not true. In fact, on any big project, developers had to essentially make two sites--one for Netscape users and one for IE users.
The "new" Microsoft it much better with getting their ideas out and working with other companies.
One of the very real issues WebComponents solve is encapsulating the component functionality and styling away from everything else in a typical web page; you know, the basic separation of concerns stuff.
Certainly nothing that Microsoft proposed then has today's comparability and flexibility of today's offerings.
Microsoft didn't lack good ideas back then when they cared about the web; they were clueless about interoperability across devices and platforms. (IE for the Mac had a better but different rendering engine than IE for Windows did.) And because of their monopoly status then, they weren't to be trusted.
I also want to correct something the article mentioned, that Netscape was irrelevant back then due to Microsoft's cool features--not true. In fact, on any big project, developers had to essentially make two sites--one for Netscape users and one for IE users.
The "new" Microsoft it much better with getting their ideas out and working with other companies.
Why shouldn't your entire application be a widget? Sometimes it's nice to embed one application into another, multiple times. I find your reasoning here short-sighted, since there's often no clear point at which components should bottom out. You can always add another layer.
I think you've misunderstood my point; I don't think that at all.
I'm specifically criticising the focus polymer has on creating user interaction elements.
My point is that this sort of low level functionality isn't the right place to focus; most low level components you need already exist. What people is a way to build robust application UIs (and yeah, that includes having a root level <App/> component).
For comparison, read:
https://www.polymer-project.org/2.0/start/
'build custom ui widgets' <-- wrong, this isn't a problem most people have.
vs.
https://vuejs.org/v2/guide/#Composing-with-Components
'build your application from components' <-- right.
I'm specifically criticising the focus polymer has on creating user interaction elements.
My point is that this sort of low level functionality isn't the right place to focus; most low level components you need already exist. What people is a way to build robust application UIs (and yeah, that includes having a root level <App/> component).
For comparison, read:
https://www.polymer-project.org/2.0/start/
'build custom ui widgets' <-- wrong, this isn't a problem most people have.
vs.
https://vuejs.org/v2/guide/#Composing-with-Components
'build your application from components' <-- right.
Actually - the process of creating both is exactly the same, I created components in angular, react and polymer. No difference IMO (apart implementation details).
That "sometimes" quickly breaks down when your application starts to grow beyond trivial. Some things that are rather application-specific like routing and dependency management don't quite compose well in the widget model. Or at least, Polymer at the moment doesn't have proper solutions to quite some edge cases that you'll be running into.
I actually implemented React's UI Router in polymer, works the same as in Angular 1/2. The biggest issue with web components in general are problems with Shadow DOM support.
Which means you need to do elements without shadow components up to top level - that is indeed annoying and reduces the pros of components.
> <select> is good enough for me, [...]
If it just was fully styleable. Browsers really should implement better selection of customizable standard widgets. Currently it requires too many hacks to re-style the built-in input elements. Web components feel a bit overkill for most cases.
If it just was fully styleable. Browsers really should implement better selection of customizable standard widgets. Currently it requires too many hacks to re-style the built-in input elements. Web components feel a bit overkill for most cases.
Or maybe designers should learn to respect the platform's widgets' look and feel, which the user is familiar with and has possibly customized according to their preferences and accessibility needs.
Unfortunately the industry just doesn't work that way.
Accessibility is one reason why css-themeable native widgets would be a win for everyone, their look will match with the branding (customer happy) and behaviour will be consistent (end user happy), and standardization would make developers happy.
Accessibility is one reason why css-themeable native widgets would be a win for everyone, their look will match with the branding (customer happy) and behaviour will be consistent (end user happy), and standardization would make developers happy.
Hah! You're kidding, right? Custom styling or "skins" has been one of the main drivers of app development since the beginnings of time. I feel that we, puritans, should just give up and accept what the masses want.
Didn’t IE use to let you style random components such as even the scroll bar?
Most if not all major browsers let you style scrollbars, but the problem is that styling for built-in widgets is not standardized, i.e. it relies on vendor prefixes and worse, not all (sub) elements can be styled at all depending on browser. E.g. <select> has poor support for styling.
Yep - I remember on vBulletin forums, the native vertical scrollbar often got the same vibrant colouring as the forum's theme.
From index page "Polymer is a JavaScript library that helps you create custom reusable HTML elements".
I'm using Polymer components same as as react's controller/view components. You don't need to reimplement custom select's or whatever. You can use exact patters as other frameworks use.
Nice; I used these "back in the day" while at Google to implement the illusion of native SVG support in Internet Explorer 6-8; I used hidden Flash for the rendering and Microsoft Behaviors wrapping it all so that the fake SVG would look like it was part of the DOM for full JS scripting. Fun times. Check it out here: https://github.com/BradNeuberg/svgweb
"Why did IE5’s HTML Components never quite catch on? Despite what you might think, it’s not because of a lack of open standards"
Actually thats precisely why it never caught on. Source: I was front end developer at one of the big dotcoms ca 2000.
Also, its remarkable how many people skimmed this article, and didn't understand that the first part was from 1999. That really says a lot about people's expectations when it comes to Microsoft and web technology.
Actually thats precisely why it never caught on. Source: I was front end developer at one of the big dotcoms ca 2000.
Also, its remarkable how many people skimmed this article, and didn't understand that the first part was from 1999. That really says a lot about people's expectations when it comes to Microsoft and web technology.
I am not sure it is not a coincidence that the same idea keeps resurfacing. I remember reading pretty early on that HTML/XML/XHTML would eventually lead to a world where "chemists would have their own tags to represent chemical formulas" and similarly each discipline would develop their own tag language. Browsers would just know how to render them!
People have tried to materialize this idea in multiple ways over time - HTC, microformats, web components etc. It should not be surprising that the solutions are similar. This isn't to say the first implementation was the best, and the others have just forgotten history. I am sure there are some pretty senior web developers around who remember their history, and were even part of it. If anything we should be optimistic that the new implementations have learned from the mistakes of the past.
People have tried to materialize this idea in multiple ways over time - HTC, microformats, web components etc. It should not be surprising that the solutions are similar. This isn't to say the first implementation was the best, and the others have just forgotten history. I am sure there are some pretty senior web developers around who remember their history, and were even part of it. If anything we should be optimistic that the new implementations have learned from the mistakes of the past.
> Browsers would just know how to render them!
They wouldn't "just know," there were supposed to be DTDs published that would tell the browser how to render that specific kind of markup.
They wouldn't "just know," there were supposed to be DTDs published that would tell the browser how to render that specific kind of markup.
I guess the rendering of custom XML documents was more supposed to be controlled by CSS via the processing instruction <?xml-stylesheet type="text/css" href="styles.css"?>. It's a little known fact that this was actually working in Mozilla/Firefox all this time, but not anymore I suspect.
I remember discovering these in the mid-2000s, and thinking along the same lines as the author: why hadn't they caught on and been standardised like XMLHttpRequest, etc. had been?
I think the reality is, Microsoft introduced these technologies at the tail-end of initial "dot com boom". Shortly afterward, most of the companies who might have built ambitious web apps using them went bust. Microsoft stopped investing in IE, and for quite a while afterwards, web development regressed to people building document and brochure-style sites. People were too busy trying to figure out complex CSS, and what `hasLayout` meant in IE to build component-based apps.
A few years later, web development crept out of the doldrums: JavaScript's reputation began to be rehabilitated, the term "AJAX" was coined, and companies like Google began building more ambitious web apps. But by now Firefox was the browser of choice for most developers, and had gained enough market share that you couldn't build IE-specific sites.
Mozilla teamed up with Opera and Apple, and later Google, to create what became HTML5, and that included reverse engineering and standardising a number of proprietary IE APIs. However, they chose to ignore element behaviours. Presumably because they had their own component technology, XBL, and wanted to make that the basis of web apps. And, since element behaviours never made it into Firefox, developers never started using them.
My guess is, had Firefox adopted them, they'd now be a standard part of the web platform, and we wouldn't have web components as they currently stand. There are a lot of similar "what ifs" in the history of the web. For example, what if Microsoft had adopted XBL? What if flexbox and grid had been implemented in early 2000s when they were originally designed, instead of fifteen years later? What if ES4 had been accepted and implemented? What if Cassowary had been built into CSS when it was proposed, instead of being ignored (and later used by Apple as the basis for auto layout)?
I think the reality is, Microsoft introduced these technologies at the tail-end of initial "dot com boom". Shortly afterward, most of the companies who might have built ambitious web apps using them went bust. Microsoft stopped investing in IE, and for quite a while afterwards, web development regressed to people building document and brochure-style sites. People were too busy trying to figure out complex CSS, and what `hasLayout` meant in IE to build component-based apps.
A few years later, web development crept out of the doldrums: JavaScript's reputation began to be rehabilitated, the term "AJAX" was coined, and companies like Google began building more ambitious web apps. But by now Firefox was the browser of choice for most developers, and had gained enough market share that you couldn't build IE-specific sites.
Mozilla teamed up with Opera and Apple, and later Google, to create what became HTML5, and that included reverse engineering and standardising a number of proprietary IE APIs. However, they chose to ignore element behaviours. Presumably because they had their own component technology, XBL, and wanted to make that the basis of web apps. And, since element behaviours never made it into Firefox, developers never started using them.
My guess is, had Firefox adopted them, they'd now be a standard part of the web platform, and we wouldn't have web components as they currently stand. There are a lot of similar "what ifs" in the history of the web. For example, what if Microsoft had adopted XBL? What if flexbox and grid had been implemented in early 2000s when they were originally designed, instead of fifteen years later? What if ES4 had been accepted and implemented? What if Cassowary had been built into CSS when it was proposed, instead of being ignored (and later used by Apple as the basis for auto layout)?
XBL 2.0 was doing well on the standard track and would have made that happen [1], but it died along with all the other technologies whose acronym starts with an X. Flexbox was by the way implemented in Mozilla back then, I used it all the time in XUL, but then that acronym also starts with an X [2].
[1] https://www.w3.org/TR/xbl
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL
[1] https://www.w3.org/TR/xbl
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL
As far I remember that time, I would say IE Components didn't succeeded, because at that time server side rendering was far more popular. I personally was doing sites in PHP and tried to avoid JS at all costs. Strange that today I'm doing exactly opposite.
And even stranger that with concerns about battery life; we should now be moving back towards server side rendering.
Unfortunately there's no real downside to eating people's battery. 99.9% of people just aren't going to know why, just that their battery dies faster.
Exactly this!
I think Web Components will have/already had the same fate.
To paraphrase the meme: "Stop trying to get Web Components/Polymer to happen. They aren't gonna happen".
At least not in this version of them. It's like XHTML that went about for years before it was taken out of its misery.
We needed something like Web Components for a long time -- but the current implementation is exactly how it should not have been done.
React/JSX got the good parts of it, and added even more useful things. If we could add the missing parts on top of that (like encapsulation from the external DOM), it would be perfect, and the rest of their horrible API/design can vanish.
To paraphrase the meme: "Stop trying to get Web Components/Polymer to happen. They aren't gonna happen".
At least not in this version of them. It's like XHTML that went about for years before it was taken out of its misery.
We needed something like Web Components for a long time -- but the current implementation is exactly how it should not have been done.
React/JSX got the good parts of it, and added even more useful things. If we could add the missing parts on top of that (like encapsulation from the external DOM), it would be perfect, and the rest of their horrible API/design can vanish.
It's happening, slowly: https://platform-status.mozilla.org/#shadow-dom
And "XHTML experience" is now built in to browsers, no developer effort needed (implementation consistency, the ACID tests, strict mode for JS, and WASM for speed)
And see also http://ishoudinireadyyet.com/
And "XHTML experience" is now built in to browsers, no developer effort needed (implementation consistency, the ACID tests, strict mode for JS, and WASM for speed)
And see also http://ishoudinireadyyet.com/
>It's happening, slowly
That's browser adoption. XHTML was also adopted by all browsers.
I'm talking about developer adoption.
That's browser adoption. XHTML was also adopted by all browsers.
I'm talking about developer adoption.
A great early site back in the DHTML/component days where IE4 was really pushing things was WebFX [1]. This was back when IE was actually a good browser as Netscape was fading due to DHTML/early AJAX (which was the XMLHttpRequest object originally from Exchange Server). DHTML at the time was mostly easier in IE because it didn't draw a new DOM for each layer i.e. document.layers (Netscape) each layer was a new full DOM and document.all (IE) was one DOM.
[1] http://webfx.eae.net/
[1] http://webfx.eae.net/
This goes into the bucket of scary, poorly thought out features that makes the web hard to secure. It's just like expression(), in that it allows code within a style take to result in script injection. CSS, due it's weird parsing behavior (data is not quoted, so it's hard to determine whether a token is data or code without a full CSS parse) is very hard to escape, and it's common to let user defined variables into CSS. Stuff like this is a nightmare for developers concerned about locking down their apps. And to the best of my knowledge, there's no way to disable it.
Fortunately, like expression, it's gone now in newer browsers, but this was not a proud moment for web security.
Fortunately, like expression, it's gone now in newer browsers, but this was not a proud moment for web security.
> "Why did IE5’s HTML Components never quite catch on?"
because technology per se is just one of the variables that matter. For example, you are missing things like "timing", "marketing strategy" and a whole lot of other things. =)
because technology per se is just one of the variables that matter. For example, you are missing things like "timing", "marketing strategy" and a whole lot of other things. =)
creating apps in html is like creating a spreadsheet in word.
why didn't we stick to xml and use a language to transform it into ui.
why didn't we stick to xml and use a language to transform it into ui.
I was a big fan of XHTML and all related XML Components, but then politics won.
To this day I'm absolutely flabbergasted that XHTML didn't win out. Well-formed XML documents, rather than a best-guess soup of broken HTML, was perfect. Absolutely perfect. I sat on the edge of my seat for 2-3 years waiting for the XHTML MIME type, with clients performing strict parsing, to become the new norm. It never happened. It's extremely sad if you think about it - we couldn't handle a world where developers had to conform to a very simple level of strictness. Imagine any backend language (C, Java, PHP, etc.) allowing you to get away with vomiting up garbage code with syntax errors, and having the compiler or interpreter best-guessing your program's logic. It's unfathomable! And yet, that is exactly what we have with HTML(5). Mind-boggling, to say the least.
Related aside: to this day, we still cannot write <script src="/main.js"/>. We must use <script src="/main.js"></script>. All because of a multi-decade old description of a CDATA element. Sigh.
Related aside: to this day, we still cannot write <script src="/main.js"/>. We must use <script src="/main.js"></script>. All because of a multi-decade old description of a CDATA element. Sigh.
The Web 2.0 movement, ditching XHTML and pushing HTML 5 instead was exactly when I went back to focusing in native applications, only doing Web when required to do so.
Web Components look to at least we can get some of those ideas back, instead of writing workarounds with HTML/CSS/JavaScript.
Web Components look to at least we can get some of those ideas back, instead of writing workarounds with HTML/CSS/JavaScript.
If you call web browser vendors mutinying against the W3C who was pushing XHTML 2 down their throats "politics", which lead to Apple, Mozilla and Opera creating the Web Hypertext Application Technology Working Group (WHATWG) and to HTML5--then I'm okay with the politics.
Yeah, I could close my tags and validate my code with the best of them back when XHTML was a thing--but that's no way to live. I'm glad WHATWG stepped in and literally saved the web from itself. OMG! XHTML 2 would have sucked so much!
Yeah, I could close my tags and validate my code with the best of them back when XHTML was a thing--but that's no way to live. I'm glad WHATWG stepped in and literally saved the web from itself. OMG! XHTML 2 would have sucked so much!
The way I remember it, there was a guy called Hixie something that was in charge of standards implementation at Mozilla and made a terrific job at that. But then he got hired by Opera and saw that there was no point in competing with Gecko and so he started a FUD campaign called "XHTML considered harmful" to lower market standards. He bluffed you into believing that namespaces are far too complicated for the human mind to comprehend, when in reality XHTML hadn't caught on because the CMS systems were not up to date. He did a terrific job at that, so he got hired by Google to publish a competing specification that was actually based on the way that Internet Explorer 6 parses HTML4. He did at terrific job at that, so we are finally back where we started, with a standard that lives forever while IE6 is long gone, and Goggle can scavenge the specifications from this forgotten future for ideas they can present as original. Even Mozilla played along with the HTML5 scheme, it was like watching a nuclear superpower go down in a fist fight. How can you not call that politics?
> XHTML 2 would have sucked so much!
why/how? because you'd have to close your tags and validate your code?
why/how? because you'd have to close your tags and validate your code?
I know this is not a popular position here, but I like writing HTML directly (say, without markdown) and appreciate the optional tags and escapes. I can see a big opportunity may have been lost technically...
Yeah but having to switch to createElement, appendChild, insertBefore, createTextNode just because innerHTML was not allowed was a pain in the butt.
at this point i'm considering creating a backend framework that sends a grid of images and uses imagemaps for clicks.
with fast internet raster images shouldn't be a big issue.
with fast internet raster images shouldn't be a big issue.
Just use SVG/CSS with JavaScript events, that is the approach for the new FitBit SDK.
Adobe ImageReady... now that is giving me some flashbacks. Pun sort of intended.
we could send 60fps image diffs now, we have the bandwidth.
and all the browser does is send the window size and cursor position.
and all the browser does is send the window size and cursor position.
We really don't.
I'm slightly confused by the combination of "introduced in Internet Explorer 5.5" and "offers a powerful new way" being written in an article posted on August 28, 2017
FTA: cough OK, obviously it’s 2017 and Internet Explorer 5.5 isn’t relevant anymore. But if you’re a Web developer, this should have given you some pause for thought. The modern Web Components pillars: Templates, Custom Elements, Shadow DOM, and Imports, were all features originally in IE5, released in 1999.
It was a truly great release.
haha, it really was too, no hint of sarcasm! Young'uns these days probably can't believe what a saviour Microsoft from the clusterfudge that Navigator represented back then.
.
Typed on Firefox :)
.
Typed on Firefox :)
Oh no, I agree. IE got its bad reputation due to neglect, not because it originally wasn’t good.
It just wasn’t good enough to last 10 years without updates
It just wasn’t good enough to last 10 years without updates
Is that really true? IE 5.5 had shadow Dom?
Yes, it's described by the article.
To a great degree, "modern web standards" are an exercise in reinventing proprietary Microsoft stuff from the 1990s.
(Or replacing some thing that Java or Flash had done for years.)
(Or replacing some thing that Java or Flash had done for years.)
Polymer will ditch 'html-import'(which is similar to the HTML component) as it is not widely implemented on browsers and such.
Polymer 3 will switch to ES6-loader and npm, probably one year away?
I spent quite some hours with Polymer, but finally give up for now, one reason is that I want Polymer 3 today, but it is not there yet, also big companies tends to make its stack for big players(look at Angular2).
I will use Vue.js for new projects at the moment, I read somewhere saying, Vue.js could be the next modern jQuery, and I kind of agree.
Polymer 3 will switch to ES6-loader and npm, probably one year away?
I spent quite some hours with Polymer, but finally give up for now, one reason is that I want Polymer 3 today, but it is not there yet, also big companies tends to make its stack for big players(look at Angular2).
I will use Vue.js for new projects at the moment, I read somewhere saying, Vue.js could be the next modern jQuery, and I kind of agree.
I think the main problem with IE technology was the way Microsoft pushed it down our throats. The tech wasn't necessarily bad, but when the giant corporation pushes new features while not respecting/implementing the existing standards very few people support their efforts.
So as a result 96% hated the IE and the other 4% were using other browsers. No wonder nobody wanted to use the newest Microsoft only features.
So as a result 96% hated the IE and the other 4% were using other browsers. No wonder nobody wanted to use the newest Microsoft only features.
I was young in 1999 so not very experienced with technology but I really doubt people were hating on Microsoft back then. Sure, every company will have a hate camp but I doubt it was as spread as it was in the past few years.
Actually, it was much worse back then. Nowadays Apple Macs are affordable and alternative PC operating systems are quite usable too. In 1999 there was a usable but limited/old Win 95 and Win 98 which was crashing on a daily basis. So you can imagine how frustarating it was to work with such a machine.
Furthermore, microsoft was fighting open source software which didn't make them more popular: https://en.wikipedia.org/wiki/Halloween_documents
Compared to those times the data collection on modern Win 10 systems and forced updates are small sins ;-)
Furthermore, microsoft was fighting open source software which didn't make them more popular: https://en.wikipedia.org/wiki/Halloween_documents
Compared to those times the data collection on modern Win 10 systems and forced updates are small sins ;-)
I used HTC a lot and waited for the other browsers to implement it. XBL came around but waited many years until it became web components. Great post!
All this talk of HTCs reminds me of HTAs: HTML Applications.
https://msdn.microsoft.com/en-us/library/bb250409(v=vs.85).a...
They behaved like a native app, with control over their native chrome, and without any browser sandboxing: their JavaScript (JScript) or VBScript could use COM components to access to the file-system and other features, including loading other binaries in-process. File-system access was through Scripting.FileSystemObject, for example.
Some built-in Windows components were/are built as HTAs, like the previous versions of the Microsoft AntiMalware / Windows Defender UI.
I tried to use it for a project in 2013 but couldn't because HTAs are forced to run in Quirks-mode, so you can't use IE11's Edge mode, unfortunately.
Best of all: they ran while needing only a few megabytes of RAM. Compare with Electron-based apps and it makes me weep because this, right here, is evidence that a Web-View can be used as the basis for an application, using a platform that was available since 1998/1999, without it dragging my PC down.
https://msdn.microsoft.com/en-us/library/bb250409(v=vs.85).a...
They behaved like a native app, with control over their native chrome, and without any browser sandboxing: their JavaScript (JScript) or VBScript could use COM components to access to the file-system and other features, including loading other binaries in-process. File-system access was through Scripting.FileSystemObject, for example.
Some built-in Windows components were/are built as HTAs, like the previous versions of the Microsoft AntiMalware / Windows Defender UI.
I tried to use it for a project in 2013 but couldn't because HTAs are forced to run in Quirks-mode, so you can't use IE11's Edge mode, unfortunately.
Best of all: they ran while needing only a few megabytes of RAM. Compare with Electron-based apps and it makes me weep because this, right here, is evidence that a Web-View can be used as the basis for an application, using a platform that was available since 1998/1999, without it dragging my PC down.
You can still do this, and in OSX too using MacGap (or writing a tiny webview wrapper yourself). The main reasons this is not widely done are incomplete device APIs, no control over browser versions/features - app might break at any moment for different subsets of users, and the lack of cross-platform compatibility. Electron actually solves most of those pain points despite the heft.
Does the Cocoa WebView expose any kind of non-sandboxed COM-like API for system access? That was what made HTAs so useful.
I still use them - IE9 being the highest available engine is just as bad as you remember, but being able to quickly whip up a few-hundred KB app HR can all use off a network drive to automate tedious tasks like recurring data-driven document generation, with a decent React UI, is worth some of the pain.
This! I love simplicity of electron but it is absurdly resource hungry.
I don't agree that Electron is simple. Electron runs a Node.js instance as a websever and application server in-proc, while also running Blink/WebKit for each frame instance. There's no consolidation going on, and I feel for a majority of Electron applications there's no need for the Node instance because all they're serving is an Angular app using the built-in `chrome.` APIs. What would be simple is if a script tag in a single HTML file could access the filesystem or Windows registry - but under Electron they can't.
[deleted]
These were widely used for at least one thing in practice: adding support for :hover pseudoclass on arbitrary elements (not just <a>) in IE6. https://peterned.home.xs4all.nl/csshover.html
Chronological snobbery? https://en.m.wikipedia.org/wiki/Chronological_snobbery
Wow, reading this is like a blast from 2004. DHTML? JScript, the propriety IE javascript dialect?
All without the marketshare of the time, thankfully.
All without the marketshare of the time, thankfully.
[deleted]
Most people don't actually derive much benefit from writing custom UI widget primitives.
Certainly, that's a useful thing for a UI toolkit builder to be able to do, but tangibly, for most people, it's not actually useful.
I don't have time to invest hours implementing `ImageDropDownSpinner` as a custom element. <select> is good enough for me, and heck, maybe I'll use some 3rd party widget if I need something special.
That's not why react, vue, angular, etc. are winning the mind share of 'how to build web apps'; building UI widget is far less interesting than the ability to decompose your UI into a custom hierarchy of re-usable self contained units of functionality, that only at the lowest level actually involve UI components, is extremely powerful.
They might look like custom widgets, but <PageFoo> isn't a UI widget, it's your entire application; that's the difference.
It's easy to say this was a revolutionary idea, before its time, and it would have flown today instead of vanished into obscurity... but I think it missed the mark; it didn't solve problems people were actually having.
...but to be fair, it's easy to look at 'Web Component' efforts (like Polymer...) and go... yeah, this seems very familiar...