Dear Dart development team, are you planning to include any UI library into Dart SDK?

1,219 views
Skip to first unread message

Abazilev

unread,
Aug 21, 2012, 4:37:33 AM8/21/12
to mi...@dartlang.org

John Evans

unread,
Aug 21, 2012, 10:13:11 AM8/21/12
to mi...@dartlang.org
Yes they are.  There is no official timeline for it, yet.

If you're interested in exploring the latest and greatest, you may want to have a look at:  https://github.com/dart-lang/dart-web-components




On Tuesday, August 21, 2012 3:37:33 AM UTC-5, Abazilev wrote:

Seth Ladd

unread,
Aug 21, 2012, 12:07:18 PM8/21/12
to mi...@dartlang.org
John is too modest, so I'll speak up for him. You might also be interested in Buckshot, John's UI lib. I'm also aware of PureMVC. You can find both of these, and more, at http://blog.dartwatch.com/p/community-dart-packages-and-examples.html

Enjoy!
Seth



--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

Colin Putney

unread,
Aug 21, 2012, 1:12:46 PM8/21/12
to mi...@dartlang.org
On Tue, Aug 21, 2012 at 7:13 AM, John Evans <pru...@gmail.com> wrote:
> Yes they are. There is no official timeline for it, yet.

You know, I think it's good that there's no UI library in the SDK. I
say this for two reasons:

1. The open source community will certainly step up here, and has
already started to do so. This is a good opportunity for folks that
aren't language designers or compiler writers to make a major
contribution, and it won't get ignored. Better to have the SDK include
stuff that really is core to the system, and leave the higher level
stuff to the community.

2. A single, "blessed" UI library is probably not a good idea right
now. Web app design, particularly user interface structures are
undergoing rapid evolution right now. The advent of fast Javascript
runtimes is letting people build web applications with the same
quality and performance as desktop applications, without being subject
to the conventions of desktop software. At the same time, mobile
devices and their limitations are putting an enormous amount of
pressure on interface design. A single, "official" UI framework would
chill the research and experimentation that's going on here, and
prematurely standardize on a UI paradigm. An official UI framework
might make sense once we've figured out how to create interfaces in a
web/mobile world, but we're not there yet.

I hope the UI library will keep getting pushed down the priority list
for the SDK. ;-)

Colin

mythz

unread,
Aug 21, 2012, 2:32:50 PM8/21/12
to mi...@dartlang.org
You know, I think it's good that there's no UI library in the SDK 
...
2. A single, "blessed" UI library is probably not a good idea right now.  

I don't. 

While I'm also like to see a plethora of different Open Source UI frameworks optimized for different use-cases, I would also definitely love to see something in Dart as big and well supported by Google like they've done with Closure Library and GWT.
It shouldn't be forced to use, but a blessed general-purpose Dart UI which will have the benefit of consistent, intuitive APIs, IDE integration and an active community around it.

JavaScript has too many UI fx's that don't play well with each other, I would definitely prefer a solid UI foundation base that others can build re-usable widgets on top of.

On that note, Dart Web Components is looking like an interesting concept :)...

John Evans

unread,
Aug 21, 2012, 2:40:10 PM8/21/12
to mi...@dartlang.org
I'm mostly in your camp Colin (and thanks for the plug Seth).

I'm neutral on whether or not Dart should sponsor it's own UI library.  Generally, I think it's a good idea to have multiple quality options available.  There is certainly enough room for more than one.

Seth Ladd

unread,
Aug 21, 2012, 2:43:10 PM8/21/12
to mi...@dartlang.org
We certainly see a future where the Dart + Web Components work will provide the foundation for various higher level frameworks. At least, that's the hope! So feedback is really appreciated for early adopters of Web Components and Dart.


--

Kai Sellgren

