The complaint: Web Components are XML

[Rob Dodson]

I think the most frequent gripe I hear about Web Components is that they look like XML and that totally freaks people out. I can definitely imagine my own horror if I were to open up a client project and top to bottom was all custom elements that I knew nothing about.

My own opinion is that they're almost like jQuery plugins. I don't see much difference in:

<div class="fancy-dropdown"></div>
$('.fancy-dropdown').dropdown();

and

<fancy-dropdown></fancy-dropdown>

and just like jQuery plugins, they're great if used in moderation but horrible if they constitute the bulk of your site. I realize that's not a very accurate analogy but I think it gets at my main point which is "If it does something mysterious then don't overuse it."

I figure in time some custom elements might become so commonplace that they achieve the same level of mindshare as seeing $ or .btn does today. Bootstrap is a good example. If I opened a document and saw <twbs-btn> then I could say "Oh! I know how Bootstrap buttons work. OK, moving on...". So my hope is that the good stuff will rise to the top and the best practice will be "liberally use the good stuff, but go easy on the esoteric or lesser known elements."

Does that make sense? What do you guys think?

[Dominic Cooney]

My $0.02: It's the web. You will occasionally be horrified and see things you wished you hadn't. On the other hand, occasionally you'll see really wonderful things--or build one yourself. To developers who are horrified: That's OK. Put on your thinking cap and start to experiment. This is how we'll collectively work out what's effective.

Dominic

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

[Seth Ladd]

On Sun, Oct 20, 2013 at 8:57 AM, Rob Dodson <lets.em...@gmail.com> wrote:

I think the most frequent gripe I hear about Web Components is that they look like XML and that totally freaks people out. I can definitely imagine my own horror if I were to open up a client project and top to bottom was all custom elements that I knew nothing about.

I'd much rather see a page of semantically interesting tags instead of the div soup I get from modern web apps today. So I'm not too worried about it :)

 

My own opinion is that they're almost like jQuery plugins. I don't see much difference in:

<div class="fancy-dropdown"></div>
$('.fancy-dropdown').dropdown();

and

<fancy-dropdown></fancy-dropdown>

and just like jQuery plugins, they're great if used in moderation but horrible if they constitute the bulk of your site. I realize that's not a very accurate analogy but I think it gets at my main point which is "If it does something mysterious then don't overuse it."

I figure in time some custom elements might become so commonplace that they achieve the same level of mindshare as seeing $ or .btn does today. Bootstrap is a good example. If I opened a document and saw <twbs-btn> then I could say "Oh! I know how Bootstrap buttons work. OK, moving on...". So my hope is that the good stuff will rise to the top and the best practice will be "liberally use the good stuff, but go easy on the esoteric or lesser known elements."

Does that make sense? What do you guys think?

I think the days of "view source" are mostly over. Modern web apps concatenate, obfuscate, minify, lazily load, and otherwise compile and build the source before it is pushed to production.

I believe the rise of custom elements will foster an easier to understand and extendable web, because it'll become easier to package up, share, and reuse the good stuff.

[Joern Turner]

Am Sonntag, 20. Oktober 2013 17:57:41 UTC+2 schrieb Rob Dodson:

I think the most frequent gripe I hear about Web Components is that they look like XML and that totally freaks people out. I can definitely imagine my own horror if I were to open up a client project and top to bottom was all custom elements that I knew nothing about.

Looks like XML? Cause it uses some well-formed markup? If developers should really choke on this bit of markup they should probably look for a job as C programmer ;)

IMO it's just a bit of markup (not even XML namespaces) and nothing to complain about - in contrast i think it's one of the superior features of web components to keep everything in one place (the script, the tempate and the CSS)

My own opinion is that they're almost like jQuery plugins. I don't see much difference in:

<div class="fancy-dropdown"></div>
$('.fancy-dropdown').dropdown();

and

<fancy-dropdown></fancy-dropdown>

i think the second is definitely more semantic than the former. As always it's also a matter of good naming your components to let the developer easily grasp the meaning of the new element.

 

and just like jQuery plugins, they're great if used in moderation but horrible if they constitute the bulk of your site. I realize that's not a very accurate analogy but I think it gets at my main point which is "If it does something mysterious then don't overuse it."

I figure in time some custom elements might become so commonplace that they achieve the same level of mindshare as seeing $ or .btn does today. Bootstrap is a good example. If I opened a document and saw <twbs-btn> then I could say "Oh! I know how Bootstrap buttons work. OK, moving on...". So my hope is that the good stuff will rise to the top and the best practice will be "liberally use the good stuff, but go easy on the esoteric or lesser known elements."

Does that make sense? What do you guys think?

I strongly hope that the declarative nature of web components will survive and we'll not fallback to doing everything in script. We've had enough of this and it definitely does not help understanding and maintenance.

 

[ad...@bewellup.com]

Are these Java,C#,C,C++,... developers who have never seen HTML before?

HTML Looks similar to XML - should freak them out too ;-).

Web components is HTML+Dart or HTML+JS.

I can imagine people want to develop Web applications like Desktop applications with a GUI designer without doing any HTML+CSS work directly.

And I am sure this will be possible in the not so far future.

[Dominic Cooney]

I understand why the "it's like XML" complaint arises. Superficially, it looks a bit like XML:

- The element names are "namespaced" with x- polymer-, etc. This looks a bit like an XML namespace.

- The element names are either from a bespoke ontology defined by the author or (increasingly) some defacto standard one (libraries, in the case of Web Components.) But not ones the reader is necessarily familiar with.

- The elements have close tags. Like XML. Modern HTML practice is not to write markup, but to write instructions to the parser, for example:

<!DOCTYPE html>

<div>Hello, world! ...

Is really shorthand for "instructions": I'm using HTML 5, create document element, create head, append head, create title, append title, pop, pop, create body, append body, create div, append div, create text node, append text node, pop, pop, pop. Custom Elements take you away from this world a little bit, because the parser groks you less.

I think programmers dislike XML for a variety of reasons. It would be a useful exercise to elicit what these reasons are, and see which ones apply to Web Components. Then you can walk people through it.

Here's a rough first cut:

XML Namespaces:

XML namespaces suck because you have two extra values/parameters (the prefix and namespace URI) you have to keep track of everywhere. If you get it wrong you get empty result sets, malformed documents, or lots of xmlns spew from different parts of the document having different prefixes. You can't understand part of a document with reference to some xmlns declaration a thousand lines away. When you edit documents you have to trim xmlns declarations elsewhere.

Web Components are much simpler: they always have one name. The prefix is part of the name. A specific element can't appear in two places with different prefixes; there's no namespace URI. There's no declaration of the prefix anywhere.

Plethora of tag names/I don't know what these tags mean:

XML documents are "hard" because I don't know what all of these tags mean.

XML is used for all kinds of random domains; Web Components are mostly used for UI widgets. So the tag names should be a bit easier to understand. [I think we could have a stronger answer to this. XML would refer you to schema, but schema is confusing. It would be nice if we had a practice of being able to say FooButton.documentation() or something and jump into documentation.]

I have to be careful or I get invalid markup:

XML processors are often strict and spew lots of errors at you if you forget to close a tag. As a result, you see nothing/no output/scary errors.

The HTML parser muddles through. As a result you get documents with a structure you didn't expect, but you do see something; use the inspector to debug. [I'm not sure if this is a better or worse situation.]

Dominic

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

[Jeremy Darling]

My personal disdain of XML has nothing to do with its similarity to HTML, in fact I rather like XHTML and knowing that a tag is properly closed.  Kind of wish we could have <script /> tags when the trailing </script> isn't necessary (eg embedding).

My personal disdain of XML is in its use with SOAP and the wire Bloat that was un-necessary even at the time it was thought of.

Then you take and add to it things like Microsofts implementation and helpers with .NET (and to some extent Java as well) and how now every "IT Guru" (at least at the Global Enterprise Level) seems to think this is the only way to do it.  I can't wait till the rest of the world figures out that JSON is lighter, Minimal Schema Design is more flexible, and having 100 element types is confusing.

If anything I would say the reason that people compare XML and HTML is their loose similarities, without understanding the differences that are there and the precursor's to XML that they were based on.  Really the only true similarity is the <>'s IMHO

A really "nice feature" to have with HTML would be something similar to "use strict"; where you could turn it on in development to validate all documents and throw proper error's when tags were not closed properly, invalid attributes were utilized, or invalid header types were utilized.  Of course, then we would have one less (or maybe more) CI test to pass/fail :)

Oh, and that was my developer, not my architect, side speaking.

 - Jeremy

[Dominic Cooney]

On Tue, Oct 22, 2013 at 11:36 AM, Jeremy Darling <jeremy....@gmail.com> wrote:

My personal disdain of XML has nothing to do with its similarity to HTML, in fact I rather like XHTML and knowing that a tag is properly closed.  Kind of wish we could have <script /> tags when the trailing </script> isn't necessary (eg embedding).

My personal disdain of XML is in its use with SOAP and the wire Bloat that was un-necessary even at the time it was thought of.

This is a good point; and the way to address this complaint is to emphasize that Web Components are not a serialization format. At most, they're a "construction and wiring description".

 

Then you take and add to it things like Microsofts implementation and helpers with .NET (and to some extent Java as well) and how now every "IT Guru" (at least at the Global Enterprise Level) seems to think this is the only way to do it.  I can't wait till the rest of the world figures out that JSON is lighter, Minimal Schema Design is more flexible, and having 100 element types is confusing.

I think this is also related to serialization. Mentioning that web apps use JSON for serialization is a good point.

--

[Louis St-Amour]

Just to chime in on this email's tangential wish for validation -- that does exist. Remember XHTML+XML mode of Firefox, that would give lovely red on cream text when your CMS messed up and forgot a closing tag when chopping paragraphs down to size? http://xhtml.com/en/xhtml/serving-xhtml-as-xml/ That's about as strict mode as things get around here, sans accessibility checkers. I'd suggest implementing your own validations server side or only running that mode under Selenium. ;-)

As to the topic at hand, I think any obfuscation here of page contents by custom elements will be resolved -- as with today's multitude of DIVs -- by the lowly Web Inspector and its live highlighting of page contents, etc.

Louis.

Sent from my iPhone

[Joern Turner]

Am Dienstag, 22. Oktober 2013 03:48:51 UTC+2 schrieb Dominic Cooney:

I understand why the "it's like XML" complaint arises. Superficially, it looks a bit like XML:

- The element names are "namespaced" with x- polymer-, etc. This looks a bit like an XML namespace.

- The element names are either from a bespoke ontology defined by the author or (increasingly) some defacto standard one (libraries, in the case of Web Components.) But not ones the reader is necessarily familiar with.

- The elements have close tags. Like XML. Modern HTML practice is not to write markup, but to write instructions to the parser, for example:

<!DOCTYPE html>

<div>Hello, world! ...

Is really shorthand for "instructions": I'm using HTML 5, create document element, create head, append head, create title, append title, pop, pop, create body, append body, create div, append div, create text node, append text node, pop, pop, pop. Custom Elements take you away from this world a little bit, because the parser groks you less.

I think programmers dislike XML for a variety of reasons. It would be a useful exercise to elicit what these reasons are, and see which ones apply to Web Components. Then you can walk people through it.

Here's a rough first cut:

XML Namespaces:

XML namespaces suck because you have two extra values/parameters (the prefix and namespace URI) you have to keep track of everywhere. If you get it wrong you get empty result sets, malformed documents, or lots of xmlns spew from different parts of the document having different prefixes. You can't understand part of a document with reference to some xmlns declaration a thousand lines away. When you edit documents you have to trim xmlns declarations elsewhere.

Sorry if that's off-topic now... XML namespaces are neither elegant nor easy to handle all the time. Big BUT - in the world of complex compound documents and XML encoded data they play a important role and unfortunately nobody has come up with something easier or more elegant. But there are XML languages which simply wouldn't work without them. Aeronautical Information Exchange Model (AIXM) is used to encode all information needed to deal with air traffic - you certainly don't want to allow any ambiguity here.

 

Web Components are much simpler: they always have one name. The prefix is part of the name. A specific element can't appear in two places with different prefixes; there's no namespace URI. There's no declaration of the prefix anywhere.

Right - because they are simply part of HTML - so no mixing of namespaces. However we'll see if this will hold in the long run when dozens of e.g. layout components from different origins pop up and name clashes become more likely. One day we probably need an answer to this or live with clashes.

Plethora of tag names/I don't know what these tags mean:

XML documents are "hard" because I don't know what all of these tags mean.

Well, also a matter of good or bad design. Decently designed XML is quite readable without much explanation while of course you can produce the complete opposite but that's true for any code - good variable names and well-structured code makes it readable and extensible while you can write absolutely horrible code in any language.

 

XML is used for all kinds of random domains; Web Components are mostly used for UI widgets. So the tag names should be a bit easier to understand. [I think we could have a stronger answer to this. XML would refer you to schema, but schema is confusing. It would be nice if we had a practice of being able to say FooButton.documentation() or something and jump into documentation.]

I'm not sure if i would limit web components to ui components. There are already example of non-UI components (localstorage, ajax ...) in Polymer.

 

I have to be careful or I get invalid markup:

XML processors are often strict and spew lots of errors at you if you forget to close a tag. As a result, you see nothing/no output/scary errors.

Well, same can be said e.g. for CSS ;) Syntax errors can scramble your whole page.

 

The HTML parser muddles through. As a result you get documents with a structure you didn't expect, but you do see something; use the inspector to debug. [I'm not sure if this is a better or worse situation.]

I think two aspects should be distinguished here. HTML was invented to display text document on the web. Today HTML is a host for more and more logic and data. While it might be acceptable that document structure is changed by a parser if it's purpose is simply the display of information for some humans. it's certainly not for logic and data marked up in HTML. Ambiguity is highly unwanted here.

To sum up: complaints like 'that looks like XML and i don't like XML' are not an argument but an opinion and are IMHO not worth much arguing. Mostly such complaints are rooted in lack of competence and knowledge. Building good applications and components is a job for professionals that know about the importance of syntax. Graphical tools will help the hobbyists in the mid-term.

So, sorry i disagree that it would be 'a useful exercise' to argue against those complaints - the time would better be spent into refining the standard and implementations. - just my personal point of view.

 

 Joern

[Dominic Cooney]

On Wed, Oct 23, 2013 at 6:39 AM, Joern Turner <joern....@gmail.com> wrote:

Am Dienstag, 22. Oktober 2013 03:48:51 UTC+2 schrieb Dominic Cooney:

I understand why the "it's like XML" complaint arises. Superficially, it looks a bit like XML:

- The element names are "namespaced" with x- polymer-, etc. This looks a bit like an XML namespace.

- The element names are either from a bespoke ontology defined by the author or (increasingly) some defacto standard one (libraries, in the case of Web Components.) But not ones the reader is necessarily familiar with.

- The elements have close tags. Like XML. Modern HTML practice is not to write markup, but to write instructions to the parser, for example:

<!DOCTYPE html>

<div>Hello, world! ...

Is really shorthand for "instructions": I'm using HTML 5, create document element, create head, append head, create title, append title, pop, pop, create body, append body, create div, append div, create text node, append text node, pop, pop, pop. Custom Elements take you away from this world a little bit, because the parser groks you less.

I think programmers dislike XML for a variety of reasons. It would be a useful exercise to elicit what these reasons are, and see which ones apply to Web Components. Then you can walk people through it.

Here's a rough first cut:

XML Namespaces:

XML namespaces suck because you have two extra values/parameters (the prefix and namespace URI) you have to keep track of everywhere. If you get it wrong you get empty result sets, malformed documents, or lots of xmlns spew from different parts of the document having different prefixes. You can't understand part of a document with reference to some xmlns declaration a thousand lines away. When you edit documents you have to trim xmlns declarations elsewhere.

Sorry if that's off-topic now... XML namespaces are neither elegant nor easy to handle all the time. Big BUT - in the world of complex compound documents and XML encoded data they play a important role and unfortunately nobody has come up with something easier or more elegant. But there are XML languages which simply wouldn't work without them. Aeronautical Information Exchange Model (AIXM) is used to encode all information needed to deal with air traffic - you certainly don't want to allow any ambiguity here.

Web Components are much simpler: they always have one name. The prefix is part of the name. A specific element can't appear in two places with different prefixes; there's no namespace URI. There's no declaration of the prefix anywhere.

Right - because they are simply part of HTML - so no mixing of namespaces. However we'll see if this will hold in the long run when dozens of e.g. layout components from different origins pop up and name clashes become more likely. One day we probably need an answer to this or live with clashes.

Yes. I think XML Namespaces place the cost of avoiding clashes up-front. Web Components naming places the cost on the author who actually has a clash. In either approach, there's a (potential) cost.

 

Plethora of tag names/I don't know what these tags mean:

XML documents are "hard" because I don't know what all of these tags mean.

Well, also a matter of good or bad design. Decently designed XML is quite readable without much explanation while of course you can produce the complete opposite but that's true for any code - good variable names and well-structured code makes it readable and extensible while you can write absolutely horrible code in any language.

 

XML is used for all kinds of random domains; Web Components are mostly used for UI widgets. So the tag names should be a bit easier to understand. [I think we could have a stronger answer to this. XML would refer you to schema, but schema is confusing. It would be nice if we had a practice of being able to say FooButton.documentation() or something and jump into documentation.]

I'm not sure if i would limit web components to ui components. There are already example of non-UI components (localstorage, ajax ...) in Polymer.

This is a good point. How should Web Components authors address this complaint?

 

I have to be careful or I get invalid markup:

XML processors are often strict and spew lots of errors at you if you forget to close a tag. As a result, you see nothing/no output/scary errors.

Well, same can be said e.g. for CSS ;) Syntax errors can scramble your whole page.

 

The HTML parser muddles through. As a result you get documents with a structure you didn't expect, but you do see something; use the inspector to debug. [I'm not sure if this is a better or worse situation.]

I think two aspects should be distinguished here. HTML was invented to display text document on the web. Today HTML is a host for more and more logic and data. While it might be acceptable that document structure is changed by a parser if it's purpose is simply the display of information for some humans. it's certainly not for logic and data marked up in HTML. Ambiguity is highly unwanted here.

To sum up: complaints like 'that looks like XML and i don't like XML' are not an argument but an opinion and are IMHO not worth much arguing. Mostly such complaints are rooted in lack of competence and knowledge. Building good applications and components is a job for professionals that know about the importance of syntax.

In my experience, people don't find this line of argument--that they're incompetent--very persuasive. Unless you're very gentle.

 

Graphical tools will help the hobbyists in the mid-term.

So, sorry i disagree that it would be 'a useful exercise' to argue against those complaints - the time would better be spent into refining the standard and implementations. - just my personal point of view.

