[dart-misc] 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]

Post by 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
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.

Post by SwarmShepherd
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).

Post by SwarmShepherd
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

Post by SwarmShepherd
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.

Post by SwarmShepherd
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写道

Post by 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
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.)

[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.

Post by 曹忠
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写道

Post by 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
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.)

--
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

[George Moschovitis]

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

There is some truth in this...

[Matthew Butler]

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]

Post by Alex Tatumizer
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]

Post by Matthew Butler

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.

Post by Matthew Butler

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.)

[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 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.

[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 an 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?

Post by 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,
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.

[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.

[George Moschovitis]

Post by 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,
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

[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

Post by Alex Tatumizer
Every declarative language sooner or later (rather sooner) hits the wall,

Post by Alex Tatumizer
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,
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

[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..

Post by 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 my illusion that declarative language is more
accessible for non-programmer. It's not. Non-programmer will hit the wall,
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

--
Cheers,
calathus

[Alex Tatumizer]

Post by calathus
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
guenter-CK6o3CertDXpqHyzgqq+***@public.gmane.org
[phone]

Post by calathus
Since Dart is much more declarative language, and provide good notation of

Post by calathus
"..' , 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.
--
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

[Alex Tatumizer]

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

[calathus]

Post by Alex Tatumizer
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.

Post by Alex Tatumizer
Since Dart is much more declarative language, and provide good notation of

Post by calathus
"..' , 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.
--
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

--
Cheers,
calathus

[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.

Post by Alex Tatumizer

Post by Alex Tatumizer
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.

Post by 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.
--
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

--
Cheers,
calathus

--
Cheers,
calathus

[Justin Fagnani]

Post by calathus
Since Dart is much more declarative language, and provide good notation of

Post by calathus
"..' , 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.

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.

Post by calathus
--
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

[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]

Post by Alex Tatumizer
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';

Post by Alex Tatumizer
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.

Post by Alex Tatumizer
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.

Post by Alex Tatumizer
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

Post by Alex Tatumizer
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

--

Post by Alex Tatumizer
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

[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?

Post by 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.
--
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

[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.

Post by 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?
*If I'd asked customers what they wanted, they would have said "a faster
horse".*
(Attributed to H. Ford)
--
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

--
Marcello Dias
Gerente de T.I

[image: Descrição: Descrição:
Loading Image...]

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-***@public.gmane.org
www.brasfond.com.br

[曹忠]

Yes! is best suited for ERP/CRM development.

圚 2014幎3月1日星期六UTC+8䞊午10时40分24秒Marcello Dias写道

Post by 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.

Post by 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?
*If I'd asked customers what they wanted, they would have said "a faster
horse".*
(Attributed to H. Ford)
--
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

--
Marcello Dias
Gerente de T.I
http://www.brasfond.com.br/email/logo-novo-puro.gif]
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
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]

Post by 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.

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.

Post by Gilad Bracha
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

Post by Gilad Bracha
<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 <http://html.spec.whatwg.org>) 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

Post by Gilad Bracha
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
--

[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)

Post by John Messerly

Post by 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.

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.

Post by Gilad Bracha
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

Post by Gilad Bracha
<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 <http://html.spec.whatwg.org>) and the
C++ DOM implementations are quirky, it is sometimes necessary to write a
<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

Post by Gilad Bracha
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
--
--

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

--
Cheers,
calathus

[Ross Smith]

For those interested in defining imperative custom elements in pure Dart
code, here is a larger example along the lines of Justin's `MyElement`,
defined (with style!) in a single .dart file:

https://github.com/rmsmith/fields/blob/master/lib/src/view/object_editor.dart

Live demo (Chrome only!)

http://futureperfect.info/fields/examples/sunflower/sunflower.html

I have written such things before in XAML and this is such a breath of
fresh air for me :)

The building blocks I use for building imperative trees of html in Dart are
in this Pub package:

https://pub.dartlang.org/packages/tags

cheers,

Post by 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)

Post by John Messerly

Post by 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.

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.

Post by Gilad Bracha
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

Post by Gilad Bracha
<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 <http://html.spec.whatwg.org>) and the
C++ DOM implementations are quirky, it is sometimes necessary to write a
<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

Post by Gilad Bracha
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
--
--

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

--
Cheers,
calathus

[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

Post by 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.
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
--
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

[Alex Tatumizer]

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


On Fri, Feb 28, 2014 at 10:34 PM, Justin Fagnani

Post by 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
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);
}
}
<!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

Post by 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.
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
--
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

--
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

[George Moschovitis]

Post by Justin Fagnani
import 'dart:html';
void main() {...
</html>

pretty nice!

[Alex Tatumizer]

Post by calathus
At that time, I thought it is difficult to use Dart class ObservableMixin

without using plymor html. But I a bit forgot the detail..

Post by calathus
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<https://pub.dartlang.org/packages/event_bus>I have used.

Post by calathus
At that time, I thought it is difficult to use Dart class

ObservableMixin without using plymor html. But I a bit forgot the detail..

Post by calathus
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
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.
--
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

[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,...)

Post by calathus
At that time, I thought it is difficult to use Dart class

ObservableMixin without using plymor html. But I a bit forgot the detail..

Post by calathus
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
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.
--
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

[Alex Tatumizer]

Not part of the core language, but there is this library<https://pub.dartlang.org/packages/event_bus> 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.

[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

Post by 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
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);
}
}
<!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

Post by 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.
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
--
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

[Günter Zöchbauer]

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

Post by 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
TypeError: b.registerElement is not a function
...b.registerElement(c,q)},"call$5","Zn",10,0,null,88,[],195,[],93,[],10,[],196,[]]