unread,
Aug 21, 2012, 4:10:40 PM8/21/12
to mi...@dartlang.org
Personally I see nothing bad in community made UI components, as long as we get a decent support for unified class-level events and some templating support so that we don't end up in so much mess as we have with these Dojo/Ext/jUI/Kendo/etc. where each of them re-implement non-UI related things like event support, mixins, etc.

Sebastien Douche

unread,
Aug 21, 2012, 4:29:06 PM8/21/12
to mi...@dartlang.org
tOn Tue, Aug 21, 2012 at 7:12 PM, Colin Putney <co...@wiresong.com> wrote:
> On Tue, Aug 21, 2012 at 7:13 AM, John Evans <pru...@gmail.com> wrote:
>> Yes they are. There is no official timeline for it, yet.
>
> You know, I think it's good that there's no UI library in the SDK. I
> say this for two reasons:

+1000. But the core teams must give a library some love (Web
Component, Buckshot, whatever) to start the "movement".



--
Sebastien Douche <sdo...@gmail.com>
Twitter: @sdouche / G+: +sdouche

Tomasz Kubacki

unread,
Aug 21, 2012, 5:08:03 PM8/21/12
to mi...@dartlang.org
hi,

My two cents.
Community driven uis almost always sucks - i say this as a linux desktop
daily basis user and part time osx/windows user.
The only successful OS ui lib i know is Twitter Bootstrap and it's not
community driven per se. I don't know why it's this way - but it's true.

Therefore i'm in dart-standart-ui camp. GWT port seems like a nobrainer
for me.

cheers,
Tomasz Kubacki

W dniu 21.08.2012 22:10, Kai Sellgren pisze:

John Messerly

unread,
Aug 21, 2012, 6:14:31 PM8/21/12
to mi...@dartlang.org
On Tue, Aug 21, 2012 at 2:08 PM, Tomasz Kubacki <tomasz....@gmail.com> wrote:
hi,

My two cents.
Community driven uis almost always sucks - i say this as a linux desktop daily basis user and part time osx/windows user.
The only successful OS ui lib i know is Twitter Bootstrap and it's not community driven per se. I don't know why it's this way -  but it's true.

Yeah, IMO you need UI designers to create good looking UIs. That's a big problem for Linux desktops. OTOH, I think developer community created frameworks have been really successful. They generally assume you have a designer helping out with the look and feel. Twitter Bootstrap is neat because it gives you nice looking UI widgets out of the box. It's a nice complement to the higher level things (e.g. databinding) people expect in UI frameworks.

- John


Ladislav Thon

unread,
Aug 21, 2012, 11:41:04 PM8/21/12
to mi...@dartlang.org


> Therefore i'm in dart-standart-ui camp. GWT port seems like a nobrainer for me.

This is exactly why I would fear a standard UI library from Google -- too high risk that it will resemble GWT. I really really don't think that constructing HTML in code (which is likely about an order of magnitude larger than the corresponding HTML itself) is the right way to do things -- and UiBinder didn't make it any better. HTML needs to be written as HTML, especially if you want HTML people to be able to work on your project.

LT

mythz

unread,
Aug 22, 2012, 12:48:53 AM8/22/12
to mi...@dartlang.org
I'm quietly confident that we don't end up with something as verbose as GWT / Closure Library - they both suffered major design short-comings as a result of trying to some of JavaScript's language deficiencies by adding typing to JavaScript to assist with building their large Internet properties. IMO improving this situation was one of the primary use-cases Dart was started to solve.

As ugly and verbose as Closure Library/GWT is, they do offer a solid and comprehensive set of UI widgets - but its verbosity has made it less enjoyable to use, which has ultimately hindered its adoption. This is an experience I believe the Dart project wants to dramatically improve.

Usually I don't like taking the "blessed" UI route on anything, but I've found most JS UI fx's up to this point have been lacking and Google remain the few companies with the talent and experience to have been able to create some of the best and most feature-rich JS Apps using their own tool chain. 

