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

71–80 of 136 posts

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

#71

Post by oblio »

mping wrote: post #68
oblio wrote: post #58

Earlier quoted context omitted.

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…

Not only that, swing applets are notoriously fugly. One reason electron is successful is because it kinda looks like native. Swing Look and Feels all seem alien.

Swing can be styled, it's that not a lot of people really bothered. Jetbrains products use Swing and they're decent.

Not amazing, but decent.

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

#72

Post by xxs »

sitkack wrote: post #49
earenndil wrote: post #35

Earlier quoted context omitted.

> 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.

If only the JVM had included unsigned math.

there is... 'char'; char is an unsigned 16bit primitive (of course, adding 2 chars results into an int and you need a cast but that's another story)

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

#73

Post by stefano »

xg15 wrote: 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

Compilation is for old people writing old programs that run on old things called "computers".

We're fresh and new and iterating quickly on our MVP, so we don't have time to wait for long compilation time. Instead we transpile our code and run it in a serverless environment, a docker container or a browser.

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

#74

Post by austincheney »

rubyn00bie wrote: post #69
austincheney wrote: post #64

Earlier quoted context omitted.

If you are compiling to the JVM the output is probably nothing related to a web app.

One isn't compiling to the JVM with this, they're compiling to WebAssembly. And I think the point of this is to compile JVM code to WebAssembly, right? Am I missing something even larger than that?! Should someone want another VM to run their code in; how, good is this at reducing the size of the std lib or the JVM itself? Can I depend on useful packages with this, or will they immediately shit the bed? Will the payl…

In that case it will be interesting to observe this in practice. My fear (and prediction) is a lot of continued frustration and failure because the web environment is a different context than the JVM target with many different technical requirements. If the underlying technical differences in the environments were so trivial in the first place then simply swapping languages from Java to JavaScript wouldn't be so challenging.

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

#75

Post by stefano »

lopatin wrote: post #62
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.

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.

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

#76

Post by vesinisa »

rubyn00bie wrote: post #69
austincheney wrote: post #64

Earlier quoted context omitted.

If you are compiling to the JVM the output is probably nothing related to a web app.

One isn't compiling to the JVM with this, they're compiling to WebAssembly. And I think the point of this is to compile JVM code to WebAssembly, right? Am I missing something even larger than that?! Should someone want another VM to run their code in; how, good is this at reducing the size of the std lib or the JVM itself? Can I depend on useful packages with this, or will they immediately shit the bed? Will the payl…

Generally speaking, there are ways to reduce a JVM library to the subset that is actually ever referenced by the app during compilation, like ProGuard. So of the 150 MB theorized library payload only maybe a megabyte is actually used by some app and needs to be delivered to client (browser).

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

#77

Post by simfoo »

The argument against the critics saying WebAssembly would make the web less open was, that you could always disassemble WebAssembly and that said disassembly would be much more readable than for example x86 assembly.

So - since a quick research did not turn up anything - is there a WASM to C "transpiler" that generates readable C?

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

#78

Post by usrusr »

gatmne wrote: post #17
ant6n wrote: post #3

Compile

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.

I think it's pretty clear that "transpile" is a subset of "compile" and that there are both examples of "compile" that are indisputably not "transpile" (plain old source to architecture specific binary) and examples of "compile" that anybody who uses the term "transpile" would include in their personal variety of "transpile" (translation between source formats that are commonly used for human written code).

I don't see why the existence of a grey area should be enough to question the utility of the term.

If compile/decompile are used for a transformations along one axis, transpile is used for transformations that are predominantly orthogonal to that axis.

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

#79

Post by cobbzilla »

xg15 wrote: 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)

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

#80

Post by MaxBarraclough »

simfoo wrote: post #77

The argument against the critics saying WebAssembly would make the web less open was, that you could always disassemble WebAssembly and that said disassembly would be much more readable than for example x86 assembly. So - since a quick research did not turn up anything - is there a WASM to C "transpiler" that generates readable C?

But that's not really the worry. It's always been possible to obfuscate JavaScript. All that changes with WebAssembly is that it might drive even more needless code, and complicate the web's architecture even further.

For example, web browsers for the blind become far harder to implement when ordinary websites are using heaps of boated JavaScript. (The web used to have HTML for content, and CSS for presentation. No longer. Now it's just a mess.) The problem would be compounded if WebAssembly+canvas were to catch on.

Post reply on HN