Dart 1.5(news.dartlang.org)
news.dartlang.org
Dart 1.5
http://news.dartlang.org/2014/06/dart-15-makes-it-easier-to-develop-for.html
14 comments
Hi! I'm on the Dart team. If you'd like, I'll try to answer any questions you have.
If Google is even half interested in Dart (which is seems to be, since it pays for the Dart team), why doesn't it do any proper moves to push it, besides for the browser which ain't gonna fly by itself?
1) Properly package and add "batteries" for a server side version of Dart. Pay some team to write a proper and complete Rails/Django or at least Flask level framework -- and document it.
2) Make a Google version of node.js using Dart instead of v8.
3) Even better, merge (1) and (2) for a serve side framework with both good syncrhonous (e.g Django like) and async (e.g Node like) story.
4) Support Dart as a first tier development language for Android.
1) Properly package and add "batteries" for a server side version of Dart. Pay some team to write a proper and complete Rails/Django or at least Flask level framework -- and document it.
2) Make a Google version of node.js using Dart instead of v8.
3) Even better, merge (1) and (2) for a serve side framework with both good syncrhonous (e.g Django like) and async (e.g Node like) story.
4) Support Dart as a first tier development language for Android.
[disclaimer: I work on the Dart team.]
1) Dart VM runs on the command line and server. You can access files, directories, sockets, HTTP, Web sockets, SSL, and more. So the core functionality is all there, out of the box.
2) When people say "node.js", they usually mean at least two different things. Forgive me if I'm assuming too much, but I'll try to answer. Node.js is "javascript + v8 + server", and the equivalent for Dart is "dart + dart vm + server". So we've delivered that. Sometimes, when people say "node.js", they mean "express + v8", and Dart has "shelf + dart vm". You can check out the shelf package here: https://pub.dartlang.org/packages/shelf
3) There are a few emerging server-side frameworks out there (I mentioned shelf above). Dart VM is asynchronous, so you'll get a Node-esque experience. There aren't plans to make a fully sync server API.
4) That would be cool!
1) Dart VM runs on the command line and server. You can access files, directories, sockets, HTTP, Web sockets, SSL, and more. So the core functionality is all there, out of the box.
2) When people say "node.js", they usually mean at least two different things. Forgive me if I'm assuming too much, but I'll try to answer. Node.js is "javascript + v8 + server", and the equivalent for Dart is "dart + dart vm + server". So we've delivered that. Sometimes, when people say "node.js", they mean "express + v8", and Dart has "shelf + dart vm". You can check out the shelf package here: https://pub.dartlang.org/packages/shelf
3) There are a few emerging server-side frameworks out there (I mentioned shelf above). Dart VM is asynchronous, so you'll get a Node-esque experience. There aren't plans to make a fully sync server API.
4) That would be cool!
> Pay some team to write a proper and complete Rails/Django or at least Flask level framework -- and document it.
> Dart VM runs on the command line and server. You can access files, directories, sockets, HTTP, Web sockets, SSL, and more. So the core functionality is all there, out of the box.
These aren't the same things and likely a major difference between a popular language and a non-popular language.
> Dart VM runs on the command line and server. You can access files, directories, sockets, HTTP, Web sockets, SSL, and more. So the core functionality is all there, out of the box.
These aren't the same things and likely a major difference between a popular language and a non-popular language.
Pretty much sums up my feeling about the responses too.
It's mostly "we provide the basics, let it to the not-really-that-big community to come up with the stuff you ask for" or "there's already some 10 ho-hum independent efforts for that", instead of: "we (Google), ourselves, will create, guide and provide top tier implementations for those things, like we do with Angular for example".
It's mostly "we provide the basics, let it to the not-really-that-big community to come up with the stuff you ask for" or "there's already some 10 ho-hum independent efforts for that", instead of: "we (Google), ourselves, will create, guide and provide top tier implementations for those things, like we do with Angular for example".
Can you write tutorials that don't require eclipse? Nobody who makes websites uses eclipse for that.
What is Google's vision for Dart going forward? Why is it not a primary language for Android?
I really like Dart. Google is pretty much the only company trying to break the tyranny of JS in browsers.
(e.g. Microsoft clearly said that they are betting on C# and .NET as their main offering for everything - would be nice if Google was capable of this sort of direct messages)
I really like Dart. Google is pretty much the only company trying to break the tyranny of JS in browsers.
(e.g. Microsoft clearly said that they are betting on C# and .NET as their main offering for everything - would be nice if Google was capable of this sort of direct messages)
I actually think microsoft is very much behind non-.net technologies as well nowadays.
My experience with their TypeScript initiative has been really smooth, feels like they're trying to improve JS instead of inventing something new (by sticking as close as possible to the ES.next specs). The generated JS is very close to the original, both in size as readability.
My experience with their TypeScript initiative has been really smooth, feels like they're trying to improve JS instead of inventing something new (by sticking as close as possible to the ES.next specs). The generated JS is very close to the original, both in size as readability.
disclaimer: I'm a huge fan of TypeScript and the folks working on it, but now work on Dart and JS stuff at Google, so I'm probably biased in all kinds of ways :)
The way I like to think of it:
If the main thing you want in JavaScript is types and classes, TypeScript is brilliant. It adds exactly those things, and does so in a very attractive and seamless way. Classes are already in EcmaScript 6, and I wouldn't be surprised if TypeScript annotations make it into a future version ES (there's a strawman proposal: http://wiki.ecmascript.org/doku.php?id=strawman:types), so the forward compatibility story is good too.
If you want to fix more things in JS, such as:
The way I like to think of it:
If the main thing you want in JavaScript is types and classes, TypeScript is brilliant. It adds exactly those things, and does so in a very attractive and seamless way. Classes are already in EcmaScript 6, and I wouldn't be surprised if TypeScript annotations make it into a future version ES (there's a strawman proposal: http://wiki.ecmascript.org/doku.php?id=strawman:types), so the forward compatibility story is good too.
If you want to fix more things in JS, such as:
* massively improve all core libraries and types
* improve the DOM
* add integers
* add operator overloading including [] []=
* make Map a distinct type, instead of all objects being maps
* switch from prototypes to classes
* removed undefined
* fix == operator
* remove implicit conversions
* tree shaking: no worries about which library is less KB's
* add named arguments
* add many features ES could add but at a faster velocity
* consistent libraries (e.g. Dart standardized on Futures)
* ... probably more stuff I'm forgetting ...
Dart is a platform play influenced by Javascript with some JS interop, but mostly requires its own new libraries and ecosystem, which allows many things to be fixed.
Typescript is a layer on top of Javascript and existing Javascript libraries that adds hybrid/latent typing. Typescript doesn't require a new ecosystem, but instead allows enhancements to the existing one.
Both approaches are valid.
(Disclaimer: MS employee, but had this discussion with Gilad a few weeks back)
Typescript is a layer on top of Javascript and existing Javascript libraries that adds hybrid/latent typing. Typescript doesn't require a new ecosystem, but instead allows enhancements to the existing one.
Both approaches are valid.
(Disclaimer: MS employee, but had this discussion with Gilad a few weeks back)
>Typescript is a layer on top of Javascript and existing Javascript libraries
With all horrible issues JS has: unpredictable perf, library hell.
Also my issues with TS are:
1) what if future ECMA will bring incompatible changes with current TS ? TS will break compatibility or we will have another EEE from MS ? Dart clean break seems like a safer approach.
2) there is no cross-platform IDE for TS (yea I know plugins - but Dart has stock cross-platform IDE)
3) TS perf will be always as good as JS
With all horrible issues JS has: unpredictable perf, library hell.
Also my issues with TS are:
1) what if future ECMA will bring incompatible changes with current TS ? TS will break compatibility or we will have another EEE from MS ? Dart clean break seems like a safer approach.
2) there is no cross-platform IDE for TS (yea I know plugins - but Dart has stock cross-platform IDE)
3) TS perf will be always as good as JS
Also Dart can evolve at 10x speed that JS does (can you believe that Harmony still hasn't arrived?).
Hi, I have two questions:
1. One big issue with JavaScript applications is that they are single threaded. Does Dart/Web Component platform provide any solution to this?
2. Will we see another UI rendering layer other than DOM for Dart?
1. One big issue with JavaScript applications is that they are single threaded. Does Dart/Web Component platform provide any solution to this?
2. Will we see another UI rendering layer other than DOM for Dart?
> One big issue with JavaScript applications is that they are single threaded. Does Dart/Web Component platform provide any solution to this?
Because Dart compiles to JavaScript, we're limited in some ways in what we can do here. We do, of course, support Web Workers, but those have a bunch of constraints that make them difficult to use in practice.
We have tried to make single-threaded async programming more pleasant. In particular, Dart comes with built-in, very rich Future and Stream types. Even better, those are deeply integrated into the code libraries, including the DOM.
Every asynchronous DOM operation in Dart returns a future, which is much more pleasant to deal with than raw callbacks. Likewise, things like events are exposed as streams, so you can map and transform them like any other stream of data.
I gave a talk on Dart at Strange Loop last year[1] that talks a bit about this. Skip to around 38 minutes.
> 2. Will we see another UI rendering layer other than DOM for Dart?
Good question! There are a few different frameworks that people have built for Dart that expose their own ways of expressing UI. I think they all ultimately fall back to the DOM because that's the primitive the browser gives you, but what you as a programmer deal with may be fairly removed from that.
These days, I mostly do command-line Dart stuff, so I don't have a good lay of the land here.
[1]: http://www.infoq.com/presentations/dart-introduction
Because Dart compiles to JavaScript, we're limited in some ways in what we can do here. We do, of course, support Web Workers, but those have a bunch of constraints that make them difficult to use in practice.
We have tried to make single-threaded async programming more pleasant. In particular, Dart comes with built-in, very rich Future and Stream types. Even better, those are deeply integrated into the code libraries, including the DOM.
Every asynchronous DOM operation in Dart returns a future, which is much more pleasant to deal with than raw callbacks. Likewise, things like events are exposed as streams, so you can map and transform them like any other stream of data.
I gave a talk on Dart at Strange Loop last year[1] that talks a bit about this. Skip to around 38 minutes.
> 2. Will we see another UI rendering layer other than DOM for Dart?
Good question! There are a few different frameworks that people have built for Dart that expose their own ways of expressing UI. I think they all ultimately fall back to the DOM because that's the primitive the browser gives you, but what you as a programmer deal with may be fairly removed from that.
These days, I mostly do command-line Dart stuff, so I don't have a good lay of the land here.
[1]: http://www.infoq.com/presentations/dart-introduction
Has there been much internal dogfooding, such that some external-facing thing I use is really powered by JavaScript that came out of dart2js?
If I'm using GWT, should I be thinking about using Dart instead?
If I'm using GWT, should I be thinking about using Dart instead?
> Has there been much internal dogfooding
Yes. We on the team, of course, use Dart heavily. My day job is working on pub, the package manager for Dart, and a slew of other libraries, all written in Dart. Our API[1] doc site is written in Dart.
Likewise, we have an increasing number of internal customers who give us the kind of feedback you only get from someone who isn't obligated to see your project succeed. :)
Obviously, a bunch of customers we can't talk about, but I can say that Google Elections and Google Fiber use Dart. Google has an internal sales tool also written using Dart and Angular.dart.
[1]: https://api.dartlang.org
Yes. We on the team, of course, use Dart heavily. My day job is working on pub, the package manager for Dart, and a slew of other libraries, all written in Dart. Our API[1] doc site is written in Dart.
Likewise, we have an increasing number of internal customers who give us the kind of feedback you only get from someone who isn't obligated to see your project succeed. :)
Obviously, a bunch of customers we can't talk about, but I can say that Google Elections and Google Fiber use Dart. Google has an internal sales tool also written using Dart and Angular.dart.
[1]: https://api.dartlang.org
re: GWT. GWT is still actively developed and making progress. I just talked with some GWT team members at I/O, and they're adding better JS-interop (like we are), incremental compilation, and are looking at web components support. One thing we talked about that would be nice is GWT-Dart interop, (if we get everything else done).
I'm biased, being on the Dart team, but I think Dart is a much nicer language that Java, so I would choose Dart for a new project. GWT might still be a good choice though if you have a large existing investment in Java that you can repurpose in the client. Many enterprises have hundreds of thousands or millions of lines of Java code that aren't going anywhere anytime soon.
So, should you think about Dart? I guess that depends on how ready or willing you are to migrate your code away form Java. If you were thinking about rewriting in JavaScript, then I'd definitely say consider Dart. If you're happy with Java and GWT, then you can keep going that direction.
I'm biased, being on the Dart team, but I think Dart is a much nicer language that Java, so I would choose Dart for a new project. GWT might still be a good choice though if you have a large existing investment in Java that you can repurpose in the client. Many enterprises have hundreds of thousands or millions of lines of Java code that aren't going anywhere anytime soon.
So, should you think about Dart? I guess that depends on how ready or willing you are to migrate your code away form Java. If you were thinking about rewriting in JavaScript, then I'd definitely say consider Dart. If you're happy with Java and GWT, then you can keep going that direction.
Although it won't fix all the language boilerplate problems, we are also adding Java 8 support to GWT shortly, which does let you go from this nastiness :)
button.addEventListener("click", new EventListener() {
to this:
button.addEventListener("click", e -> Window.alert("hello"));
button.addEventListener("click", new EventListener() {
public void onEvent(Event e) { Window.alert("Hello"); }
to this:
button.addEventListener("click", e -> Window.alert("hello"));
Awesome!
How well does Dart interact with JavaScript, especially libraries that are asynchronously loaded? I know that the Dart compiler is a whole-program optimizer, and I get the impression that Dart wants to own all the code on the page.
In my line of work (web analytics), I have to use third-party JavaScript libraries in order to integrate tools onto my page, like Adobe Analytics (formerly Omniture SiteCatalyst) or IBM CoreMetrics or WebTrends. Fully instrumenting a page generally involves wiring up other JavaScript on the page with event handlers for web analytics functions (e.g. video play/pause/progress, with video name & length as parameters).
Most analytics tools are also moving towards asychronously-loaded script-injection techniques, like Adobe DTM or Ensighten. These usually include the ability to selectively load relevant libraries, like only having video tracking on video pages.
What's Dart's story for interacting with tools like that?
In my line of work (web analytics), I have to use third-party JavaScript libraries in order to integrate tools onto my page, like Adobe Analytics (formerly Omniture SiteCatalyst) or IBM CoreMetrics or WebTrends. Fully instrumenting a page generally involves wiring up other JavaScript on the page with event handlers for web analytics functions (e.g. video play/pause/progress, with video name & length as parameters).
Most analytics tools are also moving towards asychronously-loaded script-injection techniques, like Adobe DTM or Ensighten. These usually include the ability to selectively load relevant libraries, like only having video tracking on video pages.
What's Dart's story for interacting with tools like that?
> How well does Dart interact with JavaScript, especially libraries that are asynchronously loaded?
I'm not the best person to ask about JS interop, but I know it's something that other people on the team put a lot of effort into.
> I know that the Dart compiler is a whole-program optimizer, and I get the impression that Dart wants to own all the code on the page.
dart2js likes to have access to all of the Dart code while it's compiling, so it can do global optimization, but as far as I know, that doesn't affect JS interop. Talking to JS is all dynamically dispatched at runtime, so the compiler doesn't really care about it.
(We can also do deferred loading of Dart code now too, though I don't know the details.)
> What's Dart's story for interacting with tools like that?
Beyond the general JS interop story, I don't know if we've done anything specific there. I believe you should be able to talk to JS code even if it's loaded much later.
I'm not the best person to ask about JS interop, but I know it's something that other people on the team put a lot of effort into.
> I know that the Dart compiler is a whole-program optimizer, and I get the impression that Dart wants to own all the code on the page.
dart2js likes to have access to all of the Dart code while it's compiling, so it can do global optimization, but as far as I know, that doesn't affect JS interop. Talking to JS is all dynamically dispatched at runtime, so the compiler doesn't really care about it.
(We can also do deferred loading of Dart code now too, though I don't know the details.)
> What's Dart's story for interacting with tools like that?
Beyond the general JS interop story, I don't know if we've done anything specific there. I believe you should be able to talk to JS code even if it's loaded much later.
> How well does Dart interact with JavaScript, especially libraries that are asynchronously loaded? I know that the Dart compiler is a whole-program optimizer, and I get the impression that Dart wants to own all the code on the page.
Great question. Generally dart:js will let you do interop: https://www.dartlang.org/articles/js-dart-interop/. It's designed to interact pretty well with the dart2js compiler. However it feels a lot like you're using a foreign function interface. For example, calling a the global method Object.keys is: js.context['Object'].callMethod('keys', [obj]);
For Custom Elements (one of the new web components specs) we did something better: you can register the Dart wrapper type associated with that element. Then whenever you get one of those elements, it automatically looks like the Dart type. We used this heavily in the new core_elements and paper_elements packages. Here's an example of defining a type like that: https://github.com/dart-lang/core-elements/blob/master/lib/c...
Ultimately we'd like to make something similar for all JavaScript objects and expose it from dart:js. That would make interop almost seamless (especially if we could generate the types from DefinitelyTyped's APIs).
Great question. Generally dart:js will let you do interop: https://www.dartlang.org/articles/js-dart-interop/. It's designed to interact pretty well with the dart2js compiler. However it feels a lot like you're using a foreign function interface. For example, calling a the global method Object.keys is: js.context['Object'].callMethod('keys', [obj]);
For Custom Elements (one of the new web components specs) we did something better: you can register the Dart wrapper type associated with that element. Then whenever you get one of those elements, it automatically looks like the Dart type. We used this heavily in the new core_elements and paper_elements packages. Here's an example of defining a type like that: https://github.com/dart-lang/core-elements/blob/master/lib/c...
Ultimately we'd like to make something similar for all JavaScript objects and expose it from dart:js. That would make interop almost seamless (especially if we could generate the types from DefinitelyTyped's APIs).
Hi, I'm on the Dart team too and maintain dart:js which allows you to call JavaScript from Dart. I'm a little busy right this second, but ask any questions and I'll be glad to answer them!
You can read more about the JS-Interop support here: https://www.dartlang.org/articles/js-dart-interop/
Dart in Chrome?
Dart on Android?
Will the Dart IDE look correctly on Windows 8 high-dpi devices? (I know that's partially an Eclipse problem)
In fact, what is the future of Dart? Is it just a complement to browser-based JavaScript?
Dart on Android?
Will the Dart IDE look correctly on Windows 8 high-dpi devices? (I know that's partially an Eclipse problem)
In fact, what is the future of Dart? Is it just a complement to browser-based JavaScript?
> Dart in Chrome?
We're working on it! Having two language virtual machines with objects that can contain references to each other is quite technically challenging. There's a bunch of work to be done to address that[1]. Along the way, we're working with the larger Chrome team to address any other requirements they have.
> Dart on Android?
The Dart VM does run on Android right now [2]. My understanding is that the performance is impressive relative to Dalvik/ART, though don't quote me on that.
[1]: https://groups.google.com/a/chromium.org/forum/#!topic/blink... [2]: https://code.google.com/p/dart/wiki/Android
> Will the Dart IDE look correctly on Windows 8 high-dpi devices?
Aside from the splash screen, it looks nice and sharp on my retina Mac.
> In fact, what is the future of Dart? Is it just a complement to browser-based JavaScript?
We're working to make it a comprehensive web language, both client and server-side.
We're working on it! Having two language virtual machines with objects that can contain references to each other is quite technically challenging. There's a bunch of work to be done to address that[1]. Along the way, we're working with the larger Chrome team to address any other requirements they have.
> Dart on Android?
The Dart VM does run on Android right now [2]. My understanding is that the performance is impressive relative to Dalvik/ART, though don't quote me on that.
[1]: https://groups.google.com/a/chromium.org/forum/#!topic/blink... [2]: https://code.google.com/p/dart/wiki/Android
> Will the Dart IDE look correctly on Windows 8 high-dpi devices?
Aside from the splash screen, it looks nice and sharp on my retina Mac.
> In fact, what is the future of Dart? Is it just a complement to browser-based JavaScript?
We're working to make it a comprehensive web language, both client and server-side.
An interesting advantage compared to Dalvik (or the JVM) is the ability to make use of SIMD. If your bottleneck would benefit from SIMD, you can gain quite a lot.
It does of course require some additional work, but thanks to operator overloading it looks fairly nice.
It does of course require some additional work, but thanks to operator overloading it looks fairly nice.
>Aside from the splash screen, it looks nice and sharp on my retina
Heh, I believe it, but it is a bit of a mess on high-dpi Windows 8 machines (e.g. Lenovo Yoga 2 pro). Some elements get scaled, some don't, and the entire thing looks broken. It is functional, just ugly.
Heh, I believe it, but it is a bit of a mess on high-dpi Windows 8 machines (e.g. Lenovo Yoga 2 pro). Some elements get scaled, some don't, and the entire thing looks broken. It is functional, just ugly.
Thanks for coming to answer questions. How this 1.5 release is related with the work in progress in the Ecma TC52 for Dart Standardization?
The two are mostly decoupled. The core language hasn't changed much since 1.0, and I think TC 52 is mostly focused on nailing down stuff that either shipped before 1.5 or won't appear until after.
I don't know many details here, though. The committee is still pretty new and the communication channels are still being set up.
I don't know many details here, though. The committee is still pretty new and the communication channels are still being set up.
Is there any chance there will be more support for Dart on Android?[1]
[1] More than https://code.google.com/p/dart/wiki/Android
[1] More than https://code.google.com/p/dart/wiki/Android
You may want to follow this thread: Support building native Android applications with Dart
https://code.google.com/p/dart/issues/detail?id=19266
https://code.google.com/p/dart/issues/detail?id=19266
Would be neat if they had an adapter for the polymer stuff so that a "material" UI could be rendered in a webpage or with Android's native UI depending on the execution context and no changes to the app code (written in Dart). On the edge of possible, but a lot of work.
That should work as of this week with Polymer's paper-elements: http://www.polymer-project.org/docs/elements/material.html, available for Dart at https://github.com/dart-lang/paper-elements.
You could either build it as a mobile web app, or if you need more of Android's APIs there's https://cordova.apache.org/.
You could either build it as a mobile web app, or if you need more of Android's APIs there's https://cordova.apache.org/.
Planning to build NodeJS like env in Dart?
I'd like to Dart to happen. What worries my is that Dart has Java EE mentality. Hipster programmers won't touch it and lack of traction may kill the project. What's the solution? Performance may be a great USP. Rewrite Gmail in Dart, so tools like Streak, Rapportive and other extensions won't kill the performance.
I'd like to Dart to happen. What worries my is that Dart has Java EE mentality. Hipster programmers won't touch it and lack of traction may kill the project. What's the solution? Performance may be a great USP. Rewrite Gmail in Dart, so tools like Streak, Rapportive and other extensions won't kill the performance.
> Planning to build NodeJS like env in Dart?
We aren't planning it, we've already done it. Dart comes with a command-line VM with a full-featured (IO, networking, etc.) set of libraries[1].
The performance is quite good and getting better[2], from what I understand.
[1]: https://api.dartlang.org/apidocs/channels/stable/dartdoc-vie... [2]: https://www.dartlang.org/performance/io/
We aren't planning it, we've already done it. Dart comes with a command-line VM with a full-featured (IO, networking, etc.) set of libraries[1].
The performance is quite good and getting better[2], from what I understand.
[1]: https://api.dartlang.org/apidocs/channels/stable/dartdoc-vie... [2]: https://www.dartlang.org/performance/io/
Hi! The Dart VM does run on the command line, and can access files, directories, sockets, HTTP, web sockets, and more. The Dart VM is an asynchronous light-weight server. I don't think Dart has a Java EE mentality. Far from it. :)
[disclaimer: I work on the Dart team.]
[disclaimer: I work on the Dart team.]
The SDK is shipped with a standalone version of the VM which can do I/O (via the 'dart:io' package). You can use it to write command line applications and web servers. Basically, it's like Node right off the bat.
I/O performance increased drastically with 1.3. The performance is tracked over here:
https://www.dartlang.org/performance/io/
1.4 added experimental support for ServerSocket references, which allow you to share a socket across isolates (~"workers"):
https://groups.google.com/a/dartlang.org/forum/#!topic/misc/...
I/O performance increased drastically with 1.3. The performance is tracked over here:
https://www.dartlang.org/performance/io/
1.4 added experimental support for ServerSocket references, which allow you to share a socket across isolates (~"workers"):
https://groups.google.com/a/dartlang.org/forum/#!topic/misc/...
The round-9 techempower benchmark shows Dart as very impressive in its "Multiple Queries" runs. However, the json serialization not so much. Is there something in the works to speed this up or technical reasons it does not shine here?
Also, what are the plans for speeding up regular expresssions?
With Dart 1.5 announced, I am interested in ensuring that Round 10 includes 1.5. I just posted a question [1] to our most active Dart test contributor: does the >= 1.3.0 specified in the pubspec.yaml ensure that we'll be testing on 1.5 in Round 10 or should we be more explicit about 1.5.0? If anyone else knows the answer I'd appreciate the feedback.
[1] https://github.com/TechEmpower/FrameworkBenchmarks/pull/864
[1] https://github.com/TechEmpower/FrameworkBenchmarks/pull/864
It will just cause a `pub get` fail (Package foo requires SDK version >=1.5.0 but the current SDK is x.x.x), but it won't prevent the application from running. Only `pub` cares about that pubspec.yaml file.
There's a bunch of web frameworks that already as well:
Redstone is becoming increasingly popular: http://luizmineo.github.io/redstone.dart/
Whilst I've built a simple Express-like API: https://github.com/dartist/express
Which also includes a complete port of node's popular jade view engine: https://github.com/dartist/jaded
Redstone is becoming increasingly popular: http://luizmineo.github.io/redstone.dart/
Whilst I've built a simple Express-like API: https://github.com/dartist/express
Which also includes a complete port of node's popular jade view engine: https://github.com/dartist/jaded
Are there any plans to introduce generators or async/await?
Yes! From Gilad:
> We are working out a proposal that is somewhat similar to async-await in C#. Again, we hope to finalize that in time for the next rev of the standard. Details as soon as coherent articles explaining it all can be put together.
> We are working out a proposal that is somewhat similar to async-await in C#. Again, we hope to finalize that in time for the next rev of the standard. Details as soon as coherent articles explaining it all can be put together.
I'd like to know too. As clunky as JS is, generators make possible some pretty interesting stuff[1] that I would miss in Dart.
[1] https://github.com/visionmedia/co
[1] https://github.com/visionmedia/co
It sounds like they will add support for the same constructs as JS will have in ES7 https://github.com/lukehoban/ecmascript-asyncawait
Why does "Dart SDK (64-bit Windows)" contain 32-bit Windows dart.exe binary?
Up until recently due to some issues with build scripts and MSVC parameters our bots building 64-bit SDK on Windows were just silently building 32-binaries. I have fixed[1] it couple of weeks ago, but my fix did not make it into 1.5. Sadly it's not just a build script fix, but also some changes in Dart VM to accommodate for ABI differences, so we decided not to merge. Next release will have 64-bit dart binary on Windows. Bleeding edge SDKs already contain correct version of dart binary.
[1] https://code.google.com/p/dart/source/detail?r=37078
[1] https://code.google.com/p/dart/source/detail?r=37078
I recall hearing someone at the office mention that, but I don't know the details. File a bug or ask on the mailing list and someone who knows better than me can sort it out.
Dart rocks, thanks to team for the great work
What is your take on swift? Do you think dart can borrow some ideas from swift? Most of it is just syntax sugar, but it is very pleasant to look and work with.
The main thing I miss from Swift is its extensibility letting you extend primitive types like Arrays or Strings, this lets you easily add LINQ-like capabilities even tho Swift doesn't ship with many, see: https://github.com/mythz/swift-linq-examples
Dart comes with a rich functional and Stream API's on collections so most of the time you wont need to extend it (same LINQ examples in Dart: https://github.com/dartist/101LinqSamples), but unfortunately you can't extend built-in (or external) types which means you need to use top-level methods which can break-up the flow of your beautiful expression flows. Extensions is also important for minimizing unnecessary abstraction and maximizing re-usability since you can extend without being forced to create foreign wrapper API's.
IMO Extensions are one of the most important traits for keeping a minimal friction-free language, something I see Go and Swift benefiting a lot from.
Dart does have powerful mixins (https://www.dartlang.org/articles/mixins/) but you can only mixin into classes you define (i.e. not built-in or external types).
But otherwise I find Dart's optional-typing a tonne more productive than Swift's strict type inference / generic enforcement, Dart also has a rich consistent library, integrated package manager, static analyzer and overall better development experience.
Although there's little overlap as Swift is mainly for creating iOS/OSX desktop apps and Dart is focused on rich Web Apps. Basically the only times when you'd be able to choose one or the other is in command-line scripts, I'd still prefer to use Dart for.
Dart comes with a rich functional and Stream API's on collections so most of the time you wont need to extend it (same LINQ examples in Dart: https://github.com/dartist/101LinqSamples), but unfortunately you can't extend built-in (or external) types which means you need to use top-level methods which can break-up the flow of your beautiful expression flows. Extensions is also important for minimizing unnecessary abstraction and maximizing re-usability since you can extend without being forced to create foreign wrapper API's.
IMO Extensions are one of the most important traits for keeping a minimal friction-free language, something I see Go and Swift benefiting a lot from.
Dart does have powerful mixins (https://www.dartlang.org/articles/mixins/) but you can only mixin into classes you define (i.e. not built-in or external types).
But otherwise I find Dart's optional-typing a tonne more productive than Swift's strict type inference / generic enforcement, Dart also has a rich consistent library, integrated package manager, static analyzer and overall better development experience.
Although there's little overlap as Swift is mainly for creating iOS/OSX desktop apps and Dart is focused on rich Web Apps. Basically the only times when you'd be able to choose one or the other is in command-line scripts, I'd still prefer to use Dart for.
What does Dart do to improve/address security for web? Is there any advantage of using Dart over JS in terms of security?
Thank you.
Thank you.
Yes, there is!
I don't know the details, but I believe sanitize uses of innerHTML to avoid some common security vulnerabilities. More details here: https://groups.google.com/a/dartlang.org/forum/#!topic/misc/...
I don't know the details, but I believe sanitize uses of innerHTML to avoid some common security vulnerabilities. More details here: https://groups.google.com/a/dartlang.org/forum/#!topic/misc/...
How practical is today to start with Dart for web apps instead of Javascript? speaking from someone who doesn't know JS.
It's very familiar if you're a C# or Java developer and provides a rich, clean and consistent API library which abstracts away JavaScript and DOM apis: https://api.dartlang.org/apidocs/channels/stable/dartdoc-vie...
The code-labs provide pretty good, practical walk-thru's: http://io2014codelabs.appspot.com/static/codelabs/dart-start...
The code-labs provide pretty good, practical walk-thru's: http://io2014codelabs.appspot.com/static/codelabs/dart-start...
One of the things that for some reason really confuses me about Dart even though it probably shouldn't is it's status as being full stack.
I really want to use AngularDart for the front end of an application I am using and I would like to use Rails for the back end as well as some static content. I can't seem to find an easy way to make that happen. In addition, how does Dart interact with existing JavaScript libraries?
I really want to use AngularDart for the front end of an application I am using and I would like to use Rails for the back end as well as some static content. I can't seem to find an easy way to make that happen. In addition, how does Dart interact with existing JavaScript libraries?
You can find JS Interop docs at: https://www.dartlang.org/articles/js-dart-interop/
IMO integration is as straight-forward as it gets, basically just use a HTTP Client to call JSON services. Here's an AngularDart example for calling a REST backend: http://japhr.blogspot.com/2013/10/http-requests-in-angularda...
I've also created a JsonClient that provides a terse API for calling JSON services: https://github.com/dartist/json_client
IMO integration is as straight-forward as it gets, basically just use a HTTP Client to call JSON services. Here's an AngularDart example for calling a REST backend: http://japhr.blogspot.com/2013/10/http-requests-in-angularda...
I've also created a JsonClient that provides a terse API for calling JSON services: https://github.com/dartist/json_client
So in theory it's as easy as using AngularDart and compiling the javascript and throwing that in my rails assets? I feel like I knew that and for some reason it blows my mind.
We use a similar stack except using TypeScript with Angular but keep the Rails backend.
Essentially your Angular code should boil down to one JS file, one CSS file and be hosted in an index.html. If you're dealing with modern browsers a bit of fiddling with the cross domain policy and the withCredentials flag will allow you to host the static assets anywhere (not the same domain as the Rails box).
Otherwise the easiest thing to do is compile into the /public folder of Rails. I wouldn't host in assets as you'll likely be using gulp / grunt so the compilation phase that Rails assets hosting provides will be done for you already.
Essentially your Angular code should boil down to one JS file, one CSS file and be hosted in an index.html. If you're dealing with modern browsers a bit of fiddling with the cross domain policy and the withCredentials flag will allow you to host the static assets anywhere (not the same domain as the Rails box).
Otherwise the easiest thing to do is compile into the /public folder of Rails. I wouldn't host in assets as you'll likely be using gulp / grunt so the compilation phase that Rails assets hosting provides will be done for you already.
After fighting and fighting with the asset pipeline I finally realized I could just use gulp to build to my public folder and completely avoid fucking with it. It was an amazing moment of clarity for me.
Is anybody using Dart for significant production code outside of Google? (Not mocking, genuinely curious to hear whats being done with it)
I use Dart in production, it has its advatages like:
1.- It is better than JavaScript, is like using C# with a litle mix of Java.
2.- It comes with its own libraries, no more underscore.js or other patch libraries that JS needs, it is already in the toolkit.
3.- It comes with the Dart Editor, where you can debug your code easily, for scalable projects I find this to be invaluable.
4.- It will run in all your browsers, because it will export your code to JavaScript, but not only export it, it will optimize it and will run really fast.
5.- The pub library, go to pub.dartlang.org and you will find lots of packages that you can install and use, like a bootjack, a bootstrap port in Dart.
There are prolly many more, but these are the ones that come to my head right now.
But it also has its own problems like:
1.- No Dart support for Chrome yet and we don't know if there will ever be at this point.
2.- The generated JavaScript will be huge, and I mean huge, mine is like 460k per file and I'm not using polymer, when I used polymer the generated JavaScript was over one megabyte, just insane in the cloud.
3.- Get use to regressions, with every point update I've have issues, I upgraded from 1.4 to 1.5 two days ago, now my code is broken It runs, but it will for example run futures twice, So I went back to 1.4 for now, I had some other issues with UTF when migrating from 1.3 to 1.4 so, get use to.
4.- They are slow fixing bugs, looks like polymer and speed are their priorities, but when you need something trivial that other languajes have had for years and you report a bug it will get ignored, I've waited for 18 months and my open bugs are not fixed yet.
I would say that Dart is nice and you should give it a chance.
1.- It is better than JavaScript, is like using C# with a litle mix of Java.
2.- It comes with its own libraries, no more underscore.js or other patch libraries that JS needs, it is already in the toolkit.
3.- It comes with the Dart Editor, where you can debug your code easily, for scalable projects I find this to be invaluable.
4.- It will run in all your browsers, because it will export your code to JavaScript, but not only export it, it will optimize it and will run really fast.
5.- The pub library, go to pub.dartlang.org and you will find lots of packages that you can install and use, like a bootjack, a bootstrap port in Dart.
There are prolly many more, but these are the ones that come to my head right now.
But it also has its own problems like:
1.- No Dart support for Chrome yet and we don't know if there will ever be at this point.
2.- The generated JavaScript will be huge, and I mean huge, mine is like 460k per file and I'm not using polymer, when I used polymer the generated JavaScript was over one megabyte, just insane in the cloud.
3.- Get use to regressions, with every point update I've have issues, I upgraded from 1.4 to 1.5 two days ago, now my code is broken It runs, but it will for example run futures twice, So I went back to 1.4 for now, I had some other issues with UTF when migrating from 1.3 to 1.4 so, get use to.
4.- They are slow fixing bugs, looks like polymer and speed are their priorities, but when you need something trivial that other languajes have had for years and you report a bug it will get ignored, I've waited for 18 months and my open bugs are not fixed yet.
I would say that Dart is nice and you should give it a chance.
> 2.- The generated JavaScript will be huge, and I mean huge, mine is like 460k per file and I'm not using polymer, when I used polymer the generated JavaScript was over one megabyte, just insane in the cloud.
If you include all of your 'standard' libraries in a JS app, it can be pretty big. I basically pull everything together for an Ember app I work on, and all-told it's ~3MB prior to minification. Minification takes it down to ~1.5MB, and Gzip-compression on the server takes it sub-1MB (can't recall the number off-hand). It's not that far off from what you might have in a JS-heavy app.
If you include all of your 'standard' libraries in a JS app, it can be pretty big. I basically pull everything together for an Ember app I work on, and all-told it's ~3MB prior to minification. Minification takes it down to ~1.5MB, and Gzip-compression on the server takes it sub-1MB (can't recall the number off-hand). It's not that far off from what you might have in a JS-heavy app.
Tree shaking is what you lack (yes I know Dart has tree shaking but its cross compilation has a big result)!
I love the closure compiler in advanced mode for this reason.
Thanks for the helpful feedback! The latest version of Polymer.dart removes the need for reflection at compile time, and our output is much smaller today. Curious when you last tried compiling a Polymer Dart app?
[disclaimer: I work for the Dart team.]
[disclaimer: I work for the Dart team.]
The last time I used polymer was in Dart 1.3 I believe, then I migrated all to "dart:html" and started managing all the DOM events my self, so, I'm afraid I can't give you that information. Btw, thanks for your hard work, I really apreciate it.
Our pleasure. If you're curious, I'd recommend trying Polymer.dart again. The latest version (0.11) has a transformer that replaces the reflection code with static code. The resulting output is much smaller. :)
Given the size of the generated JS file, do you find it is an issue?
When you host your Project in the cloud and you pay for the bandwidth quota then you learn the value of small generated JavaScript, but if it is a Project where bandwidth does not generate a cost like an intranet or VPN, then it doesn't really matter.
Does it have anything like AngularJS?
As mentioned already, there is AngularDart, but we also have a full port of Polymer to Dart, so you can write web components in Dart.
https://www.dartlang.org/polymer-dart/
We also have Dart packages for the Polymer project's core-elements and paper-elements (Material Design, nee Quantum Paper) that were announced at I/O.
http://pub.dartlang.org/packages/paper_elements
Web components and Dart is a really powerful combination for apps.
https://www.dartlang.org/polymer-dart/
We also have Dart packages for the Polymer project's core-elements and paper-elements (Material Design, nee Quantum Paper) that were announced at I/O.
http://pub.dartlang.org/packages/paper_elements
Web components and Dart is a really powerful combination for apps.
It has AngularDart, an official port of AngularJS to Dart. Seems promising, will try it if and only if Dart gets native support in Chrome.
You mean like https://angulardart.org/
[deleted]
[deleted]
Yes, it has AngulartDart.
I think Blossom [1] switched to it. They had some articles on their blog about the switch [2].
[1] https://www.blossom.io/ [2] http://www.ramen.io/post/46936028144/we-are-switching-to-dar...
[1] https://www.blossom.io/ [2] http://www.ramen.io/post/46936028144/we-are-switching-to-dar...
Thanks for the mention (CEO here).
We're super happy with Dart & really excited about polymer. Love the language & platform in general.
We'll put out some essays, code snippets & lessons learned in the next few days :)
Stay tuned.
We're super happy with Dart & really excited about polymer. Love the language & platform in general.
We'll put out some essays, code snippets & lessons learned in the next few days :)
Stay tuned.
[deleted]
Yup. At Sendbloom.co we have used Dart to build a tool that is used by sales people to send out email campaigns. The tool is inspired by quartz composer/Max MSP's interaction paradigms (drag-and-drop visual programming).
As someone else mentioned, Dart code can be fairly verbose, but it is very readable and programming with it is a joy when compared to writing vanilla javascript/jquery.
I'd be happy to answer if you have any other questions about Dart.
I would love to see a demo of that!
And how are you finding Dart to be verbose? In my experience it can be more concise than JS because of short lambdas, no function keyword, method cascades, real classes, the fluent Iterable and Stream interfaces.
On the other hand, I see some Dart programmers use a lot of classes and type all their variables. I'm curious what ended up being verbose for you.
And how are you finding Dart to be verbose? In my experience it can be more concise than JS because of short lambdas, no function keyword, method cascades, real classes, the fluent Iterable and Stream interfaces.
On the other hand, I see some Dart programmers use a lot of classes and type all their variables. I'm curious what ended up being verbose for you.
Surprisingly few Google properties on there, I must say. Yes, many most certainly have large existing code-bases, but that it doesn't include things like the new Google Maps (which, AIUI, has relatively little in common with the old version) seems… interesting.
Google Maps was almost certainly started before Dart was released.
I was at last year's Google IO and a lot of people were asking the Dart representatives about whether Dart was going to be supported in Chrome (not just Chromium). We were told the team was holding off because of performance considerations. It has been ONE WHOLE YEAR since then.
There were changes needed on Blink side (Oilpan project) and this sort of things take time.
Oilpan project: https://docs.google.com/presentation/d/1YtfurcyKFS0hxPOnC3U6...
You can track Darts's performance here: https://www.dartlang.org/performance/
Oilpan project: https://docs.google.com/presentation/d/1YtfurcyKFS0hxPOnC3U6...
You can track Darts's performance here: https://www.dartlang.org/performance/
I'd much rather they keep holding off. We've had more than enough of big companies fragmenting the ecosystem by making their own languages, file formats etc. because they can. As things currently stand, Dart compiles to JavaScript, which is exactly the right way to do it; that way it's a tool that's available if you want to use it, but it doesn't screw up interoperability.
>As things currently stand, Dart compiles to JavaScript, which is exactly the right way to do it
That was never going to change. The idea, as far as I understand it, is for Dart to be executed natively where there is a Dart VM. Where there isn't, the dart2js output would be executed. The DOM itself would be unchanged. I think that's reasonable. In fact, more than reasonable, that's just a good idea.
That was never going to change. The idea, as far as I understand it, is for Dart to be executed natively where there is a Dart VM. Where there isn't, the dart2js output would be executed. The DOM itself would be unchanged. I think that's reasonable. In fact, more than reasonable, that's just a good idea.
The danger is that the VM has different semantics (for example, integer overflow) than dart2js code. If the same dart code sometimes runs in JS and sometimes in the dart VM, people are going to hit weird bugs.
Also, if it is possible to ship dart code by itself - without the JS fallback - then we are going to see sites that don't bother with the JS fallback, and those sites are only going to work in chrome.
For both of those reasons, the dart VM is somewhat worrying from the perspective of the openness of the web.
Also, if it is possible to ship dart code by itself - without the JS fallback - then we are going to see sites that don't bother with the JS fallback, and those sites are only going to work in chrome.
For both of those reasons, the dart VM is somewhat worrying from the perspective of the openness of the web.
A lot of those objections could have been applied to SPDY, a protocol google developed unilaterally and initially was only supported in Chrome and Google sites. The end result was that everybody else got a regular experience while Google Service <-> Chrome users got a better one. Other sites started including SPDY, and then browsers got in on it as well. Seemed to have worked out well.
I don't see how Dart would be any different. You can cook up worst-case hypothetical scenarios in which Dart-only sites exist because the developer was OK with cutting off half his customers, and was too lazy to generate the js output (it's not like there are vendor-specific prefixes, and even technologies like WebGL, or WebRTC that don't work universally in all browsers).
>For both of those reasons, the dart VM is somewhat worrying from the perspective of the openness of the web.
In the absolute "worst" case, Dart (an ECMA standardized language at that point) becomes very popular and forces other vendors to include a Dart VM. I'm willing to live in such a world. More likely, Dart becomes a complement to JavaScript when it comes to building RIAs in the browser (because JS is really really bad when it comes to writing and maintaining big codebases), though JS still reigns as King of the Web.
I don't see how Dart would be any different. You can cook up worst-case hypothetical scenarios in which Dart-only sites exist because the developer was OK with cutting off half his customers, and was too lazy to generate the js output (it's not like there are vendor-specific prefixes, and even technologies like WebGL, or WebRTC that don't work universally in all browsers).
>For both of those reasons, the dart VM is somewhat worrying from the perspective of the openness of the web.
In the absolute "worst" case, Dart (an ECMA standardized language at that point) becomes very popular and forces other vendors to include a Dart VM. I'm willing to live in such a world. More likely, Dart becomes a complement to JavaScript when it comes to building RIAs in the browser (because JS is really really bad when it comes to writing and maintaining big codebases), though JS still reigns as King of the Web.
SPDY does have some similarities, but the differences here are very large.
As I said, Dart runs differently in the VM and in dart2js. SPDY was just not present in other browsers at first. So there wasn't a case of sites breaking in subtle and hard to debug ways in SPDY, but there is in Dart. (Later, when other browsers started to support SPDY, there were the usual spec issues, but that's a separate matter.)
The second issue I raised was that someone could ship Dart code alone, without the JS fallback. In that case, it is indeed more similar to SPDY, as someone could in principle write a SPDY-only website. Even here there is a difference, though - SPDY relies on client+server interaction. Dart is client-only (there's a Dart server, but that's not relevant here). Client-only code can more easily stay on the web for a long time, possibly forgotten and unmaintained. But this might be a small difference, so I somewhat agree with you on this point, but disagree on the previous.
As I said, Dart runs differently in the VM and in dart2js. SPDY was just not present in other browsers at first. So there wasn't a case of sites breaking in subtle and hard to debug ways in SPDY, but there is in Dart. (Later, when other browsers started to support SPDY, there were the usual spec issues, but that's a separate matter.)
The second issue I raised was that someone could ship Dart code alone, without the JS fallback. In that case, it is indeed more similar to SPDY, as someone could in principle write a SPDY-only website. Even here there is a difference, though - SPDY relies on client+server interaction. Dart is client-only (there's a Dart server, but that's not relevant here). Client-only code can more easily stay on the web for a long time, possibly forgotten and unmaintained. But this might be a small difference, so I somewhat agree with you on this point, but disagree on the previous.
Do you have any example other than integer overflow?
It's the only difference I've ever heard referenced.
The Dart team spends enormous efforts on maintaining JS-compatibility, so much so that it rejects adding any language features that can't efficiently compile to JS.
It's the only difference I've ever heard referenced.
The Dart team spends enormous efforts on maintaining JS-compatibility, so much so that it rejects adding any language features that can't efficiently compile to JS.
Another example where the VM and dart2js differ is, as others linked to elsewhere in this discussion, that dart2js relies on undefined/unspecced behavior in browsers,
https://code.google.com/p/dart/issues/detail?id=13285
In other words a dart2js app can break after a browser update, fail to run on a new browser that is fully standards compliant, etc.
https://code.google.com/p/dart/issues/detail?id=13285
In other words a dart2js app can break after a browser update, fail to run on a new browser that is fully standards compliant, etc.
Here is a question to consider: can the web where you can't efficiently[1] implement any dynamic language with a semantics different from JavaScript be called truly open?
[1] I am well aware about different attempts to attack this issue from various angles from AOT to JIT generating JS code but no attempt currently produces truly efficient solution that demonstrates small footprint and consistent high performance on par with native VM across all of the web or even across its relatively modern part.
[1] I am well aware about different attempts to attack this issue from various angles from AOT to JIT generating JS code but no attempt currently produces truly efficient solution that demonstrates small footprint and consistent high performance on par with native VM across all of the web or even across its relatively modern part.
First, you're using "open" in a way I haven't heard before (not in the context of "open web"). Not saying it's wrong :) Perhaps we should use it that way too. But you're suggesting a new perspective here. We could debate that first, before debating the technical stuff. Or perhaps we could call it "technologically open."
But to focus on the more interesting technical stuff: First, we have a fast Lua VM port. Not LuaJIT, but even the Lua VM itself is quite fast for a dynamic language (and the port is 2/3 of native speed).
Second, there are experiments with JITs targeting JS, like pypy.js. Yes, pypy.js has a large footprint, as you referred to. But I think the fact is that very little effort has gone into this. Much more is possible than has already been done.
If we had a large, serious project doing this, I think we could see the potential. Instead, things like pypy.js are spare-time projects of a single person. So it's not fair to assume that their success or failure in terms of performance and footprint is indicative.
But to focus on the more interesting technical stuff: First, we have a fast Lua VM port. Not LuaJIT, but even the Lua VM itself is quite fast for a dynamic language (and the port is 2/3 of native speed).
Second, there are experiments with JITs targeting JS, like pypy.js. Yes, pypy.js has a large footprint, as you referred to. But I think the fact is that very little effort has gone into this. Much more is possible than has already been done.
If we had a large, serious project doing this, I think we could see the potential. Instead, things like pypy.js are spare-time projects of a single person. So it's not fair to assume that their success or failure in terms of performance and footprint is indicative.
It's my understanding that Shumway is basically a full-scale AS2/AS3 VM & JIT using JS as the codegen target, is that wrong?
JSIL is increasingly a JIT that targets JS instead of an offline JS compiler, if only because JS runtimes are so terrible at optimizing C# code and semantics. Eventually it may end up being like Dalvik, where the offline compiler runs a filtering/transform pass on the input bytecode and all the actual codegen happens on the client.
Hard to be sure, as you pointed out it's hard to do serious CS research like this as one person in your spare time :-)
JSIL is increasingly a JIT that targets JS instead of an offline JS compiler, if only because JS runtimes are so terrible at optimizing C# code and semantics. Eventually it may end up being like Dalvik, where the offline compiler runs a filtering/transform pass on the input bytecode and all the actual codegen happens on the client.
Hard to be sure, as you pointed out it's hard to do serious CS research like this as one person in your spare time :-)
Thanks! I forgot Shumway. Last I heard it was competitive with the Flash runtime (better on some stuff, worse on others), so that seems like a clear counterexample to mraleph's concern.
Isn't Shumway more of a confirmation for my concern than a counter example? Shumway is running ActionScript which is extremely close to JavaScript semantically though somewhat more strict and allows for optional typing.
Yes, let's not innovate on the web anymore. Why was Chrome invented in the first place? We all should have stuck to IE 6 and Navigator. For openness.
Chrome already comes with NaCl which nobody else but Google uses it. Do we want another VM inside Chrome that nobody else will adopt?
And now they're putting Android inside ChromeOS, too, just because they don't want to admit Android itself would work better on notebooks (given the right interface) than ChromeOS.
And now they're putting Android inside ChromeOS, too, just because they don't want to admit Android itself would work better on notebooks (given the right interface) than ChromeOS.
Why do you want it to be supported in Chrome? Any performance improvements seen by your users won't apply to those using any other browser.
> Any performance improvements seen by your users won't apply to those using any other browser.
But it will apply to those using Chrome (their performance benchmarks show consistent improvement, sometimes up to 2x) and it will be using a better language for all the other ones.
But it will apply to those using Chrome (their performance benchmarks show consistent improvement, sometimes up to 2x) and it will be using a better language for all the other ones.
Because then his userbase goes from being an extremely small niche(chromium is probably less than 1%) to a much larger niche(chrome is more than 30%).
Do you mean that Chromium now has a Dart VM? The last time I checked it didn't, there was a buggy thing called Dartium.
Dartium is still separate to Chromium.
Dart -- without being in Chrome -- has the same userbase as CoffeeScript, ClojureScript, or any other language that also compiles to JavaScript.
There are some real potential wins with being in Chrome, many of which are political, but there are no technical reasons for not being in Chrome to block Dart's adoption.
There are some real potential wins with being in Chrome, many of which are political, but there are no technical reasons for not being in Chrome to block Dart's adoption.
Except Dart isn't trying to be another "compiles to javascript" language like CS, Dart is trying to completely replace js which is why it's so much more difficult to implement. They have to build an entire VM to rival V8.
The point is that if you write in Dart you still have a very large target audience without the VM.
Sure, Dart's designed to have even more benefit when run in it's own VM, but that doesn't affect its reach.
Sure, Dart's designed to have even more benefit when run in it's own VM, but that doesn't affect its reach.
> Any performance improvements seen by your users won't apply to those using any other browser.
It will be still about as fast as regular JavaScript.
It will be still about as fast as regular JavaScript.
I will say that you won't need to rely on JavaScript, .dart files size are a lot smaller and the code starts and execute faster.
I wouldn't use Dart until this bug is fixed: https://code.google.com/p/dart/issues/detail?id=13285
fyi, I think most of my original complaints in that bug are either fixed, or largely mitigated. I don't think we've had any issues for over a year now (since Dart 1.0). I still wish it was even more bulletproof, but it isn't scary anymore like it was. Google is building lots of stuff in Dart too, so we're on the hook if something breaks.
Dart doesn't work correctly in Firefox 31 Beta. People will have to recompile all their Dart apps next month.
Wow, seriously? I've been using Beta and not noticed any breakage (but that doesn't mean there isn't any). Do you have any more context?
Ouch. It looks like Dart is using Blink's IDL, not the spec IDL, for generating bindings to JavaScript, so it's only really guaranteed to work in Blink...
I would like to use it but Javascript Frameworks and libraries are being developed so rapidly that it gets difficult to choose Dart and plus it is yet to mature. I may be wrong.
Dart's been very stable for a while now, and has a really good library ecosystem already.
Personally, I wouldn't worry too much about JavaScript frameworks evolving rapidly, just go with anything the supports Web Components. In JavaScript that would be Polymer, X-Tags or Bosonic. In Dart that's Polymer. Or, in either you can write directly to the platform APIs without a library.
In my mind there is BWC and AWC: Before Web Components and After Web Components. The world or web apps is undergoing a paradigm shift on par with AJAX right now, and I wouldn't use any framework that doesn't support Web Components.
Personally, I wouldn't worry too much about JavaScript frameworks evolving rapidly, just go with anything the supports Web Components. In JavaScript that would be Polymer, X-Tags or Bosonic. In Dart that's Polymer. Or, in either you can write directly to the platform APIs without a library.
In my mind there is BWC and AWC: Before Web Components and After Web Components. The world or web apps is undergoing a paradigm shift on par with AJAX right now, and I wouldn't use any framework that doesn't support Web Components.
I have been looking at Polymer library and it looks promising.
[deleted]
I too would like to see a lot more work done on Dart web frameworks (particularly client side) and a lot more documentation/tutorials demonstrating non-trivial real applications which have a complex UI, data binding, and talk to a database on the backend. Right now it's the dearth of documentation/tutorials/books holding me back as I'm on the beginner end of the spectrum--but still very interested in Dart.
Hello, golangs channels and go routines have been quite popular with some. So popular that the clojure guys created core.async and even adopted the "go" command(as a nod I'm assuming?). This works in the JVM via clojurescript.. Has the Dart team considered such a system? Was it brought up when planning the await stuff?
It would give me greater confidence if the first Dart example[1] on the official Dart website did not point to a 404 Not Found.
[1] https://www.dartlang.org/samples/
[1] https://www.dartlang.org/samples/
Yikes! Not good. I just opened: https://code.google.com/p/dart/issues/detail?id=19708
I fixed our repo. The next time we push the site, it should be fixed. Thanks for the report!
This may be a noob question on my part, but my understanding is Dart and Rust are 2 separate efforts to come up with something to supplant javascript?
No. Rust is a systems language meant to displace c and c++.
Dart is Google's me-too attempt at creating something which compiles to JavaScript. It borrows heavily from java and generates equally bloated code.
OK, so maybe last sentence is a bit over the top critical, but last I checked, hello world in dart rendered in at 100kb [1] of js and dependencies.
[1] http://lostechies.com/jimmybogard/2011/10/12/the-dart-hello-...
Dart is Google's me-too attempt at creating something which compiles to JavaScript. It borrows heavily from java and generates equally bloated code.
OK, so maybe last sentence is a bit over the top critical, but last I checked, hello world in dart rendered in at 100kb [1] of js and dependencies.
[1] http://lostechies.com/jimmybogard/2011/10/12/the-dart-hello-...
The aim of Dart was really to provide a second VM in browser with a compatibility dart2js compilation mode. It was never intended to always be used with dart2js.
Dart 1.5.1 produces nowhere near that much for the same input, producing just 14KB (see [1]). Yes, arguably still too verbose, but note that much of the overhead is essentially a Dart-compatibility support library, so remains constant as the amount of Dart increases.
[1]: https://gist.github.com/gsnedders/ab101d73bc91d2782e0a
Dart 1.5.1 produces nowhere near that much for the same input, producing just 14KB (see [1]). Yes, arguably still too verbose, but note that much of the overhead is essentially a Dart-compatibility support library, so remains constant as the amount of Dart increases.
[1]: https://gist.github.com/gsnedders/ab101d73bc91d2782e0a
If the Dart team decided to put a lot of effort into it, I bet they could get that down, but to what benefit? The average application isn't a hello world and so most of the code that isn't being pruned is likely system runtime code that most apps need.
I decided to try such an experiment with GWT recently, since the same kind of unfair microbenchmark has been used against it.
I detail how I reduced the hello world from 2205 bytes to 710 bytes here: Th3e Hello World Challenge https://plus.google.com/+RayCromwell/posts/VK8URgZiLbS
What how did I do it? By not registering any global exception handlers, or any async tasks, and arranging for the compiler to be able to optimize away the unused runtime stuff.
But how likely is it that no one wants to catch exceptions and print pretty stack traces? Or to schedule microtasks to run at the end of the event loop?
It's not a realistic test.
I decided to try such an experiment with GWT recently, since the same kind of unfair microbenchmark has been used against it.
I detail how I reduced the hello world from 2205 bytes to 710 bytes here: Th3e Hello World Challenge https://plus.google.com/+RayCromwell/posts/VK8URgZiLbS
What how did I do it? By not registering any global exception handlers, or any async tasks, and arranging for the compiler to be able to optimize away the unused runtime stuff.
But how likely is it that no one wants to catch exceptions and print pretty stack traces? Or to schedule microtasks to run at the end of the event loop?
It's not a realistic test.
Dart is not meant to enable building "hello world" apps though.
>It borrows heavily from java and generates equally bloated code.
I don't mind Java, but I don't see how a) being compared to Java is a negative given the alternative is JavaScript (which as a language is terrible) and b) how Dart borrows heavily from Java.
Re b), there are enough differences between the two (e.g. dart has optional static typing, mixins and js-type closures, and is single-threaded and interpreted) that the similarities are completely superficial.
I don't mind Java, but I don't see how a) being compared to Java is a negative given the alternative is JavaScript (which as a language is terrible) and b) how Dart borrows heavily from Java.
Re b), there are enough differences between the two (e.g. dart has optional static typing, mixins and js-type closures, and is single-threaded and interpreted) that the similarities are completely superficial.
While it's true that Dart is aimed at the sort of territory dominated by JavaScript (client-side code in the browser), Rust is instead aiming towards the sort of use cases one might choose C++ for today – for example, as the language used to create the browser itself.
You might be confusing Rust with Typescript, which is Microsoft's attempt to "improve" javascript.
http://en.wikipedia.org/wiki/TypeScript
http://en.wikipedia.org/wiki/TypeScript
As in Mozilla Rust? That is a systems language, nothing to do with JS (other than it is being used to build Servo, Mozilla's experimental new parallel browser engine)
I think rust wants to be a system language, akin to C rather than javascript. Dart, yes, a different language running inside the browser.
[deleted]
[deleted]
Has this version been submitted to ECMA?
Anybody knows if there's a free DART PDF Book somewhere?
Not sure about PDFs, but the text for Dart Up & Running can be found here: https://www.dartlang.org/docs/dart-up-and-running/
[disclaimer: I work for the Dart team, and I'm a coauthor of that book.]
[disclaimer: I work for the Dart team, and I'm a coauthor of that book.]
I usually browse the docs when starting with a new topic; the dartlang website has tons of stuff (and the articles are usually kept up to date), it's quite easy to get started.
How does dart compare to coffeescript?
This is a very simplified answer, but here's my take:
CoffeeScript says that the main problems with JS are the inelegant C-style syntax and a few semantic trip wires. It addresses those while still keeping the underlying semantics, APIs and ecosystem.
If what drives you up the wall about JS is stuff like the DOM, or JS's object model, CoffeeScript won't help you much. If you are OK with how JS behaves and like the very large JS ecosystem, CoffeeScript can be a nice fit.
Dart takes a much larger semantic step away from JS. Syntactically, it's more similar to JS than CoffeeScript is. It sticks with braces and statements, and the whole C kit and kaboodle.
However, semantically, it's much different. It has a full-featured class system with inheritance, mixins, getters, setters, operator overloading, etc. It has a static type system so you get the nice tooling experience you expect from a language like Java or C#. It also completely revamps the DOM APIs to (hopefully) be more rational, modern and consistent.
The cost, though, is that interacting with the existing JavaScript world is a little more difficult. You can interop, of course, but it isn't as seamless as CoffeeScript.
CoffeeScript says that the main problems with JS are the inelegant C-style syntax and a few semantic trip wires. It addresses those while still keeping the underlying semantics, APIs and ecosystem.
If what drives you up the wall about JS is stuff like the DOM, or JS's object model, CoffeeScript won't help you much. If you are OK with how JS behaves and like the very large JS ecosystem, CoffeeScript can be a nice fit.
Dart takes a much larger semantic step away from JS. Syntactically, it's more similar to JS than CoffeeScript is. It sticks with braces and statements, and the whole C kit and kaboodle.
However, semantically, it's much different. It has a full-featured class system with inheritance, mixins, getters, setters, operator overloading, etc. It has a static type system so you get the nice tooling experience you expect from a language like Java or C#. It also completely revamps the DOM APIs to (hopefully) be more rational, modern and consistent.
The cost, though, is that interacting with the existing JavaScript world is a little more difficult. You can interop, of course, but it isn't as seamless as CoffeeScript.
I just don't trust Google to do languages and developer tools very well. They don't seem to depend on developers enough to bend over backwards for us the way that Microsoft does.
Plus, they seem to want to use web tech to build native desktop tools all the time and little things like "keyboard acceleration" don't seem to matter to them because there are no standards for that in web-world.
Plus, they seem to want to use web tech to build native desktop tools all the time and little things like "keyboard acceleration" don't seem to matter to them because there are no standards for that in web-world.
Not sure what you mean: MS has a history of abandoning its developer platforms and frameworks that thier developers have invested in, so much so that there's no longer a clear UI story for building native desktop windows apps, i.e. VB6, Silverlight, WinForms and WPF are all effectively deprecated. Although they have long support life, when they officially abandon a platform they also refuse to Open Source it so others can keep it alive (e.g. VB6 http://bit.ly/KPMUS6). I personally can't see how anyone can put trust into building native Windows desktop apps (i.e. over web apps) given the repeated a history of abandonment.
Even the #1 feature for VS.NET is to continue developing very popular XNA framework: http://visualstudio.uservoice.com/forums/121579-visual-studi...
Likewise on the server side there's been history of deprecated frameworks a lot of developers have invested a lot of energy into learning, e.g: .asmx, CSF, WCF, WCF/REST, WSE, WCF DataServices, RIA
Whilst VisualStudio is a great IDE, I find it a subpar experience without R#. The major advantages Dart has over C# is that it still provides an enjoyable experience to develop even without an IDE which also includes support for the most popular text editors: https://www.dartlang.org/tools/ If you like IDE and tooling support, the DartEditor offers a good experience with built-in analyzer, debugging and refactoring support you can expect from a well engineered language.
By contrast, C#'s configuration model, msbuild project format, heavy frameworks and tooling makes it unfeasible to develop without an IDE.
The other major advantage Dart has is that it compiles down to JS where even the compiler is completely self-hosting and runs inside a browser without plugins: http://try.dartlang.org/ Being able to share the same code on client and server and having a single integrated development full-stack experience is a huge win in re-usability and utility.
Another killer feature is that the language and tooling is cross-platform which supports Windows, OSX and Linux. Something .NET devs often miss out on is the value and utility of being able to host apps on cost-effective Linux servers.
Google continues to invest a tonne of resources in Dart and Polymer which are massive undertakings that are providing a much simplified and consistent experience for developing large, complex web apps. Nothing like Dart or Polymer exists. Dart is a platform that transpiles to JS, includes a native Dart VM, an entire toolchain including IDE, analyzer and debugger both in Dart Editor as well as in Chrome, in both the Dart VM as well as debugging with Source maps.
The worlds best VM engineers work on the Dart VM, i.e. the same pedigree responsible for the StrongTalk VM that was later acquired by Sun to form the basis of the world-class Java Hotspot VM that later went on to develop V8, are now leading the development on the Dart VM.
The excellence shows itself in the consistency and minimalism goals in the language, providing a productive, iterative dynamic language experience for fast prototyping with the benefit of static analysis with optional typing when scaling up to a maintainable, well-documented code-base (best of both worlds).
Not only is Dart a productive dynamic language, it also has excellent performance, the best performance of all languages I benchmarked with a port of Peter Norvig's Sudoku solver: https://github.com/dartist/sudoku_solver#benchmarks
Even the #1 feature for VS.NET is to continue developing very popular XNA framework: http://visualstudio.uservoice.com/forums/121579-visual-studi...
Likewise on the server side there's been history of deprecated frameworks a lot of developers have invested a lot of energy into learning, e.g: .asmx, CSF, WCF, WCF/REST, WSE, WCF DataServices, RIA
Whilst VisualStudio is a great IDE, I find it a subpar experience without R#. The major advantages Dart has over C# is that it still provides an enjoyable experience to develop even without an IDE which also includes support for the most popular text editors: https://www.dartlang.org/tools/ If you like IDE and tooling support, the DartEditor offers a good experience with built-in analyzer, debugging and refactoring support you can expect from a well engineered language.
By contrast, C#'s configuration model, msbuild project format, heavy frameworks and tooling makes it unfeasible to develop without an IDE.
The other major advantage Dart has is that it compiles down to JS where even the compiler is completely self-hosting and runs inside a browser without plugins: http://try.dartlang.org/ Being able to share the same code on client and server and having a single integrated development full-stack experience is a huge win in re-usability and utility.
Another killer feature is that the language and tooling is cross-platform which supports Windows, OSX and Linux. Something .NET devs often miss out on is the value and utility of being able to host apps on cost-effective Linux servers.
Google continues to invest a tonne of resources in Dart and Polymer which are massive undertakings that are providing a much simplified and consistent experience for developing large, complex web apps. Nothing like Dart or Polymer exists. Dart is a platform that transpiles to JS, includes a native Dart VM, an entire toolchain including IDE, analyzer and debugger both in Dart Editor as well as in Chrome, in both the Dart VM as well as debugging with Source maps.
The worlds best VM engineers work on the Dart VM, i.e. the same pedigree responsible for the StrongTalk VM that was later acquired by Sun to form the basis of the world-class Java Hotspot VM that later went on to develop V8, are now leading the development on the Dart VM.
The excellence shows itself in the consistency and minimalism goals in the language, providing a productive, iterative dynamic language experience for fast prototyping with the benefit of static analysis with optional typing when scaling up to a maintainable, well-documented code-base (best of both worlds).
Not only is Dart a productive dynamic language, it also has excellent performance, the best performance of all languages I benchmarked with a port of Peter Norvig's Sudoku solver: https://github.com/dartist/sudoku_solver#benchmarks
I'm feeling a little defensive here (disclaimer, MS employee, but I work for MSR, not devdiv):
> Not sure what you mean: MS has a history of abandoning its developer platforms and frameworks that thier developers have invested in, so much so that there's no longer a clear UI story for building native desktop windows apps, i.e. VB6, Silverlight, WinForms and WPF are all effectively deprecated.
WPF is still chugging a long strongly even if there aren't so many new features. Visual Studio was recently rewritten in it, and its a very good design with lots of room for encoding desktop apps in the future. I use it daily and cringe at the thought of ever doing something for the web without it.
> Whilst VisualStudio is a great IDE, I find it a subpar experience without R#.
I use visual studio just fine without R#. I see no point these days writing code without an IDE, I'm addicted to code completion. Not to mention amazing things are being done with Roslyn.
> By contrast, C#'s configuration model, msbuild project format, heavy frameworks and tooling makes it unfeasible to develop without an IDE.
C# is totally usable from the command line, most developers just refer the IDE.
> he worlds best VM engineers work on the Dart VM, i.e. the same pedigree responsible for the StrongTalk VM that was later acquired by Sun to form the basis of the world-class Java Hotspot VM that later went on to develop V8, are now leading the development on the Dart VM.
The CLR is one of the best VMs ever (read: very fast), worked on by some of the brightest who are very comparable to the Animorphic crowd. The DLR feature (ability to generate/compile expression trees at run-time) is also very cool and missing from the JVM. If you are into building language run-times, it is an awesome base for a dynamic language.
True: it is only available on Windows, but Mono has made progress as well (most features available sans WPF). I've been thinking about porting my language work [1] over to mono.cairo to see if I can achieve cross platform without going to Java or the web.
[1] http://research.microsoft.com/en-us/people/smcdirm/liveprogr...
> Not sure what you mean: MS has a history of abandoning its developer platforms and frameworks that thier developers have invested in, so much so that there's no longer a clear UI story for building native desktop windows apps, i.e. VB6, Silverlight, WinForms and WPF are all effectively deprecated.
WPF is still chugging a long strongly even if there aren't so many new features. Visual Studio was recently rewritten in it, and its a very good design with lots of room for encoding desktop apps in the future. I use it daily and cringe at the thought of ever doing something for the web without it.
> Whilst VisualStudio is a great IDE, I find it a subpar experience without R#.
I use visual studio just fine without R#. I see no point these days writing code without an IDE, I'm addicted to code completion. Not to mention amazing things are being done with Roslyn.
> By contrast, C#'s configuration model, msbuild project format, heavy frameworks and tooling makes it unfeasible to develop without an IDE.
C# is totally usable from the command line, most developers just refer the IDE.
> he worlds best VM engineers work on the Dart VM, i.e. the same pedigree responsible for the StrongTalk VM that was later acquired by Sun to form the basis of the world-class Java Hotspot VM that later went on to develop V8, are now leading the development on the Dart VM.
The CLR is one of the best VMs ever (read: very fast), worked on by some of the brightest who are very comparable to the Animorphic crowd. The DLR feature (ability to generate/compile expression trees at run-time) is also very cool and missing from the JVM. If you are into building language run-times, it is an awesome base for a dynamic language.
True: it is only available on Windows, but Mono has made progress as well (most features available sans WPF). I've been thinking about porting my language work [1] over to mono.cairo to see if I can achieve cross platform without going to Java or the web.
[1] http://research.microsoft.com/en-us/people/smcdirm/liveprogr...
> WPF is still chugging a long strongly
Your definition of strong sounds different to other peoples. There was entire FixWPF grass roots campaign to petition more investment into WPF, twitter account is at: https://twitter.com/fixwpf they also had a website and blog pleading for MS to keep investing in WPF and fix its issues.
When and what was the most recent feature added to WPF?
> I see no point these days writing code without an IDE
You may not, but most popular languages can be developed without and IDE, which is important for simplicity / deployment / portability. It's also much easier to develop in smaller laptops which can maximize real-estate. Obviously a language that is suitable without an IDE is also more suitable in an online IDE, which we're seeing with the new online IDEs becoming available.
> C# is totally usable from the command line, most developers just refer the IDE.
So it's only usable where it's worst than most other languages at? i.e. Scripts and Command-line apps? It's so totally usable that MS invented a new completely different language for creating command-line scripts (PowerShell).
As you likely already know, most .NET developers don't spend their time developing 1 file Console apps. Any task that has any meaningful user-share requires an IDE.
> The CLR is one of the best VMs ever
Citation needed, it's not as performant as the JVM, and its lack of cross-platform is a major limitation. The Sudoku benchmarks shows that it's slower (and more verbose) than Dart even removing time spent on pre-compilation. Dart also offers high-level productivity features like variable-sized integers, saving a lot of boilerplate from having to deal with specific fixed-size integers.
> awesome base for a dynamic language.
Really? All dynamic languages targetting both the CLR/JVM are either deprecated or second-class citizens on the CLR and are always better supported on the JVM: Jython/IronPython JRuby/IronRuby Clojure/ClojureCLR. The CLR is a wasteland of unpolished efforts with relatively no traction/community behind them.
The DLR team has actually been disbanded with the primary developer behind it (Jim Hugunin / IronPython) having left Microsoft (http://hugunin.net/microsoft_farewell.html) to now work at Google on the Dart project no less.
What he had to say about Dart (http://www.infoq.com/news/2011/11/dart-roundup-frog):
Your definition of strong sounds different to other peoples. There was entire FixWPF grass roots campaign to petition more investment into WPF, twitter account is at: https://twitter.com/fixwpf they also had a website and blog pleading for MS to keep investing in WPF and fix its issues.
When and what was the most recent feature added to WPF?
> I see no point these days writing code without an IDE
You may not, but most popular languages can be developed without and IDE, which is important for simplicity / deployment / portability. It's also much easier to develop in smaller laptops which can maximize real-estate. Obviously a language that is suitable without an IDE is also more suitable in an online IDE, which we're seeing with the new online IDEs becoming available.
> C# is totally usable from the command line, most developers just refer the IDE.
So it's only usable where it's worst than most other languages at? i.e. Scripts and Command-line apps? It's so totally usable that MS invented a new completely different language for creating command-line scripts (PowerShell).
As you likely already know, most .NET developers don't spend their time developing 1 file Console apps. Any task that has any meaningful user-share requires an IDE.
> The CLR is one of the best VMs ever
Citation needed, it's not as performant as the JVM, and its lack of cross-platform is a major limitation. The Sudoku benchmarks shows that it's slower (and more verbose) than Dart even removing time spent on pre-compilation. Dart also offers high-level productivity features like variable-sized integers, saving a lot of boilerplate from having to deal with specific fixed-size integers.
> awesome base for a dynamic language.
Really? All dynamic languages targetting both the CLR/JVM are either deprecated or second-class citizens on the CLR and are always better supported on the JVM: Jython/IronPython JRuby/IronRuby Clojure/ClojureCLR. The CLR is a wasteland of unpolished efforts with relatively no traction/community behind them.
The DLR team has actually been disbanded with the primary developer behind it (Jim Hugunin / IronPython) having left Microsoft (http://hugunin.net/microsoft_farewell.html) to now work at Google on the Dart project no less.
What he had to say about Dart (http://www.infoq.com/news/2011/11/dart-roundup-frog):
I've spent most of my career trying to end the battles between the dynamic
and static worlds and instead bring them together so that each side can
enjoy the benefits of the other. Writing this compiler in dart is the
first time that I've really felt the effortless blend of these worlds that
I've been seeking.
Dart is the first time that I have been able to start off writing code in
a very dynamic fashion and incrementally add static checks as designs become
solid or complexity warrants the effort.
> Your definition of strong sounds different to other peoples. There was entire FixWPF grass roots campaign to petition more investment into WPF, twitter account is at: https://twitter.com/fixwpf they also had a website and blog pleading for MS to keep investing in WPF and fix its issues.
WPF still works very well, it is not broken. It is still one of the best UI toolkits ever constructed with a lot of flexibility that I don't think is still appreciated enough.
> When and what was the most recent feature added to WPF?
No clue. I'm as curious as everyone else.
> You may not, but most popular languages can be developed without and IDE, which is important for simplicity / deployment / portability.
As far as I'm concerned, the IDE is a part of the language and at the very least the programming experience. People programming in emacs and VIM will eventually retire, the future is undeniable at this point. A language designed for an IDE will work better in an IDE than a language that is designed for least common dominator development environments. But then I'm biased since that is part of my research.
And also, Dart is so far very weak on the IDE side. I wonder if the Dart team has lots of compiler people and not a lot of IDE people, or if they have the same old-fashioned mindset as you in de-emphasizing the value of a good IDE experience. But I would expect it to get better, they hired Luke Church after all.
> It's so totally usable that MS invented a new completely different language written for creating command-line scripts (PowerShell).
PowerShell is an optional tool, not required. I've seen huge C# projects build from a CMD prompt (not that I want to bother with build configuration management myself).
> Citation needed, it's not as performant as the JVM
Citation needed, in my experience, C# kicks the JVM's butt in Win performance. Reified generics also reduce lots of boxing issues.
> The Sudoku benchmarks shows that it's slower (and more verbose) than Dart
Your numbers are completely whack. First, it shows mono being faster than the CLR, oh and you are using a virtual machine on top of that. Do you really think people will take that seriously? Also, do you ever try..you know..a multi-threaded shared memory solution?
> The DLR team has actually been disbanded with the primary developer behind it (Jim Hugunin / IronPython) having left Microsoft (http://hugunin.net/microsoft_farewell.html) to now work at Google on the Dart project no less.
Jim and Jon are gone, but the work they did is totally still around and works wonderfully. I use it, its fast, and it puts C# on par or beyond with any dynamic language that supports dynamic eval.
> Dynamic itself is a heavyweight solution and may many suggest may have been a mistake, C# 6.0 is actually introducing new '$' syntax to avoid dynamic and make working with dictionaries better.
I'm not talking about C#'s dynamic language feature, which I don't really care for, but dynamic expression tree compilation that came along with the rest of the DLR. As a language implementer, it is very useful.
WPF still works very well, it is not broken. It is still one of the best UI toolkits ever constructed with a lot of flexibility that I don't think is still appreciated enough.
> When and what was the most recent feature added to WPF?
No clue. I'm as curious as everyone else.
> You may not, but most popular languages can be developed without and IDE, which is important for simplicity / deployment / portability.
As far as I'm concerned, the IDE is a part of the language and at the very least the programming experience. People programming in emacs and VIM will eventually retire, the future is undeniable at this point. A language designed for an IDE will work better in an IDE than a language that is designed for least common dominator development environments. But then I'm biased since that is part of my research.
And also, Dart is so far very weak on the IDE side. I wonder if the Dart team has lots of compiler people and not a lot of IDE people, or if they have the same old-fashioned mindset as you in de-emphasizing the value of a good IDE experience. But I would expect it to get better, they hired Luke Church after all.
> It's so totally usable that MS invented a new completely different language written for creating command-line scripts (PowerShell).
PowerShell is an optional tool, not required. I've seen huge C# projects build from a CMD prompt (not that I want to bother with build configuration management myself).
> Citation needed, it's not as performant as the JVM
Citation needed, in my experience, C# kicks the JVM's butt in Win performance. Reified generics also reduce lots of boxing issues.
> The Sudoku benchmarks shows that it's slower (and more verbose) than Dart
Your numbers are completely whack. First, it shows mono being faster than the CLR, oh and you are using a virtual machine on top of that. Do you really think people will take that seriously? Also, do you ever try..you know..a multi-threaded shared memory solution?
> The DLR team has actually been disbanded with the primary developer behind it (Jim Hugunin / IronPython) having left Microsoft (http://hugunin.net/microsoft_farewell.html) to now work at Google on the Dart project no less.
Jim and Jon are gone, but the work they did is totally still around and works wonderfully. I use it, its fast, and it puts C# on par or beyond with any dynamic language that supports dynamic eval.
> Dynamic itself is a heavyweight solution and may many suggest may have been a mistake, C# 6.0 is actually introducing new '$' syntax to avoid dynamic and make working with dictionaries better.
I'm not talking about C#'s dynamic language feature, which I don't really care for, but dynamic expression tree compilation that came along with the rest of the DLR. As a language implementer, it is very useful.
> WPF still works very well, it is not broken. It is still one of the best UI toolkits ever constructed
What exactly do you think the FixWPF campaign was about? And what else have you used? If it's so good, why are so few Windows desktop apps that come with Windows written with it? At least Apple uses Cocoa for all its OSX Desktop apps which I find to be of much higher quality and has smoother performance.
> People programming in emacs and VIM will eventually retire, the future is undeniable at this point.
You're making it sound most developers using text editors are old kooks with 1-foot into retirement. How disconnected are you? What % of OSS projects on GitHub do you think use an IDE? More or less than 50%? https://github.com/trending
> Dart is so far very weak on the IDE side. I wonder if the Dart team has lots of compiler people and not a lot of IDE people,
They actually have quite a few IDE people on the team with many years of experience developing IDE tooling. Any immaturity is simply that the DartEditor is still so young. It was only recently that they rewrote the old Analyzer that was previously written in Java to Dart, which now runs much faster. No doubt VS benefits from a large experienced IDE team as would JetBrains.
> I've seen huge C# projects build from a CMD prompt
Seeing something done once doesn't extrapolate itself into a common use-case or a well-supported story, which it isn't. Having to maintain your own build scripts is a slow, painful and mundane experience which is why it's a rarely considered approach. Even the just released Swift has a better command-line story than C#, which supports #! scripts, a command-line REPL and LLVM debugger.
> Citation needed, in my experience, C# kicks the JVM's butt in Win performance.
Citation is still needed. Where can this butt kicking be seen?
> Your numbers are completely whack. First, it shows mono being faster than the CLR, oh and you are using a virtual machine on top of that.
They're not my numbers, that's the actual output from the command-line Console apps which you can see on the project page. But don't take my iMac's word for it, all the source code is there, run the benchmarks yourself. Your 2 points aren't exclusive, there is no "on top of that" they were all run from my iMac, I would've run C#/.NET natively, but y'know that's hard to do when it's the only platform that doesn't work cross-platform. Running inside Parallels likely accounts for about 10-15% performance overhead, it doesn't explain 2.3x worst performance.
> As a language implementer, it is very useful.
Language VM features that are optimal for compiler writers doesn't translate itself into killer general-purpose language features for everyone else.
What exactly do you think the FixWPF campaign was about? And what else have you used? If it's so good, why are so few Windows desktop apps that come with Windows written with it? At least Apple uses Cocoa for all its OSX Desktop apps which I find to be of much higher quality and has smoother performance.
> People programming in emacs and VIM will eventually retire, the future is undeniable at this point.
You're making it sound most developers using text editors are old kooks with 1-foot into retirement. How disconnected are you? What % of OSS projects on GitHub do you think use an IDE? More or less than 50%? https://github.com/trending
> Dart is so far very weak on the IDE side. I wonder if the Dart team has lots of compiler people and not a lot of IDE people,
They actually have quite a few IDE people on the team with many years of experience developing IDE tooling. Any immaturity is simply that the DartEditor is still so young. It was only recently that they rewrote the old Analyzer that was previously written in Java to Dart, which now runs much faster. No doubt VS benefits from a large experienced IDE team as would JetBrains.
> I've seen huge C# projects build from a CMD prompt
Seeing something done once doesn't extrapolate itself into a common use-case or a well-supported story, which it isn't. Having to maintain your own build scripts is a slow, painful and mundane experience which is why it's a rarely considered approach. Even the just released Swift has a better command-line story than C#, which supports #! scripts, a command-line REPL and LLVM debugger.
> Citation needed, in my experience, C# kicks the JVM's butt in Win performance.
Citation is still needed. Where can this butt kicking be seen?
> Your numbers are completely whack. First, it shows mono being faster than the CLR, oh and you are using a virtual machine on top of that.
They're not my numbers, that's the actual output from the command-line Console apps which you can see on the project page. But don't take my iMac's word for it, all the source code is there, run the benchmarks yourself. Your 2 points aren't exclusive, there is no "on top of that" they were all run from my iMac, I would've run C#/.NET natively, but y'know that's hard to do when it's the only platform that doesn't work cross-platform. Running inside Parallels likely accounts for about 10-15% performance overhead, it doesn't explain 2.3x worst performance.
> As a language implementer, it is very useful.
Language VM features that are optimal for compiler writers doesn't translate itself into killer general-purpose language features for everyone else.
> And what else have you used? If it's so good, why are so few Windows desktop apps that come with Windows written with it? At least Apple uses Cocoa for all its OSX Desktop apps which I find to be of much higher quality and smoother performance.
WPF is used for Visual Studio, and that is from VS 2010 on. WPF is used for a lot of stuff internally, its not like people are still breaking out WinForms or GDI. And then there is WP and WinRT, which are WPF derivatives.
> You're making it sound most developers using text editors are old kooks with 1-foot into retirement. How disconnected are you? What % of OSS projects on GitHub do you think use an IDE? More or less than 50%? https://github.com/trending
GitHUB isn't even a small percentage of all developers, it only represents public OSS projects. There is lots of value in a good IDE, language designers and implementors who treat it as a second class concerns are going to pay the price in popularity eventually.
> They actually have quite a few IDE people on the team with many years of experience developing IDE tooling. Any immaturity is simply that the DartEditor is still so young.
That isn't what I've heard. Anyways...Eclipse...wow...I don't see anything good coming out of that.
> It was only recently that they rewrote the old Analyzer that was previously written in Java to Dart, which now runs much faster.
Fast tools mean nothing if the UX is crap. Also, incremental performance is quite different from batch performance that you expect from the command line.
> Running inside Parallels likely accounts for about 10-15% performance overhead, it doesn't explain 2.3x worst performance.
In general, I've seen the CLR beat Mono anywhere from 1.5 to 3X. So if Mono is coming up faster than the CLR, something is probably seriously off.
> Language VM features that are optimal for compiler writers doesn't translate itself into killer general-purpose language features.
Right. But it does give you lots of options in one's managed time live programming language.
WPF is used for Visual Studio, and that is from VS 2010 on. WPF is used for a lot of stuff internally, its not like people are still breaking out WinForms or GDI. And then there is WP and WinRT, which are WPF derivatives.
> You're making it sound most developers using text editors are old kooks with 1-foot into retirement. How disconnected are you? What % of OSS projects on GitHub do you think use an IDE? More or less than 50%? https://github.com/trending
GitHUB isn't even a small percentage of all developers, it only represents public OSS projects. There is lots of value in a good IDE, language designers and implementors who treat it as a second class concerns are going to pay the price in popularity eventually.
> They actually have quite a few IDE people on the team with many years of experience developing IDE tooling. Any immaturity is simply that the DartEditor is still so young.
That isn't what I've heard. Anyways...Eclipse...wow...I don't see anything good coming out of that.
> It was only recently that they rewrote the old Analyzer that was previously written in Java to Dart, which now runs much faster.
Fast tools mean nothing if the UX is crap. Also, incremental performance is quite different from batch performance that you expect from the command line.
> Running inside Parallels likely accounts for about 10-15% performance overhead, it doesn't explain 2.3x worst performance.
In general, I've seen the CLR beat Mono anywhere from 1.5 to 3X. So if Mono is coming up faster than the CLR, something is probably seriously off.
> Language VM features that are optimal for compiler writers doesn't translate itself into killer general-purpose language features.
Right. But it does give you lots of options in one's managed time live programming language.
> WPF is used for Visual Studio, and that is from VS 2010 on. WPF is used for a lot of stuff internally
So neither that ships with Windows then?
> its not like people are still breaking out WinForms or GDI.
Do you think they've been overrun by developers breaking out WPF? Even when MS is trying to push everyone into creating WindowsStore apps? I hardly ever see any mainstream desktop apps written in WPF. What are some of the most popular WPF apps developed outside of Microsoft?
> WP and WinRT, which are WPF derivatives
How can WinRT be a derivative of WPF if it's written in C++? What WPF code-base did they derive from?
> GitHUB isn't even a small percentage of all developers,
So what does show a good measure of overall developers that shows the slow death of languages/devs without IDE's?
> There is lots of value in a good IDE
There's also lots of value in small, wrist-friendly languages that don't need an IDE and have a good story for text-editors / command-line. You may want to check out what the dev story is for Clojure / Go / Node which support live-reloading / auto-running of modified tests and fast dev iteration times without IDE's.
So neither that ships with Windows then?
> its not like people are still breaking out WinForms or GDI.
Do you think they've been overrun by developers breaking out WPF? Even when MS is trying to push everyone into creating WindowsStore apps? I hardly ever see any mainstream desktop apps written in WPF. What are some of the most popular WPF apps developed outside of Microsoft?
> WP and WinRT, which are WPF derivatives
How can WinRT be a derivative of WPF if it's written in C++? What WPF code-base did they derive from?
> GitHUB isn't even a small percentage of all developers,
So what does show a good measure of overall developers that shows the slow death of languages/devs without IDE's?
> There is lots of value in a good IDE
There's also lots of value in small, wrist-friendly languages that don't need an IDE and have a good story for text-editors / command-line. You may want to check out what the dev story is for Clojure / Go / Node which support live-reloading / auto-running of modified tests and fast dev iteration times without IDE's.
> How can WinRT be a derivative of WPF if it's written in C++? What WPF code-base did they derive from?
They derived WPFs design and API language, along with XAML. Its not like MILCORE was written in C# either.
> So what does show a good measure of overall developers that shows the slow death of languages/devs without IDE's
It shows nothing. IDEs haven't really been a thing (they weren't that good until then) since the late 90s or even mid 00s. It is taking awhile, but its happening. We will see more language designs that don't bother with IDE independence for better features. Couple that in with the Bret Victor candy, and there is only one way to get there.
> There's also lots of value in small, wrist-friendly languages that don't need an IDE and have a good story for text-editors / command-line. You may want to check out what the dev story is for Clojure / Go / Node which support live-reloading / auto-running of modified tests and fast dev iteration times without IDE's.
I know all about those systems, and they aren't very inspiring. We can do much better than that if we don't limit ourselves to languages just being syntax/semantics/and a compiler.
They derived WPFs design and API language, along with XAML. Its not like MILCORE was written in C# either.
> So what does show a good measure of overall developers that shows the slow death of languages/devs without IDE's
It shows nothing. IDEs haven't really been a thing (they weren't that good until then) since the late 90s or even mid 00s. It is taking awhile, but its happening. We will see more language designs that don't bother with IDE independence for better features. Couple that in with the Bret Victor candy, and there is only one way to get there.
> There's also lots of value in small, wrist-friendly languages that don't need an IDE and have a good story for text-editors / command-line. You may want to check out what the dev story is for Clojure / Go / Node which support live-reloading / auto-running of modified tests and fast dev iteration times without IDE's.
I know all about those systems, and they aren't very inspiring. We can do much better than that if we don't limit ourselves to languages just being syntax/semantics/and a compiler.
> They derived WPFs design and API language, along with XAML. Its not like MILCORE was written in C# either.
Got it, so it's derivative in the same way Chrome is a derivative of IE because HTML/CSS. Only a little less so due to different namespaces, missing controls, completely different runtime and incompatible desktop modes - maximizing developer happiness since 2011.
> It shows nothing. IDEs haven't really been a thing...
Not nothing, apparently it's enough to declare text-editor devs an extinct species and decree the new generation of devs will skip text editors entirely and only consider IDE-coupled languages.
> Couple that in with the Bret Victor candy, and there is only one way to get there.
Bret Victor showcases the benefits of previewing changes in real-time like the kind you can see with Clojure in LightTable or Swift's playground. Late-bound languages are more suitable for effecting real-time changes than static pre-compiled IDE-coupled languages, the kind that was being done in Smalltalk decades ago, even VB6 had better live-editing support than C#/VS.NET does now with Edit/Continue.
Got it, so it's derivative in the same way Chrome is a derivative of IE because HTML/CSS. Only a little less so due to different namespaces, missing controls, completely different runtime and incompatible desktop modes - maximizing developer happiness since 2011.
> It shows nothing. IDEs haven't really been a thing...
Not nothing, apparently it's enough to declare text-editor devs an extinct species and decree the new generation of devs will skip text editors entirely and only consider IDE-coupled languages.
> Couple that in with the Bret Victor candy, and there is only one way to get there.
Bret Victor showcases the benefits of previewing changes in real-time like the kind you can see with Clojure in LightTable or Swift's playground. Late-bound languages are more suitable for effecting real-time changes than static pre-compiled IDE-coupled languages, the kind that was being done in Smalltalk decades ago, even VB6 had better live-editing support than C#/VS.NET does now with Edit/Continue.
> Got it, so it's derivative in the same way Chrome is a derivative of IE because HTML/CSS. Only a little less so due to different namespaces, missing controls, completely different runtime and incompatible desktop modes - maximizing developer happiness since 2011.
WinRT really is WPF cleaned up a bit and done with a different language (though it supports .NET bindings easily), and ya, missing a bunch of features that even I sorely miss (though to be share, pixel shaders are kind of dangerous!). Same people, same API architecture, same etc...I still prefer WPF, but because I'm writing dev environments and not apps.
> Not nothing, apparently it's enough to declare text-editor devs an extinct species and decree the new generation of devs will skip text editors entirely and only consider IDE-coupled languages.
IDEs weren't a thing until recently (the last 15 or so years). Text-editor devs aren't extinct, just shrinking in numbers. Extinction doesn't occur for another 20 or so years. Anyways, you need IDE believers to make good IDEs, you can tell when an IDE has been pushed out by non-believers (it sucks, because they don't get it).
> Bret Victor showcases the benefits of previewing changes in real-time like the kind you can see with Clojure in LightTable or Swift's playground. Late-bound languages are more suitable for effecting real-time changes than static pre-compiled IDE-coupled languages, the kind that was being done in Smalltalk decades ago, even VB6 had better live-editing support than C#/VS.NET does now with Edit/Continue.
Why must an IDE-coupled language "static" or "pre-compiled"? I agree C# isn't very live nor would I try to make it be live, but the CLR provides a lot of the tools needed to get there (quick real-time tree compilation). I'm working on this right now...(see [1] again if you haven't, and that's from last year).
Your standards of live editing are kind of low, but that's an argument for some other time.
[1] http://research.microsoft.com/en-us/people/smcdirm/liveprogr...
WinRT really is WPF cleaned up a bit and done with a different language (though it supports .NET bindings easily), and ya, missing a bunch of features that even I sorely miss (though to be share, pixel shaders are kind of dangerous!). Same people, same API architecture, same etc...I still prefer WPF, but because I'm writing dev environments and not apps.
> Not nothing, apparently it's enough to declare text-editor devs an extinct species and decree the new generation of devs will skip text editors entirely and only consider IDE-coupled languages.
IDEs weren't a thing until recently (the last 15 or so years). Text-editor devs aren't extinct, just shrinking in numbers. Extinction doesn't occur for another 20 or so years. Anyways, you need IDE believers to make good IDEs, you can tell when an IDE has been pushed out by non-believers (it sucks, because they don't get it).
> Bret Victor showcases the benefits of previewing changes in real-time like the kind you can see with Clojure in LightTable or Swift's playground. Late-bound languages are more suitable for effecting real-time changes than static pre-compiled IDE-coupled languages, the kind that was being done in Smalltalk decades ago, even VB6 had better live-editing support than C#/VS.NET does now with Edit/Continue.
Why must an IDE-coupled language "static" or "pre-compiled"? I agree C# isn't very live nor would I try to make it be live, but the CLR provides a lot of the tools needed to get there (quick real-time tree compilation). I'm working on this right now...(see [1] again if you haven't, and that's from last year).
Your standards of live editing are kind of low, but that's an argument for some other time.
[1] http://research.microsoft.com/en-us/people/smcdirm/liveprogr...
> IDEs weren't a thing until recently (the last 15 or so years).
IDEs originated in the 1970s, and became popular in the 1980s.
> Text-editor devs aren't extinct, just shrinking in numbers.
The line between "text editor" and "IDE" is so blurry now that there's probably not a clear line between text editor devs and IDE devs. (And there's plenty of multilanguage devs whose preference on the "editor-IDE" axis probably varies by language -- certainly the level of tooling sophistication I want with Ruby is different than I want with C# or Java.)
And more and more modern languages have both "doesn't need an IDE as much as older static languages" and "can more easily support IDE tooling than older dynamic languages" as features, so there's plenty of fuel for both sides. I don't think the preference for lighter tooling is dying out.
IDEs originated in the 1970s, and became popular in the 1980s.
> Text-editor devs aren't extinct, just shrinking in numbers.
The line between "text editor" and "IDE" is so blurry now that there's probably not a clear line between text editor devs and IDE devs. (And there's plenty of multilanguage devs whose preference on the "editor-IDE" axis probably varies by language -- certainly the level of tooling sophistication I want with Ruby is different than I want with C# or Java.)
And more and more modern languages have both "doesn't need an IDE as much as older static languages" and "can more easily support IDE tooling than older dynamic languages" as features, so there's plenty of fuel for both sides. I don't think the preference for lighter tooling is dying out.
>>They're not my numbers, that's the actual output from the command-line Console apps...<<
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
WinRT was not built on the CLR. MS didn't eat it's own dogfood. Divided story between Windows Phone and Windows 8.
MS should open source the CLR. Also, the new MRT - minimal native runtime.
MS should open source the CLR. Also, the new MRT - minimal native runtime.
> MS has a history of abandoning its developer platforms and frameworks....VB6, Silverlight, WinForms and WPF are all effectively deprecated...Likewise with XNA...CSF, WCF, etc...
"Deprecated" is just a word that means absolutely nothing here since all of those kits are still fully functional on current versions of Windows (including XNA and the server side stuff that you mentioned). And VB6 is 20 years old! You wanna make a bet that your Android, Dart or Go code will run in 20 years? Android code from 2008 won't even run today mate :) Also, when Google deprecates something - it's usually hooked to a service, so there's no hope to keep using it when it's no longer fashionable (like some are doing with VB6, Foxpro and other really old kits).
> Whilst VisualStudio is a great IDE, I find it a subpar experience without R#.
And I find the lack of a single IDE built and maintained by Google to be sub-subpar. Visual Studio is superb without R#, but even if you don't think so - at least Microsoft is making life easy by offering an IDE that is tuned specifically for the task at hand instead of using some open source pile of junk that tries to do everything. There's nothing to decide when I need to do .NET - I know what tools to use. Meanwhile Google has no comprehensive strategy here and you're forced to cobble together your own toolkit. Blech.
> Another killer feature is that the language and tooling is cross-platform which supports Windows, OSX and Linux.
That's a weakness because "cross-platform" means a crappy non-native Java UI or some half-functional impostor built with HTML - and those tools suck on every platform. No thanks, I like things that are native to my platform please. Besides that, I can certainly do all of my coding on Windows and build and run it on Linux without any problem thanks (because I have been).
I don't really want to spend my time responding to another wall of text or the rest of this one so I'm going to end it here. I will say that Google does some cool stuff in the browser and with Android, but my main point here is that they don't put forth a very comprehensive strategy at all. Most of their developer stuff seems to be created by 20 percenters in their spare time instead of making a concerted effort like Microsoft does.
"Deprecated" is just a word that means absolutely nothing here since all of those kits are still fully functional on current versions of Windows (including XNA and the server side stuff that you mentioned). And VB6 is 20 years old! You wanna make a bet that your Android, Dart or Go code will run in 20 years? Android code from 2008 won't even run today mate :) Also, when Google deprecates something - it's usually hooked to a service, so there's no hope to keep using it when it's no longer fashionable (like some are doing with VB6, Foxpro and other really old kits).
> Whilst VisualStudio is a great IDE, I find it a subpar experience without R#.
And I find the lack of a single IDE built and maintained by Google to be sub-subpar. Visual Studio is superb without R#, but even if you don't think so - at least Microsoft is making life easy by offering an IDE that is tuned specifically for the task at hand instead of using some open source pile of junk that tries to do everything. There's nothing to decide when I need to do .NET - I know what tools to use. Meanwhile Google has no comprehensive strategy here and you're forced to cobble together your own toolkit. Blech.
> Another killer feature is that the language and tooling is cross-platform which supports Windows, OSX and Linux.
That's a weakness because "cross-platform" means a crappy non-native Java UI or some half-functional impostor built with HTML - and those tools suck on every platform. No thanks, I like things that are native to my platform please. Besides that, I can certainly do all of my coding on Windows and build and run it on Linux without any problem thanks (because I have been).
I don't really want to spend my time responding to another wall of text or the rest of this one so I'm going to end it here. I will say that Google does some cool stuff in the browser and with Android, but my main point here is that they don't put forth a very comprehensive strategy at all. Most of their developer stuff seems to be created by 20 percenters in their spare time instead of making a concerted effort like Microsoft does.
> "Deprecated" is just a word that means absolutely nothing here since all of those kits are still fully functional
It means everything, who want's to invest or be excited about learning technology they know to be end-of-life'd? Being deprecated is the first deathknell of a platform that begins it's slow-fade out of existence. At some point developers have to abandon the time they've invested into a platform into a new one that will be maintained in future, e.g. Cocoa/iOS/Android/HTML5/Chrome don't share the same risks of abandonment.
> And I find the lack of a single IDE built and maintained by Google to be sub-subpar
You're talking about your own feelings here, it's doesn't say anything about Google or their IDE tooling.
> Visual Studio is superb without R#, but even if you don't think so
Right, I don't, working without R# is a primitive experience that handi-caps productivity.
> at least Microsoft is making life easy by offering an IDE that is tuned specifically for the task at hand instead of using some open source pile of junk that tries to do everything
That's the exact opposite of what VS.NET is, who is the biggest offender of what you dislike. VS.NET is a kitchen-sink offering that crams in everything into a single IDE, it's the very opposite of "tuned specifically for task at hand". JetBrains platform-specific IDE's, Android Studio, XCode are examples of tuned IDE's for the task at hand. Even the DartEditor is tuned, which is more a rich editor than an IDE. It starts from a blank Eclipse Shell and only adds tooling for specifically developing Dart apps.
> That's a weakness because "cross-platform" means a crappy non-native Java UI
No cross-platform doesn't mean crappy UI, it means having the choice of developing in your preferred OS of choice, collaborating with devs on alternative OS's as well having the opportunity to host on the most cost-effective hosting solution. i.e. freedoms that .NET developers don't enjoy.
> but my main point here is that they don't put forth a very comprehensive strategy at all.
Exactly what IDE's have you used? Your perception of their tooling suggests not much. Android Studio is a very compelling offering and DartEditor actually provides a faster iterative experience which auto-builds on save and lets you debug app code natively from within Dartium in addition to the IDE.
It means everything, who want's to invest or be excited about learning technology they know to be end-of-life'd? Being deprecated is the first deathknell of a platform that begins it's slow-fade out of existence. At some point developers have to abandon the time they've invested into a platform into a new one that will be maintained in future, e.g. Cocoa/iOS/Android/HTML5/Chrome don't share the same risks of abandonment.
> And I find the lack of a single IDE built and maintained by Google to be sub-subpar
You're talking about your own feelings here, it's doesn't say anything about Google or their IDE tooling.
> Visual Studio is superb without R#, but even if you don't think so
Right, I don't, working without R# is a primitive experience that handi-caps productivity.
> at least Microsoft is making life easy by offering an IDE that is tuned specifically for the task at hand instead of using some open source pile of junk that tries to do everything
That's the exact opposite of what VS.NET is, who is the biggest offender of what you dislike. VS.NET is a kitchen-sink offering that crams in everything into a single IDE, it's the very opposite of "tuned specifically for task at hand". JetBrains platform-specific IDE's, Android Studio, XCode are examples of tuned IDE's for the task at hand. Even the DartEditor is tuned, which is more a rich editor than an IDE. It starts from a blank Eclipse Shell and only adds tooling for specifically developing Dart apps.
> That's a weakness because "cross-platform" means a crappy non-native Java UI
No cross-platform doesn't mean crappy UI, it means having the choice of developing in your preferred OS of choice, collaborating with devs on alternative OS's as well having the opportunity to host on the most cost-effective hosting solution. i.e. freedoms that .NET developers don't enjoy.
> but my main point here is that they don't put forth a very comprehensive strategy at all.
Exactly what IDE's have you used? Your perception of their tooling suggests not much. Android Studio is a very compelling offering and DartEditor actually provides a faster iterative experience which auto-builds on save and lets you debug app code natively from within Dartium in addition to the IDE.
My observations: Installing dependencies was easy. Types help a lot. The IDE is good but sometimes can not show the correct type or just shows dynamic, the autocomplete is usable if you write `this.` . Usable for a modify-refresh cycle but the attached chromium seems to be a little buggy (on xubuntu the window is not correctly drawn). In-browser exceptions are a little cryptic to read. Very similar syntax to java/c#. Good stdlib (I tried async/browser/math). Little cumbersome calling JS but it works. Bult-in factory pattern, setters/getters.
I think they could let users create multiline functions with the => operator (currently only one line). :)
I tried to pub my code, but it did not work for some reasons. I haven't tried since then so I don't know what kind of js it generates.