So whilst I hope their remains a vibrant array OSS UI options, I still look forward to a fully supported UI option from Google, even if its just open sourcing their UI library they build their future Dart Apps on (i.e. like what they did with Closure Library) - this would still be a welcomed addition.

- Demis

Alain Ekambi

unread,
Aug 22, 2012, 1:53:43 AM8/22/12
to mi...@dartlang.org
Guyz,

It s  one thing to praise Dart (and frrom day one i ve been a big fan of Dart, love how things are going).
It s another to try to bash existing technologies like GWT or Closure.
Let Dart get to that level first.

In the last couple of years i created GWT-Based tools(www.emitrom.com).
The success was so high that i quited my day to day  job.
I  dont know about Closure but  i can guarantee you that at least 50% of fortune 100 companies (Google included) use GWT this is not stoping anytime soon.
So i dont where you have the : 

"As ugly and verbose as Closure Library/GWT is, they do offer a solid and comprehensive set of UI widgets - but its verbosity has made it less enjoyable to use, which has ultimately hindered its adoption"

 - part.

Again i dont use Closure and Yes GWT is verbose. But that s because Java is verbose. But when it s comes to Enterprise application Java is the platform number one and goes faar beyong a programming language. It s an entire Platform. The  megaton of tools available in the Java ecosystem is simply unmatched and that also aint going to change anytime soon. 

Should Dart include a UI Kit ? Absolutely. 
But please stop bashing other technologies for no reason.

Talking about UI Frameworks. There are a lot of successfull examples out there.
Ext-JS, GXT, Vaadin, KendoUI, Qooxdoo, Flex, Twitter Bootstrap, etc... 

The fact that there are so many and you guyz are still complaining about no one beeing good enough simply shows that people have different preferences.
And there is nothing wrong with that.

But please support Dart without taking shots at others peole work.

Cheers



2012/8/22 mythz <demis....@gmail.com>

--

Tom Yeh

unread,
Aug 22, 2012, 4:32:47 AM8/22/12
to mi...@dartlang.org
It is too early to have a standard UI library for Dart. There are so many innovative ways to build UI. Take a look at Java. There are Struts, Wicket, JSF, ZK and a lot more. I don't think it fragmented Java web programming. Rather, it brings in innovative options.

Furthermore, Dart SDK shall be kept as neat as possible. It is aimed to run at the client where everything has to be loaded from the server. It is better to position Dart SDK as JQuery rather than JQuery UI or JQuery Mobile (or any dozen other framework). On the other hand, dart:html and dart-web-components are good since they are thin and part of HTML 5 standard.

You won't like to see Dart to release a new version every quarter just to keep up with the pace of browsers.

Disclaimer: I am one of the authors of Rikulo and ZK.

Abazilev

unread,
Aug 22, 2012, 7:00:22 AM8/22/12
to mi...@dartlang.org
Thank you very much for your answers. 

Just for now I am working using GWT, so my considerations are:
1) Modularity;
2) Rich UI in the standard package.

as I understand, Dart language perfectly addresses first item, but the second is completely important for me too, just for example. Maybe, UI library can be build upon the standard HTML 5 components, just like in GWT.

вторник, 21 августа 2012 г., 11:37:33 UTC+3 пользователь Abazilev написал:

Андрей Базилевич

unread,
Aug 22, 2012, 7:12:12 AM8/22/12
to mi...@dartlang.org
Yes, I understand, the better way will be to built own components using HTML 5 and then manipulate them using Dart. I am looking into Dart to use it like instead of GWT.

2012/8/22 Abazilev <andrey.b...@gmail.com>

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 



--
WBW, Andrey Bazilevich
Message has been deleted

Tom Yeh

unread,
Aug 22, 2012, 7:35:06 AM8/22/12
to mi...@dartlang.org
Yes, Dart brings in a lot of opportunities, so are HTML 5 and CSS 3. In additions, the growing demand of mobile devices adds more challenges, such as one single codebase to address different resolutions (aka., responsive design) and to handle mouse and touch events transparently. Allow me to promote my new project, Rikulo, a bit:) There are still more work to do, but I think it has some good answers to the challenges. Looking forward your feedback.

