Angular and Polymer, having second thoughts

[SwarmShepherd]

Hi All,

I've been busy at work full time again in Dart for a few weeks.  Not my first go at Dart, but the 6mo project was core + statistics/graphics and not much UI.  

Brief note on the project below.

After spending weeks reviewing various "stacks" I went "short" :) again with Dart and grabbed at Polymer more or less because I don't relate to the big

MVC frameworks, and polymer made sense - as far as the simple examples that are out there.  

Just now I was reading an announcement of progress on Angular-Dart (trying to keep up) and decided to check out the GitHub depositories for these

projects:

ANGULAR

 4,371 commits

 6 branches

 72 releases

 667 contributors

 

 

POLYMER

 1,249 commits

 9 branches

 18 releases

 17 contributors

I don't want to read too much into this, nor do I wish to ignore 'writing on the wall' '(if there is any).

What I'd really appreciate is, from the Dart near and longer term perspectives what relative resources are at work to complete and add features.  

Again, my feeling, based on a really not very in-depth review, was that Angular might be more likely to go head to head with "Rails" / Enterprise 

kind of stuff, whereas  Polymer has more of a "here are the basic pieces - if you are know and use good OO practices you can do "anything".

Would that be "fair" to both projects/approaches?

And finally, has Google dedicated some resources to the Polymer project?  I mean like 3-4 guys working on this stuff most every day, or has the

Polymer project, perhaps, had a few 3 party sponsors that have since gone on with other things?  Another words, is Polymer entirely alive and well

in the hearts of my fellow Dartonians?  The examples really provided a great start, but they were very basic, and haven't been updated or expanded

much in the last 3 months...  

Comments?

Thanks,

_swarmii

*Notes on the project: The current UI project is small'ish but 'very ajaxy',  in that there all kinds of updates occurring as the user selects from some 6 different Selection/Option 

components (3 of 6 listBoxes with a few custom features added).  (The project is a sort of  generalized "DataServer Navigator" and it hooks up to our dataservers that are

implemented in Ruby to do efficient CRUD.  WebSockets based.  Its rather a "distributed entry" application for now.)  

  

[Matthew Butler]

On Thursday, February 27, 2014 9:15:56 AM UTC-4, SwarmShepherd wrote:

Hi All,

I've been busy at work full time again in Dart for a few weeks.  Not my first go at Dart, but the 6mo project was core + statistics/graphics and not much UI.  

Brief note on the project below.

After spending weeks reviewing various "stacks" I went "short" :) again with Dart and grabbed at Polymer more or less because I don't relate to the big

MVC frameworks, and polymer made sense - as far as the simple examples that are out there.  

Just now I was reading an announcement of progress on Angular-Dart (trying to keep up) and decided to check out the GitHub depositories for these

projects:

ANGULAR

 4,371 commits

 6 branches

 72 releases

 667 contributors

 

 

POLYMER

 1,249 commits

 9 branches

 18 releases

 17 contributors

I don't want to read too much into this, nor do I wish to ignore 'writing on the wall' '(if there is any).

First I'll mention you looked at the JavaScript versions of each project, not the Dart versions. Angular.Dart is here:
https://github.com/angular/angular.dart

967 commits

7 branches

12 releases

39 contributors.

I can't provide the same type of details with Polymer Dart however has those sources are actually integrated directly with the Dart sources. (https://code.google.com/p/dart/source/browse/#svn%2Fbranches%2Fbleeding_edge%2Fdart%2Fpkg%2Fpolymer)

But again as you say you can't really read too much into the commits on either because not only are there the main packages but also many supporting packages. Take Polymer.dart for instance. It also includes: web_components, shadowDom, polymer_expressions, observe. And those are just the direct ones, there's also html5lib, smoke, source_maps and more that are actively maintained and contributed to by the same devs that are working on the Polymer packages.

What I'd really appreciate is, from the Dart near and longer term perspectives what relative resources are at work to complete and add features.  

Again, my feeling, based on a really not very in-depth review, was that Angular might be more likely to go head to head with "Rails" / Enterprise 

kind of stuff, whereas  Polymer has more of a "here are the basic pieces - if you are know and use good OO practices you can do "anything".

Would that be "fair" to both projects/approaches?

Pretty close yes. Angular is an MVC framework. It has a 'light' version of web-components which uses shadow dom, but not much more beyond that in terms of web-components. It also provides controllers, directives, views, etc.  Polymer is designed to bring the full glory of future web-components to browsers today. It's a 'full' version of the components found in Angular and the related polyfills. Angular components can only be used in angular projects. Polymer components can (eventually) be used everywhere, but for instance can be used currently in Angular projects as well. (I had heard rumours/talk of eventually replacing Angular components with full Polymer components in the Angular framework but I've not seen anything concrete in that area).

And finally, has Google dedicated some resources to the Polymer project?  I mean like 3-4 guys working on this stuff most every day, or has the

Polymer project, perhaps, had a few 3 party sponsors that have since gone on with other things?  Another words, is Polymer entirely alive and well

in the hearts of my fellow Dartonians?  The examples really provided a great start, but they were very basic, and haven't been updated or expanded

much in the last 3 months...  

I know of at least 2 Google devs who commit regularly (daily?) to Polymer or its related packages. That's not to say that there are not others who are working in the background who aren't doing the committing, just the ones I've seen showing up here: https://code.google.com/p/dart/source/list 

Comments?

Both Angular and Polymer projects are alive and kicking and around for some time. In the (hopefully not-too-distant) future, when web-components are natively supported by all by all browsers, Polymer may no longer be needed (though i'm sure as we get to that point, there will be more new and exciting technologies it may be polyfilling for us instead). Angular is a very robust MVC framework that helps encourage project organization with more than just elements, but still remaining declarative on html (directives, controllers). Angular integrates well with Polymer components you may have already created and helps to structure the rest of your app logic to help encourage good encapsulation between your polymer elements and the main structure for the app. 

 

Thanks,

_swarmii

*Notes on the project: The current UI project is small'ish but 'very ajaxy',  in that there all kinds of updates occurring as the user selects from some 6 different Selection/Option 

components (3 of 6 listBoxes with a few custom features added).  (The project is a sort of  generalized "DataServer Navigator" and it hooks up to our dataservers that are

implemented in Ruby to do efficient CRUD.  WebSockets based.  Its rather a "distributed entry" application for now.)  

  

Matt 

[曹忠]

Shit! my project follow polymer, please do not come and go, switch to web_ui,  switch to polymer,  switch to angular, switch to ..., shit!

在 2014年2月27日星期四UTC+8下午9时15分56秒，SwarmShepherd写道：

[Justin Fagnani]

Polymer will be around for a long, long time. The web standards that it builds upon are already landing in Chrome and Firefox. It's one of the most future-proof options you can choose right now.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[George Moschovitis]

switch to web_ui,  switch to polymer,  switch to angular, switch to ..., shit!

There is some truth in this...

[Matthew Butler]

On Thursday, February 27, 2014 3:03:15 PM UTC-4, George Moschovitis wrote:

switch to web_ui,  switch to polymer,  switch to angular, switch to ..., shit!

There is some truth in this...

There's limited truth to it. To my knowledge web_ui is still being supported just not seeing new versions. Polymer is web_ui >= 0.5.0. It was also changed to a new package to more closely mirror the functionality of the Polymer.js port. 

Beyond that, Polymer can still continue be used, even if you're using angular, or whatever the next MV* framework comes out. That's the whole point of Polymer elements. to be reusable everywhere. not just with a Polymer application. (The same cannot be said for angular/angular components).

[Alex Tatumizer]

Can someone answer a simple question?
I want to write web app in dart. I don't want to write a single line of html or css by hand. Reusable components in programming are: libraries and classes.
Can polymer help in that? Can I find menus, grids, etc as classes to be instantiated in dart proper? Is there any example of purely programmatic operation with polymer?
And after looking at angular, I'm not interested at all. It's entire new clunky language embedded in another language and then in yet another language. It may appeal to somebody, especially if properly advertised, but I'm sure there will be A LOT of people who want to write the whole thing in dart proper, without going through this tower of Babel.

[Bob Nystrom]

On Thu, Feb 27, 2014 at 1:19 PM, Alex Tatumizer <tatu...@gmail.com> wrote:

I want to write web app in dart. I don't want to write a single line of html or css by hand. Reusable components in programming are: libraries and classes.
Can polymer help in that? Can I find menus, grids, etc as classes to be instantiated in dart proper? Is there any example of purely programmatic operation with polymer?

I'm not a polymer expert by any means, but my understanding is, no, Polymer doesn't cover your use case. The folks behind Polymer are strongly in favor of declarative languages. They want you to write less code and more HTML and CSS.

Cheers,

- bob

[Alex Tatumizer]

EVEN MORE HTML AND CSS?

Oh my...

[John Messerly]

Couldn't have said that better :) Yeah, web_ui was just our code name until "Polymer" got its real name. And because it's just a bunch of elements, it should work in your framework of choice. 

That's a correct assessment of the Polymer team's opinions, however their actual elements can be created from code, e.g. " var grid = new PolymerGridLayout();" ... I'm not sure it's the best way to build up a DOM tree, but it's possible. (The main issue right now in Dart is we don't have all of the elements available yet.)

