101–110 of 113 posts
Anyone remember that Java applet in the nineties where there was some 2D wireframe "animal" moving in a rectangle and there was, IIRC, a tiny circle at each joint and you grab it and move it and it'd move the thing around / distort it. It was the first "serious" Java in the Browser I remember. It was all black & white. Maybe some HNer (not an HNer back then obviously) wrote it back in the days?
Earlier quoted context omitted.
It worth noting, that the application is written in JavaFX. For the text-hovering, what you are experiencing, is the default behaviour for JavaFX. The scrolling is also (sometimes) from JavaFX. You are right, behaving like a normal website is very important. Your observation with the scrolling is right. https://www.jpro.one/ uses the browser scrolling. https://www.jfx-central.com/ uses the scrolling of JavaFX, which…
Oh, this, like, renders JavaFX using the DOM? Wow, despite my criticisms from before, your project is very impressive! And there's lot of value in porting existing desktop apps to the web with minimal effort. Is there something from JavaFX that can't be represented in the DOM and then you need to lower to ? I'm thinking for example JavaFX charts, or maybe custom widgets > The scrolling is also (sometimes) from JavaFX…
The implementation is pretty impressive. It's not as slow as some other previous attempts. It's "only" 1mb for a hello world 3+ for anything "decent". Both of these numbers are good for Java FX but they come with a lot of caveats. E.g. accessibility seems to be broken. Performance is lagging and rendering looks "off" because it uses the FX rendering instead of system rendering.
Ultimately, FX lost the battle for the desktop, mobile, etc. this is an attempt to make it relevant again but unfortunately nothing will help FX at this point. It's a solution designed to combat Adobe Flash trying to compete in 2022. The RIA wars are over.
Earlier quoted context omitted.
Java solutions for JS and WebAssembly as targets are older than Blazor actually, see TeaVM and CheerpJ, and then there was GWT alongside Vaadin.
Yes, TeaVM predates Blazor and still has the edge on most fronts: https://frequal.com/java/TeaVmVsBlazorWasm1-0.html Comparison Chart: https://frequal.com/java/TeaVmVsBlazorChart.html
Well this isn't helpful for those of us that care about Java in the browser. In any case, JPro is really more "Java projected in the browser" (or like twitch/remote-desktop). It's a shortcut with significant drawbacks. I'm more a fan of TeaVM, CheerpJ, J2CL and JSweet. https://reportmill.com/snaptea/
Earlier quoted context omitted.
What's so bad about server rendering
- higher latency - uses more server resources per-client, therefore it's more expensive - harder to do SPA-like apps
Which is a tradeoff, and it's okay as long as the client doesn't notice it.
> - uses more server resources per-client, therefore it's more expensive
Which is okay as long as the added expense is inconsequential (which it is).
> - harder to do SPA-like apps
Why?
Java in the browser used to be called applets, no? Anyways, it failed, thought that probably had a lot to do with: JavaScript being more accessible (still is) and the security model for applets (JAAS) being rather lame (it was, and still is, and it continues to exist in spite of applets being gone because JAAS metastasized).
Earlier quoted context omitted.
Using canvas for fast visualizations is good! As you say, it's fast, you have layout management, and lower-level control of how things load and paint. Using canvas for the entire UI...is not good. You have to reinvent _everything_, poorly. You have no accessibility support. Text selection doesn't exist, things look and behave kind of "off" from what people expect. All that so you can avoid spending a few hours learni…
You really need a good reason to choose a non native language (e.g. not JavaScript for the Browser). One reason might be that you target other platforms too (cross-platform). In that case, you are outside of the browser anyway and you need to come up with solutions to these problems. Implementing those in a consistent way across all platforms for your product is not generally a bad idea. The alternative is an inconsi…
Earlier quoted context omitted.
Oh, this, like, renders JavaFX using the DOM? Wow, despite my criticisms from before, your project is very impressive! And there's lot of value in porting existing desktop apps to the web with minimal effort. Is there something from JavaFX that can't be represented in the DOM and then you need to lower to ? I'm thinking for example JavaFX charts, or maybe custom widgets > The scrolling is also (sometimes) from JavaFX…
No. It renders FX using Canvas or GL. Not the DOM. This seems to have lots of problems related to size, accessibility, etc. The implementation is pretty impressive. It's not as slow as some other previous attempts. It's "only" 1mb for a hello world 3+ for anything "decent". Both of these numbers are good for Java FX but they come with a lot of caveats. E.g. accessibility seems to be broken. Performance is lagging and…
So the text selection is done by javafx too? But the comment above implied that the text selection was done by the browser
Earlier quoted context omitted.
No. It renders FX using Canvas or GL. Not the DOM. This seems to have lots of problems related to size, accessibility, etc. The implementation is pretty impressive. It's not as slow as some other previous attempts. It's "only" 1mb for a hello world 3+ for anything "decent". Both of these numbers are good for Java FX but they come with a lot of caveats. E.g. accessibility seems to be broken. Performance is lagging and…
> It renders FX using Canvas or GL So the text selection is done by javafx too? But the comment above implied that the text selection was done by the browser