Please integrate Polymer Elements in Dart as first class citizens of the Dart framework

[DartBot]

This issue was originally filed by @Emasoft

---

With the recents developments that have seen the Polymer Elements deprecated (see: https://code.google.com/p/dart/issues/detail?id=19192 and http://japhr.blogspot.it/2014/06/polymer-elements-in-dart.html and http://japhr.blogspot.it/2014/06/polymerdart-best-in-javascript.html and https://github.com/bwu-dart/polymer_elements ) it's time to think about a native Polymer Elements class for Dart, easier to use and more performant than the javascript equivalent.
Dropping support for Dart Polymer Elements and use only PE written in Javascript is a failure for the Dart language. The future of the web is made of custom polymer elements, and if you can create those elements in Dart, then the Dart language is doomed to fail.

PROPOSAL: Write a dart:polymer library and add it to the standard dart framework. This library should have all the classes needed to write custom Polymer Elements in Dart. For example the user should be able to write:

import 'dart:html';
import 'dart:polymer';

@CustomTag('MyCustomPolymerElement')
class MyCustomPolymerElement extends PolymerElement {

    MyCustomPolymerElement.created() : super.created()
    {
       //Default constructor initialization code
    }

    @­override
    void enteredView() {
             super.enteredView();
         //...code...
    }

    //...code...
 
 }

The library should not be only a port of the https://github.com/bwu-dart/polymer_elements project, but it should integrate and improve the original Polymer with the features of the Dart framework (streams, futures, automated bindings, ajax asynch, strongly typed parameters and methods, svg loading and manipulation, error management, observables and basic events, css styling, management of z-ordering, multiple nested elements, hit-boxes, hovering events for group of multiple elements, automated localizations and translation of all textual elements and strings from external text files if presents, automated element id unique hash key generation and local storage parameters saved for each polymer object, etc. all those features should be already implemented and ready to use or override/extend from the basic polymer class).
A dart polymer element should just work, being simply instanciated with "new MyCustomPolymerElement()" and then added to the dom.

Please do this ASAP. Without such native Dart library many developers will be forced to choose javascript over Dart, because in the web of the future everything will be built as a polymer element. Make those first class citizens of the Dart language, and build the Dart framework around it. Otherwise this will be a serious blow for Dart.

[DartBot]

This comment was originally written by @zoechi

---

Which points exactly are you actually missing? This is mostly how it is currently.

[iposva-google]

Added Pkg-Polymer, Triaged labels.

[DartBot]

This comment was originally written by @Emasoft

---

What is missing from the current Polymer support is the most important part of the polymer framework, the polymer.core libraries:

dart:polymer.core.*

All the polymer.core.* classes must be written natively in dart and integrated as first class citizens in the framework. As you said in another post (I quote):

"(..) It is not planned to develop the JS core-elements (was polymer-elements, polymer-ui-elements) twice (1x JS and a second time in Dart - not porting them to Dart) but instead make the JS elements work in Dart to avoid duplicate work. (..)"

But here is the point: a native polymer.core library of elements is not "duplicate work", because Dart compiles NATIVELY in browsers suppoting it, and it is up to 4x times faster than javascript. Because the web of the future will be only made of polymer elements or or from custom elements derived/extended from those, this would mean that if the core elements will be only in Javascript, then the entire web will be written in javascript, and Dart would have no traction at all when the Dart VM will be included in the mainstream Chrome browser.
If the polymer.core classes are written natively in javascript instead, when the Chrome browser with the Dart VM will be finally shipped, all the users will see a huge jump in performances on the same websites, and Chrome will quickly become the fastest browser around. Then all the other browsers will be forced to support the Dart VM to avoid being considered slower.

Also a native Dart codebase means that you can enjoy the advanced debugging features of the Dart VM on Chromium. If all projects would be only transformed in a Dart wrapper around the JS Polymer, the debugging features offered by Dart will become useless. In other words: using Dart will be more an hindrance than a help. Switching back and forth from javascript code to dart code to develop a web application polymer based is a debugging nightmare that nobody wants, because it will overcomplicate things. Every Dart developer will go back to javascript, maybe with the help of syntactic sugar like Typescript.
For Dart giving up on the Polymer core code would be the end of it. Please stop following this suicidal route and start fighting hard on making Polymer a first class citizen of the Dart framework.

[sigmundch]

Thanks for your comments and suggestions!

You have several requests combined in this bug, so I decided to closed this bug and split it into a few smaller bugs based on your comments. That way we can associate each bug with an actionable item and keep track of progress. If there is something I missed, let us know or open a bug for it.

Write a dart:polymer library and add it to the standard dart framework.

I believe using a package instead of a "dart:" library is better here. Some generic features used in polymer do make sense to have them in core libraries. That's why we have things like ShadowDOM and custom elements as part of dart:html.

However, the rest of polymer is still changing, so it is great to be able to use package versioning to help our users have control of when they update their code. If we were to put it as a 'dart:' library, we would either have to freeze the API or break people when they update their SDK, we want to avoid both of these.

a native polymer.core library of elements is not "duplicate work", because Dart compiles NATIVELY in browsers suppoting it, and it is up to 4x times faster than javascript.

It's possible that some elements could really use a port in Dart because they are in the bottleneck of an application, but I'm sure there are many elements for which it won't matter. I created issue #19743, so we make sure to start measuring this and decide objectively what we need to do.

Also a native Dart codebase means that you can enjoy the advanced debugging features of the Dart VM on Chromium

I think having a good debugging story is a great thing to have. I don't believe you must write everything in Dart to have a good debugging story, though. I created issue #19744 to track this.

---

Added Done label.

[DartBot]

This issue has been moved to dart-archive/polymer-dart#203.