package name for platform.js?

[John Messerly]

Hello polymerites,

I'm going to create a Pub (http://pub.dartlang.org/) package for polymer's platform.js, to replace our individual polyfill pkgs: shadow_dom, html_imports, and custom_elements. The individual pkgs have been a bit of a headache as they get out of sync, etc. Plus it would be awesome to reuse exactly the same JS code from the corresponding Bower[1] package. Since "platform" is a really generic name, I was thinking of calling this package "web_components". Any objections?

Note: template_binding and observe would stay separate pkgs on Pub, so they wouldn't be included conceptually.

Cheers!

- John

[1]: leaving aside for now the question of Pub interoping directly with Bower. That's a good long term solution but will take a while to get there.

[Steve Orvell]

+1

We've been consdering re-naming platform to webcomponents as well.

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/CAJup4OUyk0TnFvL%2B7Hd%2BCO%2BgoRUsJfih_cf3h0WDtWA01GuLHA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Addy Osmani]

Whilst I like platform.js, webcomponents.js makes the literal distinction between Polymer and the polyfills all the more clear. 

Hope that rename happens :)

[Jan Miksovsky]

Based on my understanding of the Polymer strategy, I wonder if any name that speaks to directly to web components will prove too limiting in the future.

On a separate thread, I presented the view that the current polyfill strategy is suitable for much more than web components, and could (and should) be adopted for future specs. The fact that, for example, Pointer Events and Web Animations are grouped under the "web components" umbrella seems more a historical accident than intention. In the case of Pointer Events, that shipped independently in IE, and both of those technologies could be used in a page that has no component nature at all. I hear Google referring to these as web component technologies, when to me they're just new web technologies.

The same thing will surely happen going forward. The next time someone proposes a new, polyfillable spec for a feature that has nothing to do with components. Having to create a new polyfill library just for that one spec seems overly complex. Won't the most natural thing to do be to include that in platform.js? If that library is renamed webcomponents.js, it seems likely that name will eventually become increasingly inappropriate. (Cf. jQuery)

My two cents: Polymer is a great name. It's catchy, memorable, and has an etymology that can be explained. If it were up to me, I'd rename platform.js to polymer.js. Polymer would be the "brand" by which the world refers to a vendor-independent browser compatibility library.

Otherwise, I'd recommend selecting a name that suggests the role the polyfill library fills: standards.js, or compat.js.

The thing I'd rename is actually polymer.html. In my understanding, polymer.html has a more focused responsibility: support the creation of custom elements. That role seems unlikely to evolve much over time. If that's correct, then a descriptive name like customelements.html would be attractive. (Of course, I could easily be misunderstanding the boundary between platform.js and polymer.html. Please correct me if I'm wrong!)

[Scott Miles]

Thanks for the thoughtful (as usual!) feedback.

The collected polyfills don't have a strong identity for me. We made them simply as a way to get to using these technologies when we had the sad realization that web components were a long way from actual implementation in browsers (when we started this process ~18 months ago).

We worked hard to layer the polyfills so that folks could remix them as needed. This was useful in particular for Mozilla, who cherry picked Custom Elements polyfill for x-tags/brick.

Polymer itself refers to the library we have created that provides a common sugaring layer and declarative support for custom elements. This is where we express our opinions about how to utilize the web components technologies, and is really the end-product we sought to produce. Polymer proper is not beholden to any spec or committee, the Polymer team decides how it should be (incorporating as much feedback as we can from our awesome users like yourself!). For this reason, it's much more deserving of a brand than the polyfills IMO.

Also, on top of Polymer we vend one or more element sets, but I'm equally anxious to separate those element sets from Polymer itself. Ideally the ecosystem of elements is vast and interoperable, and the Polymer team can vend elements just like everybody else. Conceptually one need not know if one is using a Polymer element, an X-Tag element, plain vanilla custom element, or some mixture. The underlying technologies are hidden and the elements can work together. 

>> I'd recommend selecting a name that suggests the role the polyfill library fills:

The notion of 'platform.js' is to say 'normalize the platforms', which IMO *is* the role of those collected polyfills. Unfortunately, that name is quite generic. Although fully aware that it's less correct, I suggest `webcomponents.js` believing it more likely to communicate the necessary concept for newbies (that this file provides those futuristic features).

Scott

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/df1a28de-1117-4e98-b233-3416939e4bb2%40googlegroups.com.

[Brian Di Palma]

You could combine the two prefered names and call it "webcomponents-platform.js" then?

Or be very explict and use "webcomponents-platform-shim.js" or "webcomponents-platform-polyfill.js".

Very clear and descriptive name. Does what it says on the tin!

This is some serious bikeshedding :)

B.