z****e
发帖数: 54598 | 1 http://www.centurylinklabs.com/could-server-side-dart-replace-n
Could Server-Side Dart Replace Node.js?
Dart is a Google-produced programming language that has slowly been gaining
traction, particularly since its 1.0 release last year. While Dart has thus
far been seen as a promising alternative to JavaScript in the browser, I’d
like to argue that like Node.js, the true promise of Dart is actually on the
server side.
I too am skeptical of Dart as a client-side language, but if you cross over
to the server, Google is cooking up something extremely promising and ready
to carve out a large niche for itself, attracting not just Node.js
developers but even developers from the Java community and beyond.
DART ON THE CLIENT: A TOTAL NON-STARTER?
Since the earliest days of Dart in 2011, the language has provoked a great
deal of skepticism from all sides, primarily because Google has advertised
it as a successor to JavaScript on the client side—not just another compile
-to-JavaScript option, mind you, but rather a new, full-fledged in-browser
runtime suited for a bold new generation of thick client applications.
Sounds good, eh? Well, yes, but the skepticism towards Dart is well founded:
While the in-browser Dart VM is currently bundled with Chromium, Google has
provided only very vague promises that the Dart VM will someday be included
in Chrome as well. This makes Dart a hard sell.
One of the primary design considerations behind Dart has been to provide a
rock solid compile-to-JavaScript story so that Dart can be used now, on any
browser, even though none of the major browsers ship with a Dart VM. This is
admirable and a necessary move by Google, but the problem is that the
compiled JavaScript can be quite bulky. Even for basic apps, you’re usually
looking at over 100k, even when minified. This is a deal breaker for many,
and rightfully so.
While the Dart VM might end up being superior to V8 and other engines, it’s
not like there’s a dearth of options for client-side developers. The past
few years have seen an absolute explosion in client-side JavaScript
technologies, too many to even begin to mention. And so if Dart is going to
have traction on the client, it will have to be unquestionably, demonstrably
superior to JavaScript. I have my doubts.
Nonetheless, there are some encouraging signs for client-side Dart. Markus
Persson, aka Notch, the creator of Minecraft, has thrown his weight behind
Dart and has even begun building games in it, and projects like AngularDart
seem to be catching on. So the skeptics might be in for a surprise down the
road.
DART ON THE SERVER: LOOK OUT, NODE.JS AND JAVA
As I argued above, the skeptics are right to wonder how much of a foothold
Dart can gain. But let’s set aside the client-side Dart issue for a minute
and take a look at sever-side Dart. That’s when we start to see a much
different and more immediately promising picture.
Node.js without the JavaScript baggage — I like Node.js because of the
principles on which it was built: run things asynchronously whenever
possible, use data streams whenever you can get away with it, and tie it all
together with futures and callbacks. The problem with Node.js is that it’s
JavaScript. There’s no distinction between types of numbers, working with
arrays is always janky, NaN-infused wat moments abound, and so on.
But Dart gives you everything that’s great about Node.js without the
baggage of JavaScript clinging to the project like a nagging, alcoholic in-
law. Dart has an incredibly robust stream API and top-notch futures support
baked into the core dart:async library, plus a bunch of other stuff that you
get for free, like WebSockets, SSL support, a decent math library (complete
with ints, nums, and doubles out of the box), as well as the foundations
for an Erlang-flavored actor system in the dart:isolate library.
Basically, server-side Dart is trying to solve the same problems that Node.
js was built to solve, i.e. problems around asynchronous, non-blocking I/O,
but is doing so on a better VM and with a more robust and less flaky
language. Another bit of good news is that Dart in practice is highly
reminiscent of JavaScript, from the basic syntax to callback functions as
first-class citizens, which means that the bridge from Node.js to Dart isn’
t a terribly precarious one.
The power of Java without the verbosity — Hopefully I’ve made it clear why
Node.js devs should consider Dart. But I think that JVM folks should be
paying attention as well, because Dart offers a lot of things that no Java
developer could live without: abstract classes, declarative typing (which is
optional), generics, a real import system, metadata annotations, and
variable types that are directly inspired by Java, including final and
static variables. What this means is that Dart is frankly a better
constructed language than JavaScript in almost every regard and a natural
fit for JVM developers who want to try something that is less verbose but
also targeted at Node.js-style architectures—and who want to do so without
giving up certain coveted aspects of Java.
In terms of performance, Dart is still a ways off from JVM-caliber
performance and probably will be for quite some time. But the core libraries
are still coming together and the performance story could be markedly
different in a year’s time. Dart has already performed exceedingly well on
some benchmarks.
Other good stuff — Even though the language is young, Dart’s package
manager, pub, is simple and yet powerful, with clear debts to npm and its
package.json-based system. If you’re looking for IDE support, the makers of
Dart provide their own IDE, the Dart Editor, which isn’t too shabby at all
on its own. I would recommend, however, having a look at WebStorm‘s
support for Dart, which is currently very strong. And when it comes to
publishing and documenting code, pub.dartlang.orp is a great resource,
inspired by Rubygems and related sites, that makes it easy to publish
projects. For example, I’ve been working on a Dart HTTP client for
interacting with REST APIs called Mesh, and interacting with the main Pub
repository has been a breeze.
CONCLUSION
I’m surprised that Dart isn’t yet being taken more seriously as a server-
side option for a wide variety of use cases. The performance isn’t quite up
to JVM standards, but Dart beats scripting languages like Ruby, Python, and
PHP in a variety of areas and is explicitly designed for the same
architectures that Node.js is currently the best fit for. The next time you
sit down to write a web server or a Markdown parser or an algorithm library,
give Dart some real consideration. | t***t
发帖数: 6066 | | z****e
发帖数: 54598 | 3 不写了么
The performance isn’t quite up
to JVM standards, but Dart beats scripting languages like Ruby, Python, and
PHP in a variety of areas and is explicitly designed for the same
architectures that Node.js is currently the best fit for.
【在 t***t 的大作中提到】
: 啊？server有抓哇，为毛用大忑呢？
| g*******o
发帖数: 156 | 4 都有node.js和coffeescript了，为什么还要server-side dart？
node.js也有了generator和yield, callback hell极大缓解了～～不清楚dart io怎么
干得过node.js
and
【在 z****e 的大作中提到】
: 不写了么
: The performance isn’t quite up
: to JVM standards, but Dart beats scripting languages like Ruby, Python, and
: PHP in a variety of areas and is explicitly designed for the same
: architectures that Node.js is currently the best fit for.
| z****e
发帖数: 54598 | 5 因为node.js的作者水平不行
v8的作者就是dart的作者
dart编译成js比你手写的js要快
而且dartvm直接干掉v8的效率
http://www.dartlang.org/performance/
coffeescript只能编译成js去跑
作者并没有任何效率优化的经验
所以upper bound不会超过js的upper bound
应该这样问，有了v8和dart，为什么还需要node.js？
一个慢腾腾的玩意，睾丸还被捏在别人手里
dart的本意就是希望googler对于js效率不满意时候的另外一个选择
coffee只是js上的一个套子而已，并不能从本质上优化引擎的效率
而dart可以，lars bak搞优化出身的，水平可不是盖的
【在 g*******o 的大作中提到】
: 都有node.js和coffeescript了，为什么还要server-side dart？
: node.js也有了generator和yield, callback hell极大缓解了～～不清楚dart io怎么
: 干得过node.js
:
: and
| z****e
发帖数: 54598 | | z****e
发帖数: 54598 | 7 node.js本质上说是一个抄袭了python和ruby的
event machine还有twisted这些framework的idea
然后套在v8这个engine上，然后就拿出去忽悠了
从点子到技术核心，没有一个是它自己的东西 | g*****g
发帖数: 34805 | 8 Performance isn't critical in web frontend. At least for 99% of applications
, coz bottleneck is always on backend.
Productivity is the difference maker. Now remember js has to be in web UI
coz no other scripting language is supported in all browsers. And the people
dealing with js happen to be UI engineers. What's not to like by
programming everything in one language? | z****e
发帖数: 54598 | 9 dart可以直接编译成js跑在browser上啊
去年9月就已经有不少网站在用了
http://divingintodart.blogspot.com.au/2013/09/top-5-live-websit
js语言设计得比较糟糕，讨厌的大有人在
要不然也不会有coffee啥市场
而且现在browser市场正在逐步下来，app逐步取代之
你看swift多火
还有一点，dart本身就是js和java之间的过渡语言，可以写得象js
也可以写得象java，当一个语言让所有程序员都感到熟悉的时候
成功就不太远了，dart和swift都给我以这种感觉
再来看看其他人怎么说
tertulian • 2 months ago
Dartlang on client side is the best web dev experience you can get today on
every major platform (Win,OSX, Linux). I can't imagine going back to JS
after using Dartlang editor with debugging and intellisense.
TS is not bad too, but:
a) it's just JS on steroids
b) IDE's only for windows //这个已经not true了，editor有mac版了
bipin peterwilli • 24 days ago
Dart is progressing a lot faster, I would have said 3 years in 2013, when
they were working on 1.0, but not now. Sure Node has JS and npm to its aide,
but Dart has familiar Java syntax. It already has package manager 'pub'.
What's more, the features that JS will have/has in EcmaScript 6 are already
there in Dart promises,sets,etc. Dart feels concise and evolved, node on
other hand is pre v1.0, slowly updating its core. Node has been a success
but dart will be ready for prime-time soon.
applications
people
【在 g*****g 的大作中提到】
: Performance isn't critical in web frontend. At least for 99% of applications
: , coz bottleneck is always on backend.
: Productivity is the difference maker. Now remember js has to be in web UI
: coz no other scripting language is supported in all browsers. And the people
: dealing with js happen to be UI engineers. What's not to like by
: programming everything in one language?
| z****e
发帖数: 54598 | 10 你看这个，你们已经开始用了
http://github.com/Netflix/security_monkey
applications
people
【在 g*****g 的大作中提到】
: Performance isn't critical in web frontend. At least for 99% of applications
: , coz bottleneck is always on backend.
: Productivity is the difference maker. Now remember js has to be in web UI
: coz no other scripting language is supported in all browsers. And the people
: dealing with js happen to be UI engineers. What's not to like by
: programming everything in one language?
| z****e
发帖数: 54598 | 11 顺便说一下
angulardart也弄出来了
http://angulardart.org/
都是一个娘生的，这种支持肯定很快
十月份要在巴黎搞推广 | g*****g
发帖数: 34805 | 12 For an internal app like security monkey, Dart is fine, just like GWT. You
don't really care that much about appearance and you don't expect much
beyond basic controls. That is not the case for customer facing app.
【在 z****e 的大作中提到】
: 你看这个，你们已经开始用了
: http://github.com/Netflix/security_monkey
:
: applications
: people
| z****e
发帖数: 54598 | 13 js怎么写都那样，如果复杂的app，我直接上java/swift这些平台原生态语言了
各种支持也多，所有的脚本本质上都是一个甚至几个framework
framework用多了，performance很容易下来，客户体验就不好了
简单的东西我就上dart了，天然的mvc，editor也强大，dartium做测试也快
你说要回去用sublime甚至vim写代码，用chrome做测试
我的天，那我真不想那样搞，太苦逼了，不要，把自己累死了
js就是一邪教，我可没啥兴趣去搞那玩意，我今晚做了下dart，感觉很高效
结构清晰，代码可读性强，执行效率高，文档也完整，没有理由放着这么好的东西不用
非要去写啥坑爹的js脚本，没事自己不跟自己过不去，不要了
dart就是另外一种coffee，如果你这么理解的话，你就不会觉得这个东西有啥问题了
【在 g*****g 的大作中提到】
: For an internal app like security monkey, Dart is fine, just like GWT. You
: don't really care that much about appearance and you don't expect much
: beyond basic controls. That is not the case for customer facing app.
|
|