John Evans

unread,
Aug 22, 2012, 10:24:21 AM8/22/12
to mi...@dartlang.org
Personally, I'd like to see more people contributing to the community open source projects (like Rikulo, Buckshot, PureMVC, and others) and certainly to the Dart project itself.  The advantage over pure discourse is obvious, but I'll write it anyway:  Not only do you get to have a voice in the discussion, but you move the ball forward as well.

Tom Yeh

unread,
Aug 22, 2012, 12:50:58 PM8/22/12
to mi...@dartlang.org
To me, one of the most exciting development in the past decade is the prosperity of open source projects. One project inspires another. When I thought something was brilliant, there came another better solution. The market is finally directed more by innovations, rather than big names. The openness of Dart team started a good ecosystem. Moreover, HTML 5 is still in draft (we are still figuring how to express UI effectively). There is plenty of room for different web-based UI solutions, even if Dart SDK is shipped with one. I can image some will be as light as jQuery Mobile, and some as sophisticated as Android or Java FX.

mythz

unread,
Aug 22, 2012, 1:30:38 PM8/22/12
to mi...@dartlang.org
It s another to try to bash existing technologies like GWT or Closure.

Just to be clear I don't think GWT/Closure Lib was intentionally verbose, as I said they were both designed to fix JavaScript's language deficiencies add typing to JavaScript to facilitate in building their large JS Apps.

Again i dont use Closure and Yes GWT is verbose. But that s because Java is verbose. But when it s comes to Enterprise application Java is the platform number one and goes faar beyong a programming language. It s an entire Platform. 

i.e. Yes as I said, it's verbosity was due to adding typing as an extension to the language in docs (Closure Lib) or using a statically-typed language that transpiled to JS (Java/GWT).
Adding optional type info, proper inheritance, etc is something Dart has baked into the language from the start so I don't expect the Dart UI to be anything like their existing tools (which had to work with existing languages weaknesses).

But either way they *are* verbose, and I found it un-enjoyable to develop in, I developed the Redis Admin UI using Closure Library:
And while I got great value from using their existing well-designed widgets, I was not a fan of the mandatory namespaces for everything and how much typing I needed to write to get anything done - which was the reason I no longer used it.

So while the existing UI fx's were a marvel of engineering that were essential in building "Google-sized" JS Apps, they are not ideal for mass adoption - I'm not bashing it, that's my observation which I'm registering as feedback - with the hope the future Dart UI's helps alleviate.

Making a consistent, well-designed, enjoyable "batteries included" platform optimized for fast iteration times is exactly what the Dart team seems to be focused on and has been delivering to this date, so I don't expect any new Dart UI to maintain the unwanted side-effects present in their existing UI lib.

Josh Gargus

unread,
Aug 22, 2012, 8:00:10 PM8/22/12
to mi...@dartlang.org
You might be interested in the Enyo framework (enyojs.com), which
succeeded Mojo as the WebOS UI framework. You don't write much HTML,
instead using a DSL written in JavaScript which ends up being more
concise than the corresponding HTML. I had the opportunity to work
with the Enyo team, and have a tremendous amount of respect for their
work.

Despite Enyo being very cool, your second point still holds... I've
observed it to be somewhat difficult for "HTML people" to use.

I haven't wrapped my head around what a Dart port would look like,
since Enyo makes liberal use of eval(), prototypes, and other
JavaScript features that don't exist in Dart.

Cheers,
Josh

Kai Sellgren

unread,
Aug 23, 2012, 2:09:12 AM8/23/12
to mi...@dartlang.org
I agree that constructing UIs in code (when not needed) is not ideal. I've been doing Swing and WPF in the past year, and WPF wins by a large margin. I like to have my UI in mostly as a markup, because it tends to be more concise and clear. WPF gives me this with XAML and Buckshot tries to mimic it. What I've hated about GWT and ExtJS is that they don't give me that. Of course there are times when you need to do things dynamically in code.
Message has been deleted

