Out of pre-alpha? When?

[kwa...@gmail.com]

Coming from a more obejct oriented UI development approach (XAML, Android, ...)  I have suffered great pains with web development, both as the architect and as an implementer.

Currently I am re-architecting an old VB6 two-tiered (large) business application.
The basic plan is to have a set of HTML 5 Single Page Applications interacting with ASP.NET WebApi.

We already completed a project using jQuery, jQuery UI and kncockout.js, but again it was painful for all the reasons that web components are designed to solve.
Therefore I am looking at Web Components / Polymer with great hope, but I can't really sell an approach internally that is in a pre-alpha stage.

So, finally, my question: At what point will it become "reasonable" to start serious commercial development with Polymer?
Is there a rough time-line? Weeks? Months? Years?

Karl

[Alex Komoroske]

On Thu, Jan 16, 2014 at 7:43 AM, <kwa...@gmail.com> wrote:

Coming from a more obejct oriented UI development approach (XAML, Android, ...)  I have suffered great pains with web development, both as the architect and as an implementer.

Currently I am re-architecting an old VB6 two-tiered (large) business application.
The basic plan is to have a set of HTML 5 Single Page Applications interacting with ASP.NET WebApi.

We already completed a project using jQuery, jQuery UI and kncockout.js, but again it was painful for all the reasons that web components are designed to solve.
Therefore I am looking at Web Components / Polymer with great hope, but I can't really sell an approach internally that is in a pre-alpha stage.

The pre-alpha label looks pretty ridiculous at this stage. It was our way of communicating "use at your own risk" when we talked about this at Google I/O last year. Since then, the risk has decreased substantially--many folks have used Polymer productively, and we're very happy with how Polymer has matured--but the label hasn't changed. We hope to change it soon to reflect reality better.

So, finally, my question: At what point will it become "reasonable" to start serious commercial development with Polymer?

Ultimately, the label is just a label (we could have chosen to call the current version of Polymer 1.0 if we wanted, after all) and it's up to each individual or company to make the call for themselves. (Obviously I understand that the label can make it harder to convince other people in the organization of the readiness).

For what it's worth, a number of folks have been using Polymer for real things despite its pre-alpha label and had success. As an example, the Globe visualization for Google's 2013 Zeitgeist was implemented with Polymer, and Salesforce built some really cool stuff with Polymer.

Is there a rough time-line? Weeks? Months? Years?

Work is progressing at a very fast pace in Blink to ship HTML Imports, Shadow DOM, and Custom Elements in the next few months. Custom Elements, for example, is on track to ship in the next version of Chrome stable. Once those technologies ship, it will give me, personally, a lot more confidence.

Hope this helps.

Karl

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.

[Bobby Powers]

Hello,

Alex Komoroske wrote:
> Work is progressing at a very fast pace in Blink to ship HTML Imports,
> Shadow DOM, and Custom Elements in the next few months. Custom Elements, for
> example, is on track to ship in the next version of Chrome stable. Once
> those technologies ship, it will give me, personally, a lot more confidence.

It is great to hear that the timeframe for shipping/enabling HTML
Imports, Shadow DOM and Custom Elements in Chrome is on the order of
months rather than a year+.

yours,
Bobby

[Jan Miksovsky]

I've run into this question several times recently when trying to convince various clients to use web components and Polymer. The issue is that most businesses considering depending on a platform for real business use will need a more substantial commitment than, "Use it when you feel it's ready." People want to know when *Google* thinks it's ready for business use. (While the examples of Polymer apps out there are interesting, AFAIK, no one's bottom line currently depends on Polymer.) As you suggest, few dev leads/CTOs are going to be able to justify why they're using something that says "pre-alpha" and version 0.1.2.

Alex: I think it'd be great if Google could shoot for announcing that Polymer has reached 1.0 at Google I/O this year. Or, if not then, then to at least publish a roadmap to 1.0. That would be a huge help in promoting this to clients.

[Alex Komoroske]

On Thu, Jan 16, 2014 at 5:01 PM, Jan Miksovsky <j...@quickui.org> wrote:

I've run into this question several times recently when trying to convince various clients to use web components and Polymer. The issue is that most businesses considering depending on a platform for real business use will need a more substantial commitment than, "Use it when you feel it's ready." People want to know when *Google* thinks it's ready for business use. (While the examples of Polymer apps out there are interesting, AFAIK, no one's bottom line currently depends on Polymer.) As you suggest, few dev leads/CTOs are going to be able to justify why they're using something that says "pre-alpha" and version 0.1.2.

Yup, I understand. 

