Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Custom Elements v1: Reusable Web Components

developers.google.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Custom Elements v1: Reusable Web Components

#31

Post by [deleted] »

jarym wrote: post #7
chrismorgan wrote: post #4

Earlier quoted context omitted.

Custom Elements is the low-level API that allows you to do all kinds of things. Polymer is designed to sit on top of that as a higher-level API. This is how things should be. Otherwise you get designed into an undesirable corner. (Example: I can imagine improvements to the Polymer code achieved with decorators and TypeScript, for example, which would require a somewhat different API. To need a translation layer over…

I seem to recall IndexedDB was designed with the same thinking and that hasn't worked out so well. (Not talking about Custom Elements here since I don't know enough about it - the comment is levelled at the process). It's all too easy for people in a committee to manufacture the idea of some mythical figures further along the conveyer belt who will magically make something useful out of a giant specification with gap…

[deleted]

Re: Custom Elements v1: Reusable Web Components

#32

Post by chrismorgan »

jarym wrote: post #7
chrismorgan wrote: post #4

Earlier quoted context omitted.

Custom Elements is the low-level API that allows you to do all kinds of things. Polymer is designed to sit on top of that as a higher-level API. This is how things should be. Otherwise you get designed into an undesirable corner. (Example: I can imagine improvements to the Polymer code achieved with decorators and TypeScript, for example, which would require a somewhat different API. To need a translation layer over…

I seem to recall IndexedDB was designed with the same thinking and that hasn't worked out so well. (Not talking about Custom Elements here since I don't know enough about it - the comment is levelled at the process). It's all too easy for people in a committee to manufacture the idea of some mythical figures further along the conveyer belt who will magically make something useful out of a giant specification with gap…

Polymer in particular has been actively involved in the shaping of Custom Elements, so I believe we’re avoiding that issue with Custom Elements.

Re: Custom Elements v1: Reusable Web Components

#33

Post by reificator »

jarym wrote: post #7
chrismorgan wrote: post #4

Earlier quoted context omitted.

Custom Elements is the low-level API that allows you to do all kinds of things. Polymer is designed to sit on top of that as a higher-level API. This is how things should be. Otherwise you get designed into an undesirable corner. (Example: I can imagine improvements to the Polymer code achieved with decorators and TypeScript, for example, which would require a somewhat different API. To need a translation layer over…

I seem to recall IndexedDB was designed with the same thinking and that hasn't worked out so well. (Not talking about Custom Elements here since I don't know enough about it - the comment is levelled at the process). It's all too easy for people in a committee to manufacture the idea of some mythical figures further along the conveyer belt who will magically make something useful out of a giant specification with gap…

Polymer was released and worked on as a library while the spec was being worked on. Polymer 0.x and 1.x targeted a version that was only implemented in Chrome, which was used to build the eventual standard, and Polymer 2.x targets the final standard.

The API for web components isn't that bad. You have to stamp DOM templates yourself using whatever process, you have to handle attributes and properties yourself, and that's about it. Lots of boilerplate, but a library like Polymer can take a simple, opinionated approach to handle it for you.

From my experience Web Components have been pretty pleasant to use with or without Polymer, it's just a matter of wiring everything up if you go vanilla.

Re: Custom Elements v1: Reusable Web Components

#34

Post by [deleted] »

jarym wrote: post #7
chrismorgan wrote: post #4

Earlier quoted context omitted.

Custom Elements is the low-level API that allows you to do all kinds of things. Polymer is designed to sit on top of that as a higher-level API. This is how things should be. Otherwise you get designed into an undesirable corner. (Example: I can imagine improvements to the Polymer code achieved with decorators and TypeScript, for example, which would require a somewhat different API. To need a translation layer over…

I seem to recall IndexedDB was designed with the same thinking and that hasn't worked out so well. (Not talking about Custom Elements here since I don't know enough about it - the comment is levelled at the process). It's all too easy for people in a committee to manufacture the idea of some mythical figures further along the conveyer belt who will magically make something useful out of a giant specification with gap…

[deleted]

Re: Custom Elements v1: Reusable Web Components

#35

Post by dmitriid »

Vinnl wrote: post #9
dmitriid wrote: post #3

Custom Elements v1. Designed by committee: https://pbs.twimg.com/media/DALwpYnUAAESRjr.jpg Polymer. Designed by people who actually do web development: https://pbs.twimg.com/media/DALwpYWVoAAIvkQ.jpg

Apart from what others have mentioned about how the Polymer team contributes to the standard, as someone who's worked with Polymer, I think you're also painting a far too rose picture of Polymer, unfortunately.