Андрей Базилевич

unread,
Aug 23, 2012, 8:10:19 AM8/23/12
to mi...@dartlang.org
Yes, GWT provides the way to declare UI elements in XML-based documents. The main point is not to have a possibility to write elements in Dart language code, but to have the rich UI library based on HTML 5 with possibility to operate with using Dart language.

2012/8/23 Ross Smith <ross.m...@gmail.com>
I'm not advocating this, but GWT does have declarative ui with a form of databinding:



On Wednesday, August 22, 2012 11:09:12 PM UTC-7, Kai Sellgren wrote:
I agree that constructing UIs in code (when not needed) is not ideal. I've been doing Swing and WPF in the past year, and WPF wins by a large margin. I like to have my UI in mostly as a markup, because it tends to be more concise and clear. WPF gives me this with XAML and Buckshot tries to mimic it. What I've hated about GWT and ExtJS is that they don't give me that. Of course there are times when you need to do things dynamically in code.

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 



--
WBW, Andrey Bazilevich

Bob Nystrom

unread,
Aug 23, 2012, 5:08:00 PM8/23/12
to mi...@dartlang.org
Long thread is long!

Here's my opinions, for what they're worth:

Putting stuff closer to the core encourages reuse. Compared to the previous C and C++ communities, I felt like core reuse really flourished in Java. A big part of that, I believe, is because things like collections were in the standard library. That meant to third party libraries could reliably send lists and maps to each other since they could both take the core library for granted.

Meanwhile, in JavaScript, each UI framework is essentially an island. You can't easily mashup components from MooTools and Prototype and jQuery UI because they each have their own different conventions and don't all rely on a single shared thing that they can use to interoperate.

So there's some value in having something UI related that's blessed by the ecosystem, because then everyone's packages can use that to talk to each other.

The closer you get to the top of the software stack, the more divergent it gets. Most apps need collections, and they all need them in roughly the same way. A list that works well for a medical site will work fine for a game, and tax prep software. But the higher-level you get, the more domain-specific your code becomes, and those domains are widely divergent.

This means that I think it's really unlikely that a single UI framework will be awesome for games, small web sites, big database-driven ones, single-page AJAX-ey ones, etc. I don't think there will be one to rule them all.

Having multiple frameworks is good because it means each can serve one area really well instead of being a lowest common denominator for a bunch.

So these two points are in direct opposition. However, I think there's one thing we can do to cope:

There is already something that every UI framework can rely on to interoperate in the browser: the DOM. If UI frameworks can agree to make the DOM itself be the common substrate that they are all built in, then interoperability is possible.

That's why I think the web components stuff is really cool and is a promising foundation. So, the way I think/hope this will go is that we'll build out the web components stuff which paves the way for reusable DOM-based components and then other more tailored UI frameworks will build on top of that.

Cheers,

- bob

Colin Putney

unread,
Aug 23, 2012, 6:03:39 PM8/23/12
to mi...@dartlang.org
On Thu, Aug 23, 2012 at 2:08 PM, Bob Nystrom <rnys...@google.com> wrote:

> There is already something that every UI framework can rely on to
> interoperate in the browser: the DOM. If UI frameworks can agree to make the
> DOM itself be the common substrate that they are all built in, then
> interoperability is possible.
>
> That's why I think the web components stuff is really cool and is a
> promising foundation. So, the way I think/hope this will go is that we'll
> build out the web components stuff which paves the way for reusable
> DOM-based components and then other more tailored UI frameworks will build
> on top of that.

Yes, I'd definitely like to see support for web components in the
core. Having richer, community-supplied UI frameworks on top of that
would be great.

