Live data from Hacker News

New Java to WASM GC Transpiler: Run Java in the Browser, No Plugin Required

teavm.org

51–59 of 59 posts

Re: New Java to WASM GC Transpiler: Run Java in the Browser, No Plugin Required

#51
post #10
post #7

Ironic, given Java Applets were going to run in browsers

They were running, not going to, until Java 8. While Java Kernel did improve download times against Flash, the latter tooling was much better, and still downloaded faster. Had it not been for Apple and iOS forbidden, mostly due to app store than security concerns, and classical plugins would be around. Since browsers never contended themselves with being document only, leaving the rest for native apps, now we have pl…

> They were running, not going to, until Java 8.

Back in the '90s I tried hard, and succeeded, in getting Java applets to work in a browser

If I recall correctly it was clunky and quite annoying.

Flash succeeded, sort of, but was also clunky.

But I think both were ahead of their time.

Re: New Java to WASM GC Transpiler: Run Java in the Browser, No Plugin Required

#52

Earlier quoted context omitted.

whats the status of swing? can we port old applets easily? multi-threading or am i dreaming?

I think Swing is a non-goal of this project. It provides good interop with the DOM and core JS methods, and it makes it easy to create your own interop for JS apis that aren't in the core. There are at least two GUI toolkits that run on TeaVM: 1. Codename One. Similar to swing, but focused on mobile https://www.codenameone.com 2. SnapKit. Targeted at desktop. Also a light-weight toolkit, like Swing. https://github.co…

> I think Swing is a non-goal of this project.

It could work though by drawing to canvas.

That's what Avalonia does in C#: https://avaloniaui.net/

Here's a clone of Visual Basic 6 written with Avalonia and compiled to WebAssembly:

https://bandysc.github.io/AvaloniaVisualBasic6/

https://github.com/BAndysc/AvaloniaVisualBasic6

Re: New Java to WASM GC Transpiler: Run Java in the Browser, No Plugin Required

#53
post #49

Earlier quoted context omitted.

To me, this is one of the many ingenious things about TeaVM's architecture. By using the preferred code execution mechanisms of browser vendors (WASM and ECMAScript, plus Web APIs) to deliver Java code, it ensures they can't block or shut down this delivery mechanism. They would have to cut off their noses to spite their faces. Furthermore, since the browser vendors never want browser code to have public security iss…

Really? What stops someone from dropping WASM support?

True, WASM adoption is still low and could feasibly be removed, but TeaVM lets you target both JavaScript and WASM GC backends, so you are future proofed either way.

Re: New Java to WASM GC Transpiler: Run Java in the Browser, No Plugin Required

#54
I'm sorry if this is a dumb question, I don't really know a lot about this field.

Would this allow me to play Puzzle Pirates (a Java game) in the browser, or would the developers still need to do some work for the game to be actually playable in the browser?

Re: New Java to WASM GC Transpiler: Run Java in the Browser, No Plugin Required

#55

Earlier quoted context omitted.

F# interop support has gotten way better. I have several f# services (suave, giraffe) in prod and agree that things have been only trending positive. I write rider fsharp most days, which is a pretty good experience compared to the old days of the mono fsgen tooling taking up 100% of cpu on macOS for no reason. However, there are still some huge gaps that Kotlin doesn’t experience. Source-generation based tooling cre…

Great projects I agree, source-generation is particularly unfortunate. I don't think it's a deal-breaker per se however - most of the time a small bindings project in C# is more than enough - I just accept it as a matter of life and get on with it, luckily it has not been particularly troublesome. Perhaps it's a bigger issue for people who would like to keep their projects C#-free (which is unfortunate, because C# is…

While true the type system is a problem on the JVM world, that is taken care by the plethora of choice of implementations, some do include extensions.

Also while .NET is great and I favour it over Java when having the option, it is a guest on mobile OSes constrained by platforms FFI API surface, or subpar APIs (Catalyst on macOS), and Meadow isn't at the same level as PTC, Aicas, microEJ and many other embedded implementations.

