What is going to happen to Dartium?

[Jacob Goodson]

I thought that a thread dealing with this specifically would be good.  Will Dartium get better now?  Will Dartium be dropped?  Maybe the announcement should have been made at the Dart summit with far more detail?

[Benjamin Strauß]

What happens with new standards like PointerEvents or features like MetaClasses? Will they be added to dartium?

[Eduardo Teixeira Dias]

They are given the bad news before the summit to prevent the WTF moment.

They learned from the angular team....

2015-03-26 14:38 GMT-03:00 Benjamin Strauß <benm...@gmail.com>:

What happens with new standards like PointerEvents or features like MetaClasses? Will they be added to dartium?

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

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

[Joao Pedrosa]

Hi,

Dartium will not get better or worse. It should remain about the same I guess. And that's both good and bad depending on your needs. :-)

Dartium may continue to be considered as an unstable development platform. They don't need a lot of investments to keep it that way.

I want to know what will happen to Oilpan. I haven't been following it lately. If Oilpan manages to land in Chrome, then perhaps Dartium could use that core as a basis for further improvements in terms of GC.

Mobile platforms can be very restrictive in terms of how applications can be installed and run. They introduce their own application stores, rules and operating systems. In this case it's hard to imagine being an outlaw and challenge those authorities. :-P

Dartium should lurk there until someone finds a way to use it to sidestep some of those deployment concerns.

Cheers,

Joao

On Thu, Mar 26, 2015 at 2:29 PM, Jacob Goodson <submissio...@gmx.com> wrote:

I thought that a thread dealing with this specifically would be good.  Will Dartium get better now?  Will Dartium be dropped?  Maybe the announcement should have been made at the Dart summit with far more detail?

--

[Greg Lusk]

I'm a little concerned about Dartium too. The Observatory tool was fairly useful in diagnosing memory leaks in a large production app that we just released. We operated on the assumption that GC in the VM worked similarly enough to JS GC to allow us to find out leaks.

I haven't read all of the Dart team's replies to the various questions raised as a result of the announcement, but it sounds like the VM is no longer going to keep pace with the language. If so, then what will happen to tools like Observatory?

I may just be behind the curve, but in my opinion, the performance tools for Javascript are barely adequate and not great. Having worked a lot in the .NET world, I am accustomed to well-featured tools like Red Gate ANTS profiler. If the Dart team could find a way to work with the Chrome team to produce a highly usable profiling and debugging tool for the browser, then the Web would be better off.

[Jim Trainor]

> but it sounds like the VM is no longer going to keep pace with the language.

From the March 25 announcement:

"Many of our developers use Dart for both client and server apps, reducing costs by sharing code. We remain committed to optimizing and improving the Dart VM for developer tools, servers, and mobile apps."

... the announcement implies (strongly) the contrary.

[John McCutchan]

Observatory is still under active development. In Dart 1.9 the following new features were added:

* Builtin debugger
* CPU profile understands inlining
* Dartium integration moved from DevTools to an HTTP server so the experience is the same as using Observatory for server applications
* IC data displayed over source code
* Many important bug fixes

For Dart 1.10 there will be more features and bug fixes for Observatory. Focus is on an improved CPU profile UI and more debugger features.

Observatory will work anywhere the VM is, today, that means Dartium and the server.

Thanks,
John

[Kirth Gersen]

If they stick to dart2js for client side then they should ditch Dartium completely and provide proper debugging/profiling tools for dart2js code. I don't mind if they impose to use Chrome or embed Chromium in the Dart editor for that.

But I do mind the current state where some code can't run in Dartium and run fine with dart2js or behave differently: it makes debugging/profiling from the IDE a real pain. I almost gave up on Dart because of this.

IDE, tools and libraries are what make a programming language a success whatever its intrinsic design quality, it's all about usability and productivity. It's capital in the early years to get traction and audience.

A seamless, integrated (and complete) debugging experience from within IDEs should be a top priority.

And, for instance, C/C++ debuggers aren't C/C++ interpreters on top of a VM. They debug the compiled code using source map and other techniques. Same should be for Dart in browser if dart2js is the long term plan.

[Cristian Garcia]

Kirth that would be awful!!!!! You know the pain of having to compile just to see if the code works??? Dart2js is not exactly fast, I wait like a minute to get the whole build, fortunately I only do that to test whats going to be deployed, and finally deploy.

Fast iteration is a key feature of Dart vs say GWT, and Dartium should continue to live for that sole purpose.

[Benjamin Strauß]

As far as i know, the incremental compiler is pretty fast. I think it compiles within seconds.

[Greg Lusk]

Thanks, Jim.

I'm still catching up on all the statements from this week. You are right, that's a pretty clear statement about the viability of the VM on the server. 

[Greg Lusk]

Thank you, John. That is the information that I was looking for. As long as Dartium remains available as a development tool, my concern is alleviated for client side development.

