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.