AngularDart is going all Dart | Hacker News Reader

AngularDart is going all Dart

news.dartlang.org

104 pointstweakz92 comments

Dart is awesome. Just because currently the community is still small doesn't mean much. Google is working on so much great stuff that Dart becomes more compelling every month. They are lying low since awhile with public announcements, but if you follow the commits there is so much work being done. In a few months it will become hard to ignore Dart.

The combined development (TS+Dart) was slowing Angular development down and contribution was painful because one needed knowledge of both languages. There are notable downsides for the split development but I fully understand the decision. Implementing everything in a way that it can be translated into the other language was a real pain and limited both versions to a common denominator which prevented both versions to benefit from the advantages of their respective language.

A Dart-like language designed with WASM as target will make sense now but I think Dart(as it is now)is already doomed to die. The performance promissed is just not there.

Javascript compiled from Dart is as fast as normal Js, in some cases faster. And in the server it outperforms Node according to the Techempower benchmarks. https://www.techempower.com/benchmarks/

In some cases is slower. Last time I've checked large apps were freezing on safari. The point is that it's not signifiantly faster than js so I think it's safe to say that it failed its main objective.

Dart's main objective has never been to be faster than js. Dart's goal was to make a modern, 'sane' language.

How is that? As far as I can remember performance was always the main reason. The main contributor previously worked on hotspot. It was argued that javascript hit the limits on performance and you need a clean slate, especially due the low power of the mobile devices. "Batteries included" and fixing the javascript syntatic issues was presented as secondary objective. This might have been changed after the VM was dropped from the project. Dart was supposed to be a response to native apps which failed miserably. It's a well design ecosystem for sure but it can't even compete with javascript, let alone native apps.

The keyword you are looking for is Dartium (Chrome with Dart support compiled), and if you are benchmarking a Dart app in Dartium vs. a JS app in any of the browsers, chances are the Dartium app will be faster. The technical goal was achieved, the political support lacked.

Even with Dartium it didn't reach a speed close to native. I don't doubt that if more effort would be put in the VM the perf could get better but as it is now Dartium is no longer an option.

Dartium doesn't need to be close to native, it just needs to beat every JS engine out there; in other words: the comparison should be in the same league. Last time I've checked it did beat them.

Actually it needs because it was supposed to compete with the mobile/ios/native apps not with javascript. I don't think anyone was thinking to replace javascript with something only slightly better.

If you are really looking for mobile/native development in Dart, I'd suggest you to check out Flutter (https://flutter.io/). It can achieve 60 fps on mobile apps, which is great in my view.

But I doubt that you are really interested in any of these. I've got the impression that you only try to find a justification of not using Dart, which is fine, but looks a bit weird when you are masking political decisions as technical ones.

I need someone to convince me that Dart is worth the switch and that it is safe for long terms investment. Having said that I geniunely tried Dart about 2 years ago. The plan was to try it for a small/admin app and then migrate the main app to Dart as well. Unfortunately there were issues with E2E testing; if I remember there was no Karma-like framework and on top of that the app froze several times on safari mobile. So at that time it was risky and it clearly had some technical issues. Now we know that the VM won't get into Chrome and it seems the new technologies(WASM, JS upgrades) put Dart in a difficult position. Is there any reference/complex mobile webapp 100% Dart powered?

the new AdWords UI: http://news.dartlang.org/2016/03/the-new-adwords-ui-uses-dar...

It seems they ended-up with an native iOS app and provide only some very basic information on the web version. Quite disappointing.

http://i.imgur.com/ZS0bxpi.png http://i.imgur.com/uKmnAU2.png