[Bob Nystrom]

On Sat, Mar 28, 2015 at 9:25 AM, Kirth Gersen <kirth...@gmail.com> wrote:

If they stick to dart2js for client side then they should ditch Dartium completely and provide proper debugging/profiling tools for dart2js code.

Why not both?

Dartium is great for a lot of things. At the same time, we have clear feedback that users want a more debuggable human-readable JavaScript story, so we're also working on a dev compiler to JS that produces readable JS much faster than dart2js does and compilers more incrementally (per-library instead of whole program).

It's here: https://github.com/dart-lang/dev_compiler

Cheers!

- bob

[Kirth Gersen]

both ? sure, the more the better...

but both means an IDE debugger that work both with Dartium and dart2js and an Observatory for dart2js too then...

Otherwise we will have the same issues because Dartium isn't equivalent to dart2js

Providing a dev_compiler isn't doing 'both' but it's a first step and nice to have.

Kirth

[Everton Marques]

On Saturday, March 28, 2015 at 4:00:01 PM UTC-3, Cristian Garcia wrote:

Fast iteration is a key feature of Dart vs say GWT, and Dartium should continue to live for that sole purpose.

I wonder if there are any compelling reasons left, other than fast iteration, to prefer Dart over GWT? 

Everton

[Don Olmstead]

An aversion to Java? Wanting to use dart specific libraries, aka Polymer?

--

[Benjamin Strauß]

Not using Java. 

[Joao Pedrosa]

Hi,

Some of the reasons to dislike Dart also apply to GWT. Web developers cannot seem to use and depend on huge frameworks. Like any developer they prefer to stay "closer to the metal" and in this case it's the barebones HTML, CSS, JavaScript etc.

So long as frameworks like Angular provide some of them with some structure, they don't mind their JavaScript. And nowadays they are also using another such framework called ReactJS. Not to mention TypeScript for the IDE goodness some people are used to. A lot of web developers are not used to such "IDE goodness," even.

The deal is the "Leaky Abstractions" we end up creating with these huge frameworks.

Say both Dart and GWT ceased to exist. Nowadays people would not have a problem with that since they have got alternatives. More and more people are using Node.JS for their applications and relegating Java to the past. And Apple does not care one bit about Java either since they have Swift and prefer little runtime environments.

So why Java and not JavaScript or Dart or one of those frameworks or...? Young developers are not taking up Java a whole lot. On Microsoft environments people are taking up C# which is not Java. And on the web whether client or server-side people are taking up JavaScript. While Java is still useful and being taught at universities, in practice people would rather avoid it if they can.

Google may have a goal of bringing the web to the masses. We've recently learned about Chromebooks bringing down the price of computers. The greater that the web gets, the more that Google can earn with advertisement. So technologies that target the web more thoroughly are seen as good opportunities to Google.

Java is just on the way out. Android notwithstanding. People have been writing Java off for a while now. GWT being powered by Java does not help it much.

Best bet would be that Dart provides some of that Java IDE goodness for folks to make the transition.

Cheers,

Joao

--

[Alain Ekambi]

"Java is just on the way out."  

Where do  you have that one from ?  

Java stil runs the enterprise. And that wont change anytime soon.

--

Alain Ekambi

Co-Founder

Ahomé Innovation Technologies

http://www.ahome-it.com/

[Jim Trainor]

Fletch

Sky

--

[Alex Tatumizer]

> Java is just on the way out.

You mean, philosophically? Maybe.
But in practice, rumors of its demise are slightly exaggerated. At least where I live, it's ALL java. You can live quite comfortably if you have it on your resume with Spring framework, J2EE (whatever that means) etc. There's staggering amount of legacy code. No chance it will be replaced EVER. It's like Cobol on mainframes. This stuff will outlive any of us here.

[Joao Pedrosa]

Hi,

Indeed, Alex. Java support will continue. And Java can still be useful for some deployment targets. But Java is just being overwhelmed by everything that is not Java or Java-aware. There are just too many things that don't owe anything to Java nowadays. For systems level programming there is LLVM, for example.

But I mentioned it just because one of the potential advantages of GWT is that developers could reuse code they have in Java for the web. The way I see it though is that many developers don't have Java or don't want to have Java at all and would rather use an alternative like Go or Node.JS or Mono C# or Unity3D or I don't know... the alternatives to Java keep increasing. Even Microsoft recently released some of their core .NET stuff as open source for other platforms.

Particularly JavaScript has had a lot of traction lately. It's hard not to go on a programming forum and see some JavaScript related news. Specifically when I just want to see how active JavaScript developers are nowadays I browse a little bit of the Reddit JavaScript news here: http://www.reddit.com/r/javascript/

I recently helped someone on the Reddit JavaScript forum and even though they did not know programming a whole lot, they used some jQuery APIs to augment the code and before long they had a customized UI for their needs. Creating an alternative to that kind of thing can be difficult, hence the challenges that Dart has faced.