[John Messerly]

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

Post by Günter Zöchbauer
Take a look at this SO question
http://stackoverflow.com/questions/22098276

Post by 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
TypeError: b.registerElement is not a function
...b.registerElement(c,q)},"call$5","Zn",10,0,null,88,[],195,[],93,[],10,[],196,[]]

--

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

[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....
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


On Wed, Mar 5, 2014 at 11:54 AM, Milan Zimmermann <

Post by 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
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

Post by 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
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);
}
}
<!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

Post by 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.
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
--
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

--

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

[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

Post by John Messerly

Post by Matthew Butler

switch to web_ui, switch to polymer, switch to angular, switch to

Post by 曹忠
..., 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.

Post by Matthew Butler

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]

Post by 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.

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.

Post by Cassio Tavares
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

Post by John Messerly

Post by Matthew Butler

switch to web_ui, switch to polymer, switch to angular, switch to

Post by 曹忠
..., 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.

Post by Matthew Butler

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.)
--

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

[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

Post by Justin Fagnani

Post by 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.

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.

Post by Cassio Tavares
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

Post by John Messerly

Post by Matthew Butler

switch to web_ui, switch to polymer, switch to angular, switch to

Post by 曹忠
..., 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.

Post by Matthew Butler

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.)
--

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

--
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

[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.

Post by 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.

[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 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

Post by 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.
--
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

[曹忠]

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写道

Post by 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
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.)

[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

Post by 曹忠
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写道

Post by 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
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.)

[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

Post by 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]

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

I'll just leave this here...
https://groups.google.com/forum/#!topic/scala-language/PV4q6O1qIh8/discussion
Thomas

Post by 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.

[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

Post by 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.

[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)

[曹忠]

Please keep work for polymer, that's great!

圚 2014幎2月27日星期四UTC+8䞋午9时15分56秒SwarmShepherd写道

Post by 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
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

Post by 曹忠
Please keep work for polymer, that's great!
圚 2014幎2月27日星期四UTC+8䞋午9时15分56秒SwarmShepherd写道

Post by 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
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.)

--
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

[Alex Tatumizer]

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.

Post by Günter Zöchbauer
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 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?

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

[Justin Fagnani]

Post by Alex Tatumizer
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.

Post by Günter Zöchbauer
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.

Post by Alex Tatumizer
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

Post by Alex Tatumizer
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

Post by Alex Tatumizer
It's a puzzle. We can try to solve it my collective brainstorming, but I'm
not sure..
--
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

[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.
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.

Em quinta-feira, 27 de fevereiro de 2014 10:15:56 UTC-3, SwarmShepherd

Post by 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
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.)