Dart vs Golang for Server-side Development

[Richard Eng]

I've been playing with Golang and Beego for server-side web development. I chose Beego because it's the most mature and popular framework out of the three main ones currently available (ie, Beego, Revel, Martini). I'm a little confused about Dart. What are the most mature and popular server-side Dart frameworks currently available? And for what reasons should I consider migrating from Golang to Dart? Thanks.

[Matthew Butler]

On Saturday, November 8, 2014 11:05:32 AM UTC-4, Richard Eng wrote:

I've been playing with Golang and Beego for server-side web development. I chose Beego because it's the most mature and popular framework out of the three main ones currently available (ie, Beego, Revel, Martini). I'm a little confused about Dart.

Confused about what exactly?

 

What are the most mature and popular server-side Dart frameworks currently available?

There are a number of frameworks available including Shelf, forcemvc, vane, redstone, and numerous others I haven't mentioned. As with any other framework it takes searching and evaluating to decide which best suits your needs.

 

And for what reasons should I consider migrating from Golang to Dart? Thanks.

On the server? Truthfully if you have a working, in production fairly well advanced and stable server, then you shouldn't. Don't migrate just for the sake of migrating. Go is extremely powerful on the server and can make great use of the platform you're running on. 

If you're starting a new project, and particularly looking at using Dart on the front end, then one of the main benefits is that you can keep your mindset in the same language. Using Dart on the server and client helps to reduce the mental shift changing from one language to another. Additionally, in a well modelled project, you can actually share code for objects on the client and objects on the server when working with databases and such and minimize duplication of efforts. 

Dart fits well on the server in the same way node.js fits on the server. To keep using the same language on both the client and server. Darts async nature makes it easier to write non-blocking server routines (however done incorrectly you can still write blocking asynchronous code). As with any development option, its about knowing the tools you have available and which best fit to your development needs and the needs of your project.

Matt

[Richard Eng]

I'm confused about the framework choices. I'm trying to determine which framework is popular enough for me to invest my time and energy in. All my Googling is unable to reveal the answer.

Investing time and energy in a framework that is not thriving would be a colossal waste for me. I am aware of the frameworks that you've listed (and more). However, it is difficult to determine which ones have "legs". Most of them undoubtedly will be "fly by night"; they'll languish and die after a few years (or sooner!).

I've seen the exact same situation in the Golang community. Frameworks sprout up like weeds, but most of them are largely defunct now. Beego and Revel have clearly risen to the top of the heap.

So which Dart framework(s) is(are) thriving?

[Matthew Butler]

Shelf -> Maintained by the Google Dart team, plugable architecture means not all plugable components are also maintained by them however.

Vane -> Created and specifically used by the DartVoid.com site. Used as part of their business.

RedStone -> very active 

Rikulo Stream -> Mature, well supported and in use by other commercial entities

Best suggestion would be to use pub.dartlang.org to search for server options and evaluate the various projects (most have a homepage or source repository listed for you to check out activity etc). Unfortunately there is no clear answer to provide due to the age of Dart in general. You mention that "Most will be fly-by-night and die after a few years" when the Dart language and its core libraries haven't even been considered 'stable' (post 1.0) for a few years yet. It's impossible to say which of the above (or yet to be written) framework will become the next 'Ruby on Rails' for Dart, or the next Django, or Express.

Matt 

[Joris Hermans]

All these serverside frameworks are developed in the open, most of them are on github! So you can always help the frameworks, build something on top of it. 

Contribution and helping each other to build great things with dart is the way we should go with this community the make the best software there is!

But indeed, like Matt said, just try some frameworks out, and see what is for you the most productive. Every framework has its pro's and con's and one framework will be more easily to learn then another depending from what you already know from within another programming language.

Joris

--
You received this message because you are subscribed to the Google Groups "Dart Server-side and Cloud Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cloud+un...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/cloud/.

[Günter Zöchbauer]

You didn't tell about the features you need. What advantage does the most mature and perfectly maintained framework if it doesn't provide the features you need for your application.

When developing with Dart a lot of functionality moves from the server to the client therefore the requirements differ a lot between a web application written in Go or written in Dart.

I think the main reason to move from Go to Dart for server side code is if you develop the client in Dart and prefer to use the the same language for the server for reasons like

- code reuse

- focus to master one language well instead of several mediocre

[Anders Holmgren]