[Alex Tatumizer]

Every declarative language sooner or later (rather sooner) hits the wall, upon which the decision has to be made: either to cease to exist, or become Turing-complete language.

Who wants to cease to exist? Naturally, everyone moves towards Turing-completeness. one feature at a time. It's a bottomless pit.

.

The whole effort is driven by illusion that declarative language is more accessible for non-programmer. It's not. Non-programmer will hit the wall, too, soon after "hello world"", and will face a similar choice:

either to give up, or to become a programmer.. 

I had very bad recollections of one contract gig I had, the project started by non-programmers (or I don't know whom) using certain declarative (graphical!) language, which was impossible to maintain after hitting complexity wall.

Just hated myself for doing this, despite good pay and everything... You can't believe what happens outside of your ivory tower guys.

Create good programmatic API and library of reusable components - people will happily use it without depending on endless stream of new "frameworks", all doomed to begin with.

[Arron Washington]

I am officially fascinated.

Back in the day I used C / C# / Java / "write your GUI in code" languages and HTML + CSS (or QML, or GTK's Glade, or XAML) is like the Taj Mahal in comparison. Most of my colleagues agree with me, and since I'm seeing a lot more of node-webkit based applications floating around, my take is that it's a pretty popular position.

This is the first time I've ever seen someone yearn to craft their UI in code. Can you share in what way you find it to be superior? What was it about the declarative language you used in the past that became frustrating and cumbersome?

[Alex Tatumizer]

Arron, do you read it on your gmail?

OK, Right mouse click -> View Page source.

Please come back and report your findings :-)

But if you are reading it on mailing list - even better! Same operation with mouse, and view page source. 

The infinitesimal amount of html markup they have is just a way to bootstrap, there's no real content there. And this small amount could  be written in HTML, or generated completely, with the same number of lines - it doesn't matter. The whole thing is purely programmatic endeavor.

[Günter Zöchbauer]

I have not used it myself, but what I have seen http://dartwebtoolkit.com/ uses only (mostly?) Dart code to build the UI. 

[Alex Tatumizer]

Gunter, thanks for the link!

I have to dig deeper, but it might be something I am looking for.

I google-searched for old threads, and really found it mentioned only a couple of times, very briefly. 

If someone used it, please share your experiences.

Thanks again.

[George Moschovitis]

Every declarative language sooner or later (rather sooner) hits the wall, upon which the decision has to be made: either to cease to exist, or become Turing-complete language.

Who wants to cease to exist? Naturally, everyone moves towards Turing-completeness. one feature at a time. It's a bottomless pit.

.

The whole effort is driven by illusion that declarative language is more accessible for non-programmer. It's not. Non-programmer will hit the wall, too, soon after "hello world"", and will face a similar choice:

either to give up, or to become a programmer.. 

