4 ms·

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 co

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

solarkraft 4y ago
That's actually an interesting way to encourage efficient resource usage.
- voidwtf 4y ago
  Efficient resource usage or Java. You can only choose one :p
  - deleted 4y ago
    [deleted]
dixie_land 4y ago
maybe that's the selling point? I opened up one demo and despite it is indeed running the browser, it definitely _feels_ like running an AWT widget in ActiveX! oh the memories!
floriankirmaier 4y ago
It was the HN traffic. Usually it's very smooth.
- nextaccountic 4y ago
  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 https://www.jfx-central.com/home (the site with custom scrollbar) but not in https://www.jpro.one/ 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
  - floriankirmaier 4y ago
    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/ https://www.jpro.one/ uses the browser scrolling. https://www.jfx-central.com/ 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.

solarkraft 4y ago

That's actually an interesting way to encourage efficient resource usage.

voidwtf 4y ago
Efficient resource usage or Java. You can only choose one :p
- deleted 4y ago
  [deleted]

dixie_land 4y ago

maybe that's the selling point? I opened up one demo and despite it is indeed running the browser, it definitely _feels_ like running an AWT widget in ActiveX! oh the memories!

floriankirmaier 4y ago

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

nextaccountic 4y ago
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 https://www.jfx-central.com/home (the site with custom scrollbar) but not in https://www.jpro.one/ 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
- floriankirmaier 4y ago
  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/ https://www.jpro.one/ uses the browser scrolling. https://www.jfx-central.com/ 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.