Can't wait to bring Spring, dependency injection and Factories into my browser apps!
CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
141–150 of 179 posts
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#142Can't wait to bring Spring, dependency injection and Factories into my browser apps!
Well I'd go with Swing and SB for the back end. Opens up the possibility of a monorepo though! Also that'd mean web and desktop code would be the same. That's awesome
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#143Earlier quoted context omitted.
DHTML was basically just a buzzword for the first SPA interactions. The first, real uses cases for XMLHttpRequests was sending chunks of HTML over the wire and updating the DOM via JavaScript - so “Dynamic HTML”
I had a book on DHTML in the late 90s long before ajax was a thing. It simply meant scripting the DOM. The MS version did have some fancy transition filters too.
Yep spa weren't even a possibility back then
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#144Earlier quoted context omitted.
Do any of the native AOT implementations outperform the best JITs? I remember trying bcc’s Java compiler years ago, and it was significantly slower than standard JITted Java, but maybe better systems exist.
Considering the time-limit of JIT compilation, I'd say almost certainly yes. AOT can analyze code basically forever (ask C++ compilers), so there's a whole class of time-intensive optimizations that JIT simply cannot do. I'd personally always bet on AOT performance to beat JIT - to convince me otherwise is what I would require evidence for.
Why is there a time limit? Doesn’t Java do multi tiered jitting with background compilation? Should be able to take as much time as needed in a background thread while code is executing in less optimized tier.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#145Earlier quoted context omitted.
I had a book on DHTML in the late 90s long before ajax was a thing. It simply meant scripting the DOM. The MS version did have some fancy transition filters too.
Yep spa weren't even a possibility back then
They were. Microsoft Outlook Web Access was exactly that, it's why Microsoft invented XHR. Google Maps later got a lot of credit for kicking off "Ajax", but OWA laid the groundwork.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#146Earlier quoted context omitted.
>If only we could get a new version of Java for the browser. Something more of a scripting language that is not compiled but interpreted. Could probably knock out a proof of concept in a week, might call it Javascript or something... I get the joke. It is sad though how Java didn't end up being the ubiquitous runtime for browsers... It started off so promising... Compiling source to byte code is really fast in Java (…
> It's amazing how badly the Java ball got dropped. It still boggles my mind that Sun Microsystems fully owned the tech for the only ubiquitous browser plugin for full fledged applications with > 95% deployment and somehow screwed it up and went out of business a few years later. Despite all their engineering prowess it seems like they just couldn't make Java work seamlessly and smoothly. I'd like to think it was jus…
I recall those days. To be fair, it was asking a lot of the hardware at the time to run both a browser and Java itself. I also recall the JVM had painfully slow start times that weren't rectified for years. These were also largely the 1.x versions of the language to boot.
On top of it all, Java integration was really just an excuse to plop a grossly out of place app UI in the browser window. Would have been much better if we could have had deeper behind the scene integration with the DOM layer.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#147If only we could get a new version of Java for the browser. Something more of a scripting language that is not compiled but interpreted. Could probably knock out a proof of concept in a week, might call it Javascript or something... In all seriousness, anything that spits out canvas for a simple textbox is completely misguided about what the web is.
> In all seriousness, anything that spits out canvas for a simple textbox is completely misguided about what the web is. I suspect the goal is a way to bring Java desktop applications into the browser without rewriting the application from scratch. Personally, as a fan of Blazor, I thought this was going to be a Java-based analog of Blazor; or a modernized replacement for GWT. (One flavor of Blazor compiles C# to WAS…
I think the real killer of Java in the browser was Flash. It was still terrible, but Flash was way more accessible.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#148Earlier quoted context omitted.
Yep spa weren't even a possibility back then
They were. Microsoft Outlook Web Access was exactly that, it's why Microsoft invented XHR. Google Maps later got a lot of credit for kicking off "Ajax", but OWA laid the groundwork.
While we’re narrowing actuallys, it was Gmail that got the credit. And somewhat relevant to the article, I believe that was Google’s first major showcase of the Java-based GWT.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#149Earlier quoted context omitted.
I think you’re a little misconceived, WebAssembly runs entirely in the client and have no bindings to the server, as far as the server is concerned such apps may as well be static HTML. This is Blazor WebAssembly. It will be just as trivial to run such on Mac, Linux or Windows server or any other plain web servers. TeaVM seems to be the same except it compiles Java to JavaScript which means has fast startup times. We…
Ah, sure, for whatever WASM variant you're referring to. Whichever form of blazor I use pretty obviously makes calls back to the server to interact with client state on a per-event basis. If the backend has to restart, the clients all lose connection and die. I won't pretend to be an expert in the framework, or even C#. I had avoided both until recently, and this introduction hasn't made me particularly fond of eithe…
Server-side or WASM is an option when you create a Blazor project in Visual Studio.
You can write libraries and either approach can use the same library.
Server-side Blazor keeps a websocket open to send messages back and forth. If you can tolerate the latency, it allows your UI code to be able to handle data that needs to remain secret on the server.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#150Earlier quoted context omitted.
Direct ByteBuffers are used to interop with the underlying platform, particularly for the purpose of IO. I could be wrong, but I fail to see how 'WASM memory direct Buffers' will work in that scenario.
What IO devices would you even have access to from a browser sandbox?
What app is going to function without IO?