6 ms·

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 ou

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.

garganzol 3y ago
I think this is more for "write once, run anywhere side" of compiled Java. But we can achieve the same level of ubiquity with HTML nowadays.
cbsmith 3y ago
>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 (and modern browsers generally do much more work compiling JavaScript). Even if the browser downloaded source code (and why not? --byte code is so much more compact and faster to parse), you wouldn't even notice the compiling down to bytecode step. It's amazing how badly the Java ball got dropped.
- zmmmmm 3y ago
  > 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 just a hard engineering challenge, but as someone who went all in on Java WebStart for deployment at one point and then watched them take it from a highly attractive platform to actively ruining it within a few years, I have to attribute it more to incompetence.
  - cbsmith 3y ago
    I worked at Sun during that time period, and as much as they liked to pretend they were a software business, they were a hardware business whose primary feature was software, which is really, really not the same thing. They never really figured out how to be in the software business if it wasn't in service of selling hardware. Such an amazing fail.
  - Mountain_Skies 3y ago
    I graduated college around that time. Microsoft held an event on campus that took two hours, explaining how great it is to work at Microsoft. A month later Sun came to campus and spent two hours telling us how awful Microsoft is and we shouldn't have anything to do with them. What they didn't do was tell us why we should want to work for Sun. On a larger scale, Sun did seem to lose focus and concentrate too much on getting Microsoft back for making a faster and more stable JVM. What they didn't do was come up with improvements that users wanted. At least not at the rate they should have.
    - cbsmith 3y ago
      Yeah, Sun stock really soared when they started going after Microsoft, but I kept pointing out that the valuation was from the distorted perception where they looked bigger because they were taking on a big foe. It was a sugar high that was obviously going to come crashing down if they weren't focused on delivering a better product.
  - NBJack 3y ago
    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.
    - cbsmith 3y ago
gwbas1c 3y ago
> 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 WASM, and uses a C# templating engine to generate HTML.)
- knome 3y ago
  >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.
  - gwbas1c 3y ago
    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 performance.) Otherwise, every time you navigate to a new page on a non-SPA, the browser still needs to send an IF-CHANGED-SINCE request to the server. As a developer, though, the BIG drawback of SPAs is that they require building much stricter APIs for everything. In a traditional server-side HTML page, you can quickly prototype something where the code that's putting together the HTML has access to privileged data that you can't expose through an API. (IE, if you just need to prototype something, server-side HTML rendering code can directly talk to the database.)
    - ptx 3y ago
      > 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 to enable ManifestStaticFilesStorage: https://docs.djangoproject.com/en/4.2/ref/contrib/staticfiles/#django.contrib.staticfiles.storage.ManifestStaticFilesStorage https://docs.djangoproject.com/en/4.2/ref/contrib/staticfile...
meltedcapacitor 3y ago
That web is no more, sadly. 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...
LudwigNagasena 3y ago
Then we would have a horrible culture of polyfills and transpilers. We would have code that gets shipped unmiminized and with comments that weren’t removed. Eventually, that language will get repurposed for other tasks such as server-side applications or even mobile-applications (imagine shipping a separate runtime for extra language in mobile apps, ugh) due to the growth of the web and the rise in the number of web developers. That sounds like a horrible idea. I hope it never comes to fruition.

garganzol 3y ago

I think this is more for "write once, run anywhere side" of compiled Java. But we can achieve the same level of ubiquity with HTML nowadays.

cbsmith 3y ago

>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 (and modern browsers generally do much more work compiling JavaScript). Even if the browser downloaded source code (and why not? --byte code is so much more compact and faster to parse), you wouldn't even notice the compiling down to bytecode step. It's amazing how badly the Java ball got dropped.

zmmmmm 3y ago
> 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 just a hard engineering challenge, but as someone who went all in on Java WebStart for deployment at one point and then watched them take it from a highly attractive platform to actively ruining it within a few years, I have to attribute it more to incompetence.
- cbsmith 3y ago
  I worked at Sun during that time period, and as much as they liked to pretend they were a software business, they were a hardware business whose primary feature was software, which is really, really not the same thing. They never really figured out how to be in the software business if it wasn't in service of selling hardware. Such an amazing fail.
- Mountain_Skies 3y ago
  I graduated college around that time. Microsoft held an event on campus that took two hours, explaining how great it is to work at Microsoft. A month later Sun came to campus and spent two hours telling us how awful Microsoft is and we shouldn't have anything to do with them. What they didn't do was tell us why we should want to work for Sun. On a larger scale, Sun did seem to lose focus and concentrate too much on getting Microsoft back for making a faster and more stable JVM. What they didn't do was come up with improvements that users wanted. At least not at the rate they should have.
  - cbsmith 3y ago
    Yeah, Sun stock really soared when they started going after Microsoft, but I kept pointing out that the valuation was from the distorted perception where they looked bigger because they were taking on a big foe. It was a sugar high that was obviously going to come crashing down if they weren't focused on delivering a better product.
- NBJack 3y ago
  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.
  - cbsmith 3y ago

gwbas1c 3y ago

> 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 WASM, and uses a C# templating engine to generate HTML.)

knome 3y ago
>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.
- gwbas1c 3y ago
  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 performance.) Otherwise, every time you navigate to a new page on a non-SPA, the browser still needs to send an IF-CHANGED-SINCE request to the server. As a developer, though, the BIG drawback of SPAs is that they require building much stricter APIs for everything. In a traditional server-side HTML page, you can quickly prototype something where the code that's putting together the HTML has access to privileged data that you can't expose through an API. (IE, if you just need to prototype something, server-side HTML rendering code can directly talk to the database.)
  - ptx 3y ago
    > 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 to enable ManifestStaticFilesStorage: https://docs.djangoproject.com/en/4.2/ref/contrib/staticfiles/#django.contrib.staticfiles.storage.ManifestStaticFilesStorage https://docs.djangoproject.com/en/4.2/ref/contrib/staticfile...

meltedcapacitor 3y ago

That web is no more, sadly. 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...

LudwigNagasena 3y ago

Then we would have a horrible culture of polyfills and transpilers. We would have code that gets shipped unmiminized and with comments that weren’t removed. Eventually, that language will get repurposed for other tasks such as server-side applications or even mobile-applications (imagine shipping a separate runtime for extra language in mobile apps, ugh) due to the growth of the web and the rise in the number of web developers. That sounds like a horrible idea. I hope it never comes to fruition.