maybe for the mobile version (flutter is early stage, so i didn't expect Google to use Dart there [https://flutter.io/]. The last mobile webapp i worked on was just replaced with a native version which runs smoother, so i guess native development beats webdev at the moment). How about with the web version for desktop? The announcement showed advanced ui-elements: [https://lh5.googleusercontent.com/GRV687LnnWpFCpPcQ6vxjd_kEQ...] So a primitiv result there would indeed be a disappointment. It might still be work in progress. I guess they started 4 month ago with the rewrite?!

This is the original dart language announcement: http://googlecode.blogspot.co.uk/2011/10/dart-language-for-s....

You are right. Perhaps I heard only I wanted to hear. Anyway here is a talk about performance so definitely it was marketed as a high performance language for the web too. https://www.infoq.com/presentations/Performance-V8-Dart

Dart was only created to be faster than JavaScript. Here's the leaked memo about why it was created: https://gist.github.com/paulmillr/1208618

tldr; JavaScript has "baggage" and can't be made any faster than it currently is, need a different VM + language with types.

Btw, the Dart creators are compiler engineers, not language designers. It explains a bit about why it has failed to catch on.

I think this[0] summarises the main objective of Dart. Having said that I fail to see how it succeeded. Maybe it helped JavaScript evolve a bit but IOS development experience and performance is still vastly superior to Dart/JavaScript/Web.

[0] `The emergence of compelling alternative platforms like iOS has meant that the web platform must compete on its merits, not just its reach. Javascript as it exists today will likely not be a viable solution long-term. `

> not language designers

They designed a language. Is there some other qualification for being a language designer?

Lars Bak made V8, and both Kasper Lund and Lars Bak contributed the HotSpot VM. And if you don't consider Gilad Bracha (Who works on the Dart Language Specification) to be a language designer, you probably don't have a clue what he has done.

There is nothing in dart that would freeze it on safari, except that large app are slow on safari, regardless of dart. Btw. the linked benchmarks are server-side.

I have not followed WASM that closely, but I believe they are talking about adding DOM integration and other features to support languages like Dart.

It will probably not happen quickly - but in the meantime, dart2js does an admirable job.

I think the performance is there, it's just gained from JS VM optimizations instead of an alternative VM in the browser. The advantage is that it gets the benefit on all browsers (even those that would never add a Dart VM) and all other xxxToJS languages get the benefit as well. Dart has enough other advantages so being on par with others on performance doesn't mean Dart has to die.

Maybe won't die but it won't thrive either. I guess it's the new GWT. Not a bad thing but it won't disrupt the web development for sure.

> Dart is awesome. Just because currently the community is still small doesn't mean much.

Well, it does mean something. Go is evidence that languages can gain momentum very fast so the fact that Dart still hasn't should be a bit of a concern (and probably partially caused by Typescript's popularity).

Dart does have some momentum as well and it's younger than Go. Go's 1.0 release was at 28 of March 2012, whereas Dart's was November 14, 2013.

- https://blog.golang.org/go-version-1-is-released - http://news.dartlang.org/2013/11/dart-10-stable-sdk-for-stru...

I'm working on a project in Dart. It just works, and it feels simple, and the type system means I can think more cleanly about my code. I like it, and this news is great!

My initial reactions upon hearing this.

  * wait, is dart still a thing?
  * this can't be good for angulardart.

Basically they're splitting the project into two projects, claiming that both sides will benefit from lots of support. I suppose if the typescript half of angular was held back by any needs to cross-compile into dart, then the typescript half will be losing shackles.

I honestly don't see how a low-penetration language is going to benefit much here - are we going to see a resurgence of interest in dartlang just because now there's a more native-feeling angular library for it? I've been wrong in the past, I guess.

Many Google teams are using it so it will be maintained regardless. The team maintaining it doesn't really depend on outside enthusiasm (though it would certainly be nice).

> are we going to see a resurgence of interest in dartlang

It is hard to predict the future, but I do think this is a very positive move for Dart that will drive adoption.

Dart frameworks were always playing second fiddle to the needs of Javascript developers - resulting in compromises.

A Dart first framework (with some awesome Material widgets thrown in) will offer a compelling developer experience.

Combine that with Dart on Mobile (flutter.io), Dart on IoT (dartino.io) and Dart on the server, and you have a very nice story.

Rectify dart and go for me, please.

Why should I learn one or the other?

If the ideas and concepts behind dart are so good why isn't golang taking input from it?

If golang is so good why does dart even exist?

Dart and Go each serve different platforms.

Your question is kind of nonsensical. The two languages have little, if any, overlap in use cases.

This isn't true; they're both general purpose programming languages with strong static type systems and decent async I/O stories. You can write a web app or a server in either language, though Dart has a better ecosystem for frontend development, and Go has a better ecosystem for backend development.

Is there any "ecosystem for frontend development" for Go at all?

Dart is dynamically typed.

It's technically optionally typed, but it has a static type checker which puts it more in the "static" camp in my mind. https://www.dartlang.org/articles/language/optional-types

Well, for example, you could use Go on the server and Dart in the browser. (I quite like using Go with App Engine.)

Of course that means you can't share code between client and server, but not everyone needs that.

Both Dart and Go can be run in the browser or on the server, so you can share code between client and server regardless of which language you choose, so long as you don't mix them.

Well, maybe. I have not kept up with GopherJS; how are they doing on code size? And while you can certainly run Dart on an App Engine Managed VM, there is no free tier like with Go.