I had very bad recollections of one contract gig I had, the project started by non-programmers (or I don't know whom) using certain declarative (graphical!) language, which was impossible to maintain after hitting complexity wall.

Just hated myself for doing this, despite good pay and everything... You can't believe what happens outside of your ivory tower guys.

Create good programmatic API and library of reusable components - people will happily use it without depending on endless stream of new "frameworks", all doomed to begin with.

+1 

I would like to have both a programmatic way and a declarative way to build the UI. Polymer, more or less, does that, I guess we need to wait till it gets out of alpha.

Angular looks too opinionated/magic to me.

[George Koller]

Thanks Matt and all others,

I'm studying every word, chasing down links, and reshuffling my thinking even as my little project is gaining a bit of a what I consider "proper" structure.

As a old hand at OO I feel down deep that:

     Give me "real" objects,  and I can get "real" a real project done (one way or another).  

So I'm busy (and happy) digging down into my trusted bag of "OO" tricks,  and I think things are coming along ok,  if slowly.  Re-exposure to HTML+CSS has re-convinced me that even OO hell is better than that hopeless quagmire of issues - IF one needs to go much beyond the basics.  

Right now I've been able to implement:

1.  An essentially static class where all the current/selected elements have been collected.  So I can have some central logic in the form of nice clean logical getters on the info collected here.

2. A nice "DataServer" class that handles all "transport" issues in one place, features one method for custom handling per component.  (Same names so could be made automatic with some "Smoke and Mirrors",  if I really wanted to.  Smells like another framework in the making?)

3. A "AppElement" which contains methods common to the components, maybe more before this is done, but right now reduced to almost empty...

4.  A rather nice and evolving "tracing system" that lets me view, among other things,  the multiple stages of a    request/response  encode to decode and all between. It can fail anywhere as this is still rather immature code.

Its a work in progress but I'm feeling pretty good about it.

  

BTW my last little har-pulling impasse related to the difference between:

somePublishedList = [];             AND      somePublishedList.clear;

Sloppy! Sloppy!   

So I wanted "real Objects", and the above little experience reflects on whether we are really ready for them?

Bring 'em on, I say!   :)

Thanks again,

_george  

[Frank Pepermans]

We're building an enterprise Dart app,

Back when it started, web_ui was still in its infancy, and Polymer didn't exist,

I then quickly built a small UI framework resembling (now Apache) Flex.

We use it now for our project without and I still update regularly.

Don't expect too much, I needed something to work with at the time :

http://www.igindo.com/dart/dartflex/dart_flex_example.html

https://github.com/frankpepermans/dart_flex/tree/master/lib

On 28 February 2014 08:38, George Moschovitis <george.mo...@gmail.com> wrote:

Every declarative language sooner or later (rather sooner) hits the wall, upon which the decision has to be made: either to cease to exist, or become Turing-complete language.

Who wants to cease to exist? Naturally, everyone moves towards Turing-completeness. one feature at a time. It's a bottomless pit.

.

The whole effort is driven by illusion that declarative language is more accessible for non-programmer. It's not. Non-programmer will hit the wall, too, soon after "hello world"", and will face a similar choice:

either to give up, or to become a programmer.. 

I had very bad recollections of one contract gig I had, the project started by non-programmers (or I don't know whom) using certain declarative (graphical!) language, which was impossible to maintain after hitting complexity wall.

Just hated myself for doing this, despite good pay and everything... You can't believe what happens outside of your ivory tower guys.

Create good programmatic API and library of reusable components - people will happily use it without depending on endless stream of new "frameworks", all doomed to begin with.

+1 

--

For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[曹忠]

Dart and polymer.dart very great, but we need to just work, do not let us fall into a large bug inside.

You know our project now have over 100 + polymer components, our team has invested a year of time, we have no way out but to follow polymer forward.

在 2014年2月27日星期四UTC+8下午9时15分56秒，SwarmShepherd写道：

[calathus]

Alex,

I have a similar feeling about some recent trends using separate html(xml) file for GUI specification.

they end up mixing layout information with procedural action codes.

For instance I investigated Apache pivot which is using BXML, and it seemed following approach of other project/product.

Since Dart is much more declarative language, and provide good notation of "..' , it is possible to define with similar amount of code as HTML, it become less persuasive in Dart than in other more verbose language.

The main advantage of using code rather than template will be to make it more composable (not like using template). 

But there are a few obstacles to write more declarative GUI code in Dart(or some other language like Java).

For instance, it is ideal if we can define fields with some GUI related annotations(like JPA, JAXB) rather than separating field declaration and the initialization of the fields in the constructor.

One way to achieve this is using mirror library and annotation. I wrote some blog for this approach:

http://dartathus.blogspot.com/2013/10/lazy-initialization-og-gui-components.html

http://dartathus.blogspot.com/search/label/GUI-Design

In general, I tried to develop generic webkit lib which has such a goal before.

http://dartathus.blogspot.com/2013/10/github-reflective-web-dev-kit.html

I actually stopped developing them since Dart reflection(which is base of the approach), was shaky, namely the API changed incompatible ways and there were many significant bugs at that time, and Mirror was not usable in JS mode. it was about 4 month ago.

But I know some of issues seems fixed, and it may be more stable. So I may start working on this again..

On Thu, Feb 27, 2014 at 6:18 PM, Alex Tatumizer <tatu...@gmail.com> wrote:

Every declarative language sooner or later (rather sooner) hits the wall, upon which the decision has to be made: either to cease to exist, or become Turing-complete language.

Who wants to cease to exist? Naturally, everyone moves towards Turing-completeness. one feature at a time. It's a bottomless pit.

.

The whole effort is driven my illusion that declarative language is more accessible for non-programmer. It's not. Non-programmer will hit the wall, too, soon after "hello world"", and will face a similar choice:

either to give up, or to become a programmer.. 

I had very bad recollections of one contract gig I had, the project started by non-programmers (or I don't know whom) using certain declarative (graphical!) language, which was impossible to maintain after hitting complexity wall.

Just hated myself for doing this, despite good pay and everything... You can't believe what happens outside of your ivory tower guys.

Create good programmatic API and library of reusable components - people will happily use it without depending on endless stream of new "frameworks", all doomed to begin with.

--

For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--
Cheers,
calathus

[Alex Tatumizer]

Since Dart is much more declarative language, and provide good notation of "..' , it is possible to define with similar amount of code as HTML, it become less persuasive in Dart than in other more verbose language.

The main advantage of using code rather than template will be to make it more composable (not like using template).

Yes, this is exactly how I feel about it, too. You can say new Element.div()..text="hello"..onClick.listen(()=>...) - how it can be BETTER? What are you missing here to the extent you would want to go through several wormholes through several languages, jump from one screen in editor to another and yet another, etc just to not write this line?

I don't understand it, but I'm not against anything: let all flowers blossom, it's just I want to use programmatic style, that's all.

BTW, I'm using annotations and reflection in another project, and every feature of reflection I need, except findInContext(which I actually don't need as much), works lately in dart proper. I'm not sure about javascript though.

The problem is to develop good library of widgets, which the guy from dartwebtoolkit apparently done (I don't know to which extent), but there's not much activity on that project lately. There's, of course, a room for other competing libraries, it would be even better to have a choice.

[Günter Zöchbauer]

Sergey who ported from GWT to DartGWT is now working on porting Dart UI to AngularDart UI ;-)

Mit freundlichen Grüßen

Günter Zöchbauer
gue...@gzoechbauer.com
+43 (699) 10 18 87 15

[Alex Tatumizer]

Let's look at it positively: he is helping another flower to blossom :-)

[calathus]

>BTW, I'm using annotations and reflection in another project, and every feature of reflection I need, except findInContext(which I actually don't need as much), works lately in dart proper. I'm not sure about javascript though.

Mirror worked on DartVM even 4 month ago.

but using dart2js, and run the application on javascript mode, if it uses mirror lib, it did not work.(but I think some may have worked, essentially Mirror support for JS was not complete. (Gilad confirmed this point at that time.))

So if your goal is running in browser, you may have ugly surprise. It is worth testing.

Actually I have not noticed any announcement of completion of Mirror support for JS, I'm still suspicious about it.

In fact, dart2js seems doing too much(unnecessary) thing than which is normally required for most of mirror usage. Namely we only need to access meta info for statically known classes, but such translation seems trying to support forName like dynamic loading of class, which make difficult to generate compact js codes. (anyway this is just my suspect). So what I want to have is  full support of mirror feature for the statically decidable Dart class in javascript mode.

(Anyway I also developed some library to support running reflection code in javascript mode)

It is true we need to have good widget library.

But my feeling is these library should have consistent programming style. so it would be necessary to integrate such widget library to follow certain style.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--
Cheers,
calathus

[Justin Fagnani]

That's why you go with Polymer - to get libraries of components that are actually compatible and play nice with HTML. It also give you choice in the declarative vs. imperative debate. As John noted Polymer can be used in a purely imperative way, from pure Dart-code, because the API for using Polymer element is just the same as the API for using HTML.

The most important thing that people should know about Polymer is that Polymer elements are just elements. Once you know that, then you can apply your knowledge of HTML, and tools that work with HTML, to Polymer.

Whether or not you care about the declarative vs. imperative debate, this is an amazing thing. If you want declarative markup, write an HTML template. If you're an imperativist, simply use the dart:html APIs. Your choice, and the two worlds are compatible. If you felt like writing a non-HTML template language that produces DOM, chance are that it'll work with custom elements too. Same with an alternative imperative DOM API. The only wrinkle that Polymer/custom elements introduces is that the set of tags is not fixed (so some libraries that provide a factory function for every element simply won't work in a custom element world).

The point is that you don't need to create another abstraction layer, which is always some UI framework's concept of a widget, above the DOM to get an imperative style. And creating that abstraction layer has a _massive_ downside: compatibility.

JavaScript is famous for have far too many incompatible frameworks, and this isn't just UI frameworks, it's basic stuff like defining classes, collections, and then of course widgets. Incompatible widgets is IMO the worst of these. With classes, maybe you can't inherit properly across implementations, maybe you can, but at least two objects produced by two different class implementations still behave like normal objects and can interact well with each other, but incompatible widgets are terrible: You can't even easily add a widget from one framework to another. Take a look at GWT/DWT's container classes. They define: void add(Widget w). Want to add a widget from Frank Pepperman's library? Tough. Or you can wrap it.

But it gets worse. Any UI framework that works by wrapping severely breaks down when you start interacting with its DOM. Let's say you create a bunch of Buttons in DWT (I really don't mean to pick on DWT, I think it's great work, see below [1]) and you give them a class of "form-button". Button has a field called enabled, and you want to disable all the buttons for some reason. If you know some dart:html, you might think this is easy:

querySelectorAll('.form-button').forEach((b) { b.enabled = false; });

But that doesn't work, because what you actually get back from the query is a the DOM element ButtonElement, not the DWT Button wrapper for it. ButtonElement doesn't have an enabled property, and if it did you'd run the risk of putting the DOM and the wrapper out of sync by messing with the DOM. In fact, there's no way to go from element -> widget to get the wrapper objects so that you can use them. The best you can do is write a parallel set of DOM operations that work on the widget/wrapper hierarchy rather than the DOM hierarchy, so that you could do things like query widgets.

Custom elements (what Polymer produces) fix all that. When you access the DOM, you actually get the real objects you want back, not just some dumb DOM that's useless without its wrapper. If you want to access a property on a custom element, then querySelector(...).property will just work.

Or consider Angular (which I guess you wouldn't if you don't like declarative UI, but stay with me). I've see this question a bit: how could you use Angular with GWT widget? Well... you can't, at least easily. There's no way in an Angular template to write markup that produces GWT widgets. You'd have to write directives for every GWT widget you wanted to use, and even then I bet it'd be a major pain because you have to decide when you need to interact with the wrapper, vs the DOM. With custom elements you just write normal Angular templates and use the custom tags. It just works.

I don't think the significance of custom elements has sunk in very much around the web dev world. It's going to make all the wrapping UI frameworks completely obsolete, and you will get to the point where you have a plethora of compatible widget libraries to choose from. There's already a few in Dart (we should probably put a list up somewhere).

I hope that was helpful!

  -Justin

[1] DWT is actually an amazing achievement and is incredibly complete. It's perfect for an existing GWT project that wants to quickly port to Dart, maybe by also using the java2dart converter on their codebase. I've been hoping to find a team to try that out with.

[calathus]

Maybe 'statically decidable' was a bit vague. it will be still difficult to determine which class are to be used for mirror in the program.

then other approach will be to use annotation like  @MIRROR_JSCODE so that dart2js will only generate reflection codes for the classes  with this annotation.

 

--
Cheers,
calathus

[Alex Tatumizer]

Justin,

thanks for your response. Yes, it's helpful and informative. I'd like to see it implemented. One small thing that a bit worries me is that you didn't start from polished programmatic API and then create declarative layer on top of it (for those who like it), but you are going in reverse direction (I may be mistaken though). I know from experience that this kind of reverse direction may eventually work, too, but you may need more iterations, and as a result, the API can be not as good as it could be otherwise (just because it primarily serves the interests of declarative style). Again, I might be wrong. Still, If you ever have a minute (or an hour), please write something about purely programmatic operation with polymer. While writing this description, you might see wrinkles, and that might help you, too. Plus, it will provide material for discussion.

Right now, html API is very good, from what I saw. Great idea of returning streams for onClick and friends. And everything else looks clean. If you can make Polymer fit into this nicely, it will be great!

[Justin Fagnani]

On Fri, Feb 28, 2014 at 1:54 PM, Alex Tatumizer <tatu...@gmail.com> wrote:

Justin,

thanks for your response. Yes, it's helpful and informative. I'd like to see it implemented.

? It is: import 'package:polymer/polymer.dart';

 

One small thing that a bit worries me is that you didn't start from polished programmatic API and then create declarative layer on top of it (for those who like it), but you are going in reverse direction (I may be mistaken though).

No, there's both a pre-existing imperative API (dart:html) and pre-existing declarative syntax (HTML). It's not going in either direction, it's working from what's already there.

Custom elements and Polymer do add some small things on top of both to make custom elements easier, like lifecycle methods, and the template and binding syntax for HTML.

 

I know from experience that this kind of reverse direction may eventually work, too, but you may need more iterations, and as a result, the API can be not as good as it could be otherwise (just because it primarily serves the interests of declarative style). Again, I might be wrong. Still, If you ever have a minute (or an hour), please write something about purely programmatic operation with polymer.

Me and plenty of others around here could probably write blog posts on it, but there have been quite a few threads already. Mostly they were necessary when things weren't working as seamlessly as they should and you had to manually trigger lifecycle events. Now the blog post would be: just use dart:html. Seriously, your code example from up thread would be this with a Polymer element: new MyElement()..text="hello"..onClick.listen(()=>...) or even new Element.tag('my-element')..text="hello"..onClick.listen(()=>...). It all just works together.

 

While writing this description, you might see wrinkles, and that might help you, too. Plus, it will provide material for discussion.

I'm not designing Polymer, but that team thinks about these things a _lot_. They're not amateurs. You should try it and if you want join them at polym...@googlegroups.com

 

Right now, html API is very good, from what I saw. Great idea of returning streams for onClick and friends. And everything else looks clean. If you can make Polymer fit into this nicely, it will be great! 

Did you read me message? :) Using Polymer elements is just using HTML. It's the _same_ API.

Cheers,

  Justin

[Alex Tatumizer]

Justin, I looked into examples - you are building Turing-complete language.

      <template repeat="{{fruit in fruits}}">
        <li>
          I like {{ fruit }}.
        </li>
      </template>

Very bright people are very prone to creation of new languages. This is not to say it's bad - dart is a new language, too.

But for some reason, I feel sad looking at the above example. Can't even explain why. Let's move on guys. I'm sure polymer will become very popular and successful framework.

[Justin Fagnani]

I'm not getting though here some how.

The examples show the _creation_ of Polymer elements using the declarative syntax (this is what most people want).

You've been talking about _using_ widget libraries. Polymer widget libraries are just libraries of custom HTML elements. Their APIs are just HTML: elements, with properties, attributes and events. The code example that you gave earlier, which you claimed couldn't get any better, so I assume you like it, is the same with a Polymer element. If you want to use a Polymer element, you never need to touch or see the template binding syntax, just use the normal, imperative, dart:html APIs that you like.

What's not clear about that?

--

[Alex Tatumizer]

It's the same as saying that to use dart class, go ahead and use it; but if you want to define dart class, please write it in HTML, using <tags> and {{special language}}.

What makes html elements so special they warrant special syntax for definition? Is dart not powerful enough to cover this case? And why declarative approach is PRIMARY?

Probably, it's possible to create this class programmatically, I don't know, but all terminology will (probably) come from declarative syntax, including "template" element etc right?

I think this is a valid question, no?

Regarding "most people want it" - there's a famous quote:

If I'd asked customers what they wanted, they would have said "a faster horse".

(Attributed to H. Ford)

[Marcello Dias]

I might have got them wrong,but for me Angular is for very Dynamic web sites with more images than logic.Where the contents changes in a daily basis(B2C portals for instance).

Polymer gives you more control and is best suited for ERP/CRM development,and any other kind of development that will have  dozens,hundreds,thousands of components interacting with each other.

I think is like comparing Oranges to orange juice,since Angular will probably use polymer one day.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--

Marcello Dias

Gerente de T.I

Rua Olimpiadas, 194 - 2º/8º/9º/13º Andares
Vila Olímpia - São Paulo / SP - Brasil
Cep: 04551-000
Tel.: + 55 11 3028-9800
Fax: + 55 11 3028-9842
marcelo@brasfond.com.br
www.brasfond.com.br

[Gilad Bracha]

Perhaps I understand what Alex is trying to articulate. Projects like Polymer are forced to re-invent large sections of a general purpose programming language in the context of HTML in order to express what's needed. 

Specifically:

variables

{{count}}

conditionals

    <template if="{{count <= 0}}">
      <p>Click the button. It's fun!</p>
    </template>

loops

<template repeat="{{fruit in fruits}}">
        <li>
          I like {{ fruit }}.
        </li>
      </template>

imports

<head>
  <link rel="import"
    href="packages/fancy_button/fancy_button.html">
</head>

classes (aka custom tags)

inheritance

<polymer-element name="fancy-button" extends="button">

and even procedural abstraction. This is not aesthetically satisfying; a general purpose language does these things better. The use of HTML allegedly reduces the risks from imperative side effects (but your controllers will still do as they please).  Disciplined developers can define their view code in a functional style anyway however. If your controllers aren't functional as well, things aren't all that declarative anyway.

Ultimately the main thing is this is what most people expect right now. But fashions change.

--
Cheers, Gilad

[John Messerly]

On Fri, Feb 28, 2014 at 6:56 PM, Gilad Bracha <gbr...@google.com> wrote:

Perhaps I understand what Alex is trying to articulate. Projects like Polymer are forced to re-invent large sections of a general purpose programming language in the context of HTML in order to express what's needed. 

FWIW, I personally tend to sympathize with this sentiment. However it does seem pretty common to have a DSL for constructing views in UI systems (usually HTML or XML derived). Maybe the problem is that the base languages don't optimize enough for construction, or they don't make reactive programming easy enough to express. I'm not sure. It definitely seems like our attempts at encoding RP in Dart code were more verbose/complex compared to their equivalent HTML form.

 

Specifically:

variables

{{count}}

conditionals

    <template if="{{count <= 0}}">
      <p>Click the button. It's fun!</p>
    </template>

loops

<template repeat="{{fruit in fruits}}">
        <li>
          I like {{ fruit }}.
        </li>
      </template>

Clarification here: these aren't quite analogous to conditionals or loops. They respond to changes in the data and update what is displayed. It's more like reactive programming. That's where it gets the biggest value add over just writing a loop and a bunch of node.append calls to build the tree.

imports

<head>
  <link rel="import"
    href="packages/fancy_button/fancy_button.html">
</head>

classes (aka custom tags)

inheritance

<polymer-element name="fancy-button" extends="button">

Yeah, "extends" is unfortunate. The reasons for it are a bit subtle. The mapping from HTML tag to DOM type is many-to-one. So knowing the base class isn't enough by itself to know the HTML tag that is being extended. Even worse, because HTML parsers are quirky (thanks to implementation quirks in old browser, and now standardized) and the C++ DOM implementations are quirky, it is sometimes necessary to write a custom element like:

<select is="my-select">

  <!-- now the HTML parser can correctly parse this using the "select" parsing rules -->

  <option>...

</select>

Now if we could push a button wipe out all the legacy magically, we'd be free of all of these maddening constraints and could design something perfect**. But since that is unlikely, we try and make the best of the situation.

(** at least that's what people think going in: "This time we'll get everything right!" Occasionally it actually happens. ;) )

and even procedural abstraction. This is not aesthetically satisfying; a general purpose language does these things better. The use of HTML allegedly reduces the risks from imperative side effects (but your controllers will still do as they please).  Disciplined developers can define their view code in a functional style anyway however. If your controllers aren't functional as well, things aren't all that declarative anyway.

Ultimately the main thing is this is what most people expect right now. But fashions change.

--
Cheers, Gilad

--

[Justin Fagnani]

Yes, I understand this, but like you say, users demand it. They know how to write HTML, and they want some constructs to parameterize their HTML with.

What I'm saying is that you don't have to use that. It's just an option within Polymer, even if it's the most advertised option. And Polymer is only a helper for creating custom elements. All the APIs are still there to do everything from Dart. If you want to just write Dart code, and no HTML, you can.

My big point is that regardless of whether you like imperative or declarative styles, you should still go with custom element based widgets because of the major problems with the wrapping model. Don't choose DWT just because you want to avoid the template. You don't have to use Polymer, but it's helpful for some people.

For a pure Dart code example, here's a click-counting button custom element, with shadow DOM, using no templating and no Polymer:

import 'dart:html';

void main() {

  document.register('my-element', MyElement);

  document.body.children.add(new Element.tag('my-element'));

}

class MyElement extends HtmlElement {

  MyElement.created() : super.created() {

    var shadowRoot = this.createShadowRoot();

    var button = new ButtonElement()..text = '0';

    var clickCount = 0;

    button.onClick.listen((e) {

      button.text = '${++clickCount}';

    });

    shadowRoot.children.add(button);

  }

}

The HTML is nearly empty except the necessary script imports:

<!DOCTYPE html>

<html>

  <body>

    <script type="application/dart" src="custom.dart"></script>

    <script src="packages/custom_element/custom-elements.debug.js"></script>

    <script src="packages/browser/dart.js"></script>

  </body>

</html>

I don't know how to more clearly say that you don't need to use the declarative templating. Whether or not someone else element uses templating internally shouldn't be of much concern.

Cheers,

  Justin

--

[Alex Tatumizer]

Justin, thanks! This example (MyElement) is exactly what I wanted. to see, It's a nice code indeed.  

[calathus]

such reactive programming should not require special syntax in extended html.

I created a Monitor class which will do the similar thing.

http://dartathus.blogspot.com/2013/10/reflective-interceptor-monitor-in-dart.html

http://dartathus.blogspot.com/2013/10/here-is-code-using-monitor.html

http://dartathus.blogspot.com/2013/10/lazy-initialization-og-gui-components.html

At that time, I thought it is difficult to use Dart class ObservableMixin without using plymor html. But I a bit forgot the detail..

But in general, it will be better to provide some of feature without relying on 'declarative' or 'external' html file.

Also if we want to define generic 'element'(generic dart class creating some element), we cannot define such element in polymer.

I had same problem in Apache Pivot before. So if we want to develop generic class library, we need to directly use dart(java) code.

I think GUI developer are a bit special type of programmers who are not much concerned about generics, or type system. This may come from some historic reason for poor language support etc, but now Dart support generics, this possibility should be more investigated.

The real component based Web GUI should rely on generics based composition, not template.

(for instance, I developed CRUD generics library as an example before)

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--
Cheers,
calathus

[George Moschovitis]

import 'dart:html';

void main() {...

</html>

pretty nice!

[Alex Tatumizer]

> At that time, I thought it is difficult to use Dart class ObservableMixin without using plymor html. But I a bit forgot the detail..

> But in general, it will be better to provide some of feature without relying on 'declarative' or 'external' html file.

For reactive programming, one class is sorely missing in dart: EventBus.

This idea is widely used in electronics, and it's a good way to achieve loose coupling.

Components subscribe to bus events (not to other components directly!) and specify a filter for types (and sources?) of events they are interested in.

In which case you don't even need ObservableMixin, or annotations, or anything: just call eventBus.send(new MyVarSetEvent(...)) from setter explicitly.

Like in the case of html components, I would prefer explicit code over annotations (like @observable), code generation and other implicit methods.

Same idea of event bus idea also can be used to distribute the load across isolates: first isolate that "swallows" the event will do some computations,

and the caller will simply subscribe to response. 

Do other languages have this idea implemented on the core level? I don't know, my knowledge of "other languages" is limited.

[Allan MacDonald]

Not part of the core language, but there is this library I have used.

[Günter Zöchbauer]

Angular has this integrated in it's Scope. It also makes use of the scopes tree structure to allow to limit how far an event may reach (only children, entire tree, all children of the parent,...)

[Alex Tatumizer]

> Not part of the core language, but there is this library I have used.

Very good one! Thanks!

The problem is exactly that it's not in the core. So everyone will write it's own, with different APIs and features. Angular has another one, and Polymer maybe yet another one... 

And they can't talk to each other, which defeats the goal of event bus. Maybe we have to petition dart team for inclusion into core? It's a small lib, overall footprint won't suffer at all.

[曹忠]

Yes! is best suited for ERP/CRM development.

在 2014年3月1日星期六UTC+8上午10时40分24秒，Marcello Dias写道：

[曹忠]

Please keep work for polymer, that's great!

在 2014年2月27日星期四UTC+8下午9时15分56秒，SwarmShepherd写道：

Hi All,

I've been busy at work full time again in Dart for a few weeks.  Not my first go at Dart, but the 6mo project was core + statistics/graphics and not much UI.  

Brief note on the project below.

After spending weeks reviewing various "stacks" I went "short" :) again with Dart and grabbed at Polymer more or less because I don't relate to the big

MVC frameworks, and polymer made sense - as far as the simple examples that are out there.  

Just now I was reading an announcement of progress on Angular-Dart (trying to keep up) and decided to check out the GitHub depositories for these

projects:

ANGULAR

 4,371 commits

 6 branches

 72 releases

 667 contributors

 

 

POLYMER

 1,249 commits

 9 branches

 18 releases

 17 contributors

I don't want to read too much into this, nor do I wish to ignore 'writing on the wall' '(if there is any).

What I'd really appreciate is, from the Dart near and longer term perspectives what relative resources are at work to complete and add features.  

Again, my feeling, based on a really not very in-depth review, was that Angular might be more likely to go head to head with "Rails" / Enterprise 

kind of stuff, whereas  Polymer has more of a "here are the basic pieces - if you are know and use good OO practices you can do "anything".

Would that be "fair" to both projects/approaches?

And finally, has Google dedicated some resources to the Polymer project?  I mean like 3-4 guys working on this stuff most every day, or has the

Polymer project, perhaps, had a few 3 party sponsors that have since gone on with other things?  Another words, is Polymer entirely alive and well

in the hearts of my fellow Dartonians?  The examples really provided a great start, but they were very basic, and haven't been updated or expanded

much in the last 3 months...  

Comments?

Thanks,

_swarmii

*Notes on the project: The current UI project is small'ish but 'very ajaxy',  in that there all kinds of updates occurring as the user selects from some 6 different Selection/Option 

components (3 of 6 listBoxes with a few custom features added).  (The project is a sort of  generalized "DataServer Navigator" and it hooks up to our dataservers that are

implemented in Ruby to do efficient CRUD.  WebSockets based.  Its rather a "distributed entry" application for now.)  

  

[Joao Pedrosa]

Hi,

Ah nice discussion.

I like the confidence with which some have exposed their ideas.

I think Polymer is important. It appears to bring the ideas of server-side templating to the client-side. And by staying closer to HTML that approach is at least tightly coupled to its medium. Like in server-side templating, sometimes people can have a hard time imagining doing much with it beyond presenting some content, perhaps.

But cross-browser development continues to be challenging, and Polymer may work better for a nice cross-browser experience needed by popular applications and services.

Perhaps another take is to use Canvas to present your whole UI and that way kind of break with the web tradition while gaining some more finer-grained control over the pixels. I think I know libraries that will prefer that approach. Paranoid developers may also try the Canvas approach. Why paranoid? Perhaps because they want an all-or-nothing determinism. They may lose web features based on accessibility by going there, but they may afford that price.

Another interesting thing is that the code needed to generate a custom Polymer application appeared to me to be very scary-looking. A lot of code for what in a Tcl/Tk interface may have been expressed in a handful of lines. But again, the need in the web to try to use features like CSS were present. CSS/Styles are such a nice thing that going the Canvas based approach may miss on some of that.

In all actuality though, I am not sure the Dart developers can be trusted with creating a succinct programmatic API in the spirit of Tcl/Tk and such. The Dart way seems to be a little verbose compared to the scripting languages of yore and that adds a cost by itself, never-mind not being fully compatible with the web.

Whatever the future may bring in terms of UI, let this thread be remembered for some nice insights.

Cheers,

Joao

--

[Alex Tatumizer]

Yeah, it was a fruitful discussion indeed. Going again through the messages, though, I couldn't help but notice that while each individual post certainly makes sense (with the possible exception of my own ones), the whole thing is utterly confusing.

Let's start from the following statement:: 

> Sergey who ported from GWT to DartGWT is now working on porting Dart UI to AngularDart UI ;-) 

There's DartGWT - rich set of components. What is missing? Shadow DOM! These components are not composable, they don't behave like native HTML elements, etc.

It stands to reason to assume that the natural step would be: refactor all these components and turn them into shadow DOM elements. Then, they will be instantly available through programmatic interface (the whole DartGWT is programmatic, so it's just a natural next step).And then, they will be perfectly composable, and everything else - the dream comes true.

Except that it doesn't: instead, port to Angular is taking place. I personally will never touch Angular with 6-foot pole, but this is immaterial. The question is: will these components be reworked into shadow DOM elements in Angular? Please correct me if I'm wrong, but I can think only of 2 possible answers: Yes or No.

In case of Yes, what's the role of Polymer, which targets the same niche? 

In case of No, they whole thing just doesn't make sense: after all this herculean job of porting GWT to dartGWT and then from dart GWT to Angular, components still won't be composable, and now what? Will the same author start porting Angular components to Polymer? 

It's a puzzle. We can try to solve it by collective brainstorming, but I'm not sure.. 

[Justin Fagnani]

On Sun, Mar 2, 2014 at 8:52 PM, Alex Tatumizer <tatu...@gmail.com> wrote:

Yeah, it was a fruitful discussion indeed. Going again through the message, though, I couldn't help but notice that while each individual post certainly makes sense (with the possible exception of my own ones), the whole thing is utterly confusing.

Let's start fro the following statement:: 

> Sergey who ported from GWT to DartGWT is now working on porting Dart UI to AngularDart UI ;-) 

There's DartGWT - rich set of components. What is missing? Shadow DOM! These components are not composable, they don't behave like native HTML elements, etc.

It stands to reason to assume that the natural step would be: refactor all these components and turn them into shadow DOM elements. Then, they will be instantly available through programmatic interface (the whole DartGWT is programmatic, so it's just a natural next step).And then, they will be perfectly composable, and everything else - the dream comes true.

Except that it doesn't: instead, port to Angular is taking place. I personally will never touch Angular with 6-foot pole, but this is immaterial. The question is: will these components be reworked into shadow DOM elements in Angular? Please correct me if I'm wrong, but I can think only of 2 possible answers: Yes or No.

But of course the answer is somewhere in between :)

Shadow DOM is only one part of the web components suite of standards, and from the point of view of reusable components not really the most important one - that would be Custom Elements. Shadow DOM provides encapsulation, which is important, but Custom Elements is what eliminates the wrapping model, and eliminating the wrapping model is what makes it so that when you get an element out of the DOM it actually has all the proper properties and behaviors and they aren't stashed away in some other object that's hard or impossible to get to.

Unfortunately while AngularDart does use Shadow DOM to encapsulate its components, it does not use Custom Elements to register the components Instead, it relies on it's own mechanisms for parsing HTML, recognizing component tags and directive selectors, and instantiating those objects separate from the DOM. This is just the wrapping problem all over again, but even more complex because you can have multiple wrappers per Element. Luckily Angular only allows one NgComponent per Element.

Still, it is the wrapper approach, and a non-Angular app won't be able to import a library of Angular components and use them - It can't just drop a <my-element> tag (where my-element is defined in Angular) into it's HTML and have it work without itself being an Angular app.

This is why I just couldn't recommend writing a widget library using anything other than Custom Elements, whether using Polymer as a helper or not. Your widgets will forever be locked into a fragmented ecosystem rather than accessible to all web applications.

 

In case of Yes, what's the role of Polymer, which targets the same niche? 

Polymer helps you write Custom Elements. It makes some things simpler, that's all. It's really an internal implementation detail of the custom element, and outside the custom element you don't need to care whether it was built with Polymer or not.

On the JS side of things, Mozilla has a similar library called X-Tags. Polymer and X-Tags widgets work together because they're all just Custom Elements. In Dart we don't have another Custom Element helper, which is a shame because there are other approaches that are possible to explore. 

In case of No, they whole thing just doesn't make sense: after all this herculean job of poring GWT to dartGWT and then from dart GWT to Angular, components still won't be composable, and now what? Will the same author start porting Angular components to Polymer?

This is all very new stuff. Custom Elements and Polymer didn't exist when DWT started (and DWT can still be incredibly useful to GWT existing developers). For sure, not everyone groks all the implications of Custom Elements. The knowledge and how far reaching this will all be is very slowly getting out there, even among framework developers.

I wish it would happen faster, because at some point in the not-too-distant future, all these wrapping frameworks will be relegated to the dustbin of history. If they want to stay relevant they should be producing custom elements as soon as possible.

I hope that helps explain things some more.

Cheers,

  Justin

It's a puzzle. We can try to solve it my collective brainstorming, but I'm not sure.. 

[Cassio Tavares]

John, if it is supported or not is the least important thing here. Sincerely, if you start new Dart project today are you gonna use web_ui? What about an entire set of components like our friend (from Japan?) is doing?

I started coding all my ui programatically, then I changed to web_ui, and now I'll change to polymer. 

Every time I get a new version of Dart Editor I pray to not have to refactor my projectS again. That's the price for using an evolving technology but I hope not have to pay this price forever.

I hope you're right about polymer long life. Like it or not I'd like to see something stable.

Em quinta-feira, 27 de fevereiro de 2014 18h55min41s UTC-3, John Messerly escreveu:

On Thu, Feb 27, 2014 at 11:22 AM, Matthew Butler <butler....@gmail.com> wrote:

On Thursday, February 27, 2014 3:03:15 PM UTC-4, George Moschovitis wrote:

switch to web_ui,  switch to polymer,  switch to angular, switch to ..., shit!

There is some truth in this...

There's limited truth to it. To my knowledge web_ui is still being supported just not seeing new versions. Polymer is web_ui >= 0.5.0. It was also changed to a new package to more closely mirror the functionality of the Polymer.js port. 

Beyond that, Polymer can still continue be used, even if you're using angular, or whatever the next MV* framework comes out. That's the whole point of Polymer elements. to be reusable everywhere. not just with a Polymer application. (The same cannot be said for angular/angular components).

Couldn't have said that better :) Yeah, web_ui was just our code name until "Polymer" got its real name. And because it's just a bunch of elements, it should work in your framework of choice. 

On Thu, Feb 27, 2014 at 1:38 PM, Bob Nystrom <rnys...@google.com> wrote:

On Thu, Feb 27, 2014 at 1:19 PM, Alex Tatumizer <tatu...@gmail.com> wrote:

I want to write web app in dart. I don't want to write a single line of html or css by hand. Reusable components in programming are: libraries and classes.
Can polymer help in that? Can I find menus, grids, etc as classes to be instantiated in dart proper? Is there any example of purely programmatic operation with polymer?

I'm not a polymer expert by any means, but my understanding is, no, Polymer doesn't cover your use case. The folks behind Polymer are strongly in favor of declarative languages. They want you to write less code and more HTML and CSS.

That's a correct assessment of the Polymer team's opinions, however their actual elements can be created from code, e.g. " var grid = new PolymerGridLayout();" ... I'm not sure it's the best way to build up a DOM tree, but it's possible. (The main issue right now in Dart is we don't have all of the elements available yet.)