I know there are no roses in Polymer :) I just wanted to point out that the horrible low-level API of Custom Elements could easily be avoided.

Re: Custom Elements v1: Reusable Web Components

#36

Post by dmitriid »

chrismorgan wrote: post #4
dmitriid wrote: post #3

Custom Elements v1. Designed by committee: https://pbs.twimg.com/media/DALwpYnUAAESRjr.jpg Polymer. Designed by people who actually do web development: https://pbs.twimg.com/media/DALwpYWVoAAIvkQ.jpg

Custom Elements is the low-level API that allows you to do all kinds of things. Polymer is designed to sit on top of that as a higher-level API. This is how things should be. Otherwise you get designed into an undesirable corner. (Example: I can imagine improvements to the Polymer code achieved with decorators and TypeScript, for example, which would require a somewhat different API. To need a translation layer over…

Riight. What you're saying is: "we must have horrible imperative code that takes three times as much code as a simple declarative/fluent API because ... reasons".

There's next to zero requirements for "static get observableAttributes" and "attributeChangedCalback" which in 99% of the cases can easily be replaced with

   static get properties() {
       return {
         x: {reflectToAttribute: true}
       }
   }
etc.

Re: Custom Elements v1: Reusable Web Components

#37

Post by dmitriid »

reificator wrote: post #33
jarym wrote: post #7

Earlier quoted context omitted.

I seem to recall IndexedDB was designed with the same thinking and that hasn't worked out so well. (Not talking about Custom Elements here since I don't know enough about it - the comment is levelled at the process). It's all too easy for people in a committee to manufacture the idea of some mythical figures further along the conveyer belt who will magically make something useful out of a giant specification with gap…

Polymer was released and worked on as a library while the spec was being worked on. Polymer 0.x and 1.x targeted a version that was only implemented in Chrome, which was used to build the eventual standard, and Polymer 2.x targets the final standard. The API for web components isn't that bad. You have to stamp DOM templates yourself using whatever process, you have to handle attributes and properties yourself, and th…

> The API for web components isn't that bad.

> Lots of boilerplate

If there's lots of boilerplate, the API is bad.

Re: Custom Elements v1: Reusable Web Components

#38

Post by dmitriid »

Cthulhu_ wrote: post #8
dmitriid wrote: post #3

Custom Elements v1. Designed by committee: https://pbs.twimg.com/media/DALwpYnUAAESRjr.jpg Polymer. Designed by people who actually do web development: https://pbs.twimg.com/media/DALwpYWVoAAIvkQ.jpg

Your comment is unnecessarily snide / cynical; you should be aware that the Polymer team is the main driver of the Custom Elements committee. Polymer 2 is now a framework on top of the Custom Elements standard they helped develop and flesh out with Polymer 1.

Your comment basically reads like "Polymer team made sure the API is horrible so that everyone would flock to Polymer when looking for better/saner ways to deal with WebComponents"

Re: Custom Elements v1: Reusable Web Components

#39

Post by reificator »

dmitriid wrote: post #37
reificator wrote: post #33

Earlier quoted context omitted.

Polymer was released and worked on as a library while the spec was being worked on. Polymer 0.x and 1.x targeted a version that was only implemented in Chrome, which was used to build the eventual standard, and Polymer 2.x targets the final standard. The API for web components isn't that bad. You have to stamp DOM templates yourself using whatever process, you have to handle attributes and properties yourself, and th…

> The API for web components isn't that bad. > Lots of boilerplate If there's lots of boilerplate, the API is bad.

ServiceWorker vs Application Cache, I'll take ServiceWorker every time.

When you're talking about a low level primitive, boilerplate is preferable. It means you have options. You can throw Polymer or any other library on top and get what you want out of the standard, while someone else can come with different requirements and not be boxed in by your own.

If you can distill your argument to one sentence, it probably isn't blindly applicable to all circumstances. Yes that was one sentence.

Re: Custom Elements v1: Reusable Web Components

#40

Post by cztomsik »

reificator wrote: post #19
cztomsik wrote: post #13

please correct me if I'm wrong but it seems that custom elements still do nothing about dependency hell (it's not possible to use same lib in different versions)

Why would they be expected to?

Basically, it's about "we can't use lib x because it will break lib y" - this already happens in java and I would consider java being very conservative and slow-progressing.

Now, imagine how quickly is javascript evolving, libraries, frameworks, etc.

Solution to dependency hell is a major reason why node.js succeeded (along with browserify/webpack) unlike anything with flat dependencies (bower)

Post reply on HN