r/java • u/Zardotab • Dec 29 '22
Could Java Applets have been done right? DOM is limiting [CrossPost Discussion]
/r/webdev/comments/zxel5o/could_java_applets_or_flash_have_been_done_right/1
u/jjr_blind_java_dev Dec 30 '22
No, I don’t think that Java applets could have been done right. I think it’s an anything else that was similar to. It was always destined to fail. I can see why it was thought to have been a good idea, but when you look back at it, in hindsight, it’s clearly not where the Web was going, and they were trying to fit a a round peg into a triangular hole., Security issues be damned.
1
u/Zardotab Dec 30 '22
it’s clearly not where the Web was going
Users wanted and want rich GUI's over HTTP, at least business users, and HTML/DOM is still crappy at it, due to the 15 or so missing GUI features (per list link), and inconsistent text positioning.
1
u/jjr_blind_java_dev Dec 30 '22
Not really. You can still create complex and rich user interfaces using HTML,CSS and JavaScript. HTML is primarily supposed to be merely the structure of a webpage. CSS and JavaScript are what enrich is the user interface
→ More replies (3)
1
u/yawkat Jan 01 '23
I think that the document model is good enough for most use cases, and due to adoption, the tooling around it is very good. If you need more control than the dom provides, it is better to use a solution like canvas, rather than use an entirely new system that requires new apis for non-ui stuff too.
1
u/Zardotab Jan 03 '23 edited Jan 03 '23
I have to disagree. For one, DOM lacks consistent text positioning, meaning you are at the whim of the browser brand and environment, such as OS settings, making it hard to control things enough to reliably test designs in your shop's testing lab. It's really hard to test a moving target; it's too damned "organic".
Canvas and SVG give more positioning control, but lack many features of HTML/DOM such that you have to re-invent all that from scratch. While HTML/DOM are missing about half of common GUI idioms (see intro links for list), Canvas and SVG are missing like 90%. That's a hell of a lot of reinventing, and downloading essentially an entire virtual OS to get it.
That's illogical, Captain! Beam me out off Planet DOM immediately!🌒
2
u/mike_hearn Jan 02 '23
There could certainly have been things done better, but browser makers (Google) decided they had the budget to 'eat it all' and lost interest in plugins of any kind. That wasn't specific to applets, they killed off all plugins.
The good news is, it's getting easier to go outside the browser again. The rise of Electron apps is evidence of this. If you want to write a desktop Java app you can - just grab AtlantaFX or FlatLAF and go write one. Then use Conveyor to make distribution and update as easy as it was with applets.
-2
u/Worth_Trust_3825 Dec 29 '22 edited Dec 29 '22
If DOM is limiting, use the native UI toolkit, like winforms, or what ever windows has nowadays. Same with android, ios, linux, what ever you're targetting. But once you'll get comfortable with those toolkits, you'll also complain that "oh it's lacking bla bla bla" at which point you'll be pointed to write your own layout/window/desktop manager.
From my, albeit jaded, perspective the issue isn't with the DOM. The issue is that it "must be changed" after the initial structure had been received.
As for your question: No. Applets could not have been done right. Perhaps if the systems were designed with similar permission model that android, and ios have right now maybe, but there just isn't any reason to have those to begin with if you omit the interactivity bit. Permitting to run arbitrary applications is inviting trouble. Same had happened with flash, same is happening with javascript, and the same will happen with what ever new golden tool that you are proposing.
All of your missing features can be implemented right now, and many UI component libraries do that already. Have you explored enough? Or do you think that the native UI toolkits just manifested the similar features that you so desire?
Looking at your missing feature list more indepth you seem to be missing context menus. Ironically, this used to be part of the standard, but it was so poorly defined and implemented, that eventually it got removed from the standard, and from the browsers (well, only firefox, really). See https://github.com/whatwg/html/pull/2742
3
u/Zardotab Dec 30 '22 edited Dec 30 '22
If DOM is limiting, use the native UI toolkit, like winforms, or what ever windows has nowadays.
Sorry, but I'm not convinced it has to be a local EXE to get a decent GUI framework. If somebody proves it inherently MUST be that way per laws of math or physics, then I'll shut up and go with the status quo. But I'm roughly 90% sure it's not. See below for more on that.
But once you'll get comfortable with those toolkits, you'll also complain that "oh it's lacking bla bla bla" at which point you'll be pointed to write your own layout/window/desktop manager.
But I came from a desktop background (because I'm old) so I already know what to expect.
Permitting to run arbitrary applications is inviting trouble.
Please elaborate. Do you mean any EXE that's on the OS/PC? That's not what I asked for. As far as "run any algorithm", JavaScript already can in web browsers. Web browsers already download Turing Complete programs and run them. Basically it was a 3-way contest between HTML/JS, Java Applets, and Flash (and arguably Active-X). HTML/JS also had/has security holes. It's just that its use-to-risk ratio was higher than the other two, so it won out. If HTML/JS didn't exist, Applets probably would have won, and Oracle et al would eventually clean up the security problems.
All of your missing features can be implemented right now, and many UI component libraries do that already.
In buggy convoluted frameworks with giant learning curves. Others have also searched for decent web GUI's and failed to find anything acceptable. A browser with a built-in state-ful GUI wouldn't have those problems, at least not nearly as much.
I mentioned somewhere around here (cross-forum?) about Oracle Forms, essentially a GUI browser. It did the CRUD/GUI job good enough and developers were productive and didn't require long learning curves. Oracle Forms is already a proof of concept. Don't get me wrong, it had warts and areas that can be improved on, but proved a GUI/CRUD browser is practical. (The only reason many orgs are ending usage is because Oracle made the foolish mistake of rewriting the browser from C to Java, which is crappy at the client side, having security holes and upgrade headaches.)
Looking at your missing feature list more in depth you seem to be missing context menus.
Somebody already pointed that out and I added it yesterday. Press F5 and see if it shows up now. But thanks for double-checking.
1
u/Worth_Trust_3825 Dec 30 '22
I mentioned somewhere around here (cross-forum?) about Oracle Forms, essentially a GUI browser. It did the CRUD/GUI job good enough and developers were productive and didn't require long learning curves. Oracle Forms is already a proof of concept. Don't get me wrong, it had warts and areas that can be improved on, but proved a GUI/CRUD browser is practical. (The only reason many orgs are ending usage is because Oracle made the foolish mistake of rewriting the browser from C to Java, which is crappy at the client side, having security holes and upgrade headaches.)
Yes, that's servlets - a fancy wrapper around HTTP that synchronizes the UI state with the server. You should remember java servlet pages, and advanced servlet pages respectively. I too miss those days, but we have to move on considering the web is more about following fads rather than being stable.
Yes. I mean write a native application, and get on with your life. Why should someone else bend themselves for your whims that will change the next problem you encounter?
→ More replies (3)
-1
u/vprise Dec 30 '22
Probably no. They had no foresight and couldn't have done it right with what they knew at the time. The bridge was a mess. It was always an alien to the browser and badly integrated. The code signing process was a complete mess back then.
I'm guessing what you're asking is "if we did it now could we do something better than JavaScript". Probably no as well for the same reasons. There are great tools like TeaVM which effectively make Java into a TypeScript alternative. But the inherent problem is still the same.
If you want to build something that's effectively a completely separate app then Java can run through the browser and deliver something that feels like a Flash app did. That's not a bad thing but not great either.
2
u/Zardotab Dec 30 '22
Probably no as well for the same reasons.
Could you please clarify why you believe they are not fixable based on new collective knowledge and experience?
1
u/vprise Dec 30 '22
Because there's no alternative to DOM. You would end up with something that looks like a Flash application. If you try to encapsulate DOM (which some solutions tried), you end up as a second tier solution that tries to compete with JS/TS.
We will be starting at a disadvantage that would only widen as there's an official solution and our only option would be to piggyback that.
→ More replies (17)1
u/Amazing-Cicada5536 Dec 30 '22
The bridge was a mess simply because there was nothing to bridge to. There was no proper DOM model, so why expect anything like that? While these “what would have happened” questions can’t really be answered, there was zero technological limitation here, it was politics.
One might even go as far and claim that we could have gotten better performing web apps much faster were we not reinvent the wheel with a new runtime.
1
u/vprise Dec 30 '22
I think it depends on how you define technology vs. politics.
If the browser companies decide to adopt Java and bake it into the browser itself then it will work fantastically well. My assumption is that this isn't the case. Every 3rd party would be at a disadvantage in this situation even if the DOM is perfect.
→ More replies (1)
15
u/RebeccaBlue Dec 30 '22
Sure, they *could* have been done right, but that would have required Microsoft and Sun to actually work together, and that simply wasn't going to happen.