[dart-announce] Announcing Dart 2: Optimized for Client-Side Development

['Anders Sandholm' via Dart Announcements]

Today, we’re announcing Dart 2, a reboot of the language to embrace our vision of Dart: as a language uniquely optimized for client-side development for web and mobile.

See our Medium post for the full announcement.

--

Anders Sandholm, Product Manager, Dart

--
For more news and information, visit https://plus.google.com/+dartlang
 
To join the conversation, visit https://groups.google.com/a/dartlang.org/

[Jonathan Rezende]

\o/

Atenciosamente, 

Jonathan Rezende

--
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
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Michael Francis]

YA!!!!!!!!!!!!!!!!!!!!!!

--

Michael Francis

solariumvr.com

[kur...@gmail.com]

I was out of loop for a while so excuse me if this is a repeat. For context, do you have a roadmap for Dart on server side/standalone VM? Sounds like the vision is to focus on client-side development then how much effort, if any, will be invested in standalone VM?

Thanks,

Kurman

---
You received this message because you are subscribed to the Google Groups "Dart Announcements" group.
To unsubscribe from this group and stop receiving emails from it, send an email to announce+u...@dartlang.org.

[Michael Francis]

"Dart on server side/standalone VM" What exactly is everyone looking for with this. Dart on the server works perfectly fine and improvements to the language and VM for Client side development will only improve the performance and developer story on the server.

I think what most people are looking for is a database connection library or large framework. There's no reason this needs to come from the core Dart team. These tools aren't made by the core teams of other languages so why should Dart be any different? Example, the node.js team doesn't create the Sequelize library. One could argue that Dart comes with more out of the box features for server side development than most other languages.

--

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

---

You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--

Michael Francis

solariumvr.com

[kur...@gmail.com]

Just to clarify, I was asking about the roadmap and vision (forward looking vs status quo).

-K

[Sean McCleary]

I was also surprised that the Dart 2 announcement didn't even mention the server. I know it focuses on differences introduced in Dart 2, but the announcement will get a lot of interest and someone reading it and coming to the language for the first time would walk away from that not even knowing that server side Dart is a thing. But oh well. It's announcing the changes in Dart 2, not Dart in general, I guess.

I think it makes people with an interest in server-side Dart nervous to keep hearing it described as a client-side language at DartCon, and now this announcement.

Congrats to all on Dart 2.0. I love the language, the tooling, the libraries. I'm going to run right out upgrade.

[Frank Rollpin]

Congrats on the release, fantastic work!

As well as few posters before me, I am surprised that the server-side story is not mentioned, as this is truly a killer feature for building complex applications. Of course there is some room for improvement (db interfaces similar to JDBC or ADO.NET, etc), but it is extremely valuable even the way it is now. Personally, I would not have even given Dart a chance 5 years ago if not for the server story that offers code reuse, sane language and high-performance VM.

[Kevin Moore]

We're super excited about folking using Dart on the server. We think it's critical to have a focus – and for now it's client development.

There are many community members pushing Dart server support – we're even using it on the Dart Package site.

If you'd like to chat w/ more folks using Dart on the server, I recommend spending time at https://gitter.im/dart-lang/server

[Sean McCleary]

I think everyone understands that the focus is client-side, and isn't expressing any concern about that at all.  Just that it seems like a lot of material lately has described Dart in ways which give the impression that it is a client-side-only language.  Given that, along with Google's reputation for dropping products early and often, it's understandable that someone with an interest in server-side Dart may have gotten jumpy.  It's nice of the Dart team to chime in and assuage those fears.  So I think everyone here, or on Gitter, or somewhere with contact to the Dart team, understands that the value of server-side dart still exists.  

I'd suggest thinking, in promotional material, whether or not it might give the misleading impression that Dart is a client-side-only language.  It sounds like people are chiming in and saying that, lately at least, it does.  And like Frank expressed, if it hadn't been clear to me a couple years ago that dart was a client+server language, I personally wouldn't have given it a second look, because code re-use between the client and server is a massive value proposition.  To think that there are people out with needs like mine and Frank's there who might not realize how awesome Dart is because only the client-side is even _mentioned_ makes me sad. 

Again, great work Dart folks.  Still loving it.

[Andrew Skalkin]

> I think what most people are looking for is a database connection library or large framework. There's no reason this needs to come from the core Dart team. 

Let me disagree with that. The core classes and interfaces have to come from the core Dart team, otherwise there will be no standard, every single library will use its own API (or there will be competing sets of API), and there will be no ability to polymorphycally use implementations. Both Java and .NET understood it, both came up with a standard set of classes that can be extended by the db drivers, and the ecosystems flourished. Developer love it since you just learn JDBC/ADO.NET once, and use the same API against different databases. DB vendors love it because it's a well-defined set of classes and interfaces that they need to develop their drivers against.

It's really a win-win-win for everyone involved, but the first step needs to be taken by the Dart team.

[Matan Lurey]

On Sat, Feb 24, 2018 at 1:57 PM Andrew Skalkin <ska...@gmail.com> wrote:

> I think what most people are looking for is a database connection library or large framework. There's no reason this needs to come from the core Dart team. 

Let me disagree with that. The core classes and interfaces have to come from the core Dart team, otherwise there will be no standard, every single library will use its own API (or there will be competing sets of API), and there will be no ability to polymorphycally use implementations.

Is that true?

The "node" team never shipped database APIs, yet nodejs is one of the most popular platforms for creating server-side applications.

I'd rather see the Dart community that uses server-side Dart (we, the Dart team, do not use it much outside of internal tooling) decide what the best practices, interfaces, and drivers should do, rather than try and figure it out given that we don't use this platform ourselves.

 

Both Java and .NET understood it, both came up with a standard set of classes that can be extended by the db drivers, and the ecosystems flourished. Developer love it since you just learn JDBC/ADO.NET once, and use the same API against different databases. DB vendors love it because it's a well-defined set of classes and interfaces that they need to develop their drivers against.

It's really a win-win-win for everyone involved, but the first step needs to be taken by the Dart team.

Full stop I can say this is extremely unlikely anytime soon. But I'd love to see more of the community work together on this project, and I suspect many on the Dart team would love to support (code reviews, answer questions, help with testing, etc).

[Andrew Skalkin]

On Saturday, February 24, 2018 at 5:28:42 PM UTC-5, Matan Lurey wrote:

On Sat, Feb 24, 2018 at 1:57 PM Andrew Skalkin <ska...@gmail.com> wrote:

> I think what most people are looking for is a database connection library or large framework. There's no reason this needs to come from the core Dart team. 

Let me disagree with that. The core classes and interfaces have to come from the core Dart team, otherwise there will be no standard, every single library will use its own API (or there will be competing sets of API), and there will be no ability to polymorphycally use implementations.

Is that true?

The "node" team never shipped database APIs, yet nodejs is one of the most popular platforms for creating server-side applications.

Honestly, after having used JDBC and ADO.NET (especially C#'s LINQ) what Node offers is a complete disaster. Yes it got popular due to millions of JS developers, but you can do a lot better with Dart!

[tatumizer-v0.2]

IMO, the only realistic way for dart to obtain reliable DB drivers is to write java2dart compiler.

See also this thread: https://groups.google.com/a/dartlang.org/forum/#!topic/misc/YfDzBjaP5Xw

Lots of open source JDBC drivers are available, equipped with test suites.

And this issue goes much further than JDBC.

BTW, user-facing API can be made completely different from JDBC (via dart wrappers), so no API copyright issue here IMO.

[Sean McCleary]

On Saturday, February 24, 2018 at 11:28:42 PM UTC+1, Matan Lurey wrote:

The "node" team never shipped database APIs, yet nodejs is one of the most popular platforms for creating server-side applications.

Yeah I'd be hesitant to look to node and JavaScript in general as an example of how to do it right.  I suspect a lot of people come to dart to escape the chaotic JavaScript ecosphere.  It's true of me.  I'd rather have the big-brotherly guiding hand of Java or .NET than the ever-changing JavaScript framework-of-the-week.  One of the things I love about Dart is the massive, useful library and officially-sanctioned packages it has.  It's why I prefer it over TypeScript.  I'd like to see even more of an iron fist from Dart's competent creators.    

I'd rather see the Dart community that uses server-side Dart (we, the Dart team, do not use it much outside of internal tooling) decide what the best practices, interfaces, and drivers should do, rather than try and figure it out given that we don't use this platform ourselves.

That'd be cool too.  Kind of like PHP's PSR efforts for framework interoperability.  It's community-driven, and has tamed a lot of the babel. 

Sean  

[Bob Nystrom]

On Sat, Feb 24, 2018 at 2:28 PM, Matan Lurey <ma...@lurey.org> wrote:

On Sat, Feb 24, 2018 at 1:57 PM Andrew Skalkin <ska...@gmail.com> wrote:

> I think what most people are looking for is a database connection library or large framework. There's no reason this needs to come from the core Dart team. 

Let me disagree with that. The core classes and interfaces have to come from the core Dart team, otherwise there will be no standard, every single library will use its own API (or there will be competing sets of API), and there will be no ability to polymorphycally use implementations.

Is that true?

The "node" team never shipped database APIs, yet nodejs is one of the most popular platforms for creating server-side applications.

The key difference is that JS is untyped, so you can have polymorphic APIs — i.e. two unrelated DB packages that implement the same interface — without needing those packages to agree on a single third package / core library that defines that DB interface. As long as they expose the same methods, it works.

With a nominally typed language, those two packages need to declare they implement the same API and that API needs to be defined somewhere. Defining it in the core libraries is a great way to encourage strong consensus towards that being the canonical type all DB implementations support, but it's not the only to get that consensus. Strong communities, good communication, and great API design can also get a third party API to become canonical. See, for example, the Rack protocol in Ruby-land.

There are downsides to being in the core libraries too — core APIs are really hard to evolve. So, often you can get stuck with an API that is the best way we knew to solve some problem twenty years ago. As they say in Python, "core is where libraries go to die".

Cheers!

– bob