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  
<https://www.polymer-project.org/1.0/docs/devguide/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.


On Sunday, October 20, 2013 at 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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/polymer-dev/6d53eee7-78c2-4277-af07-6c8ad5b38ff3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to