Live data from Hacker News

Java in the Browser

jpro.one

61–70 of 113 posts

Re: Java in the Browser

#65

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™. Defini…

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

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.

Re: Java in the Browser

#66

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: https://frequal.com/wordii/

See also: Migrating Browser-Based Java Applets to IcedTea-Web Using JNLP https://news.ycombinator.com/item?id=32565828

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?

Re: Java in the Browser

#67
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).

Re: Java in the Browser

#68

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

  - higher latency
  - uses more server resources per-client,
    therefore it's more expensive
  - harder to do SPA-like apps

Re: Java in the Browser

#69

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

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!

Re: Java in the Browser

#70
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.

Post reply on HN