[Justin Fagnani]

On Mon, Mar 3, 2014 at 12:21 AM, Cassio Tavares <cas...@gmail.com> wrote:

John, if it is supported or not is the least important thing here. Sincerely, if you start new Dart project today are you gonna use web_ui? What about an entire set of components like our friend (from Japan?) is doing?

I started coding all my ui programatically, then I changed to web_ui, and now I'll change to polymer. 

web_ui is just a very old name for Polymer, and so it refers to a very old version of Polymer. There aren't that many differences. Some names have changes, the expression syntax is no longer just Dart, and the toolchain is quite different now, but it's not hard to migrate.

Every time I get a new version of Dart Editor I pray to not have to refactor my projectS again. That's the price for using an evolving technology but I hope not have to pay this price forever.

I hope you're right about polymer long life. Like it or not I'd like to see something stable.

Em quinta-feira, 27 de fevereiro de 2014 18h55min41s UTC-3, John Messerly escreveu:

On Thu, Feb 27, 2014 at 11:22 AM, Matthew Butler <butler....@gmail.com> wrote:

On Thursday, February 27, 2014 3:03:15 PM UTC-4, George Moschovitis wrote:

switch to web_ui,  switch to polymer,  switch to angular, switch to ..., shit!

There is some truth in this...

There's limited truth to it. To my knowledge web_ui is still being supported just not seeing new versions. Polymer is web_ui >= 0.5.0. It was also changed to a new package to more closely mirror the functionality of the Polymer.js port. 

