[HN Gopher] Java in the Browser
___________________________________________________________________
Java in the Browser
Author : krisgenre
Score : 92 points
Date : 2022-08-23 11:12 UTC (11 hours ago)
(HTM) web link (www.jpro.one)
(TXT) w3m dump (www.jpro.one)
| cryptonector wrote:
| 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).
| samwillis wrote:
| Site appears to be down, there is an archive here from June 2020:
|
| https://archive.ph/mJDAT
|
| Newer archive on IA from March this year doesn't load anything:
|
| https://web.archive.org/web/20220316200857/https://jpro.one/
|
| However has source code including: <jpro-app
| loader="none" href="/app/default" fxcontextmenu="false"
| fullscreen="true" nativescrolling="true" fxheight="true"
| snapshot="auto" userselect="true"></jpro-app>
|
| So assuming there was a newer site that had some sort of embedded
| Java thing...
|
| By the sounds of it, it was a demo where the website ran as java
| on the server, rendering and pushing to the browser in real time?
| Guessing it couldn't handle HN traffic...
| Koshkin wrote:
| They should have built it with jpro.
| qsort wrote:
| Before it went down I noticed it was sending data through a
| socket, rendering everything at the very end.
|
| So basically a worse Blazor.
| paultopia wrote:
| Proposed subtitle: "the original sin"
| jeffreportmill1 wrote:
| Well this isn't helpful for those of us that care about Java in
| the browser. In any case, JPro is really more "Java projected in
| the browser" (or like twitch/remote-desktop). It's a shortcut
| with significant drawbacks. I'm more a fan of TeaVM, CheerpJ,
| J2CL and JSweet.
|
| https://reportmill.com/snaptea/
| adrianmsmith wrote:
| 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 useful loading indicators, e.g.
| click a link, nothing happens, or go to the doc section and
| navigate and lots of empty screens (presumably while the content
| is loading). No browser loading indicator, nor spinner in the
| content.
| qsort wrote:
| > I have looked around the website and I really have no idea
| what this is.
|
| Judging from the browser developer tools, something that (very
| slowly) sends the client stuff via a socket.
| JLCarveth wrote:
| The calendar demo I tried was quite slow as well.
| twic wrote:
| 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 websocket to a JavaScript driver running in a browser".
| It's sort of an ingenious idea.
|
| I assume the target market here is companies which already have
| custom desktop applications written with JavaFX, and want to
| make them available remotely. This is competing with remote
| desktop solutions, not React, wasm, etc.
| prionic6 wrote:
| 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.
| rch wrote:
| I used a graph analysis app ~2011 that communicated with the
| server over zmq and rendered via lwjgl. At the time, and
| perhaps even now, it wouldn't have been reasonable to expect
| adequate performance if all the results of interactive
| manipulation were executed on the client hardware. Which was
| unfortunate for me since I'd also spent a few weeks writing
| code to visualize the same data, and it was definitely a
| 'works on my machine' application.
|
| I've considered revisiting the problem, but probably not
| following the implementation discussed here.
| TeaVMFan wrote:
| 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/
| exabrial wrote:
| Nice username :)
|
| It looks like TeaVm is still setting steady releases? It's
| certainly bucking industry trends, which concerns me about
| maintenance.
| pestatije wrote:
| See also: Migrating Browser-Based Java Applets to IcedTea-Web
| Using JNLP
|
| https://news.ycombinator.com/item?id=32565828
| dukoid wrote:
| 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?
| [deleted]
| TacticalCoder wrote:
| 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?
| robin_reala wrote:
| The first Java applets that stood out for me were Anfy Team's.
| My images looked supercool with a rippling reflection
| underneath them!
| ihaveajob wrote:
| 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, and PHP
| became part of the web-app "standard" (the LAMP acronym was
| started to be used around then). But I never learned PHP.
| Sakos wrote:
| On the other hand, Java has established itself as one of the
| most common server-side languages for building websites.
| ihaveajob wrote:
| 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.
| digitallyfree wrote:
| Honestly with all the Electron-based desktop apps out there
| people are still thinking that way. Just with a different
| language and framework.
| thyrsus wrote:
| I remember when nytimes.com started using java like this, and
| something like 8 out of 10 failed to function in Firefox on
| Linux.
| CmdrKrool wrote:
| I remember! Perhaps that is Soda Constructor:
|
| https://en.wikipedia.org/wiki/Soda_Constructor
| http://maciejmatyka.blogspot.com/2018/02/soda-constructor-re...
| [deleted]
| jmiskovic wrote:
| 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
| matsemann wrote:
| 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 ).
| rzzzt wrote:
| There is a paper on two-legged animals learning different
| methods of walking: https://youtu.be/pgaEE27nsQw (or
| https://youtu.be/FahK9srJq10 for the slightly better known
| "music video" version).
|
| Soda Constructor's wikipedia page also links to a 3D applet
| named "Springs World 3D", I was playing with that one back
| in the day.
| monkpit wrote:
| SodaPlay and SodaConstructor
|
| It's on GitHub now:
|
| https://github.com/SodaLtd/Sodaplay
| StevePerkins wrote:
| 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.
| floriankirmaier wrote:
| It was the HN traffic. Usually it's very smooth.
| messe wrote:
| 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.
| nextaccountic wrote:
| 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
| floriankirmaier wrote:
| 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.
| nextaccountic wrote:
| 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).
| dixie_land wrote:
| 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!
| solarkraft wrote:
| That's actually an interesting way to encourage efficient
| resource usage.
| voidwtf wrote:
| Efficient resource usage or Java. You can only choose one :p
| [deleted]
| gabereiser wrote:
| So I guess we've come full circle now? Java was the first to run
| in the browser (via applets).
| oaiey wrote:
| 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?
| pjmlp wrote:
| Java solutions for JS and WebAssembly as targets are older than
| Blazor actually, see TeaVM and CheerpJ, and then there was GWT
| alongside Vaadin.
| kaba0 wrote:
| You left out probably the most widely used one, Google's j2cl
| compiler (java->js), which is used quite extensively in many
| google products for shared business logic. It is the
| spiritual inheritor of GWT.
| pjmlp wrote:
| Ah, wasn't aware of it.
| oaiey wrote:
| 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.
| opvasger wrote:
| it's sort of funny - I expect Java in the browser not to work
| well (as it didn't, historically)... And sure enough - the site
| returns a 502 error :P
| moffkalast wrote:
| A self fulfilling prophecy.
| butz wrote:
| Time to update "3 Billion Devices Run Java" message.
| specialist wrote:
| 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(tm). Definitely
| the best effort thus far. (I haven 't used SwiftUI yet.)
| luzifer42 wrote:
| 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
| kevincox wrote:
| 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.
| jwandborg wrote:
| 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?
| floriankirmaier wrote:
| 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.
| prionic6 wrote:
| Is it like Eclipse RAP, just for Java FX? How does it compare
| to Gluon?
| invalidname wrote:
| 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.
| pjmlp wrote:
| JPro can also target WebAssembly.
| ziftface wrote:
| What's so bad about server rendering
| cryptonector wrote:
| - higher latency - uses more server resources per-
| client, therefore it's more expensive - harder
| to do SPA-like apps
| mirko22 wrote:
| - waiting for javascript to load is not considered latency
| but kills user experience
|
| - depends how you do it
|
| - not all apps need to be SPA but also you can render
| fragments if you really want
| invalidname wrote:
| Well.. I come from the age of dumb terminals so trauma. We
| have powerful machines today. Using them like a dumb terminal
| rubs me the wrong way.
| ziftface wrote:
| I've recently come to appreciate server rendering for its
| simplicity, at least for the tasks it is suited for. But I
| know what you mean. As a user, it's better to have local
| apps doing the real work.
| pjmlp wrote:
| Welcome to cloud computing.
| invalidname wrote:
| Serverless is the new timeshare.
| pjmlp wrote:
| The new CGI actually.
| invalidname wrote:
| Your code is running on their hardware. But I get your
| point...
| bschwindHN wrote:
| This is very advanced satire.
| stall84 wrote:
| I busted out laughing
| nice_byte wrote:
| I tried the demo website - it takes seconds to respond to clicks,
| even on an M1 mac. I'd rather set myself on fire than use
| software built using this technology.
| manholio wrote:
| 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
| yuri91 wrote:
| Here you go: https://chrome.google.com/webstore/detail/cheerpj-
| applet-run...
|
| CheerpJ does exactly that: it ships a full JVM implementation
| (including Swing/AWT, Threads, ...) that runs in JS/Wasm inside
| your browser. The Applet Runner extension detects applets in
| the page and runs them through CheerpJ.
|
| The example that you list seems to work.
| manholio wrote:
| I know about the extensions, it's exactly how I was able to
| run that specific applet, but that's a high friction
| experience for the user. If the applet does not run it's very
| unlikely I will install an extension (or search for a Firefox
| alternative) unless I'm very motivated.
|
| I'm thinking more like a line or two you can add to your
| pages hosting applets, and it would enable any modern browser
| to use it. Minimal friction for the webmaster, zero friction
| for users.
| yuri91 wrote:
| That is also possible:
| https://docs.leaningtech.com/cheerpj/Getting-Started
|
| See "Converting an applet"
| slowmotiony wrote:
| 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.
| mirko22 wrote:
| See now, I think COBOL in the browser would be a winner!
| pavlov wrote:
| Java in the Browser, February 1996 edition:
|
| http://www.antipope.org/charlie/old/journo/netscape.html
| solardev wrote:
| Totally forgot that Netscape had email and a usenet client
| built-in! What nostalgia.
|
| It's funny to me that the original use case of Java -- write-
| once, run-anywhere -- was eventually overtaken by Javascript, a
| language that had nothing at all to do with it and just wanted
| to steal its name for marketing. Well, guess it worked? lol
| quickthrower2 wrote:
| I made an applet in '99. As good as a React app these days.
| mondainx wrote:
| WASM really is the way to go for this kind of thing IMHO; I love
| me some Java and have for decades, but Applets were painful,
| especially when hooking in native code. HN seems to have killed
| the demo, I'll have to remember to come back later when the
| hoopla dies down.
| elwell wrote:
| "Your scientists were so preoccupied with whether or not they
| could, they didn't stop to think if they should." - Dr. Ian
| Malcolm
| Joyfield wrote:
| Gb != GB.
| stall84 wrote:
| wait a minute .. LOL!!!
| robertwt7 wrote:
| there's a price for this??
|
| I'm not sure what this is by looking at their homepage, is this
| similar to WASM?
|
| also who would pay to develop something for the web anymore?
| pjmlp wrote:
| Enterprises that aren't going to rewrite from scratch and
| rather look forward to solutions to keep existing code running.
|
| The same reason IBM and Unisys keep their mainframes and
| microcomputers running with updated hardware.
| peterkelly wrote:
| I thought we tried this already...
| [deleted]
| bmacho wrote:
| And it was way better than anything before and after, but the
| current politics the given time killed it (which may or may not
| be relevant anymore).
| dhosek wrote:
| 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
| challenging to run now (it also has Maple and Mathematica
| versions of the explorations).
| kaba0 wrote:
| > 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 itself
| could have easily been used as the web-native language if
| it is made to interact with the DOM natively.
| cesarb wrote:
| > 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.
| qsort wrote:
| > 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.
| bmacho wrote:
| > 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.
| ksherlock wrote:
| There was also Browser in the Java - HotJava, Sun's circa 1996
| web browser written in Java.
|
| https://en.wikipedia.org/wiki/HotJava
| Koshkin wrote:
| Looks like it's a custom webserver.
___________________________________________________________________
(page generated 2022-08-23 23:01 UTC)