I think it would be a shame if "entry level"? developers didn't embrace Web Components. Web Components should expand the scope and complexity of what a given engineer can build, but particularly so for these developers since the gap from what you can do with a composition of HTML elements alone, to what you can do with a composition of Web Components, is so large (assuming you have a good set of components on your palette.)

--

[John Barton]

Both XML and Web Components use angle brackets. I don't see any other overlap.

XML is a transport syntax. All of the semantics behind the tags is defined in the endpoints. XML "components" exist in the markup only to the extent that endpoints agree to decouple the meaning of a tree branch from its context. The only other component aspect is the specification of an XML language and corresponding construction of specialized transcoders; together they form a kind of bulky component in the world of documents.

Web Components encapsulate an implementation of semantics.  The interpretation of the semantics is independent of the endpoints: that is what it means to have a open standard.  The semantics may be modifiable or elastic, but the word component is not accidental.

(These kinds of questions seem pointless but I think they help newbies like me think about the technology from further back than a line of documentation).

[Joern Turner]

Am Mittwoch, 23. Oktober 2013 01:29:23 UTC+2 schrieb Dominic Cooney:

On Wed, Oct 23, 2013 at 6:39 AM, Joern Turner <joern....@gmail.com> wrote:

Am Dienstag, 22. Oktober 2013 03:48:51 UTC+2 schrieb Dominic Cooney:

I understand why the "it's like XML" complaint arises. Superficially, it looks a bit like XML:

- The element names are "namespaced" with x- polymer-, etc. This looks a bit like an XML namespace.

- The element names are either from a bespoke ontology defined by the author or (increasingly) some defacto standard one (libraries, in the case of Web Components.) But not ones the reader is necessarily familiar with.

- The elements have close tags. Like XML. Modern HTML practice is not to write markup, but to write instructions to the parser, for example:

<!DOCTYPE html>

<div>Hello, world! ...

Is really shorthand for "instructions": I'm using HTML 5, create document element, create head, append head, create title, append title, pop, pop, create body, append body, create div, append div, create text node, append text node, pop, pop, pop. Custom Elements take you away from this world a little bit, because the parser groks you less.

I think programmers dislike XML for a variety of reasons. It would be a useful exercise to elicit what these reasons are, and see which ones apply to Web Components. Then you can walk people through it.

Here's a rough first cut:

XML Namespaces:

XML namespaces suck because you have two extra values/parameters (the prefix and namespace URI) you have to keep track of everywhere. If you get it wrong you get empty result sets, malformed documents, or lots of xmlns spew from different parts of the document having different prefixes. You can't understand part of a document with reference to some xmlns declaration a thousand lines away. When you edit documents you have to trim xmlns declarations elsewhere.

Sorry if that's off-topic now... XML namespaces are neither elegant nor easy to handle all the time. Big BUT - in the world of complex compound documents and XML encoded data they play a important role and unfortunately nobody has come up with something easier or more elegant. But there are XML languages which simply wouldn't work without them. Aeronautical Information Exchange Model (AIXM) is used to encode all information needed to deal with air traffic - you certainly don't want to allow any ambiguity here.

Web Components are much simpler: they always have one name. The prefix is part of the name. A specific element can't appear in two places with different prefixes; there's no namespace URI. There's no declaration of the prefix anywhere.

Right - because they are simply part of HTML - so no mixing of namespaces. However we'll see if this will hold in the long run when dozens of e.g. layout components from different origins pop up and name clashes become more likely. One day we probably need an answer to this or live with clashes.

Yes. I think XML Namespaces place the cost of avoiding clashes up-front. Web Components naming places the cost on the author who actually has a clash. In either approach, there's a (potential) cost.

The fact that the custom element name is hardwired in a component makes it hard to resolve clashes once you have them. Probably some aliasing mechanism could help. Something like:

<my-component is="some-component" ...

I'm aware that 'is' is already reserved and implies an inheritance but i couldn't guess of something better quickly but i hope you get the idea. This would say 'create a custom element with name 'my-component' which is actually the 'some-component' custom element.

 

Plethora of tag names/I don't know what these tags mean:

XML documents are "hard" because I don't know what all of these tags mean.

Well, also a matter of good or bad design. Decently designed XML is quite readable without much explanation while of course you can produce the complete opposite but that's true for any code - good variable names and well-structured code makes it readable and extensible while you can write absolutely horrible code in any language.

 

XML is used for all kinds of random domains; Web Components are mostly used for UI widgets. So the tag names should be a bit easier to understand. [I think we could have a stronger answer to this. XML would refer you to schema, but schema is confusing. It would be nice if we had a practice of being able to say FooButton.documentation() or something and jump into documentation.]

I'm not sure if i would limit web components to ui components. There are already example of non-UI components (localstorage, ajax ...) in Polymer.