Beyond that, Polymer can still continue be used, even if you're using angular, or whatever the next MV* framework comes out. That's the whole point of Polymer elements. to be reusable everywhere. not just with a Polymer application. (The same cannot be said for angular/angular components).

Couldn't have said that better :) Yeah, web_ui was just our code name until "Polymer" got its real name. And because it's just a bunch of elements, it should work in your framework of choice. 

On Thu, Feb 27, 2014 at 1:38 PM, Bob Nystrom <rnys...@google.com> wrote:

On Thu, Feb 27, 2014 at 1:19 PM, Alex Tatumizer <tatu...@gmail.com> wrote:

I want to write web app in dart. I don't want to write a single line of html or css by hand. Reusable components in programming are: libraries and classes.
Can polymer help in that? Can I find menus, grids, etc as classes to be instantiated in dart proper? Is there any example of purely programmatic operation with polymer?

I'm not a polymer expert by any means, but my understanding is, no, Polymer doesn't cover your use case. The folks behind Polymer are strongly in favor of declarative languages. They want you to write less code and more HTML and CSS.

That's a correct assessment of the Polymer team's opinions, however their actual elements can be created from code, e.g. " var grid = new PolymerGridLayout();" ... I'm not sure it's the best way to build up a DOM tree, but it's possible. (The main issue right now in Dart is we don't have all of the elements available yet.)