I suppose there's another aspect to this question, which is this: what
sort of an ecosystem will Dart grow into? If you see Dart as "Google's
new stack for web applications," the successor to GWT and in
competition similar offerings from IBM, Oracle or Microsoft, then
obviously it needs a UI framework. Dart-based open source projects are
nice, but not that important.

On the other hand, if you see Dart as an "open-source programming
language" in the vein of Python, Ruby or, especially Javascript (which
had a similar creation and nurturing by Netscape/Mozilla), well, a
marketplace of open source projects built on top of the core is
crucial. Depending too much on a single corporate sponsor, even one as
big and powerful as Google, risks inhibiting adoption.

Colin

Bob Nystrom

unread,
Aug 27, 2012, 4:19:02 PM8/27/12
to mi...@dartlang.org
I can't speak for the entire team, but I believe philosophically we lean towards the latter.

I think we all believe that it's critical that Dart be "batteries included". To get people to switch to Dart, it needs to have libraries for all of the major pieces of functionality that they are currently using in other languages.

At the same time, I don't think we expect every one of those batteries to be coming directly from Google. We are deeply committed to open source and the web community, and in that world, collaboration and contribution from a bunch of different people is much more important than having everything coming out of a single organization.

I want Dart to have a big, rich, thriving ecosystem, and I want lots and lots of people and organizations to be contributing to that, not just Google. That's how most of the other languages and communities that I admire work.

Cheers,

- bob


 

Colin

John Messerly

unread,
Aug 28, 2012, 2:01:58 PM8/28/12
to mi...@dartlang.org
On Mon, Aug 27, 2012 at 1:19 PM, Bob Nystrom <rnys...@google.com> wrote:
I think we all believe that it's critical that Dart be "batteries included". To get people to switch to Dart, it needs to have libraries for all of the major pieces of functionality that they are currently using in other languages.

At the same time, I don't think we expect every one of those batteries to be coming directly from Google. We are deeply committed to open source and the web community, and in that world, collaboration and contribution from a bunch of different people is much more important than having everything coming out of a single organization.

I want Dart to have a big, rich, thriving ecosystem, and I want lots and lots of people and organizations to be contributing to that, not just Google. That's how most of the other languages and communities that I admire work.


Well said Bob.

Allow me to take this discussion in a more concrete direction:

Is there anything we can do to make this better? I think one problem we have now is that people don't realize all the cool libraries (including UI ones) that already exist for Dart. I think Pub can definitely help here, by highlighting packages on pub.dartlang.org. I also opened http://dartbug.com/4779 with another idea (linking from Editor's Welcome Page to http://blog.dartwatch.com/p/community-dart-packages-and-examples.html).

Cheers,
- John

Keerti Parthasarathy

unread,
Aug 29, 2012, 1:20:16 PM8/29/12
to mi...@dartlang.org
Hey John, thanks for the suggestion. Coming soon to the Editor's Welcome page - link to the community dart packages and examples.


--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 



--
Keerti

John Evans

unread,
Aug 29, 2012, 1:24:32 PM8/29/12
to mi...@dartlang.org
Awesome!

Cliff Hall

unread,
Aug 29, 2012, 3:29:17 PM8/29/12
to mi...@dartlang.org
Thanks for that URL. Will be looking into this soon!

Cheers,
-=Cliff>


On Tuesday, August 21, 2012 10:13:11 AM UTC-4, John Evans wrote:
Yes they are.  There is no official timeline for it, yet.

If you're interested in exploring the latest and greatest, you may want to have a look at:  https://github.com/dart-lang/dart-web-components




On Tuesday, August 21, 2012 3:37:33 AM UTC-5, Abazilev wrote:

Андрей Базилевич

unread,
Aug 30, 2012, 3:58:33 AM8/30/12
to mi...@dartlang.org
Thank you!

2012/8/29 Cliff Hall <futur...@gmail.com>

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 



--
WBW, Andrey Bazilevich
Reply all
Reply to author
Forward
0 new messages