Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Hello World" in Dart, compiled to JavaScript

gist.github.com

Post reply on HN
Print view View original

81–90 of 162 posts

Re: "Hello World" in Dart, compiled to JavaScript

#81

Post by kelnos »

geoffhill wrote: post #10
swannodette wrote: post #9

I'll repeat what I said in the GitHub thread: There's this interesting tool called Google Closure Compiler. It does dead code elimination. https://gist.github.com/1277285 Notice that this source is now 2000 lines of pretty printed JS. Given that anything interesting these days uses jQuery or Underscore.js clientside, and similar things serverside, this amount of JS for even Hello World is standard fare. EDIT: To be c…

I'm sorry, but 2,300 lines of code is in no way acceptable as a "dead code"-eliminated Hello World program. Not by a longshot.

  $ cat hello.c 
  int main() { printf("Hello, world!\n"); }
  $ gcc hello.c
  $ ls -l a.out 
  -rwxr-xr-x  1 brian  staff   8.5K Oct 11 02:23 a.out*
And that's compiled code! And it also links to libc! But then again, any JS program requires tons of compiled C/C++ code to run.

Re: "Hello World" in Dart, compiled to JavaScript

#82

Post by sambeau »

wlievens wrote: post #71
rayiner wrote: post #49

Earlier quoted context omitted.

CoffeeScript is meant to be synaptic sugar on top of JS. Dart is a language with different semantics that happens to compile to JS. As such it includes a lot of runtime code. More appropriate examples would be Emscripten, Parenscript, or ClojureScript.

> synaptic sugar Is this a typo, tongue-in-cheek, or a technical term I don't know? I've only heard of "syntactic sugar" myself.

Dopamine is synaptic sugar.

Re: "Hello World" in Dart, compiled to JavaScript

#83

Post by rue »

tolmasky wrote: post #19
geoffhill wrote: post #10

Earlier quoted context omitted.

I'm sorry, but 2,300 lines of code is in no way acceptable as a "dead code"-eliminated Hello World program. Not by a longshot.

If all you use javascript for is console.log("Hello World"); then v8 will seem unnecessarily large too. If all you do is one DOM transformation then jquery will seem huge compared to just doing it by hand (probably hundreds or thousands of lines of code vs 3). I guess at this point I'm just repeating the OP, but this is simply in no way demonstrative of Dart. It can at best serve as a learning tool of the internals (…

v8 actually runs the code, though, so it's not an accurate comparison.

(That said, this thread is just silly. I don't like Dart because it looks like it's built for obsolescense, but the hello world extrapolation is nonsense, as has been pointed out.)

Re: "Hello World" in Dart, compiled to JavaScript

#84

Post by bad_user »

devin wrote: post #72
cdata wrote: post #65

Earlier quoted context omitted.

"...given that they should be grasping for any chance to leave the warty and dated pile of compromises that is Javascript behind..." I would not characterize the JavaScript community as desperate graspers, but even so, I don't see the virtue in grasping for the chance to replace a dated pile of compromises with a contemporary pile of compromises. All the hate is totally overblown - this project is young and will like…

Not desperate graspers? Try and count the number of libraries and frameworks that have come out in the last 5 years for JavaScript. Think of how many "to JS" solutions there are. Seriously, google that. Like 20? 25? How much "to C" solutions do you see getting on the front page of Hacker News these days? It's staggering how much 'grasping' has been happening compared to other ecosystems. It's ironic that people would…

    The only reason it's fashionable to do so is 
    because it's Google. If this was some independent
    developer everyone would be falling over themselves 
    to dig in.
Except that there's nothing released to "dig in" and if this came from an independent developer I would barely open the link.

Re: "Hello World" in Dart, compiled to JavaScript

#85

Post by dextorious »

cdata wrote: post #77
devin wrote: post #72

Earlier quoted context omitted.

Not desperate graspers? Try and count the number of libraries and frameworks that have come out in the last 5 years for JavaScript. Think of how many "to JS" solutions there are. Seriously, google that. Like 20? 25? How much "to C" solutions do you see getting on the front page of Hacker News these days? It's staggering how much 'grasping' has been happening compared to other ecosystems. It's ironic that people would…

I'll take the alleged mob mentality over Google elitism any day of the week. Google can try to move the web any direction it feels is appropriate - it's Google's time, it's Google's money - but let's be clear: JavaScript is not as deficient as you might think it is, and the JavaScript community is not dumb to expect more than what Dart has offered so far (in an admittedly short span of time). "There are just two kind…

"Probably over-quoted these days, but I think we all know where JavaScript falls."

Well, if the distinction is between the ones nobody uses and the one "everybody complains about", then we also know where Dart falls...

Re: "Hello World" in Dart, compiled to JavaScript

#86

Post by dextorious »

geoffhill wrote: post #10
swannodette wrote: post #9

I'll repeat what I said in the GitHub thread: There's this interesting tool called Google Closure Compiler. It does dead code elimination. https://gist.github.com/1277285 Notice that this source is now 2000 lines of pretty printed JS. Given that anything interesting these days uses jQuery or Underscore.js clientside, and similar things serverside, this amount of JS for even Hello World is standard fare. EDIT: To be c…

I'm sorry, but 2,300 lines of code is in no way acceptable as a "dead code"-eliminated Hello World program. Not by a longshot.

Do you even understand programming? It includes the runtime, dammnit.