[Joao Pedrosa]

Hi,

I just browsed some information on Custom Elements and Polymer to try to learn some more about them.

I kind of liked something that I read about Custom Elements in the specification. Something about registering the tag but still having the code in JavaScript.

Also it appears that a lot of the hoopla of Custom Elements is making the component attributes be part of the DOM proper. So in a way it still is some kind of encapsulation.

As it's just part of an encapsulation effort, perhaps there will be a salvation to the developers who don't jump on the bandwagon. They could eventually just adapt to these encapsulation efforts by exposing just as much as needed from their applications.

When I am creating a Dart application I have a self-interest in breaking the windows into components. It helps me to test the parts more independently from one another. It allows me a faster iteration when developing a part since I can reload just that to see changes. And finally as a component the part could be reused by other components.

I have a dislike for applications that are built monolithically. But I reckon that some developers don't care and in fact may prefer a monolithic approach to applications.

Taking that in consideration I am not sure we'll see the end to this discussion about components just yet. There's always a catch to reusing components, which is who is making them in the first place.

Cheers,

Joao

[Milan Zimmermann]

No markup in UI code, this is what I was looking for as well, thanks for posting it. I pasted the code to Dart editor and created an application from it. It runs in Dartium. However, when run as Javascript, I get a blank page and in the console:

