Node.js as a target for dart2js or DDC: effort required?

209 views
Skip to first unread message

DoHyung Kim

unread,
Nov 23, 2016, 5:00:34 AM11/23/16
to Dart Misc
Dear all,

Recently my team has been writing a simple CI system in Dart currently for running on Google Cloud Platform. We had hard time due to lack of readily available libraries including official support for Google Cloud Platform and simple things like ssh client. Different from front-end and typical web back-end, it was really painful to do such things in Dart. So after having hit an internal milestone recently, we are in the course of discussing on whether we should keep Dart.

So as an alternative we can choose, I'd like to evaluate possibility of making dart2js or DDC available on Node.js ourselves. Until Dart has an ecosystem comparable to Node.js', I think it's practical and beneficial to leverage that of Node.js where appropriate.

Could someone in the Dart team give me some hints on how much work it would be? I know there have been some effort from outside of the Dart team to run dart2js output on Node.js and to implement dart:io on Node.js APIs. Though such outcome can be leveraged, I think it's better to have it incorporated into the Dart SDK in the end.

Any hint will be appreciated.

Best regards,
DH

Florian Loitsch

unread,
Nov 23, 2016, 5:47:13 AM11/23/16
to mi...@dartlang.org, Natalie Weizenbaum
I believe Natalie did some work on this, to make sass run on node.js.

--
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.

DoHyung Kim

unread,
Nov 23, 2016, 6:07:23 AM11/23/16
to Dart Misc, nw...@google.com
Thanks, Florian.

I had a quick look at it. And it's using node_preamble for running it on Node.js and configuration-specific imports for doing I/O both on Dart VM and Node.js.

In the case of Sass, I think it's a viable choice, but I'd like to stick with standard dart:io. Maybe adding the preamble and creating patches for dart:io using Node.js API will do?

BR, DH


2016년 11월 23일 수요일 오후 7시 47분 13초 UTC+9, Florian Loitsch 님의 말:

Vyacheslav Egorov

unread,
Nov 23, 2016, 7:44:45 AM11/23/16
to Dart Misc, nw...@google.com
Until Dart has an ecosystem comparable to Node.js', I think it's practical and beneficial to leverage that of Node.js where appropriate.

That is certainly a valid approach from the practical standpoint. 

However here is a thing to think about.

When node.js was just released it had no ecosystem. 

Ecosystem grew because people started writing tons and tons of libraries ignoring the fact that similar libraries already exist for languages like Ruby, Python, etc.

If those people would instead start compiling JavaScript to Ruby then there would be no such thing as node.js ecosystem.

In other words - ecosystem will only grow if there are people willing to invest their faith and time into growing it. 
--
// Vyacheslav Egorov

DoHyung Kim

