111–120 of 179 posts
Web apps are bad enough as it is. But downloading massive jar files and execute them at a major performance penalty? No thanks. I will actively avoid websites that use heavyweight tech like this.
Earlier quoted context omitted.
>as a fan of Blazor I really dislike this stuff. It's easy-ish to write, but it's like the authors of it hate everything about the web. SPAs do a lot of annoying stuff, and blazor encourages all of it. I really hope things swing back away from this grotesque tight binding between the server and the client.
One of the nice things about SPAs is that they allow navigation without the latency needed to re-load all assets. You can get there the old-fashioned way if all your assets are cached in the browser with long timeouts; but that implies that you're doing something like putting hashes in the asset URL and hashing them as part of your build process. (This, is why loading JavaScript and CSS from CDNs helps with performan…
But that solves the problem, doesn't it? And it seems a lot simpler than implementing an SPA.
Django has this feature built-in. You just have to enable ManifestStaticFilesStorage: https://docs.djangoproject.com/en/4.2/ref/contrib/staticfile...
Who would want a lazily ported Java desktop UI in the browser? Web apps are bad enough as it is. But downloading massive jar files and execute them at a major performance penalty? No thanks. I will actively avoid websites that use heavyweight tech like this.
Earlier quoted context omitted.
anyone remember dhtml, which allowed adding powerpoint-like transitions to hyperlinks?
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”
Earlier quoted context omitted.
You could have built DHTML/AJAX though just powered by Java code. SPAs could have been built then. Edit: Repliers live in an alternate reality where good applets were made and HTML didn't win.
The idiomatic and library-supported way to make a Java web application was to make a richer interface using Java itself. Why reinvent the wheel to make a HTML interface, only to incur a performance penalty? EDIT: Java applets failed because of Java's poor integration and (at the time) performance and sandbox security. That had little to do with the DOM interface. Using that would have made things worse .
Who would want a lazily ported Java desktop UI in the browser? Web apps are bad enough as it is. But downloading massive jar files and execute them at a major performance penalty? No thanks. I will actively avoid websites that use heavyweight tech like this.
This lets you run an existing Java web applet that you already have, from way back when those were supported, in a modern browser with real sandboxing. Even if you don't have the original source. It's for legacy stuff, not new projects.
With this and Ruffle, we will soon return to the days of Internet Explorer 6 but with 4k monitors! All we need now is to run ActiveX. I think BottledWine can run Windows executables in the browser, how hard would it be to simulate the ActiveX bindings?
Earlier quoted context omitted.
One of the nice things about SPAs is that they allow navigation without the latency needed to re-load all assets. You can get there the old-fashioned way if all your assets are cached in the browser with long timeouts; but that implies that you're doing something like putting hashes in the asset URL and hashing them as part of your build process. (This, is why loading JavaScript and CSS from CDNs helps with performan…
> One of the nice things about SPAs is that they allow navigation without the latency needed to re-load all assets. [...] You can get there the old-fashioned way if [...] you're doing something like putting hashes in the asset URL and hashing them as part of your build process. But that solves the problem, doesn't it? And it seems a lot simpler than implementing an SPA. Django has this feature built-in. You just have…
Depends on your design goals.
BTW, I'm not pro/against SPAs. It's just a tool, and like all tools, they have their advantages and disadvantages.
In general, the fact that you can update the page without a server-side round trip is a major advantage. Granted, you can also do that with server-side rendering; but then your rendering logic is defined in two places.
Earlier quoted context omitted.
I did, as I said, those are likely 'Virtual WASM Direct Buffers' which are not really 'Direct (Memory) Buffers' - and therefore, not really what they are meant for, though it's impossible to tell. Given how WASM works, I'm pretty sure (but not certain) that anything that uses nio to interface to anything else is not going to work, other than maybe things which are 'fully contained'. The 'test' would be to dynamically…
So your complaint about a JVM environment in the browser is that it can't load DLLs from your Operating System? Anyway, let's assume you're talking about a DLL or native lib it gets from the same origin. That also should work totally fine. Because CherpJ implements a virtual file system. I suspect even JNI will work fine. Anyway, doing stuff like that on a browser is way out of the norm, so it seems to me you're look…
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... In all seriousness, anything that spits out canvas for a simple textbox is completely misguided about what the web is.
It's just a question of time before the containerized crowd discover that the exact version of Chrome they test their website with can be compiled to the WASM+canvas platform, bundled with the website, and solve all browser issues forever...