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

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

teavm.org

Post reply on HN
Print view View original

31–40 of 136 posts

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

#31

Post by nurettin »

gatmne wrote: post #27
nurettin wrote: post #25

Earlier quoted context omitted.

I assume "javascript crowd" knows how to compile their node binary. Thus, they know the distinction between babeljs and gcc, and therefore they know the distinction between compiler and transpiler.

What's the distinction between Compile and transpile then? and is this distinction agreed upon and meaningful?

I agree with drdrey's definition here[1], which is echoed in paragraph two here[2] as well, which provides you with the agreement part at least. Whether if it is meaningful to you, is up to you.

[1] - https://news.ycombinator.com/item?id=16076823 [2] - https://hackernoon.com/moving-to-es6-babel-and-transpilers-3...

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

#32

Post by rusbus »

billsix wrote: post #30

That word,"Transpile". Lol. GCC transpiles C to assembly.

I guess it implies a 1-1 or similar conversion without optimizations or multiple levels of intermediate representation. GCC certainly doesn't "transpile" in that case...

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

#34

Post by frik »

The last thing we need in hindsight to Meltdown and Spectre is running untrusted binaries in the browser aka WebAssembly.

Btw deactivating WebAssembly support in Chrome 63 (up-to-date) doesn't work anymore!!

  chrome://flags/#enable-webassembly
Setting it to "deactivated" does nothing, WebAssembly is still active.

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

#35

Post by earenndil »

kodablah wrote: post #4

For the reverse, I wrote a WASM-to-JVM compiler: https://github.com/cretz/asmble . I think WASM has the ability for us to finally cross the language boundaries without marrying ourselves to C/C++ ABI. But at this early stage, there's no common stdlib for all languages to share.

> I think WASM has the ability for us to finally cross the language boundaries without marrying ourselves to C/C++ ABI

Uhhhhh. This sounds like a kind of silly thing to say, when you just described the jvm. Except for the part where there is a common stdlib.

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

#36

Post by jayd16 »

dizon wrote: post #15
grzm wrote: 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.

Caching exists. You hsouldn't have to redownload the same libraries for each page load.

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

#37

Post by lloeki »

drdrey wrote: post #24
clhodapp wrote: post #18

Earlier quoted context omitted.

At the point where we are calling things that compile to assembly "transpilers" I don't think there is any distinction left, much less a useful one. I mean the classic notion of a compiler is a program that turns things into assembly, which is then taken into machine code by an assembler. I agree with you that we've lost though: no amount of protest is going to make people stop using the word "transpiler".

A compiler is a program that turns programs in a source language into equivalent programs in a target language. It is generally assumed that a compiler goes from high level to low level, a decompiler low-to-high and a transpiler high-to-high. I guess in this case the transpiler is low-to-low, so maybe "transpiler" is just used to mean "samey-to-samey"

Isn't "low-to-low" typically called static recompilation or binary translation esp. in emulation circles?

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

#38

Post by pjmlp »

frik wrote: post #34

The last thing we need in hindsight to Meltdown and Spectre is running untrusted binaries in the browser aka WebAssembly. Btw deactivating WebAssembly support in Chrome 63 (up-to-date) doesn't work anymore!! chrome://flags/#enable-webassembly Setting it to "deactivated" does nothing, WebAssembly is still active.

I keep saying that WebAssembly is the revenge of Flash, Applets, Silverlight, ActiveX,...

Just wait until it gets a bit more mature.

It will be the same fun as when Ads moved away from Flash into HTML 5/JavaScript.

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

#39

Post by pjmlp »

doug1001 wrote: post #11
burke wrote: post #9

Earlier quoted context omitted.

I get that we've lost this battle, and some people seem to think there's a useful distinction being made, but man, does the word 'transpile' grate on me.

thank you; some consolation to know it's not just me does this seems like another instance of the annoying practice in our field of someone giving a name to a thing because they think it's new, though it's not (ie, source-to-source compilers have been around as long as source-to-bytecode compilers)--no need to re-name them wish they would just stop it and get the hell off my lawn

Yep, like calling themselves Engineer without having the respective degree.

Thankfully in most jurisdictions it is forbidden by law to do as such.

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

#40

Post by fulafel »

dizon wrote: post #15
grzm wrote: 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 JVM can be very small. The libraries shouldn't be any worse than with current JS.

The browser won't have to re-download on each page load because the browser has a cache, which can be validated on each page load to check for updates.

Post reply on HN