This is a good point. How should Web Components authors address this complaint?

Sorry - which complaint?

 

 

I have to be careful or I get invalid markup:

XML processors are often strict and spew lots of errors at you if you forget to close a tag. As a result, you see nothing/no output/scary errors.

Well, same can be said e.g. for CSS ;) Syntax errors can scramble your whole page.

 

The HTML parser muddles through. As a result you get documents with a structure you didn't expect, but you do see something; use the inspector to debug. [I'm not sure if this is a better or worse situation.]

I think two aspects should be distinguished here. HTML was invented to display text document on the web. Today HTML is a host for more and more logic and data. While it might be acceptable that document structure is changed by a parser if it's purpose is simply the display of information for some humans. it's certainly not for logic and data marked up in HTML. Ambiguity is highly unwanted here.

To sum up: complaints like 'that looks like XML and i don't like XML' are not an argument but an opinion and are IMHO not worth much arguing. Mostly such complaints are rooted in lack of competence and knowledge. Building good applications and components is a job for professionals that know about the importance of syntax.

In my experience, people don't find this line of argument--that they're incompetent--very persuasive. Unless you're very gentle.

 

Graphical tools will help the hobbyists in the mid-term.

So, sorry i disagree that it would be 'a useful exercise' to argue against those complaints - the time would better be spent into refining the standard and implementations. - just my personal point of view.

I think it would be a shame if "entry level"? developers didn't embrace Web Components. Web Components should expand the scope and complexity of what a given engineer can build, but particularly so for these developers since the gap from what you can do with a composition of HTML elements alone, to what you can do with a composition of Web Components, is so large (assuming you have a good set of components on your palette.)

My statement was not meant to leave anyone before the door. But

"Make everything as simple as possible, but not simpler" Albert Einstein

The web component spec is a big step forward in that direction compared to XBL which surely can be seen as a predecessor but was never accepted due to its overly complexity.

So what are we discussing here? Is it just the demand of well-formedness (which makes things predictable in terms of parser behavior) or is the declarative approach in markup as a whole is questioned? This is IMO one of the 'sexy' aspects of web components and replacing that by a set of instructions (as you mentioned above) would really a big step backwards.

Further it might help to distinguish between web component users and web component implementors. The latter surely need a higher level of competence. Tooling can help both groups to get it right - for the former is easy to imagine graphical frontends with DnD while the latter would profit from good editors with syntax highlighting and error detection.

Also a strict mode as suggested in this thread is also a good idea for component developers.

[arien...@gmail.com]

On Sunday, October 20, 2013 5:57:41 PM UTC+2, Rob Dodson wrote:

I can definitely imagine my own horror if I were to open up a client project and top to bottom was all custom elements that I knew nothing about. 

that and

I figure in time some custom elements might become so commonplace that they achieve the same level of mindshare as seeing $ or .btn does today

this. New and unknown things make people uncomfortable (me included), until they are no longer unknown.

IMO the question shouldn't be "is componentizing the web good or bad", but more about how can the spec be optimized so that we get the best possible reuse of components.

I don't want to HAVE to understand a custom element, unless I plan to use it directly. When I call a function, I mostly care about behavior.

[Ted Driggs]

The ability to alias imports is definitely something worth considering: If two large sets of content ever do collide, neither party will quietly accept going off and rewriting all their content to use a new non-conflicting name.

[pat...@patrickmetcalfe.com]

My opinion on Web Components has two sides.