Re: New Java to WASM GC Transpiler: Run Java in the Browser, No Plugin Required

#56
post #37

Earlier quoted context omitted.

Java plugins were mainly useful to do naughty things (for instance in a previous life I used a Java plugin to load and call into a native DLL via JNI which spawned a Win32/D3D9 game client inside a browser by attaching as a child window of the Java plugin canvas). Fun stuff but not really a good idea from a security point of view ;) And of course this cannot be replicated with a Java plugin running in a (browser) WAS…

All code can be abused for naughty things, including crypto miners in modern Web APIs.

That's why content-blockers exist.

Re: New Java to WASM GC Transpiler: Run Java in the Browser, No Plugin Required

#57
post #47

Earlier quoted context omitted.

True, but are people turning off ECMAScript/WASM in their browsers to avoid this? As an app developer, I want to know if my app will keep running. In the Java Applet days, at some point the security scares became frequent enough to cause articles like "Turn off Java except on websites where you are actively using it". Once your users have to find and toggle a setting to make your app work, your audience size drops si…

Good luck turning those things off in modern Web, unless you plan to have a custom browser.

[deleted]

Re: New Java to WASM GC Transpiler: Run Java in the Browser, No Plugin Required

#58

Earlier quoted context omitted.

Great projects I agree, source-generation is particularly unfortunate. I don't think it's a deal-breaker per se however - most of the time a small bindings project in C# is more than enough - I just accept it as a matter of life and get on with it, luckily it has not been particularly troublesome. Perhaps it's a bigger issue for people who would like to keep their projects C#-free (which is unfortunate, because C# is…

Agreed on c# having better low-level primitives available. I know Java has some long-term projects in flight (Valhalla and friends), but dotnet has all of that available today. I’m curious in what industry you’re utilizing those features. I imagine you must be using mostly your own code since much of nuget contains things that don’t take performance as a first priority. I imagine it would be similar to the trading co…

> I’m curious in what industry you’re utilizing those features.

Performance engineering for CDN systems!

> I imagine you must be using mostly your own code since much of nuget contains things that don’t take performance as a first priority.

This was my assumption too. While "much of nuget" trend continues to hold, there are actually quite a few performance-oritned libraries nowadays.

Bindings and binging generators (that are near-zero-cost), managed allocator implementations, high-performance parsers and serializers (which completely wipe the floor with alternatives written in flimsy languages like Go), higher-level APIs for graphics libraries (DX12, Vulkan, ...), high-performance primitive libraries, game engines, and more.

You are correct to point out that performance-sensitive code tends to avoid standard library containers and certain APIs, but CoreLib itself has been exposing quite a few APIs (like ArrayPool) and tends to practically always offer Span-based method overloads so the data can reside in any memory if it needs so (stackalloc, array pool, unmanaged, or anything in between).

Sure, if you have a hot path you will probably avoid using List and StringBuilder in favor of something less allocation-heavy, but it's generally the Unity land that is subjected to pain of fighting with every allocation rather than .NET itself.

Re: New Java to WASM GC Transpiler: Run Java in the Browser, No Plugin Required

#59
post #2

The new release of TeaVM (0.11.0) now supports WebAssembly GC. This increases performance while further decoupling TeaVM apps from ECMAScript. TeaVM ( https://teavm.org/ ) is an Apache-licensed project, free for use in commercial projects. It is mature and used widely, including in frameworks like Flavour ( https://frequal.com/Flavour/book.html ) and more projects listed here: https://www.frequal.com/TeaVM/TeaVmBased…

whats the status of swing? can we port old applets easily? multi-threading or am i dreaming?

If that's your goal, you should look at CheerpJ, which supports Swing and has the goal of making it so you can easily port applets and other existing apps to the web.

I think TeaVM is more focused on letting you share code with the web instead of porting entire apps.

Post reply on HN