A C hello world (#include "stdio.h", int main(void){printf("Hello World\n"); return 0; }) produces an 8K executable on my Mac.

8K --you know, they used to write whole games in 8K.

Re: "Hello World" in Dart, compiled to JavaScript

#87

Post by bad_user »

tolmasky wrote: post #19
geoffhill wrote: post #10

Earlier quoted context omitted.

I'm sorry, but 2,300 lines of code is in no way acceptable as a "dead code"-eliminated Hello World program. Not by a longshot.

If all you use javascript for is console.log("Hello World"); then v8 will seem unnecessarily large too. If all you do is one DOM transformation then jquery will seem huge compared to just doing it by hand (probably hundreds or thousands of lines of code vs 3). I guess at this point I'm just repeating the OP, but this is simply in no way demonstrative of Dart. It can at best serve as a learning tool of the internals (…

jQuery is huge compared to doing it by hand, and I actually chose against jQuery for a web service targeted at mobile phones.

However, in the case of jQuery the productivity / KB ratio is freakishly huge.

I fail to see how that will be the case for a new programming language. Javascript is already fast and still improving in bounds and leaps. It is also finally possible to write correct cross-browser code with the help of jQuery and CoffeeScript. It is a true standard.

What can Dart really provide that Javascript cannot?

Refactoring tools? Some people would like that, but it still won't be bullet proof (as I understand the static types in Dart are optional), and there's nothing worse that a tool on which you can't rely on (personally I hate the Intellisense attempts being made in IDEs for Ruby or Python).

What about speed? Well, Java/Quake2 was compiled to Javascript using GWT and it worked just fine -- what more could you want from a sandboxed environment? To me, these days big page load times either on my desktop or on my mobile are almost always related to bandwidth.

Re: "Hello World" in Dart, compiled to JavaScript

#88

Post by georgemcbay »

msy wrote: post #76
devin wrote: post #73

Earlier quoted context omitted.

There was an internal memo. They're going to push it. Why do you have to "buck the man" in order to feel like you're in control of your tools? Why does it need to be repeated that everyone has a choice? If Dart grows and solves some of the junk I have to deal with in the JS ecosystem, I will use it. We'd all be fools not to.

Wouldn't happen to be a Flash dev would you? I do not want the core technologies on which the web is built owned or controlled by any one company. No matter how you look at it Dart is not a standard, it's not controlled or directed by any open body and its development is not public. It took a goddamn decade to break Microsoft's endless attempts to own core web technology, if you're happy with another company doing it…

"Dart is not a standard, it's not controlled or directed by any open body"

You say that like it is a bad thing. I don't think it is.

Standardizing technologies is great once they are mature and are already accepted as the obvious de-facto standard, but trying to push real change through standards bodies results in exactly the sort of morass that JavaScript has been stuck in and which makes Dart a refreshing attempt at change.

Yeah, yeah, the great new version of JavaScript will be here next year, same as it has been going to be here next year for the past 10 years.

When it comes to making real progress you almost always need to buck the standards and drag the world kicking and screaming into a better future and then let the standards bodies figure out how to fit things in to their world later on. I'm continually shocked there are so many people in this industry that don't see this even though the proof for it is everywhere.

I'm not sure Dart really is the better future we need in a client-side language as there is still a ton more work to be done (the technology is far less baked than I expected it would be, even though it is only a preview release), but I applaud Google for trying and I'd suggest other players trying to sabotage their efforts should redirect their own efforts into something even better than Dart. Win on the merits of the technology, not on slavish devotion to existing standards. With increased competition everybody wins, especially if everyone uses an OSS model as permissive as Google is with Dart, and maintains JavaScript as a legacy lingua franca.

Re: "Hello World" in Dart, compiled to JavaScript

#89

Post by DasFuxx »

drgath wrote: post #22

Funny. But to be fair, a Hello World in C compiles to a 27k binary. Yeah yeah, optimize this, leave out that and you can get it smaller. Still doesn't change the fact that Hello World is not the target use-case for either C or Dart. Dart is intended for very large applications (compared to JS), so the additional weight for includes isn't that big of a deal. It also doesn't change the fact that Dart sucks. For other r…

Cause you doing it wrong. As i already mentioned in the gist comments, putting the c library static into the application is like putting the browser into js.

Without a lot of optimizing iam around 5k binary and 200 lines of assembler (without linker and other header overhead)

Re: "Hello World" in Dart, compiled to JavaScript

#90

Post by akrymski »

sjs wrote: post #25

As me1000 (Randy Luecke) says Dart is not meant for hello world. If you run this through closure-compiler it's reduced to 2000 lines which is nothing next to Underscore, jQuery, Dojo, etc. We all know the benefits of offloading code to a well known and well tested library or framework, especially if you're writing an app that is thousands of lines anyway. How is this contentious at the end of 2011 unless you're just…

In general I do agree with you, but there's also some truth to the argument that statically linking only the required dependencies is better than embedding a VM. In a way, this is the difference between CoffeeScript and Dart for client side programming. Sure when your app is really large you'll probably end up with the same thing, but for smaller apps "compiling" should mean "including only the necessary stuff" which CoffeeScript successfully does.

I do have an issue with this trend of building VMs on top of VMs, abstracting further and further away to the point where we're using 1000 times more CPU cycles than in the 80s to run the same Pacman in the web browser. I'm for translation rather than virtualization I guess.

Post reply on HN