TypeError: b.registerElement is not a function

...b.registerElement(c,q)},"call$5","Zn",10,0,null,88,[],195,[],93,[],10,[],196,[]]

Is this expected or am I missing something?

Thanks

Milan

[Günter Zöchbauer]

Take a look at this SO question http://stackoverflow.com/questions/22098276

[John Messerly]

fyi -- I replied to the SO question with a few guesses about this error.

[George Koller]

Hi again,

When I started this thread now just over a week ago I was having some very real problems finding my way around Polymer.  The only examples of use to me were very basic, and I was running into a "brick wall" again and again trying to coordinate between our six main and option type "compound elements" which have a number of inter-relationships.  For example when a (different/new) element of one particular "dropBox" list is selected all the other 5 Polymer Elements must be updated....  

From the beginning it was my goal that:

1.  No "Business Knowledge" embedded into the UI Objects - 

2.  "Reasonable Minimum" of Redundant code - only comprise now is to keep code

    obvious :)

3. Websockets would be used to communicate with our DataServers and the protocol 

(keys and all) would be kept in a nice central and understandable manner, and NOT embedded piecemeal into the Polymer Elements.

4. minimal HTML - completely standard as possible to get functionality

All the above design objectives have now been met and the system is "snappy" and seems manageable.  

Right now I'm a very happy camper! 

