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

81–90 of 113 posts

Re: Java in the Browser

#81

Post by floriankirmaier »

nextaccountic wrote: post #80
floriankirmaier wrote: post #72

Earlier quoted context omitted.

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…

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.

Re: Java in the Browser

#83

Post by messe »

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.

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.

Re: Java in the Browser

#84

Post by cesarb »

kaba0 wrote: post #51
dhosek wrote: post #44

Earlier quoted context omitted.

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

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

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

Re: Java in the Browser

#85

Post by nextaccountic »

floriankirmaier wrote: post #81
nextaccountic wrote: post #80

Earlier quoted context omitted.

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…

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. (...) 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, is a normal cursor, is an edit cursor, is a clicking hand, etc), and use this by default (perhaps with an option to use the JavaFX defaults if someone wants them).

Re: Java in the Browser

#86

Post by matsemann »

jmiskovic wrote: post #27
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?

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

Re: Java in the Browser

#87

Post by bmacho »

cesarb wrote: post #84
kaba0 wrote: post #51

Earlier quoted context omitted.

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

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

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

Re: Java in the Browser

#89

Post by qsort »

cesarb wrote: post #84
kaba0 wrote: post #51

Earlier quoted context omitted.

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

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

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

Re: Java in the Browser

#90

Post by prionic6 »

twic wrote: post #34
adrianmsmith wrote: post #2

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

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

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.
Post reply on HN