Here's a decent JS clone for some nostalgia: http://panoramx.ift.uni.wroc.pl/~maq/lovesoda/0.36beta.html
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.
https://en.wikipedia.org/wiki/Soda_Constructor http://maciejmatyka.blogspot.com/2018/02/soda-constructor-re...
It’s on GitHub now:
Transpiles Java threads into async/await calls. Pretty cool stuff.
- higher latency
- uses more server resources per-client,
therefore it's more expensive
- harder to do SPA-like apps- depends how you do it
- not all apps need to be SPA but also you can render fragments if you really want
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?
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.
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
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.
EDIT: The latency between mouse clicks and actions is atrocious as well.
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.
> 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.
I've considered revisiting the problem, but probably not following the implementation discussed here.
Judging from the browser developer tools, something that (very slowly) sends the client stuff via a socket.
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?
https://frequal.com/java/TeaVmVsBlazorWasm1-0.html
Comparison Chart: https://frequal.com/java/TeaVmVsBlazorChart.html
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.)
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 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.
Example: https://www.grc.nasa.gov/www/k-12/rocket/ienzl.html
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'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.
See "Converting an applet"
https://blogs.oracle.com/javamagazine/post/java-in-the-brows...
For example, try this 5-letter word game:
It looks like TeaVm is still setting steady releases? It’s certainly bucking industry trends, which concerns me about maintenance.
TeaVM is coming up on 10 years, so it has proven its longevity.
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.
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
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...
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.
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?
The same reason IBM and Unisys keep their mainframes and microcomputers running with updated hardware.