As far as keeping web_ui package stable, it's definitely something we're keeping an eye on. When I've forgotten about implications for the web_ui codebase, Siggi always remembers and keeps me honest ;-)
In terms of feature parity with web_ui, I'd say it's in really good shape now, thanks to Terry landing scoped styles :)
Of the top of my head the only things that are missing compared to web_ui:
I wanted to follow up on this with a question. Where does Polymer stand now with feature parity with web_ui? I love seeing work on it steaming ahead and I think this change will make keeping Polymer up-to-date with changes in dart:html and other internal changes we don't see and just take for granted. However I have a comfortable sized project already in production that's written with web_ui. And I'm concerned that moving Polymer into the svn, will also delay, or even just leave forgotten, any related web_ui changes that may be needed.
I knew that soon I would have to change this to polymer and I don't mind that. One of the factors that's been holding me back from doing so is that we didn't have feature parity between the two, and 2, the documentation. I can now get around point 2 with the great examples that Seth has been working on. But I'm concerned about starting if point 1 hasn't been reached yet. I would rather not have to implement a bunch of work-arounds to get by until they are implemented and go back and patch them properly.
If we're not quite at point 1 yet, should I be concerned about web_ui not being maintained until that transition period is reached.
Any advise for a concerned, but enthusiastic, developer?
On Tuesday, August 20, 2013 12:45:52 AM UTC-3, John Messerly wrote:
You've probably been burned by Pub version mismatches at one point or another. It's that frustrating "the packages are broken" feeling that happens far too often.
Here's what we're doing about it: polymer.dart source code and its dependencies are moving to "dart/pkg". That's the same place where many other Dart packages live (such as args, serialization, unitttest, and yaml, just to name a few). The upshot is we get testing on the Dart buildbots, which means more browser coverage and no more releasing Editor/SDKs without the corresponding packages working.