Live data from Hacker News

TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

teavm.org

91–100 of 136 posts

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#91

Earlier quoted context omitted.

very cute, i like your sarc. for those who aren't familiar with transpiling, in this case it's kind of a legitimate use of the term: taking one flavor of compiled code (java bytecode, binary stuff that runs on a jvm) and translating that directly to another type of compiled code (wasm, binary stuff that runs in a browser)

That is actually what compilation means.

I suppose "compilation" usually refers to translating source code (as in human-readable) to some kind of byte code (as in machine-readable).

Here, we start with Java byte code which isn't exactly human-readable, hence the use of the term "transpile". But then again, you're right that on some abstract level, it all is just a translation process from one representation to another.

"A rose by any other name would smell as sweet."

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#92
post #66

I think, by now "transpile" just means "compile, but in web development". Because, as we all know, web development you never compile things... /s

What is the difference between cross-compile and transpile? (Honest question, no sarcasm)

The way you write them.

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#93
post #66

I think, by now "transpile" just means "compile, but in web development". Because, as we all know, web development you never compile things... /s

What is the difference between cross-compile and transpile? (Honest question, no sarcasm)

Doesn't "cross-compile" mean to compile a binary meant to run on a different platform than the host? Like, compiling a Linux binary on a Mac... If I'm right then that's nothing like what "transpile" means.

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#94
post #88

Earlier quoted context omitted.

That is actually what compilation means.

They're both bytecodes though? I don't see how that is compilation.

Compiling is independent of source and target language, although it is mostly used to describe transformation from a higher-level human friendly language into a lower-level machine friendly language. Even so, the defined meaning of compiling is independent of the source and target languages. If you want to use the word "transpiling", you would have to define it in terms of compiling; transpiling is a special case of compiling, where the source and target languages have such and such properties.

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#95
post #75
post #62

Earlier quoted context omitted.

There was a battle? Transpile is between human readable sources, and compiler is always into machine readable code. This is the only project that I've seen to (for some reason) not conform to that definition. I guess I don't see the point of contention.

Transpilers used to be called "source-to-source compilers", or "compilers" when the "source-to-source" distinction wasn't relevant. Then the JS world came along and decided to use a new word to make it look more hip and cool.

It's not a new word. People have been using the word "transpiler" or "transcompiler" for source-to-source compilers since at least the late 80's [0]. They used to be popular for translating between different dialects of assembly. Then they fell out of fashion for a while before gaining popularity again in the last decade for targeting JavaScript. So while the "JS world" is responsible for re-popularizing both the word and the concept, they certainly didn't invent it.

[0]edit: Apparently 60's.

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#96
post #75
post #62

Earlier quoted context omitted.

There was a battle? Transpile is between human readable sources, and compiler is always into machine readable code. This is the only project that I've seen to (for some reason) not conform to that definition. I guess I don't see the point of contention.

Transpilers used to be called "source-to-source compilers", or "compilers" when the "source-to-source" distinction wasn't relevant. Then the JS world came along and decided to use a new word to make it look more hip and cool.

>decided to use a new word

A friendly FYI... the old word "transpiler" has been around since at least the 1960s. See the 2nd-to-last paragraph on the last page:

http://comjnl.oxfordjournals.org/content/7/1/28.full.pdf+htm...

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#97
post #66

I think, by now "transpile" just means "compile, but in web development". Because, as we all know, web development you never compile things... /s

very cute, i like your sarc. for those who aren't familiar with transpiling, in this case it's kind of a legitimate use of the term: taking one flavor of compiled code (java bytecode, binary stuff that runs on a jvm) and translating that directly to another type of compiled code (wasm, binary stuff that runs in a browser)

Yeah, that's a good definition.

My (less sarcastic) understanding was that "compiling" means translation from a "high-level"/"humans-first" to a "low-level"/"machines-first" language while "transpiling" is translation from one high-level to another high-level language.

That would make gcc, clang (mostly) and javac clear examples of compilers while GWT, coffeescript and the C preprocessor would be transpilers.

I guess TeaVM would fit neither by those definition but it would definitely be closer to a transpiler.

Then again, I believe GWT calls itself a compiler, so I got nothing...

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#98
post #15
post #14

Earlier quoted context omitted.

You don't need to have Java enabled in your browser.

The problem with that is you'll essentially re-download the entire JVM (and libraries) on each page load. If you don't want to use a Java applet, you would need to reimplement GC, JNI, and so on. Java didn't work on the web for a reason.

> The problem with that is you'll essentially re-download the entire JVM (and libraries) on each page load.

I always here these arguments, but if you develop an angular application and somehow can't turn on AoT you need to download a ton of stuff, too. Also it's way easier to make use of dead-code elimination on java than on javascript (especially without reflective code)

Post reply on HN