Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java in the Browser

jpro.one

Post reply on HN
Print view View original

71–80 of 113 posts

Re: Java in the Browser

#71

Post by jwandborg »

luzifer42 wrote: post #49
specialist wrote: post #4

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

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?

Re: Java in the Browser

#72

Post by floriankirmaier »

StevePerkins wrote: post #17

I 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…

It was the HN traffic. Usually it's very smooth.

Re: Java in the Browser

#73

Post by ihaveajob »

Sakos wrote: post #43
ihaveajob wrote: post #32

Earlier quoted context omitted.

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, an…

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.

Re: Java in the Browser

#74

Post by monkpit »

TacticalCoder wrote: post #16

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?

SodaPlay and SodaConstructor

It’s on GitHub now:

https://github.com/SodaLtd/Sodaplay

Re: Java in the Browser

#77

Post by oaiey »

pjmlp wrote: post #22
oaiey wrote: post #18

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.

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.

Re: Java in the Browser

#80

Post by nextaccountic »

floriankirmaier wrote: post #72
StevePerkins wrote: post #17

I 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…

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

Post reply on HN