I read all the postings on this thread multiple times and nobody that I recall mentioned the "team aspect" of Polymer.  As a ("real")  programmer I can understand the urge to want to push the HTML out there 100% under Our control, sure!  But :)  Is it not just a whole lot better to kick things off with Minimal HTML then let SOMEBODY ELSE take over the details?   (We are a small team but HTML programmers are not hard to find.)

(Also - anything BUT minimal HTML there are issues of multiple browser and IE versions and all that - I know this is the LAST thing I want to spend my time dealing with.)

I'm not sure how to share what worked for me, except two general things:

I created a "WebServer" class with a "transport" method where ALL the websocket stuff was concentrated.  This class is instantiated Once for EVERY need to fetch information from the server.  There is also ONE METHOD PER COMPONENT (same name - I keep thinking....) that the corresponding element uses...  and here's a key to it all... inside this element a Future was created.  And inside those curly brackets the goings on of the Asynchronous  world around "goes away" and there an Oasis of Synchronous sanity. 

The other trick that worked out for me (it wasn't inheritance) is a sort of "Lock and Key" 

set of complimentary methods in the (static - data commons) organizing class: 

    static void element1Updated(String option)   {....

    static bool isElement1UpdateDue(var tryVal) {....

The first method "Maintains" the various Keys and status bits.

The complimentary method USES this info under multiple circumstances (eg update required directly, or by way of another component).

This way the Polymer Elements themselves are "Application Logic Free" except for some minimal code that looks something like this (for option_selected) Lifecycle:

 if (element2Ar.isNotEmpty) {

       String option = optionAr[selected];

       if ( DC.isElement2UpdateDue(option) ) {

       

          DC.element2Updated(option); 

             

          DC.listboxElement3.component_update(); 

       }

     } 

The code is new and there is much to do, I have tried to think how I can share my experience but this is about as best I can do in a general way at this time.

Thanks for so many interesting postings!

_george

[Kao peter]

Hello 曹忠, 

     Even you jump on angular side, you will find there still remain some bugs need to fix some feature are not ready  

On Friday, February 28, 2014 5:28:43 PM UTC+8, 曹忠 wrote:

Dart and polymer.dart very great, but we need to just work, do not let us fall into a large bug inside.

You know our project now have over 100 + polymer components, our team has invested a year of time, we have no way out but to follow polymer forward.

[Alex Tatumizer]

It seems wind changed direction already. "React" (courtesy of FB) is all the rage now. Fully programmatic framework, with a bit of syntax sugar.
Interesting idea: they translate something that looks like embedded HTML into normal code, e.g. you write

var CommentBox = React.createClass({
  render: function() {
    return (
       <div className="commentBox">
          Hello, world! I am a CommentBox.
       </div>
    );
  }
});

and they generate
var CommentBox = React.createClass({ 
   render: function() { 
      return ( 
         React.DOM.div({ 
           className: 'commentBox', 
           children: 'Hello, world! I am a CommentBox.' 
         })
       ); 
   } 
}); 

Obviously, you can write directly in the latter format, with no preprocessing, but they claim embedded "HTML" is more readable. Maybe. But the point is that even with preprocessing, everything is simple and fast and intuitive and programmatic.
If same idea can find its way to dart (natively, not as a wrapper around they lib), I think it can become an instant hit, especially considering that dart is much nicer language  to begin with.

[Thomas Stephenson]

I'll just leave this here...

https://groups.google.com/forum/#!topic/scala-language/PV4q6O1qIh8/discussion

Thomas

[Thomas Stephenson]

Actually, that was a bad idea -- here's the relevant portion of the post

> The easiest win is probably XML literals. Seemed a great idea at the
time, now it sticks out like a sore thumb. I believe with the new
string interpolation scheme we will be able to put all of XML
processing in the libraries, which should be a big win. It also means
we could provide swappable alternatives to the current XML system such
as Anti XML or others.

--Martin Odersky

I'm not saying it would be a bad idea in dart -- dart is wedded to HTML a lot closer than java/scala are to XML. But making the language almost unparsable (and thus killing third party tool support) in exchange for fancy templating?!?

Thomas

[Alex Tatumizer]

I'm not saying it's a good or bad idea - I personally don't have a basis for such generalizations for the lack of experience with this framework.

But: there is a simple way to mitigate "parsability" problem, by wrapping HTML in a new kind of string quotes, e.g.

`<div className="commentBox">

          Hello, world! I am a CommentBox.

</div>`

It just a string, in much the same way as r'''blahblah''' is a string.

My point, however, was a bit different. The argument was made that declarative style is what people want, and angular gives them what they "want".

As was already noted by someone, "what people want" is changing every day. To me, angular is a terrible kludge. And eventually, it's always the case that

simplicity and "style" win. Finding something that deserves the name of a "style" is very difficult. I don't know whether react qualifies, but it gives some food for thought.

[Thomas Stephenson]

It's obviously not an insoluble problem, but it does complicate the language and tooling considerably. Having a clear delineation of the start and end of a section of html might help parseability, but it certainly doesn't eliminate it entirely. It's not just a string -- it's a string that requires syntax highlighting and error reporting which is different from the rest of the file.

A probably bigger problem is the io/html divide in dart. Would literals be allowed in 'dart:io' files, which can't do dom manipulation?

Fresh thinking and ideas are obviously valuable and I didn't mean to seem like I was putting the idea down without thought. As I inferred, it's probably a better idea for dart than it was for scala and polymer certainly isn't the silver bullet that it was sold to be...

Thomas

[Alex Tatumizer]

BTW, we discussed a similar  (but not necessarily identical) issue related to this a year ago

https://code.google.com/p/dart/issues/detail?id=9831

Bakquotes there were not meant to be an ad-hoc feature for html - but rather a general sugar for wide range of uses.

Syntax highlighting IS an issue, but there are very simple solutions - e.g. when you write your README in markdown, github displays it with syntax highlighting correctly, because there are pluggable syntax highlighters there, specific for each language. Editor team can implement this kind of thing for backquotes/HTML  before breakfast, if they wish (e.g. by just cloning existing HTML highligher) 

[Marcello Dias]

I know people hate when somebody revivals such old threads.

But know I understand what Gilad and João Pedrodsa said.

I just can´t stand Polymer way of doing things.

Too much verbose,and difficult to see the whole picture.

I fact I would like the power of Dart+Polymer but in

the ExtJs way.

I´m the first to consider myself paranoid like Joao Pedrosa said.