More and more people are also using things like Node.JS on the server. Not long ago I learned about how BBC was implementing some new web services using Node.JS rather than Java. And to me that means that even conservative shops are starting to adopt things like Node.JS.

And we have learned about new projects such as React Native that brings JavaScript to the mobile client-side.

Soon enough, ECMAScript 6 features could further entrench JavaScript on the server-side as well. Not to mention TypeScript as it could keep growing from its now niche.

With the plugins being vanquished from the browser, even the banks would have to learn how to do their authentications without requiring the Java plugin. Which is another strike against Java.

Java will not be replaced. It will wither away.

Cheers,

Joao

[Daniel Morilha]

(speculative mode on)

For me it is easy to understand why Google would fund an alternative to Java from the business perspective. If you follow the course of action they smartly invested in getting a deep understanding of javascript and its community while developing v8. It might have been concluded at that point that javascript wasn't an alternative to Java either and Dart was created.

With the recent shift of directions - by deciding not to integrate the dart vm into chrome - a big supportive argument for Dart of making the browser platform to run faster falls off, hitting its credibility.

From a different perspective - when looking at things like react native - it looks like the browser might not be the platform going forward anyway and the integration with chrome would be a waste.

My current conflict is how to justify the Dart or, as people pointed out, why adopting Dart over GWT. For adoption, Dart would need to show considerable difference over Java and JavaScript. Productivity is one but I wish to have others.

I think Dart is driven by very competent people in their field and I want to believe that will make the difference.

--

Daniel Morilha (dmor...@gmail.com)

[Everton Marques]

Perhaps Google should be pushing this: http://www.gopherjs.org/

 

[Jan Mostert]

potential advantages of GWT is that developers could reuse code they have in Java for the web. The way I see it though is that many developers don't have Java or don't want to have Java at all and would rather use an alternative like Go or Node.JS or Mono C# or Unity3D or I don't know... the alternatives to Java keep increasing. Even Microsoft recently released some of their core .NET stuff as open source for other platforms.

I don't see Java going away anytime soon, the JVM is still king when it comes to enormous enterprise systems and if you had to spend millions of your currency to fund development of something, would you rather spend it on something that's been proven to have a solid track record (Java being about 20 years old) and have plenty of developers that can work on it or the new kid on the block which after every new version breaks compatibility with older software and if your lead developer leaves, you're stuck with code that nobody knows how to work on.

GWT is an incredible beast, but it's horrendously slow to develop in (compared to just using jQuery) and since the user interface component of a system is something that gets updated frequently, you don't want a quick iteration to take much longer than it needs to or have your expensive senior developers bogged down fiddling with an abstraction layer to make the UI do what it's supposed to do (I have the same gripes with JSF, maybe Java is not a good fit for frontend development other than opening up APIs to Java backends for another frontend stack to use)

After 4 years of using GWT (all the way from pre 1.5 to 2.5), I dumped it for Dart, my reason being that projects kept on missing deadlines, it was a mission to just give my code to a designer and tell them to make it look pretty (even with the whole UI:Binder thing in place), fast iteration was difficult, the learning curve was very steep for most people using it.

With Dart being so close to JavaScript, I hand the designer a bunch of html files, css files and Dart and within a very short period of time, the designer can start working on it, iteratively making changes and seeing immediate feedback in the browser without having to deal with PermGen issues, GWT slowing down the dude's machine, cryptic error messages (which non-java developers don't understand) etc - instant productivity. Same with Frontend Developers, they just get it!  It just feels more natural working closer to the metal than having this enormous abstraction layer (GWT) over everything.

If your whole system is API driven (which is a good design principle in any case), Dart's increase in productivity over GWT is enormous, the little bit of code-reuse you can do in GWT is not worth the extra effort, complexities and cost.

I feel Dart has so far been an excellent replacement for GWT for our needs (an excellent balance between giving you speed of frontend developement like with jQuery without the problems of code being difficult to maintain), it's not perfect, but then again, GWT had 8 years to try and convince me, Dart is still in its infancy and so far it's impressive!

That's just my 2 cents.

--
Jan Vladimir Mostert
janvladimirmostert.com

--

[DoHyung Kim]

Dear Bob,

I'm following up discussions on the Dartium after the no-DartVM-in-Chrome announcement a little late, and after catching up with the threads in this group, I'm still unclear on what will be going on regarding Dartium.

Regarding what you wrote below, I think more is better than less only if we have unlimited resource. Also when it comes to the Dartium, its existence itself will impose huge effort considering it needs to keep up to date with Chromium and restricts how Dart interoperates with JS.

IMHO, I think things like the dev-compiler you mentioned below are the right direction for dismissing the concerns on the Dartium going away.


2015년 3월 31일 화요일 오전 1시 29분 50초 UTC+9, Bob 님의 말: