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

111–120 of 136 posts

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

#111

Post by frostmatthew »

diegoperini wrote: post #86
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

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

compile: convert from one language to another (though usually used in the specific context of converting from high level source code to lower level code like assembly/machine/etc)

cross-compile: convert from one language to another that will be executed on another platform (e.g. compiling something on a linux box to be ran on a windows machine)

transpile: convert from one (typically high level) source language to another (high level) source language

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

#112

Post by progman »

gatmne wrote: post #89
usrusr wrote: post #78

Earlier quoted context omitted.

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 s…

At the time of this reply, there are at least five competing definitions being argued for and against in this thread; some either requiring that the input and output be machine code or disallowing it, some necessitating that both input and output be at "the same level of abstraction" and others arguing that inputs and output can be at different levels of abstraction. Given the large inconsistency and incompatibility…

>After all, what use is a nuanced term if it can't reliably convey that additional information.

I would recommend the general term "A/B compiler" where A and B are arbitrary regular languages. That way it would be pretty clear what a Pascal/C compiler is, or a JVM/Webasm compiler, for instance. Or a x86/C compiler which would also make the word "decompiler" obsolete.

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

#113

Post by shakna »

pjmlp wrote: post #105
PyComfy wrote: post #87

Earlier quoted context omitted.

I always understood it as this Transpilation: text to text (eg: Scheme to C) Compilation: anything to anything but usually it implies text to binary code transpilation is compilation but compilation is not necessary transpilation (the all squares are rectangles but all rectangles ... )

So classical UNIX C compilers are now transpilers, because they always did text to text (C to Assembly), before forking to the assembler.

The first AIX C compiler called itself a "transcompiler" in it's manual, so yes, they are.

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

#114

Post by [deleted] »

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

[deleted]

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

#115

Post by konsoletyper »

norswap wrote: post #100

Does this support (a subset of) the standard Java libraries? Where can I find what is supported? (I just saw mentions that reflection wasn't)

As for 0.5.x version, see this: http://teavm.org/jcl-support/0.5.x/jcl.html

And even more in 0.6.x (including Stream API)

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

#116

Post by konsoletyper »

rubyn00bie wrote: post #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 m…

One of the most important features in TeaVM is its inteprocedural dead code elimination algorithm, which allows to produce very small code for simple Java programs. For example, Hello World produces about 40 kb JavaScript, TodoMVC (http://teavm.org/live-examples/todomvc/#/) is only 125 kb.

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

#117

Post by kodablah »

taxreform wrote: post #84

I read some parts of the spec of WebAssembly recently, and there were several things that disappointed me. To name a few: 1) There is no way to allocate in a function's variable stack continuous memory space that spans more than 8 bytes. This implies that if a function has as a local variable compound data structure such as an array or a struct, you have to a) have a global virtual stack pointer, b) manipulate the st…

See the GC proposal: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O.... Here you get structs, arrays, and tuples (that can be used for multiple returns). I am not disappointed that none of these features made the MVP personally.

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

#118

Post by konsoletyper »

rufugee wrote: post #106
olingern wrote: post #22

> If you are a Java (or Kotlin, or Scala) developer who used to write back-end code, TeaVM might be your choice. It’s true that a good developer (including Java developer) can learn JavaScript. However, to become an expert you have to spend reasonable amount of your time. Oh, this is nice. I finally have a reason to give Kotlin a go. I have some time off and want to write something basic. Pretty excited about this, R…

Kotlin compiles to javascript already...why wouldn't you go that route?

Kotlin/JS does not allow to reuse Java code and Java libraries. That's the main difference.

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

#119

Post by konsoletyper »

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?

Currently, if you run TeaVM with 'debug' (-g) option, and WASM target, you'll get both '.wasm', '.wast' and '.c' files. C file is compilable with GCC and you should write several trivial functions manually to get working binary, either '.so' or '.exe'.

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

#120

Post by crazyhatfish »

rubyn00bie wrote: post #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 m…

If you look at how much their demos in their gallery downloads, it's in the hundreds of kilobytes on average. Granted these are not full web apps but even still it's roughly on par with the latest web app framework's demos.

Performance is not too shabby either

Post reply on HN