Not sure about GopherJS. I'm confused about how App Engine's pricing model relates to whether or not Dart is well-suited to server tasks?

Well, it's relevant to those of us who are using App Engine. Where else can I can I set up a service for a hobby project without a monthly charge if it's barely used?

I'm personally of the opinion that many languages is a good thing. I don't like monocultures much, so on that level, I want dart to succeed.

I agree that having a robust dart-first framework (and widget library) is a necessary condition for making dart popular. Here's hoping it is also sufficient. I feel like Dart lost its biggest edge when google moved away from the dart runtime. If everything is just compiled down to js anyway, dart can't do much more than put syntactic sugar over what's already there, instead of providing a real new language experience.

Then again, clojure, scala, and java are really different experiences. Maybe google's backing keeps the language running long enough to gain real traction.

From http://angularjs.blogspot.com/2016/07/a-dedicated-team-for-a...:

"If you're a TypeScript or JavaScript developer, you'll also benefit from cleaner JavaScript APIs and performance gains as we simplify the TypeScript codebase to remove the need for compilation to Dart."

Maybe this split was prompted by the imminent release of Typescript 2.0?

What a train-wreck. So now AngularDart has it's own dedicated team? Angular is already swimming upstream having lost its position to React and it's respect within Google to Polymer. That they are going to be supported 2 separate language versions of the same giant framework is kind of hilarious.

The Javascript wild wild west.

Unfortunately that also means web www

Calling it a train wreck is massive hyperbole. Just because React is so popular on hacker news or in the SF bubble does not mean it is anywhere near a de facto superior choice. Using such hyperbole detracts from the conversation and misleads young developers who may not yet know how to accurately weigh software stack decisions for personal or professional projects.

And this is coming from someone who was really excited for 2.x (and TS for that matter) but has resigned to probably staying with 1.x and es5/6 for the foreseeable future.

Totally my opinion but react is simply the best way to create user interfaces, regardless of language. If someone made react using Python targeting GTK components it would be the best. The one way data flow and flux architecture is superior to other UI frameworks I've used.

I find flux to be a really bad way to organize an application. It removes the good engineering practice of having self-contained components. So if you're writing a tabs widget you can't put all of its code together, you have to maintain a separate "reducer" or whatever for the tab state in a different file usually in a completely different location, and the top level of the application has to know about that reducer.

I think this architecture is an awful way to go, and I have no idea how it has become popular.

All of the components are totally independent. You pass functions as props for events that happen inside of the component, and choose to use whatever storage mechanism you want. Maybe you don't fully understand how react works.

I was talking about flux. You might have recognized it because I used the word "flux" in the first sentence.

> I find flux to be a really bad way to organize an application.

To be fair, Flux != React. Plenty of people do fine with `setState` and passing down props and you can get quite far. Honestly, I am with you that Flux/Redux ecosystem seems quite overengineered not by their "leaders" and creators (who ask people to keep things simple!) but by regular users. A lot of people solving problems they don't have.

1. Tab state is presentation state, so generally belongs in the component rather than in Flux which is generally for business state.

2. If you do have a tabs reducer, it should be considered part of your tabs component. Use a good boilerplate that sets it up that way, like https://github.com/mxstbr/react-boilerplate

I'm using redux with angular2 at work. Flux != React, and angular2 itself (just like React) does not impose any required data flow or other organization even.

What stops you from migrating to 2.x? I'm geniunly interested. I have a fat app in 1.x myself but for new peojects I would consider Polymer instead of Angular 2.x

Happy to answer that. First off we don't use vanilla angular 1.x, we use meteorJS + Angular-Meteor which means we're locked in to Meteor's build pipeline.

Angular-Meteor supports both 1.x and 2.x, and Meteor's build pipeline has us writing angular code in ES6 that is on the cutting edge of 1.x and looks very similar to 2.x without actually being typescript.

The Meteor and Angular-Meteor teams are both really great, really quick response times to issues and combined have a really great ecosystem that helps bridge the gap between traditional angular libraries and the Angular-Meteor stack.

However 2.x support in Angular Meteor is slightly different then the bleeding edge of 2.x from the Angular teams. Last I checked their are a few shims and it is also incompatible with a lot of third party meteor and angular-meteor libraries. Furthermore switching to 2.x would require a decent amount of refactoring, not necessarily because we'd HAVE to refactor it but because if we did refactor we'd want to take advantage of as much of 2.x as possible which would require rewrites.