1. HTML is about being accessible to everyone and as a self-taught programmer I believe the div soup is inaccessible to people who are interested in how a website works (Don't tell me you haven't been there before. I've learned so many things from Cmd+Opt+U) or even new coworkers who have to an encyclopedia and an expert to understand how a site is laid out before he can do anything, just look at this page. div>div>div...forever... 

2. I'm worried devs will make tags that totally obfuscate their code for performance gains or to make it unreadable to outsiders (opposite of an open web see #1 above). Imagine if Google was filled with tags along the lines of <g-weibvlqbeqbiubqkjdbiuqbek> that only Google can understand. This has serious ramifications beyond my programmer-friendly point in terms of accessibility, SEO , etc. Its important to remember that HTML should be readable and comprhenible without a user-agent stylesheet hiding the tags and stuff.

[Rob Dodson]

re: point no. 2

This is already the case today. Here's a screenshot of the markup generated by gmail. That code is the byproduct of some framework just spitting out DOM as a substrate. So they're already sort of obfuscating but hopefully you wouldn't need to spew out all of that DOM if whatever they were building was just encapsulated in Shadow DOM and wrapped in a Custom Element.

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/40653bc6-0d68-47a0-90e9-7d484d4958f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[rvin...@gmail.com]

Hey all, great discussion! I totally agree with Patrick's Point #2 

I learnt more from viewing source of how a big website implements cool effects than reading tutorials on the internet. Is it possible that the HTML imports being used can be viewed as well? 

[Rob Dodson]

You can look at the content of an import using the dev tools

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/a9e3c6c4-813e-4f90-846b-784bfdf73da6%40googlegroups.com.

[Scott Miles]

Well said and 100% correct IMO.

On Mon, Apr 28, 2014 at 6:12 AM, <ryan...@nthpenguin.com> wrote:

To the notion that the OP and others brought up regarding the desire for people to 'not use Web Components to make the whole site'... isn't that the point? Turning the entire application into granular, reusable, well encapsulated components that can be easily composed into larger specialized components in a declarative manner is pretty much the whole idea here. For me, that's been the promise of the web platform all along, and the great frameworks embrace this (Enyo, Facebook React, Polymer, X-tags). Markup is a natural expression layer for this compositional way of working. Enyo achieves their declarative composition with JSON mixed into the component's imperative declaration, and that's fine too, but the beauty of using markup is that you can easily embed and compose at the document level. That's HUGE! Please don't view that as even remotely a negative. Being able to compose semantic markup (that comes with rich functionality) at the document level brings clarity to the web development process. It brings the expression of what you want the app to do closer to the implementation of making it happen.

Not only do I think people should be embracing this, I can attest to the power of doing so. Before Web Components was a glean in the collective eyes of the W3C, I have been using one widget/component based framework or the other, often writing my own (https://github.com/theVolary/feather). Once you get practiced in thinking through how to break the application up into small chunks of compose-able functionality, you will be pleasantly surprised at just how often you get to reuse your components in contexts other than the one you initial created it for. It also becomes a heck of a lot easier to re-organize things when requirements change.

There is nothing wrong with markup, nor with using a component based approach to create the entire application. 

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/2cbd0bde-d7b6-4c68-acad-026cc30b474e%40googlegroups.com.

[Joern Turner]

I fully agree Ryan - thanks for posting.

You received this message because you are subscribed to a topic in the Google Groups "Polymer" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/polymer-dev/lzvaDViB_Ow/unsubscribe.
To unsubscribe from this group and all its topics, send an email to polymer-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAHbmOLbPH%3DywkXbbjekd_3%3DUxeVNR%2BTFesdkNHYiG165rgNuiw%40mail.gmail.com.

[hungry...@gmail.com]

On Tuesday, October 22, 2013 5:39:16 PM UTC-4, Joern Turner wrote:

 

Web Components are much simpler: they always have one name. The prefix is part of the name. A specific element can't appear in two places with different prefixes; there's no namespace URI. There's no declaration of the prefix anywhere.

Right - because they are simply part of HTML - so no mixing of namespaces. However we'll see if this will hold in the long run when dozens of e.g. layout components from different origins pop up and name clashes become more likely. One day we probably need an answer to this or live with clashes.

Personally, I think they need to bind document.registerElement and HTMLImport <link /> tag.  This way the page designer can set the name tag for conflicts. i.e.

<link rel="import" href="component1.html" for="mine">
<link rel="import" href="component2.html" for="theirs">
<mine-toolbar/>
<theirs-toolbar/>

so when registerElement is called, it prepends the for with a dash, in the component.html files.  The component writers are not going to know the ultimate goal of the plugin or even how it will be extended, but the end user page designer will.

- Jeremy

[mass.inf...@gmail.com]

The real distinction lurking beneath the surface of this thread is not between XML and HTML (though I agree that self-closing elements would be nice and namespaces or at least aliasing will definitely be required) but rather between the web as URL+API vs the web as URL+Markup. If markup doesn't matter, then asm.js, DIV soup, famo.us and to some extent React may well represent the future of web development -- and as was mentioned before, we simply need to get over the warm and fuzzy feeling of being able to "View Source" (which is effectively compiled). But if markup _does_ matter (for apps as well as docs), then surely making it extensible is a winning move (i.e. open-ended vocabularies should be considered a blessing not a curse). 

I have a gut feeling that markup matters, even for apps (I enjoyed Adobe Flex and OpenLaszlo was fun as well), but where are such projects now (XUL?), and why is it so difficult to pinpoint the benefit of markup over "js-compiled" solutions?

Manor.

[Alex Russell]

On Thu, Oct 30, 2014 at 12:08 PM, <mass.inf...@gmail.com> wrote:

The real distinction lurking beneath the surface of this thread is not between XML and HTML (though I agree that self-closing elements would be nice and namespaces or at least aliasing will definitely be required)

Full aliasing should become possible from script if we add doucument.unregisterElement(). Assuming 2 imports don't conflict today, aliasing is already possible.

 

but rather between the web as URL+API vs the web as URL+Markup. If markup doesn't matter, then asm.js, DIV soup, famo.us and to some extent React may well represent the future of web development -- and as was mentioned before, we simply need to get over the warm and fuzzy feeling of being able to "View Source" (which is effectively compiled). But if markup _does_ matter (for apps as well as docs), then surely making it extensible is a winning move (i.e. open-ended vocabularies should be considered a blessing not a curse). 

I have a gut feeling that markup matters, even for apps (I enjoyed Adobe Flex and OpenLaszlo was fun as well), but where are such projects now (XUL?), and why is it so difficult to pinpoint the benefit of markup over "js-compiled" solutions?

Because it isn't local to the developer who is comfortable making components for others. It's social and environmental. In small-ish orgs, the benefits are about enabling one team to build tools for another who might not be staffed with people who think of themselves as engineers.

At a global level, markup becomes important for understanding (e.g. Search), but again, that's not about the code that any individual engineer is writing. They are diffuse and indirect impacts, no matter how important they are.

 

On Sunday, October 20, 2013 11:57:41 AM UTC-4, Rob Dodson wrote:

I think the most frequent gripe I hear about Web Components is that they look like XML and that totally freaks people out. I can definitely imagine my own horror if I were to open up a client project and top to bottom was all custom elements that I knew nothing about.

My own opinion is that they're almost like jQuery plugins. I don't see much difference in:

<div class="fancy-dropdown"></div>
$('.fancy-dropdown').dropdown();

and

<fancy-dropdown></fancy-dropdown>

and just like jQuery plugins, they're great if used in moderation but horrible if they constitute the bulk of your site. I realize that's not a very accurate analogy but I think it gets at my main point which is "If it does something mysterious then don't overuse it."

I figure in time some custom elements might become so commonplace that they achieve the same level of mindshare as seeing $ or .btn does today. Bootstrap is a good example. If I opened a document and saw <twbs-btn> then I could say "Oh! I know how Bootstrap buttons work. OK, moving on...". So my hope is that the good stuff will rise to the top and the best practice will be "liberally use the good stuff, but go easy on the esoteric or lesser known elements."

Does that make sense? What do you guys think?

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/57f37a96-70ed-4320-8f56-4e8b669ef7c7%40googlegroups.com.

[mat...@mateusribeirooliveira.com]

I completely agree with you. In time there'll be a dominant web component library framework and everybody will understand the "mysteries" tags...

[mat...@mateusribeirooliveira.com]

I understand Patrick worries, but in the end there'll be a dominant web component library. Bad code will always be discarded .. 

 

[mdiasinf...@gmail.com]

Everybody that comes from C#,Delphi seems coming back to something less productive than Cobol.
I know if comparing to the old way of doing thing in Net programming thats an enourmous evolution.
But I just can´t use for creating an ERP.

[Bruce Anderson]

Great question.  I think there are a few concerns about using an HTML-centric markup, vs doing everything with JavaScript.  Keep in mind I'm fully in the HTML-centric camp, but I think these are some concerns worth overcoming, especially in a world competing with Typescript intellisense / navigation support +  template strings or JSX. 

1)  Developers need a seamless way to navigate between a web component tag, and the "code-behind" that makes the web component tick.  When I look at an ANT build script or Visual Studio build task, I want to be able to easily jump to the code to gain a better understanding of what the task is doing.  Not being able to do so is a real turn off.  Likewise with web components. Webstorm, for example, is pretty good at jumping between an html file which consumes polymer-based web components, and the code for the actual component.  Unfortunately, it may be the only IDE at this point.  And of course it is important that IDE's support any kind of ergonomic layer behind the web component.  No IDE I've seen yet provides intellisense for all the exposed attributes that are associated with the component.

2)  Often the webcomponent is providing a wrapper around a complex JavaScript api (e.g. charting libraries).  Web components provide a great way of making the api declarative, but developers quickly sour on this if the declarative markup syntax prevents you from doing anything you could do with the api. 

3)  Along those lines, complex components, like grids, typically have a huge feature set, beyond the ability to easily memorize all the property names.  One way or another, developers will want to customize / configure the settings in a way where autocomplete with tooltip info is available. Because the underlying api will typically use JSON like syntax to configure the grid, and because the ability to do this with intellisense / compile type checks available with Typescript is quite alluring, and because IDE support for HTML attributes isn't there yet, to my knowledge, (and arguably because defining all these custom settings using attributes would result in HTML clutter that isn't very semantic), I think there is a need for a special custom element that you can use to "decorate" other custom elements, just as JavaScript decorators can be used to configure JavaScript methods or properties.  This custom element would allow you to dynamically add behaviors onto the element, which would be JavaScript Object references (just like Polymer behaviors , but applied by consumers of the web component, externally to it, rather than within the web component itself).  Easy to develop such a thing, but it would be great if Polymer suggested a way to do this universally.

Just my two cents.