Also consider a micro service approach and then you can try dart on the server for new services

--

[David Notik]

My bet's on Shelf. There's a lot of excitement for it, it seems very well thought out, it's modular and extensible and and there are already a lot of contributed pieces, and of course some great folks at Google are actively improving it. I'd like to move to it soon. You can of course also just roll your own simple framework (as I did given Shelf wasn't on my radar at the time) using some contributed pieces: route_hierarchichal for routes, http_server for your server, there are probably some request/response packages, etc.

--D

[Anders Holmgren]

I would second that. Shelf is very modular so you end up with an ecosystem of components. You can simply pull in the components you like or use higher level frameworks that bundle and integrate some. That helps spread your risk a little as it's unlikely that all the components you pick will wither and die ;-).

[Richard Eng]

I don't have a specific application in mind. I'm looking for a "general-purpose" framework. I don't want a framework with a narrow focus.

Based on responses, as well as examining the Github repos, I've come to realize that the only "mature" framework is Rikulo Stream. Everything else is in flux (gestating; nowhere close to Version 1.0) and not ready for prime time. If I had to place a bet, I'd put it on Rikulo Stream.

Now I have to decide whether to adopt Dart/Rikulo Stream, or stick with Golang/Beego. Using a common language between client side and server side does not apply to me because I don't believe Dart will succeed on the client side (where I would prefer to go with JS). I don't want to start a flame war; I know Dart is trying to unseat JS, but, frankly, that isn't going to happen (not even with Dart->JS transpilers).

[David Notik]

I don't think anyone's banking on Dart unseating JS, and it doesn't need to. It compiles to JS to work across modern web browsers while smoothing a fair deal for you in the way of optimizations and cross-browser issues. But that's saying nothing of the real reason folks choose Dart, or JS or any transcompiler or framework for that matter: the ways in which it may benefit you and your projects, relative to your other choices. 

In Dart's case relative to JS, I think the language is more sane, debugging easier, the core libraries really powerful, the tooling more uniform, and the ecosystem more organized. I like the idea of one language on client and server, and yet the way it's done in JS-land with Node feels wilder and less approachable than I liked when I researched it some years back. That's just me, and admittedly I don't have all that much experience in the world of JS before I dove into Dart.

There are some tradeoffs of course, the biggest being that you sort of block yourself off from a world of JS libraries and even community to some extent. There's dart:js interop to wrap any JS library, and work being done to make that even easier with js:interop, but I think there'll always be some disconnect. Still, it's about costs versus benefits, and there are many benefits that I think ultimately outweigh the costs.

The point is there are a whole host of reasons to choose Dart, and I think it's foolish for any one of those reasons to be because you think it'll unseat JS. It won't, but there might be merit to it unseating JS in your own workflow.

FWIW.

--D

--

[Seth Ladd]

On Mon, Nov 10, 2014 at 8:57 PM, Richard Eng <horrido...@gmail.com> wrote:

I don't have a specific application in mind. I'm looking for a "general-purpose" framework. I don't want a framework with a narrow focus.

Based on responses, as well as examining the Github repos, I've come to realize that the only "mature" framework is Rikulo Stream. Everything else is in flux (gestating; nowhere close to Version 1.0) and not ready for prime time. If I had to place a bet, I'd put it on Rikulo Stream.

Now I have to decide whether to adopt Dart/Rikulo Stream, or stick with Golang/Beego. Using a common language between client side and server side does not apply to me because I don't believe Dart will succeed on the client side (where I would prefer to go with JS). I don't want to start a flame war; I know Dart is trying to unseat JS,

Just to be clear, Dart is not trying to unseat JavaScript. Dart offers choice to developers that want to build for the server or for the web with a productive, light weight, familiar, class-based, optionally-typed, fast, rich core libraries, scripting language (which happens to compile to JavaScript when you want to target the web).

 

but, frankly, that isn't going to happen (not even with Dart->JS transpilers).

On Monday, 10 November 2014 11:00:52 UTC-5, Günter Zöchbauer wrote:

You didn't tell about the features you need. What advantage does the most mature and perfectly maintained framework if it doesn't provide the features you need for your application.

When developing with Dart a lot of functionality moves from the server to the client therefore the requirements differ a lot between a web application written in Go or written in Dart.

I think the main reason to move from Go to Dart for server side code is if you develop the client in Dart and prefer to use the the same language for the server for reasons like

- code reuse

- focus to master one language well instead of several mediocre

On Monday, November 10, 2014 4:19:39 PM UTC+1, Richard Eng wrote:

I'm confused about the framework choices. I'm trying to determine which framework is popular enough for me to invest my time and energy in. All my Googling is unable to reveal the answer.

Investing time and energy in a framework that is not thriving would be a colossal waste for me. I am aware of the frameworks that you've listed (and more). However, it is difficult to determine which ones have "legs". Most of them undoubtedly will be "fly by night"; they'll languish and die after a few years (or sooner!).

I've seen the exact same situation in the Golang community. Frameworks sprout up like weeds, but most of them are largely defunct now. Beego and Revel have clearly risen to the top of the heap.

So which Dart framework(s) is(are) thriving?

On Monday, 10 November 2014 10:02:15 UTC-5, Matthew Butler wrote:

On Saturday, November 8, 2014 11:05:32 AM UTC-4, Richard Eng wrote:

I've been playing with Golang and Beego for server-side web development. I chose Beego because it's the most mature and popular framework out of the three main ones currently available (ie, Beego, Revel, Martini). I'm a little confused about Dart.

Confused about what exactly?

 

What are the most mature and popular server-side Dart frameworks currently available?

There are a number of frameworks available including Shelf, forcemvc, vane, redstone, and numerous others I haven't mentioned. As with any other framework it takes searching and evaluating to decide which best suits your needs.

 

And for what reasons should I consider migrating from Golang to Dart? Thanks.

On the server? Truthfully if you have a working, in production fairly well advanced and stable server, then you shouldn't. Don't migrate just for the sake of migrating. Go is extremely powerful on the server and can make great use of the platform you're running on. 

If you're starting a new project, and particularly looking at using Dart on the front end, then one of the main benefits is that you can keep your mindset in the same language. Using Dart on the server and client helps to reduce the mental shift changing from one language to another. Additionally, in a well modelled project, you can actually share code for objects on the client and objects on the server when working with databases and such and minimize duplication of efforts. 

Dart fits well on the server in the same way node.js fits on the server. To keep using the same language on both the client and server. Darts async nature makes it easier to write non-blocking server routines (however done incorrectly you can still write blocking asynchronous code). As with any development option, its about knowing the tools you have available and which best fit to your development needs and the needs of your project.

Matt

--

[Richard Eng]

There are some real problems with using Dart on the client side. For starters, it is highly unlikely that the Dart VM will be incorporated into any major browsers other than Chrome. Second, it is highly unlikely that Dart-to-JS transpilers will support anything but the latest browser versions. You cannot assume that the whole world will upgrade to the latest browser versions, and to disfranchise even a minority of web users from Dart applications or Dart-enabled websites is a big no-no. Third, compiling to JS will be slow because generating optimized JS is hard work. Once you enter the test/debug/edit/compile cycle of your JS output (and you must test your JS output), it will be inconvenient and time-consuming. So whatever the "benefits", I'm not convinced that they outweigh the costs.

[Kevin Moore]

Richard: there are certainly some tradeoffs. For tiny apps, even I would import jQuery and do something simple.

At a certain level of complexity, having a structured language is really helpful. There are a number of companies (and important teams at Google) that believe Dart is a great investment for browser apps.

As always, we recommend that everyone do their own analysis.

[Richard Eng]

One can draw similarities between Dart and GWT. Both offer a structured language suited to large-scale development. But GWT never took off. It's really hard to convince developers to add an extra layer to the development process. That's why the prognosis for Dart is not bright.

I wish the Google Dart team the best of luck. I really do. But I am not sanguine. My 30 years of experience in IT tell me that this is not a good bet; I have a bad feeling in my gut. (Maybe I should've laid off that last burrito.)

[Anders Forsell]

One can draw similarities between Dart and GWT. Both offer a structured language suited to large-scale development. But GWT never took off. It's really hard to convince developers to add an extra layer to the development process. That's why the prognosis for Dart is not bright.

As far as I heard GWT is doing quite well. The new "Inbox by Google" is using it and other frameworks like Vaadin utilize the technology. 

So I would say that GWT took off for large-scale development. For "mainstream" development JavaScript is hard to beat as you really need just a simple text editor with no extra tooling to get started.

My take is that Dart on the client-side will definitely be a major player for large-scale development, but for "taking off" for the masses I believe the VM has to be integrated at least in Chrome.

Even adding a thin layer of tooling like TypeScript or Angular 2.0's AtScript seems to be "too much" for the JS community.

I am happy to hear that server-side Dart caught your interest and hope you find a good framework that suit your needs.

[Gérald Reinhart]

(I love Dart the language and the platform)

At some point, I planned to push Dart in my company, starting with the client-side with a long plan going to the server side.

BUT, I'm waiting the Dart VM on Chrome : it would be a Google commitment to Dart and I would have enough argument to push this technology in my company. 

(Moreover not a word on Dart during the 2H keynote on Google IO last june)

As many Dartisans, I'm working on Dart at night and hesitating to push it on there company during the day.

Hope it will change soon.

[Filipe Morgado]

On Friday, 14 November 2014 03:42:07 UTC, Richard Eng wrote:

One can draw similarities between Dart and GWT. Both offer a structured language suited to large-scale development. But GWT never took off. It's really hard to convince developers to add an extra layer to the development process. That's why the prognosis for Dart is not bright.

I wish the Google Dart team the best of luck. I really do. But I am not sanguine. My 30 years of experience in IT tell me that this is not a good bet; I have a bad feeling in my gut. (Maybe I should've laid off that last burrito.

I thought we were talking about server-side Dart. Even Go requires a compilation step (even if it is quite fast). It's hard to find a language with a shorter development cycle than Dart.

As for the client-side, if you're not using any "extra layer", you're doing it wrong. Even plain JS requires join/minify/gzip for production code (and the burden of explicitly handling multiple files while in development). Again, thanks to the Dart VM, it's hard to find anything with a shorter development cycle than Dart.

On Friday, 14 November 2014 09:05:28 UTC, Gérald Reinhart wrote:

(I love Dart the language and the platform)

As many Dartisans, I'm working on Dart at night and hesitating to push it on there company during the day.

Hope it will change soon. 

+1 

[Richard Eng]

When I say GWT has never taken off, I mean that it's not ubiquitous. Sure, it's used in a few major endeavours, but it's not widespread. In fact, it wasn't even on my radar until a few months ago (and I've been in IT for over 30 years!). GWT does not have much mindshare. It will continue to "do well" in the same way that desktop Linux is doing well...both have tiny market share, but committed and avid fans.

[Richard Eng]

We *were* talking about server-side Dart. We're off on a slight tangent here...

I **love** Go. And I like web development using Beego (so much so that I wrote an "advanced tutorial" [here](http://goo.gl/9WhUoy).) Yes, it compiles quickly and the development cycle is short. My gripe with client-side Dart is that eventually you have to muck around with the JS output; you can't do all your testing and debugging in Dart and then simply compile to JS in production and forget it. There is a world of difference between the Dart VM and JS output. I suppose a similar reason is why GWT never took the world by storm.

[Kevin Anderson]

What I take issue with is the notion that because of the lack of wide spread adoption things like GWT, Dart, etc should be abandoned. What did GWT bring to the table? It brought the notion of actually writing client side code in a language that was type safe. Bringing the years and years of enterprise development to the front end from code organization to programming patterns. This caused JavaScript developers to really start thinking about application development not just dom manipulation. This (and I am not saying it was the first)  created the forum for other Compile-To-Javascript frameworks to be developed. There are now many JavaScript frameworks surrounding the notion of actual application development.

What we need is a competitor to JavaScript in the browser. These compile to javascript solutions are not enough. Competition breads innovations. That is what Dart brings to the front end. The Dart team may take the approach that they are not trying to replace JavaScript, but I would hope they are doing their best to create an environment that competes with them. (And I do.) The DartVM is the power of Dart, the language has some nice features, but what Dart really brings is a potential competitor to Javascript in the browser. And the ecma community, whether they admit it or not, have seen that they need to innovate on the standards so that they still have relevance in the future. Which is great! We should be applauding these efforts and encouraging these emerging technologies to push the boundries, instead of dismissing their relevance because they are not adopted universally overnight. If they never "take the world by storm" does not mean they are a failure or irrelevant.

Keep up the good work Dart Team. I look forward to seeing what the future brings.

--

[Richard Eng]

I agree 100 per cent – we need to replace JavaScript in the browser. All this crap with compiling to JS will never fly.

The issue is not so much technical as it is political. We need the Dart VM built into every major browser, not just Chrome. How to accomplish this is the Question of the Day. It's difficult to see how we can force the likes of Microsoft, Apple, and Mozilla to fall in line. If we can't come up with an effective strategy, then we are largely wasting our time with Dart (it'll be just another technology that litters the web landscape).

Forget the childish plan to use a Dart-enabled Chrome to showcase Dart applications and attract a major user migration (thereby giving Chrome's competitors a swift kick in the rear). This plan can only work if Dart applications are ubiquitous or if a few "killer" Dart applications take the world by storm. The latter is a faint hope, and the former is unlikely. Users of the web must be shown the actual utility of Dart applications.

[Kevin Anderson]

Cross browser adoption is the key to wide spread adoption. But having one major browser supporting the effort is a good start. The path is unclear, but I don't think that lack of immediate clarity should deter the community from exploring and creating with Dart. 

[Filipe Morgado]

On Friday, 14 November 2014 16:28:16 UTC, Richard Eng wrote:

The issue is not so much technical as it is political. We need the Dart VM built into every major browser, not just Chrome.

I disagree with this.

The power of Dart comes from the Dart VM AND from the fact that the language compiles to JS.

We will never see any Dart feature which cannot be efficiently compiled to JS.

When JS evolves, great, dart gets more room for improvement.

(Would love to see ES6 tuples in Dart ... and protected members, which TypeScript is getting).

Every browsers already run Dart apps in JS.

If/when Dart gets into Chrome, Dart apps will get a speed boost and reduction in memory usage out-of-the-box. Programmers won't have to change a thing.

We will start to see "Works better in Chrome" messages, until other browsers ship with Dart as well.

This will be very important for performance-intensive apps, such as games, where the performance of JS is just not enough.

The mobile market is booming. The market share of Android is huge and will probably get bigger.

I wouldn't be surprised if Chrome has 80+% market share in 5-10 years.

Can you see the potential for Dart apps?

There are already other options to boost performance of web apps: asm.js or (P)NaCL.

Yeah, it's already "Works better in Firefox" or "Works only in Chrome".

Would you rather write your games in Dart (which runs everywhere) or C++ (which may not run everywhere)?

If there is a bug in your production app ... yeah, debugging JS output is a pain.

Personally, I would just use Dartium and try to replicate the bug because it's likely a bug in my code.

If Dart and JS have different behaviors, it's a dart2js problem. It's up to the dart2js team to worry about it, not Dart programmers.

dart2js bugs should become quite rare (if they're not already).

In the end, a Dart programmer will only see Dart code.

C'mon Google, make a commitment!!!!

[Seth Ladd]

On Fri, Nov 14, 2014 at 8:28 AM, Richard Eng <horrido...@gmail.com> wrote:

I agree 100 per cent – we need to replace JavaScript in the browser. All this crap with compiling to JS will never fly.

The issue is not so much technical as it is political. We need the Dart VM built into every major browser, not just Chrome.

You may want this (and it certainly would be cool!), but Dart doesn't need this to succeed. Success for Dart is that developers are productive and happy and building awesome experiences on the web and the server. Dart is useable today, there are plenty of developers building with Dart and deploying into the wild. See https://www.dartlang.org/community/who-uses-dart.html for some examples.

I hear some people say "I can't use Dart until all browsers incorporate the VM", which is the wrong signal to wait for. Dart is a general purpose programming language with a compiler to JavaScript. You can use it today if you enjoy it and it makes your life better as a developer. :)

[Richard Eng]

Not everyone uses Chrome in their Android device. There are, in fact, quite a few different browsers to choose from, and none of them are perfect (hence, the selection).

We can't count on Chrome getting 80+% of the market. IE and Firefox are not going away anytime soon, and it is not possible to ignore these users. And absolutely we cannot ignore Apple users.

Also, AFAIK, transpiled Dart apps only run in the latest browser versions. Again, we cannot ignore the minority of users on older versions.

The reality is, a Chrome-only future is a pipe dream. Realistically, any web developer must support nearly all users on the planet.

[Richard Eng]

It depends on your definition of "success". If you want to restrict the definition to, "success is providing a useful platform for a dedicated minority of developers", then sure it's a success.

But unless Dart is used by a large percentage of the world's developers, unless there are thousands of well-known Dart apps available to the general public, no one I know would consider it a success.