Live data from Hacker News

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

teavm.org

51–60 of 136 posts

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

#51
post #17

Earlier quoted context omitted.

Agreed especially given that "transpile" lacks a well-defined meaning. Just ask folks how this term differentiates from Compile and you'll get wildly varying answers and definitions.

“Transpile” is a proper subset of “compile”, where both the source and target of compilation are languages designed primarily for direct human editing (source code); it is source-to-source compilation. Using the term for anything where the source is JVM bytecode is plain wrong, and it's also dubious for anything targeting WebAssembly (though if the target is specifically .wat/.wast, it may perhaps be arguably defensi…

there existed "translators" from one asm variant to another in the past. [0][1]

so i guess one might use "transpile" wrt bytecode in the spirit of that. but i guess asm source files are still "human readable", where bytecode generally isn't considered as such.

[0] P47, "TRANS": http://www.patersontech.com/dos/Docs/86_Dos_usr_03.pdf

[1] http://www.s100computers.com/Software%20Folder/Assembler%20C...

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

#52
post #46
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.

> untrusted binaries afaik, wasm is not 'binaries' in that it's not an arbitrary blob of machine code fed right into the cpu. it's still running in a sandbox (a la javascript) including similar limitations wrt CORS etc.

And a sandbox so powerful that all the browser vendors just turned off SharedArrayBuffer.

https://www.chromium.org/Home/chromium-security/ssca

https://blog.mozilla.org/security/2018/01/03/mitigations-lan...

WASM is portable binaries.

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

#54
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 browser would cache that automatically. And in many cases, you'd probably use a Service Worker to implement your own custom cache and "install" the application locally in the browser, so that is usable offline and only version updates are downloaded in the background.

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

#55
post #42

Earlier quoted context omitted.

it's not a new word. i find it odd how some people react to it.

Not new, but as unnecessary as ever.

i find it fascinating how some in a community notoriously anal about 'being precise' want to be less precise, presumably because of some incorrect assumptions about a word.

is it because they think it's a neologism? is it because they associate it with javascript developers, who they look down upon and sneer at?

the word and idea predates javascript. rather amusing. :)

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

#56
post #52
post #46

Earlier quoted context omitted.

> untrusted binaries afaik, wasm is not 'binaries' in that it's not an arbitrary blob of machine code fed right into the cpu. it's still running in a sandbox (a la javascript) including similar limitations wrt CORS etc.

And a sandbox so powerful that all the browser vendors just turned off SharedArrayBuffer. https://www.chromium.org/Home/chromium-security/ssca https://blog.mozilla.org/security/2018/01/03/mitigations-lan... WASM is portable binaries.

well, i guess in the same way that javascript or anything else is, when there are sandbox escapes. bugs are a thing.

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

#57
So... from reading the page linked (admitting my ignorance)... I really wonder how useful this is? Not to be rude, or to talk ill of the work, it’s far better than I could do... but!

With the release of other ahead of time compilers/VMs/features for the JVM/Java9, I cannot fathom this produces a small enough payload for a web app over a mobile connection.

Im probably totally missing something; could someone educate me on practical or even useful but novel applications of this?

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

#58
post #54
post #15

Earlier quoted context omitted.

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 browser would cache that automatically. And in many cases, you'd probably use a Service Worker to implement your own custom cache and "install" the application locally in the browser, so that is usable offline and only version updates are downloaded in the background.

Weren't applets also cached?

To be honest, I think that hate of applets comes from a time when 56kbps download speeds were considered very high, the average CPU had 1 core at 200 Mhz and the average webpage weighed 20k and executed 5-10 lines of Javascript.

I haven't used applets in the time, but if the user experience would be improved (nice looking UI, respecting modern UX conventions, etc.), I imagine your average applet from circa 1999 would run circles around Gmail, for example :)

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

#59
post #55

Earlier quoted context omitted.

Not new, but as unnecessary as ever.

i find it fascinating how some in a community notoriously anal about 'being precise' want to be less precise, presumably because of some incorrect assumptions about a word. is it because they think it's a neologism? is it because they associate it with javascript developers, who they look down upon and sneer at? the word and idea predates javascript. rather amusing. :)

An old colleague of mine hated the word "awesome" because, in his words, "it's a word js-kiddies use to exaggerate their little accomplishments".

Guess how he reacted when someone used the phrase "isomorphic js"...

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

#60
post #37
post #24

Earlier quoted context omitted.

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?

That is correct but we are not talking in the context of the emulation circles.
Post reply on HN