unread,
Nov 23, 2016, 9:06:09 AM11/23/16
to Dart Misc, nw...@google.com
I fully understand your point. But at least, the initial momentum on Dart has been lost somewhat (regardless of Dart's future), and I can't write everything missing myself from the scratch.

For instance, the major public cloud providers including Google provide SDK for their selection of languages. And it's non-trivial to write and maintain non-official SDKs for them.

My point here is I want to stay in the Dart ecosystem as close as possible while leveraging Node.js (hopefully tentatively). Don't get me wrong. My colleagues are already contributing small packages to the Dart ecosystem, and I want to keep doing so by not deviating too much from the standard Dart.


DH

2016년 11월 23일 수요일 오후 9시 44분 45초 UTC+9, Vyacheslav Egorov 님의 말:

Natalie Weizenbaum

unread,
Nov 23, 2016, 3:46:41 PM11/23/16
to DoHyung Kim, Dart Misc
There isn't currently a Node implementation of dart:io, mostly because no one's decided to sat down and put in the effort to create one. Making one is tricky because we don't have a great test suite for dart:io, so making it robust would probably involve writing a lot of tests, too. But if you're interested, I certainly encourage you to create one!

Once nice thing is that such a package could be written externally and incrementally. You wouldn't even need to use configuration-specific imports in the package itself; if you match (a subset of) the dart:io API, you can just rely on downstream users to do a configured import if it fits their needs.

Filip Hracek

unread,
Nov 23, 2016, 4:21:12 PM11/23/16
to mi...@dartlang.org, DoHyung Kim
I'm not sure this is entirely relevant, but there's node_io, which is used at DGLogic. Kenneth is probably on this list.

William Hesse

unread,
Nov 23, 2016, 4:30:54 PM11/23/16
to General Dart Discussion, DoHyung Kim
Isn't https://github.com/dart-lang/googleapis , with documentation at
https://www.dartdocs.org/documentation/googleapis/0.32.0/ ,
a supported, complete Dart package supporting all Google cloud APIs?

On Wed, Nov 23, 2016 at 10:20 PM, 'Filip Hracek' via Dart Misc
William Hesse

DoHyung Kim

unread,
Nov 23, 2016, 6:43:24 PM11/23/16
to Dart Misc, dyn...@gmail.com
As Flilip pointed out, node_io is an existing attempt to provide an API compatible implementation of dart:io using node.js APIs, but resides in libraries with different names.

What I'm not satisfied with it is that there is no way to use existing pub packages that are not written with node_io in mind. If I understand correctly, what you suggest has the same limitation.

Please correct me if I'm wrong.

Thanks.

DH

2016년 11월 24일 목요일 오전 5시 46분 41초 UTC+9, Natalie Weizenbaum 님의 말:

DoHyung Kim

unread,
Nov 23, 2016, 6:55:27 PM11/23/16
to Dart Misc, dyn...@gmail.com
It's an autogenerated APIs. My team encountered many edge cases where it doesn't handle properly. This is same for other cloud providers than Google. For instance, Azure has a swagger spec for all of its APIs but with MS specific extensions. MS has their own API generator that understands those extensions. If one generates an API implementation with a plain swagger generator, it lacks much of features available to API implementations generated with MS' generator.

If you are interested, I'll invite one of my colleagues to describe what he encountered. We observed a weird behavior, and then had to consult the source code of an officially supported SDK to find out what's different.

DH

2016년 11월 24일 목요일 오전 6시 30분 54초 UTC+9, William Hesse 님의 말:

DoHyung Kim

unread,
Nov 23, 2016, 8:00:08 PM11/23/16
to Dart Misc, dyn...@gmail.com
To be clear, I'm not saying googleapis package is useless. And maybe I should have said "a few" in place of "many" when I said my team encountered edge cases. :)

2016년 11월 24일 목요일 오전 8시 55분 27초 UTC+9, DoHyung Kim 님의 말:

DoHyung Kim

unread,
Nov 23, 2016, 8:11:50 PM11/23/16
to Dart Misc, dyn...@gmail.com
Another point I missed in Natalie's comment below is that multiple dart:io implementations would become to exist if a node.js implementation of dart:io is ever created. Going one to two may be a huge undertaking, since it requires enough test cases to ensure compatibility.

From my understanding, that means it's difficult to add it to the official SDK in the near future, even if someone ever contributes it. 


2016년 11월 24일 목요일 오전 5시 46분 41초 UTC+9, Natalie Weizenbaum 님의 말:
There isn't currently a Node implementation of dart:io, mostly because no one's decided to sat down and put in the effort to create one. Making one is tricky because we don't have a great test suite for dart:io, so making it robust would probably involve writing a lot of tests, too. But if you're interested, I certainly encourage you to create one!

Natalie Weizenbaum

unread,
Nov 23, 2016, 8:39:18 PM11/23/16
to General Dart Discussion, DoHyung Kim
Dart and its ecosystem aren't generally designed to make it easy to use a package in a way that it wasn't intended to be used by its authors. Our philosophy is that GitHub makes it easy to make upstream packages more flexible as-necessary, so building in enforced flexibility is often more painful and a higher maintenance burden than you get benefit.
Reply all
Reply to author
Forward
0 new messages