Java in the Browser
jpro.oneI don't know if the performance is terrible in general, or if the demo site is getting crushed by HN traffic at the moment.
If it's the former, then this is completely useless. If the latter, then I suppose it COULD have some use cases for internal tools and dashboards, in small to mid line-of-business shops that don't have many front-end developers on staff (i.e. basically a competitor to .NET's Blazor).
The REALLY interesting thing here is that this product isn't licensed per-server, or per-CPU, but rather "per 8GB block of RAM"! Look, I love Java. It's helped me build a great career, build a future for my family, and I really do believe that it's the best developer experience out there for the server-side. However, the idea of licensing a Java-based product by its memory usage makes me laugh out loud.
maybe that's the selling point? I opened up one demo and despite it is indeed running the browser, it definitely _feels_ like running an AWT widget in ActiveX! oh the memories!
It was the HN traffic. Usually it's very smooth.
Something that bothers me is that this subtly breaks many UI conventions of the browsers. For example, when I hover the mouse over a text it doesn't change the cursor to text edit, it stays in the regular cursor. When I select text it doesn't happen exactly like in the browser - in the browser, text selection can begin by dragging the mouse outside a text element, with jpro it must begin with the mouse inside a text element
Also it looks like you made your own scrollbar instead of using the browser scrollbar. And scrolling is very slow here (I hope/suppose it isn't fetching anything from the web while scrolling)
[ edit: scrolling is slow in https://www.jfx-central.com/home (the site with custom scrollbar) but not in https://www.jpro.one/ (which uses the regular browser scrollbar), so.. maybe they are running different versions of jpro? ]
Are you really reimplementing many core browser functionalities in jpro? .. but why??? This seems very annoying to interact with! In a native application outside the browser we may have an expectation that it doesn't behave exactly the same, but the selling point of the web is that its interfaces converge. If every site reimplemented text selection in mildly different ways, it would harshly degrade the UX of the web (I recognize that some web apps sometimes do this, and also other frameworks like Flutter do even worse, but still, it's a concerning trend)
Somehow jpro feels like old flash websites that reimplement their own UI (or java applets) even though it doesn't use plugins
Sorry for the harsh criticism but I had to let it out
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 is still a bit slow due to the hight traffic.
The text-selection is actually from the browser. The question remains why it behave different - which is something to improve.
Because we are using normal text elements (and normal links) the site is also indexed by google.
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 <canvas>? I'm thinking for example JavaFX charts, or maybe custom widgets
> The scrolling is also (sometimes) from JavaFX. (...) 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 is still a bit slow due to the hight traffic.
But does JavaFX scrolling requires network requests? Are you like running JavaFX in the backend and making a network request for each scroll in https://www.jfx-central.com/? And https://www.jpro.one/ doesn't need this because the scroll is handled by the browser
> You are right, behaving like a normal website is very important.
Well I think that if you have this as a goal your project will surely improve. The text hovering one seems like a low hanging fruit: if you go through each widget you can verify what mouse cursor browsers typically use for that by default (for example, <button> is a normal cursor, <textarea> is an edit cursor, <a> is a clicking hand, etc), and use this by default (perhaps with an option to use the JavaFX defaults if someone wants them).
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 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.
> 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
It's configurable in JPro. In JPro you can say, that the text-elements should support the standard browser text selection. This is the case for https://www.jpro.one/ . The demos usually have this feature disabled - most of the demos are more like "rich desktop applications".
There's no text selection when you run FX code. See the demos section.
https://www.jfx-central.com/ is listed as a demo and it has text selection
Not universally. Notice the widgets that have text selection seem like HTML. That's because they are. FX supports embedding HTML. But then it scrolls oddly.
I went to the demo at "https://demos.jpro.one/controlsfx.html", and found that I could only scroll the "Source" textboxes by manually dragging the scrollbar, and not by two-finger scroll / scrollwheel.
EDIT: The latency between mouse clicks and actions is atrocious as well.
That's actually an interesting way to encourage efficient resource usage.
Efficient resource usage or Java. You can only choose one :p
Actual Java in the browser (working, fast, passes Lighthouse) with TeaVM:
https://blogs.oracle.com/javamagazine/post/java-in-the-brows...
For example, try this 5-letter word game:
See also: Migrating Browser-Based Java Applets to IcedTea-Web Using JNLP
This sounds more like server-rendered again if I understand this correctly? Is there actually a DOM-based AWT emulation for J2cl (GWT) or TeaVM that can be used to actually run old Applets purely in the browser?
Nice username :)
It looks like TeaVm is still setting steady releases? It’s certainly bucking industry trends, which concerns me about maintenance.
Yes, TeaVM is still actively maintained by the original author (and contributors). Java 17 record support was recently implemented, for example.
TeaVM is coming up on 10 years, so it has proven its longevity.
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?
Soda Constructor? Yeah, that was a fun one.
Here's a decent JS clone for some nostalgia: http://panoramx.ift.uni.wroc.pl/~maq/lovesoda/0.36beta.html
Huh, I once made a workshop where people used evolutionary algorithms to make a similar shape learn to walk (see gif on top here https://github.com/Matsemann/walkingea ).
There is a paper on two-legged animals learning different methods of walking: https://youtu.be/pgaEE27nsQw (or https://youtu.be/FahK9srJq10 for the slightly better known "music video" version).
Soda Constructor's wikipedia page also links to a 3D applet named "Springs World 3D", I was playing with that one back in the day.
Back in college I had an assignment to build some kind of CRM-like system, and the professor made a point that we used Java applets, because that was the future (https://en.wikipedia.org/wiki/Write_once,_run_anywhere was all the rage).
I proposed instead learning PHP and using it for that purpose, but was laughed out of the room. Developing this was a PITA and I feel vindicated that applets faded away soon after, and PHP became part of the web-app "standard" (the LAMP acronym was started to be used around then). But I never learned PHP.
On the other hand, Java has established itself as one of the most common server-side languages for building websites.
Yes, it's so interesting how tortuous and serendipitous the evolution of Java has been. It started as a language for embedded devices, then made its way to the interactive web because its bytecode was so portable, and then somehow people figured out it's a good language for the backend because it's managed and thus safer than the alternatives, despite its inherent performance disadvantage. So many unintended extra lives.
I remember when nytimes.com started using java like this, and something like 8 out of 10 failed to function in Firefox on Linux.
Honestly with all the Electron-based desktop apps out there people are still thinking that way. Just with a different language and framework.
I remember! Perhaps that is Soda Constructor:
https://en.wikipedia.org/wiki/Soda_Constructor http://maciejmatyka.blogspot.com/2018/02/soda-constructor-re...
The first Java applets that stood out for me were Anfy Team’s. My images looked supercool with a rippling reflection underneath them!
So many good java games likely lost to time. The falling sand games were my jam back then.
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.
Are you building Java apps that need to be in the browser, or are you a fan of the concept of Java in the browser?
I have looked around the website and I really have no idea what this is. I feel their marketing and doc could do with a bit more explanation if it's intended for devs. Is it like applets in that there is a runtime in the browser? Or more like GWT which compiles Java to Javascript?
Also, the website which is apparently created with the technology, is incredibly slow, at least for me.
And the website doesn't give useful loading indicators, e.g. click a link, nothing happens, or go to the doc section and navigate and lots of empty screens (presumably while the content is loading). No browser loading indicator, nor spinner in the content.
From elsewhere (site is down for me):
> jpro is a new technology which brings Java back into the browser — without Java Plugin. To achieve that, jpro runs JavaFX on the server and maps its scenegraph directly into the browser.
JavaFX is the most recent of the standard GUI libraries for Java. Seems like the Java all runs server-side, but it is effectively using a display device which is "send draw commands via a websocket to a JavaScript driver running in a browser". It's sort of an ingenious idea.
I assume the target market here is companies which already have custom desktop applications written with JavaFX, and want to make them available remotely. This is competing with remote desktop solutions, not React, wasm, etc.
A Swing version of the same idea: https://jetbrains.github.io/projector-client/mkdocs/latest/
It sounds a lot like Eclipse RAP / RWT which is basically swt in the browser. The biggest downside is that every user has a heavyweight session on the server that holds all the UI state. I think Vercel is also a bit similar to this model.
I used a graph analysis app ~2011 that communicated with the server over zmq and rendered via lwjgl. At the time, and perhaps even now, it wouldn't have been reasonable to expect adequate performance if all the results of interactive manipulation were executed on the client hardware. Which was unfortunate for me since I'd also spent a few weeks writing code to visualize the same data, and it was definitely a 'works on my machine' application.
I've considered revisiting the problem, but probably not following the implementation discussed here.
> I have looked around the website and I really have no idea what this is.
Judging from the browser developer tools, something that (very slowly) sends the client stuff via a socket.
The calendar demo I tried was quite slow as well.
Java in the Browser, February 1996 edition:
Totally forgot that Netscape had email and a usenet client built-in! What nostalgia.
It's funny to me that the original use case of Java -- write-once, run-anywhere -- was eventually overtaken by Javascript, a language that had nothing at all to do with it and just wanted to steal its name for marketing. Well, guess it worked? lol
I made an applet in ‘99. As good as a React app these days.
There was also Browser in the Java - HotJava, Sun's circa 1996 web browser written in Java.
Interesting. Runs app on the server, does final rendering of the UI's scene graph on the client (within the browser).
It's not clear from skim reading if the client side rendering is implemented with the DOM or a canvas element.
I've always thought it'd be hysterical to use canvas. The whole browser just to hoist a client side frame buffer. X-Windows reinvented.
FWIW, JavaFX is so close to The Correct Answer™. Definitely the best effort thus far. (I haven't used SwiftUI yet.)
The canvas is a powerful tool, especially if you do a lot of graphical work. Rendering the entire UI yourself, gives you complete freedom of layout management. Plus, you avoid any DOM manipulation, directly or through a myriad of JavaScript frameworks. Remember: there is no silver bullet. Example: https://www.isochart.com
My interpretation of "it's hysterical to use canvas" was that it would be hysterical to draw content elsewhere and then send it to the browser for display.
Implementing something that looks like and behaves like a web page in a canvas on a web page is a "of course it's possible, but there must be a better solution" moment.
If you then have to pay for the amount of RAM of your central layout/rendering process, it would make it hysterical, as in "maybe we could pay less for RAM if we figured out how to offload layout and rendering to the client".
There's probably a niche for this still, because Java isn't inherently bad (pun intended), and if you run out of time but keep getting requirements, this thing could make your existing app be more like a web page, but if you're starting from scratch, why wouldn't you not use this?
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 learning some CSS? Not sure it's worth it.
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 inconsistent but native UX for each platform.
Isn't WebAssembly the clear answer here? You can bind to JavaScript so you can still have all that comes with a browser environment, while still being able to use a different language. Performance may not be as good depending on what you're doing, but it's certainly better than reinventing a whole UI framework in a canvas.
But you also lose a ton of browser features such as options to open links in new tabs or download them, spell checking, search for selected text, find in page, shortcuts to jump to links... You can reimplement each specific feature but you will never get all of the features in every browser.
it's sort of funny - I expect Java in the browser not to work well (as it didn't, historically)... And sure enough - the site returns a 502 error :P
A self fulfilling prophecy.
Some notes from the developing company:
First of all, sorry for the bad performance in the first hours after this post. The server isn't setup up for a big traffic peak. It was way higher than we are used to. To improve the performance, we increased the memory.
Many of our demos represent heavy business applications. Especially the "FlexGanttFX Demo" is a good example.
With JPro the Application itself runs "logically" in the server, and the rendering happens with javascript in the client.
Usually, the performance is very fast - and the architecture is not noticed by the user.
Feel free to ask any further questions.
Is it like Eclipse RAP, just for Java FX? How does it compare to Gluon?
Site appears to be down, there is an archive here from June 2020:
Newer archive on IA from March this year doesn't load anything:
https://web.archive.org/web/20220316200857/https://jpro.one/
However has source code including:
<jpro-app loader="none" href="/app/default" fxcontextmenu="false" fullscreen="true" nativescrolling="true" fxheight="true" snapshot="auto" userselect="true"></jpro-app>
By the sounds of it, it was a demo where the website ran as java on the server, rendering and pushing to the browser in real time? Guessing it couldn't handle HN traffic...
Before it went down I noticed it was sending data through a socket, rendering everything at the very end.
So basically a worse Blazor.
They should have built it with jpro.
So I guess we’ve come full circle now? Java was the first to run in the browser (via applets).
I do not know. .NET created with Blazor a modern Applet tech stack based on WebAssembly and HTML.
Would not Java be able to do the same and just port the applet API onto a Canvas? Would not that reactivate a whole existing ecosystem?
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
That chart is funny:)
ChherpJ seems more like a browser extension. TeaVM sounds like it at least from the runtime perspective (not so much from app model.. neither applet or Blazor alike? ... But indeed it is older). I think TeaVM could be the foundation to run applets on a WebAssembly and not browser extension.
You left out probably the most widely used one, Google’s j2cl compiler (java->js), which is used quite extensively in many google products for shared business logic. It is the spiritual inheritor of GWT.
Ah, wasn't aware of it.
Now someone please compile a real JRE into WASM and do it right, so I can revive applets with a simple embed. There are loads of old applets that have huge historic and technical value which are becoming harder and harder to use.
Example: https://www.grc.nasa.gov/www/k-12/rocket/ienzl.html
Here you go: https://chrome.google.com/webstore/detail/cheerpj-applet-run...
CheerpJ does exactly that: it ships a full JVM implementation (including Swing/AWT, Threads, ...) that runs in JS/Wasm inside your browser. The Applet Runner extension detects applets in the page and runs them through CheerpJ.
The example that you list seems to work.
I know about the extensions, it's exactly how I was able to run that specific applet, but that's a high friction experience for the user. If the applet does not run it's very unlikely I will install an extension (or search for a Firefox alternative) unless I'm very motivated.
I'm thinking more like a line or two you can add to your pages hosting applets, and it would enable any modern browser to use it. Minimal friction for the webmaster, zero friction for users.
That is also possible: https://docs.leaningtech.com/cheerpj/Getting-Started
See "Converting an applet"
We still use Java applets at work. For example the IBM Host On Demand is used by the cobol/mainframe folks in a lot of banks and other financial institutions. I hate it so much.
See now, I think COBOL in the browser would be a winner!
This is very advanced satire.
I busted out laughing
Site is down but it seems like server side rendering which is pretty terrible. There are better solutions for Java developers such as teavm one which Codename One built the web UI support. It supports both web assembly and plain JS. The latter has the advantage of smaller size.
Transpiles Java threads into async/await calls. Pretty cool stuff.
What's so bad about server rendering
Well.. I come from the age of dumb terminals so trauma. We have powerful machines today. Using them like a dumb terminal rubs me the wrong way.
I've recently come to appreciate server rendering for its simplicity, at least for the tasks it is suited for. But I know what you mean. As a user, it's better to have local apps doing the real work.
Welcome to cloud computing.
Serverless is the new timeshare.
The new CGI actually.
Your code is running on their hardware. But I get your point...
So it isn't terrible?
- higher latency - uses more server resources per-client, therefore it's more expensive - harder to do SPA-like apps- waiting for javascript to load is not considered latency but kills user experience
- depends how you do it
- not all apps need to be SPA but also you can render fragments if you really want
> - higher latency
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?
JPro can also target WebAssembly.
WASM really is the way to go for this kind of thing IMHO; I love me some Java and have for decades, but Applets were painful, especially when hooking in native code. HN seems to have killed the demo, I'll have to remember to come back later when the hoopla dies down.
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).
Yes. Java was removed from browsers due to "security concerns", and yet, here we are, compiling Java to WASM and running it in the browser. Truth is, removing it was more of a political move against Oracle.
I tried the demo website - it takes seconds to respond to clicks, even on an M1 mac. I'd rather set myself on fire than use software built using this technology.
"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should." - Dr. Ian Malcolm
Time to update "3 Billion Devices Run Java" message.
there's a price for this??
I'm not sure what this is by looking at their homepage, is this similar to WASM?
also who would pay to develop something for the web anymore?
Enterprises that aren't going to rewrite from scratch and rather look forward to solutions to keep existing code running.
The same reason IBM and Unisys keep their mainframes and microcomputers running with updated hardware.
Proposed subtitle: "the original sin"
Gb != GB.
wait a minute .. LOL!!!
I thought we tried this already...
And it was way better than anything before and after, but the current politics the given time killed it (which may or may not be relevant anymore).
The load times and performance for applets were all pretty dismal, and given that about half of them were a site logo with moving waves at the bottom, not so missed. That said, I have a Number Theory textbook which uses computer-assisted explorations (e.g., get lists of pythagorean triples, factor a bunch of large numbers, etc.) and the most accessible version of those was through a set of applets which are challenging to run now (it also has Maple and Mathematica versions of the explorations).
> The load times and performance for applets were all pretty dismal
Javascript was abysmally slow as well, but then it got some insane amount of man-hours spent on it. Also, with that internet speed, everything was slow - I don’t see why would that be a valid criticism against java, especially that Java byte code is insanely compact, much more so than minified js.
I think it was just ahead of its time, and Java itself could have easily been used as the web-native language if it is made to interact with the DOM natively.
> Javascript was abysmally slow as well
From what I remember, the Java VM took around a minute to start the first time you opened any page with a Java applet, and it locked the whole browser while it started. Compared to that, Javascript loaded instantly. Also keep in mind that much less was done in Javascript back then, so even though it was interpreted, it didn't feel that slow.
> and Java itself could have easily been used as the web-native language if it is made to interact with the DOM natively.
From what I recall, a Java applet could interact with the DOM directly (even though most applets didn't); the DOM specification had both Java and Javascript as targets, and it always felt to me that it favored the Java style in its interfaces.
> Java applet could interact with the DOM directly
It could. A funny piece of web-gore from that time: some mostly static websites (especially those made by people who didn't really know what they were doing), used Java Applets for client-side interactivity, like you would use Javascript in a server-rendered page today.
> From what I remember, the Java VM took around a minute to start the first time you opened any page with a Java applet, and it locked the whole browser while it started. Compared to that, Javascript loaded instantly. Also keep in mind that much less was done in Javascript back then, so even though it was interpreted, it didn't feel that slow.
I don't remember this. Probably its very early days at most.
Looks like it’s a custom webserver.