Finally I don't really like Typescript. I think its advantages over ES6 are marginal for most small or medium apps. Having to refactor Es6 -> Typescript and 1.x -> 2.x seems like a lot of work to me, especially because 2.x will have the growing pains of being bleeding edge, meaning fewer stack overflow answers and a much smaller ecosystem.

For a new side SPA project where I could write a custom build system via Gulp I would probably write it in 2.x, or maybe try out React. But I still wouldn't use it for a new production app because I see too much added complexity that would diminish the productivity I've already built up in 1.x.

Oh and then the only effect it has on end-users is slightly faster performance. You can argue for weeks over the value of this, but for us it's fairly marginal. Our app doesn't render tons of rows or anything that is slow to begin with, so it would almost have no affect on them whatsoever.

Thanks for the answer! Shortly said I feel the same. Angular 2.x would bring fairly marginal value to an existing project. Considering the amount of refactoring it's not worth it yet.

Since ES6 is valid TypeScript, it seems like you could move to Angular 2 without learning much about TypeScript (beyond how to run the compiler).

I'm not making any value judgment here; I dislike React and it's over-abstraction paradigm. I long for the days when web components will be mature enough that we can leave frameworks behind.

But there's no denying that if you go to a web/js meetup in just about any city in the US 8/10 talks will have something to do with React, and that's the position Angular was in 3 years ago. Doing silly things like maintain 2 frameworks with the same name isn't going to help.

FWIW, I don't think number of talks on meetups is a good measure of long-term success at all.

AngularDart's play is not to be the next React (the same way Go is not trying to be the next PHP). AngularDart users at Google are, to my knowledge, extremely happy with the framework, but their enthusiasm won't necessarily (or even probably) translate to large portions of JS crowd. AngularDart works for a specific set of problems (very large web apps that need to be performant and work well on mobile, built mostly by developers with classic CS background).

I personally think insisting on the one framework (Dart+JS+TS) was the silly thing to do, and I'm glad that's over.