Alex: I think it'd be great if Google could shoot for announcing that Polymer has reached 1.0 at Google I/O this year. Or, if not then, then to at least publish a roadmap to 1.0. That would be a huge help in promoting this to clients.

I spend a lot of time thinking carefully about this kind of thing. :-) 

[Jan Miksovsky]

Alex: I think it'd be great if Google could shoot for announcing that Polymer has reached 1.0 at Google I/O this year. Or, if not then, then to at least publish a roadmap to 1.0. That would be a huge help in promoting this to clients.

I spend a lot of time thinking carefully about this kind of thing. :-) 

No doubt! I'm only trying to help reinforce the message that outside parties are eager to promote web components and Polymer, and that a 1.0 version number will make that much easier. Thanks for listening!

[kwa...@gmail.com]

This is well stated - could not agree more.

But in all fairness to Google, it is also hard to label Polymer as version 1.0 when the underlying web standards are not yet final, a process over which Google does not have sole control.

Karl

[Alex Komoroske]

I just realized that my answer could have come across at flippant, which was not my intention. One of the things that excites me most about Polymer (and web components in general) is how folks from the community--like you!--have taken such an active role in evangelizing to developers. As always, your analysis and insight are very valuable.

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/7886e7bd-9990-4887-ae43-896edced9d7c%40googlegroups.com.

[Jan Miksovsky]

Alex: No flippancy heard on this end. You guys are doing great at encouraging and listening to community feedback.

I did want to follow up on Karl's point about the underlying web standards not being finished. Given Polymer's specific mission, I argue that it's in the industry's best interests for the completion state of those standards to not be a criteria for defining a Polymer 1.0 milestone.

As I see it, Polymer's reason for existence is to provide a "browser of the future". I think I've heard Google use some characterization like that in the past. By adopting Polymer, I can pretend that all of my users are running a browser that doesn't exist yet. That virtual browser implements standards that are so new, no native implementation exists. And, in some cases, the standards themselves are still being revised and debated.

The clever thing about the way Polymer's been defined is that it's a general purpose strategy for tackling any new polyfillable web technology, not just web components. The Pointer Events and Web Animations specs, for example, don't seem like critical pieces of an initial web components platform; they're simply new interesting web technologies that can be polyfilled the same way. It seems reasonable to conclude that more technologies will be proposed in the future which can be polyfilled that way too. That is, Polymer will always include features based on specs that have not yet closed.

So I'm hoping an approach to versioning Polymer will accommodate the fact that it polyfills support for specs that have not yet closed. I think it's fine for there to be some Polymer version/spec matrix that indicates: "Polymer version N implements this set of specs, which are in the following states. Polymer N+1 implements this larger set of specs; some more are closed, the newest specs are still being worked on."

I think there's another concession that needs to be made in defining versions for Polymer, which is limiting the guarantee of support for all future releases of the supported browsers. Often a 1.0+ version number implies indefinite customer support and bug fixing on behalf of the product creator. Given the nature of Polymer, I think such an expectation may be unfair.

Suppose Polymer version 1.0 supports IE 10/11. Perhaps that version also works on IE 12, but let's imagine something lands in IE 13 that breaks Polymer 1.0 sites. I think it's acceptable to tell the Polymer 1.0 site that they need to upgrade the (two year-old) version of Polymer they're using. In other words, the support bargain between Polymer and the site using it could be: "If you want to exist in the world of auto-upgrade browsers, you yourself may occasionally need to upgrade your code." I think many small sites get written and then essentially left alone in perpetuity. If those sites want some guarantee they will work forever, they should wait for native implementations in all mainstream browsers. The browser manufacturers are generally very careful to avoid breaking old code. But the Polymer collective shouldn't be responsible for guaranteeing indefinite compatibility, because the ground can shift underneath them. If an organization is willing to invest in keeping their site up to date, then should feel comfortable using Polymer. The converse is also true: a organization that is unwilling to keep their site up to date should not use Polymer.

In short, I'd be willing to accept a Polymer 1.0 that include provisos: "Polymer 1.0 includes support for the following standards as of this date, which are in the following stages of completion. Polymer 1.0 works on the following specific browser versions today. It is designed to work on those browsers as they auto-upgrade, but there exists a possibility that a future browser release may break code depending on Polymer 1.0, and require you to upgrade the version of Polymer you are using."

[Alex Komoroske]

Sorry for the delay in responding. I don't have anything in particular to say to your email, other than that it is insightful and gives me a lot to mull over. Thanks for sharing!

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/15033339-d8e0-40b6-8ee8-f9fdc749b867%40googlegroups.com.