Closure Compiler in JavaScript • Hacker News Board

Re: Closure Compiler in JavaScript

#81

Post by nevir » Tue, Dec 06, 2016, 10:20 PM UTC

manishsharan wrote: post #14

Can anyone comment on the state of Typescript - Google Closure integration ?

Both Closure and TypeScript support (some of) the JSDoc type annotations and syntax (http://usejsdoc.org/). AFAICT, TypeScript supports a subset of what Closure does - so anything here should be portable between the two:

https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-i...

Re: Closure Compiler in JavaScript

#82

Post by pitaj » Tue, Dec 06, 2016, 10:55 PM UTC

reitzensteinm wrote: post #4

yegortimoshenko wrote: post #3

Earlier quoted context omitted.

It makes a completely self-hosted ClojureScript compiler possible.

It already is, except for the final Closure Compiler pass.

And that is precisely why this makes a completely self-hosted compiler pass possible.

Re: Closure Compiler in JavaScript

#83

Post by austincheney » Tue, Dec 06, 2016, 10:56 PM UTC

Bah. It still requires a build step. I will stick with Pretty Diff and its "correct" option.

Re: Closure Compiler in JavaScript

#84

Post by nothrabannosir » Tue, Dec 06, 2016, 11:00 PM UTC

This is fantastic. I never thought I'd be celebrating yet another "now-in-JS" release, but clojure being Java was a constant pain in the CI gonads. Wonderful to finally be able to include this in generic npm packages without any crazy extraneous build steps.

Re: Closure Compiler in JavaScript

#85

Post by dang » Tue, Dec 06, 2016, 11:16 PM UTC

dr_win wrote: post #7

Old news, article dated Wednesday, August 31, 2016

Interesting stories that haven't had significant attention yet are welcome here.

Re: Closure Compiler in JavaScript

#86

Post by SquareWheel » Tue, Dec 06, 2016, 11:30 PM UTC

dang wrote: post #85

dr_win wrote: post #7

Old news, article dated Wednesday, August 31, 2016

Interesting stories that haven't had significant attention yet are welcome here.

I'd appreciate if titles at least mentioned when this is the case. I thought this was an update to the Closure Compiler they released months ago.

Re: Closure Compiler in JavaScript

#87

Post by grzm » Tue, Dec 06, 2016, 11:38 PM UTC

SquareWheel wrote: post #86

dang wrote: post #85

Earlier quoted context omitted.

Interesting stories that haven't had significant attention yet are welcome here.

I'd appreciate if titles at least mentioned when this is the case. I thought this was an update to the Closure Compiler they released months ago.

Often that is the case. If you see one (such as this), and suggest adding a date (such as 2016-08) in a comment, it's often updated. Even having such a comment, while not visible from the front page, can be useful in and of itself.

Re: Closure Compiler in JavaScript

#88

Post by icebraining » Tue, Dec 06, 2016, 11:51 PM UTC

komali2 wrote: post #57

TazeTSchnitzel wrote: post #47

Earlier quoted context omitted.

There's no intrinsic property of “desktop” languages preventing them targeting “browser” languages. Any Turing-complete language can be compiled to and from any other. And you don't even need to go down to that level of abstraction for Java-to-JavaScript, the two share many commonalities. Java classes can become JavaScript objects, Java methods can become JavaScript functions, Java exceptions can become JavaScript ex…

So I don't know much about Java, but I was under the impression that it compiles to a binary fie (like C), and thus could do things that directly affect the hardware like malloc. How would Javascript handle something like that? I'm not aware of Javascript being able to perform these kinds of tasks. I guess they just have workarounds, like what you're saying for file access?

In this case it doesn't apply, but Emscripten actually compiles LLVM assembly to JavaScript. The way they deal with malloc is by implement it in JS, that is, instead of calling the kernel malloc(), you're just calling a JS function that expands an array of bytes (specifically: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...)

Re: Closure Compiler in JavaScript

#89

Post by agumonkey » Wed, Dec 07, 2016, 12:16 AM UTC

SpencerWood wrote: post #12

Why would I use this over babel?

afaik babel isn't about performance, but linguistic traits.

Re: Closure Compiler in JavaScript

#90

Post by brucehauman » Wed, Dec 07, 2016, 12:47 AM UTC

espeed wrote: post #38

swannodette wrote: post #23

Earlier quoted context omitted.

Nothing. Zero benefits here for typical usage of ClojureScript. Potentially interesting for 3rd party bootstrap efforts like Planck, Lumo, etc.

True, but it helps fix the TTFX metric -- "Time to First XML" ;-) -- Derek Slager made a case for this in his talk at the Conj: "ClojureScript for Skeptics" https://youtu.be/gsffg5xxFQI?t=20m9s The remaining bit of Java is like "a little piece of kelp that's stuck to the hull, and even though it's little, you don't want anything stuck to the hull" ( http://www.tv-quotes.com/shows/the-west-wing/quote_14096.htm... ). T…

To be fair, the XML is listed at the very bottom as the last of the options for getting your dependencies.