Not just hyperbole, as others have suggested, but most of what you're saying is flat false. Google's (and maybe the world's) most profitable app, AdWords, is built on Angular 2 and Dart, as is their entire internal CMS. Inside and outside of Google, Angular 2's adoption numbers are extremely impressive for a beta framework.

Yeah, this is really bizarre. It was confusing enough that Angular 1 and Angular 2 are completely different. Now there are two completely different versions of Angular 2 with potentially different support cycles (and different bugs).

I find Dart consistent, fun and the documentation very beginner friendly, especially compared to Go.

I really want to use it and wish the community/IRC was slightly more active.

A lot of community members hang out on slack:

https://dartlang.slack.com

https://www.dartlang.org/community most discussions are on Slack. It's a bit unfortunate because one needs to register but it seems to be the platform most Dartisans are comfortable with.

How is Dart more beginner friendly than Go? You can't do much with Dart without an IDE for example. The language itself is also more complex than Go

I wrote "Documentation" is beginner friendly.

Spend some time reading their docs. Dart has language, Web and Server tutorials specifically for beginners. The style of writing in which they build up to explain simple concepts to things like method chaining just click. Its very natural.

Go is minimal and great for people already experienced.

I felt Dart docs were centered around human problems and Go around CS problems.

The community is quite active, I think. Most chatting is happening on Slack. Lots of articles/tutorials pop up on Dart Academy (https://dart.academy). For Slack details and other means of hanging with the community, check out the Community Page (https://www.dartlang.org/community).

"First they ignore you, then they laugh at you, then they fight you, then you win." - Mahatma Gandhi

Frankly, all these arguments are by people who never tried Dart in the first place. Dart is perfect for large scale applications - especially enterprise ones.

"... But they also laughed at Bozo the Clown."

- Carl Sagan

I tried both TS and Dart and Dart has just way better developer exp. especially when using IntelliJ and doing lot of small apps which have to be mantained.

Would be great if you could provide some details.

I only have experience with Typescript, almost none with Dart, and I would love to see a comparison of the two in practical use, especially with Intellij.

[edit typos] This should be whole blog post, but I will try to show most important points from top of my head. I do compare my exp using TS with VScode and Dart IntelliJ.

Dart analyzer is usually able to show more common mistakes even if you are not heavy type user. Shorter time to find simple typo.

It's easier to start debugging and it's more reliable. This could be IntelliJ itself.

code in Dart is shorter for small apps since it has build in SDK - no need to external libs. It's easier to back to this code after few weeks - easier to mantain. Also time to start from scratch is shorter

Pub (external libs) is way superior to what we have in TS world

One library importing mechanism which doesn't confuse me

I'm not afraid if lib x confilts with lib y

await async works on non ES6 browsers - no wired settings in main config file!

There is one thing better in TS which I like very much - how interfaces can be aplied to decoded Map

The big difference between Dart and TypeScript is that Dart has a standard library for DOM.

But I'm not sure how that's different than .d.ts files for DOM that TypeScript has in its core. After all DOM code is translated to JS code 1:1. Maybe Dart does more magic?

Dart has more polyfill stuff built-in. This is IMHO a big advantage when I see all the related StackOverflow Angular2 TS questions. A downside is that it is sometimes a bit more cumbersome to work around if something is not fully polyfilled by Dart and you have to work around "manually".

TypeScript is evolving towards the same language and tooling goals as Dart has already achieved. I have worked with both, and I find TypeScript tooling to be years behind Dart (event with recent improvements of type inference and e.g. VS's intellisense).

The main reason TypeScript got more adoption was the fact that it was built on top of JavaScript, and people could easily start mix-and-match with their JS code. While that is great for easier adoption, it may not protect your engineers on the same level as Dart does.

Thank god - for anyone who has contributed to Angular 2, having to write code a certain way because of dart sucks.

Dart doesn't suck. Dart is different and developing in a way that meets both language needs is a pain in many situations. If you say Dart sucks you also have to admit that TS sucks. They just suck at different things. There are no upsides without downsides. It's just about what upsides and downsides you are more comfortable to live with.

I don't think OP was saying that dart sucks. He was saying it was a pain to have to write his ts code in a certain way to accomodate the Dart side of things. By splitting the repo he doesn't have to worry about that anymore, just like Dart developers won't have to worry about the ts/js side.

I didn't say Dart sucks - I said having to write the code a certain way when contributing due to Dart support, which is near non-existent outside Google, sucks.

In addition, it has complicated a lot of stuff for a long time due to build setups, bugs related to toolchains around Dart and Angular 2's repository, lengthier CI runtimes, and more. It was a huge net negative for those looking to contribute, even for simple changes.

> I said having to write the code a certain way when contributing due to Dart support

It sucks in both directions. If you're trying to fix things for Dart users, it's also a real hassle to have to figure out how to back-translate that into some kind of TypeScript that will then be compiled back into the Dart code you have in mind.

Having a single source of truth that you translate to JS/TS and Dart makes a lot of sense when the value you get from sharing outweighs the cost of dealing with the pipeline. My impression is that that cost/benefit hasn't worked out well for Angular. I think being split will enable both sides to move faster, even if it means manually migrating some fixes between the two languages.

The post you are replying to didn't say Dart sucks.

> having to write code a certain way because of dart sucks

Oh come on, it was obviously meant as

> having to write code a certain way (because of dart) > sucks

OP didn't quite say that Dart sucks though, did he? He said that coding in TS having to also cater to Darts needs/conventions sucks (which might be true or not, no idea really).

So there is now Angular 1, Angular 2, AngularDart. Next I predict they will launch Angular 3 which is incompatible with all the others.

To me Angular2 is not really worth it. The magic was on Angular-1. It did good but now Polymer and React have the mojo each for different reasons. Unfortunately the web development is still a big mess even on new projects with supoort for latest browsers only.

Angular1's USP was basically the magic that turned out to be a bad idea and was removed or at least significantly reduced in Angular2: scopes and dependency injection.

I can still see the appeal of Angular2 to non-JS developers (e.g. C# or Java developers switching to JS) but it's a very different framework. It's certainly no longer living up to its original claim "designers can write code without being programmers" (though that was only ever really advisable for prototypes to begin with).

One of the most frequent criticisms I have heard from JS developers about Angular is that being a good JS developer and being a good Angular developer are separate pairs of shoes (compared to e.g. React+Redux where most of the learning curve is JS rather than React or Redux). I don't see Angular 2 having done anything to change that.

Having written a handful of apps using Angular 1, I would say it's true that you have to learn Angular's way of doing things, but most of the code for the apps I've written is plain JS.

Angular 2 no longer has its own module system, so that's one less Angular-specific thing you have to learn about.

> Dart was designed "batteries included" – it’s not just a programming language, but also a set of stable libraries, solid tools, a great framework — and soon, a repository of battle-tested UI widgets.

Clicked on solid tools link. Got 404: Page not found.

Not a solid start.

Just what the javaScript framework world needs, more competing standards!

Reply on news.ycombinator.com