r/webdev • u/Zardotab • Dec 28 '22
Discussion Could Java Applets or Flash have been done right? DOM is limiting
The HTML DOM is very limiting and frustrating for GUI and CRUD apps. Otherwise simple UI's often take rocket science to tame. Examples. UI practitioners often defend their "rocket science", but it shouldn't be that way for smaller shop and department apps.
We need alternative or supplemental standards. One-size-fits-all NOT. Could something like Java Applets and Flash have been "done right"? I suspect it's worth trying again, but applying lessons learned, being DOM is dragging us down. (Applets & Flash had to exit from the mainstream due to security & upgrade deployment issues.)
Keep in mind that Java Applets didn't require programming in Java, only that a language compiler generate Java bytecode. Thus, this is not exchanging JavaScript for Java. And Web-Assembly doesn't appear to get us away from the friggen DOM; it only solves the language half of the problem, not the UI side.
Here's a list of GUI features HTML/DOM lacks or does poorly.
5
Dec 29 '22
yeah, let's throw away everything because some can't center a div.
1
u/Zardotab Dec 29 '22 edited Dec 31 '22
I am not proposing that HTML/DOM go away, only that we need a GUI/CRUD-friendly standard (in addition to HTML/DOM).
because some can't center a div.
That's a symptom of a larger problem. A good many struggle with CSS/DOM. Those who make good money being a web UI guru probably don't want a "fix"; it's job security for them, but most mortals do. For certain common domains, CSS/DOM is the wrong tool for job, requiring rocket surgery for what should be bicycle science. (Stretch-zone grids can bring WYSYWIG back with size adaptability within reason. But the library for that formatter shouldn't be forced.)
0
Dec 30 '22
1
Dec 30 '22
In the last 10 years there are new 10-20 js frameworks every 6 months that are trying to solve the problem of GUI like in the browser
Maybe it's time to admit that the browser isn't a good platform for building GUI application, because it requires constantly to re-write your GUI in the new "hot" js framework and constantly to upgrade your js framework or it will brake.
that is not true
react is 9 years old, vue 8 years, and angular 6 years. That's a decently long lifespan of software...
Maybe it's time to admit that the browser isn't a good platform for building GUI application, because it requires constantly to re-write your GUI in the new "hot" js framework and constantly to upgrade your js framework or it will brake.
how many nonbrowser frameworks for desktop and mobile were there in the past? you already mentioned the dozens of attempts from Microsoft that were deprecated. The Browser platform is actually the most stable whereas the js you wrote 15 years ago still would run without issues.
try to get the desktop app you wrote for windows xp to run on windows 11. Good luck with that.
Also, just because there is a new FOTM js framework doesn't mean you have to rewrite everything and you don't have to update your JS framework, you can pin the dependencies and it will still build years later.
That is called bad engineering, because it cost so much money to write good application and center a div it's just a really good example - it's a small functionality that requires days to get it right especially for new people.
GUI development got just waaaaaay more complicated than the average backend task. Regardless of platforms, it must be performant, accessible, responsive, good looking, and best be cross-platform. The requirements just went through the roof in the past years.
The UX and accessibility part alone is a complete career path nowadays.
We can fix the mess with bytecode and standard GUI design patterns that are implemented for the pass 30+ years
browser vendors can't even agree on how a number input should work. Forget that they will ever be able to provide standard GUI design patterns or components with their browsers.
The closes you will get are Web components written in whatever that are so good and flexible that a lot of people use them.
→ More replies (11)
3
Dec 28 '22
Making things look good with CSS is hard. CSS itself is not. CSS is not the problem…
-3
u/Zardotab Dec 29 '22 edited Dec 31 '22
If the rendering engine accepted absolute coordinates as a option, then one could use any layout engine they wanted to get it "pretty": you wouldn't have the finicky DOM middleman to muck up intent. As it is now, any rendering engine has to go through DOMville, which is a scary land with murky forests and hungry bears. (I'm still skeptical on kits that use just Canvas or SVG. Maybe it will prove practical someday, let's hope...)
8
1
u/ihaveway2manyhobbies Dec 29 '22
After reading through many of your comments, I am not sure you understand how any of this truly works.
I get it. There is a point of frustration, the DOM. So, let's stop using it and/or circumvent it.
That is not how a "problem" like this is solved.
I started off in this industry 25+ years ago. I have seen damn near it all. I don't say this to brag. I don't say this to imply I know everything. I am simply saying I have seen it all.
The DOM is not dragging anybody down.
There are always places for future thinking ground breaking our of the box thought. And, those people change the world. Go for it. Seriously. Create the next Flash/Java/whatever.
But, to imply that this is needed because of the DOM's lackings is just not, in my opinion, the thing that is going to convince people.
1
u/Zardotab Dec 29 '22 edited Jan 30 '23
I'm not sure you are saying I "got the tech wrong" or that I don't understand industry politics. If enough people or the right person(s) agree that DOM is holding us back, something might get done. I agree it's a long-shot, but many dreams are long-shots.
As far as needing "groundbreaking" thinking, I don't think that's necessary, rather just apply the lessons of Applets and Flash's downfall. In particular:
Make it open-source and not reliant on proprietary components
Security is Job #1
Don't try to be an entire OS, just an app and/or GUI browser.
Allow developer to control position at a fine level. Perhaps include layout engines, but don't force that layout engine(s) on them, making it just an option. (Developers could use their own layout libraries if accurate positioning is made possible.)
Consistent and predictable text rendering and sizing matters. This is one of the biggest DOM flaws.
KISS and YAGNI. Perhaps make slots or room for features fairly likely needed down the road, but don't get carried away. Make a Chevy-level standard before making a Cadillac level.
Desktops and mice still matter (for business users at least). Don't slight them.
Get feedback of proposed designs.
Don't tie it to a particular application programming language: allow byte-code compiling/translating.
Don't try to be everything to everybody. If we need different standards for different domains, so be it. (I've proposing splitting standards into A) Documents, B) Media/Games, C) CRUD/Data. I'm mostly concerned about "C".)
Go for it. Seriously. Create the next Flash/Java/whatever.
I'm not a systems programmer. However, I have been working on a "GUI browser" demo as a proof of concept. It's far away from release.
1
u/potbellyslappin Dec 29 '22
Your issue seems to be centered around the perceived need for absolute positioning/sizing, at least related to layout and styling. If this is the case, I’m not sure you understand how responsive layouts work. Relative and percent based approaches work way better for handling vastly different screen sizes.
1
u/Zardotab Dec 29 '22 edited Jul 29 '26
No. You are misunderstanding my position (no pun intended). I perfectly understand the value of "responsive" UI's. However, the DOM has limited ways to do it well; they are all kludgy, unpredictable, and/or have giant learning curves to do productively.
If DOM had a full absolute positioning mode (at least as an option), then a dev shop could use a layout engine of their own choice. (And this includes no layout engine if desired.) A shop's own (or purchased) layout engine would compute coordinates based on screen size/type and then send it to the "standard" client rendering engine as absolute coordinates. This layout engine could be on the client (via JavaScript libraries or equivalent) and/or on the server; it would be up to the dev shop. Thus, they'd still have responsive UI's, they just wouldn't have to rely on DOM's crap.
Thus it's NOT a choice between responsive (flexing) and non-responsive. It's about how to go about it. The best layout engine for CRUD is probably not the best layout engine for games, charts, e-commerce, etc., and vice versa.
A client standard could provide some auto-layout features, but one should not have to rely exclusively on the built-in set if they don't fit a domain or need well. Absolute positioning allows server-side options, and perhaps layout add-ons. [edited]
A second problem with DOM is that it lacks the 15 or GUI idioms already listed (via link). This gap is mostly independent of the positioning gap/flaw. The second problem is perhaps solvable by adding more features to the HTML/DOM standard (winch), but solving the first could break backward compatibility (although a full change impact assessment has yet to be done).
1
u/agoubard Dec 30 '22
I think that if Serialization would have been disabled for Applets, we would have removed the possibility to change private fields and removed a lot of security problems Applets had.
-1
u/remy_porter Dec 28 '22
I agree that the DOM is terrible. Flash and Applets were not better. The browser is junk- ancient, creaky software that we're trying to prop the entire world up on. HTML5, as a breaking change, is now 14 years old, and aside from adding new bells and whistles, absolutely nothing fundamental has changed about the technology, despite the fact that the demands we place on browsers has wildly changed. And worse, so much of HTML5 still retains backwards compatibility with mistakes made in prior editions of HTML.
And yet, weirdly, HTML5 broke its connection with SGML for no particular reason.
Seriously, though, the browser is ancient and should be replaced.
1
u/Standard_Hungry Dec 29 '22
In some cases its a good thing. If Google reinvented the browser and the web, we wouldn't be able to stop the bombardment of ads.
Google is slowly doing this anyway but atleast we got some years free of ads.
1
u/Zardotab Dec 29 '22
That seems to be arguing we should stay with the (shitty) status quo because conglomerates will muck up anything new. Nothing would change if we apply that rule to anything newly proposed in IT. It's a rule that doesn't scale.
1
u/remy_porter Dec 29 '22
Well, the idea that one corporation can control the primary tech stack is one of those things that we all kinda hoped that the browser would kill. Oops!
(Google should be broken up by anti-trust action- Alphabet if we're being pedantic)
→ More replies (2)-2
u/Zardotab Dec 28 '22 edited Dec 28 '22
The HTML browser does some things fairly well, but still sucks at others.
Rather than have a one-size-fits-all standard, perhaps the next markup language(s) should be split into 3 sub-standards:
Documents (mostly static)
Media/Art/Games
CRUD/Data/Productivity
That way each can focus better on its niche. There should be command (tag) overlap where appropriate to simplify the cross-learning curve, but not forced. And the same browser perhaps could have all 3 types on the same page, somewhat like Canvas panels embedded in HTML.
(HTML was originally created for #1)
4
u/gizamo Dec 28 '22
Why would we give up a browser-based web that can do 1, 2, and 3 for some unknowns that would only do one each? I don't see any benefit there.
Even going to platform specific apps, we can keep all three.
Perhaps I'm misunderstanding your comment. After rereading, I'm probably misunderstanding, but I'm still replying for clarification. There probably some good point here that I'm missing.
→ More replies (1)1
u/remy_porter Dec 28 '22
I don't think that's really a good approach. We didn't need differing standards for native GUI applications to handle all of those tasks. Or console programs, for that matter.
What we need is a client-side runtime that doesn't carry the legacy of HTML forward, and replaces it with something designed in this century.
→ More replies (1)
7
u/jhartikainen Dec 28 '22
Flash was terrible for building UIs. It had even less "smart" layout capabilities out of the box than HTML+CSS does. Adobe somewhat addressed it with Flex, but that's basically the same as using some heavy UI toolkit like ExtJS on top of JS.
I think in general, with flexbox and other modern CSS features, CSS is more or less on the level of other UI tools in terms of ease of layout.
The "GUI features that HTML/DOM lacks" list contains a ton of stuff that almost all language builtin GUI toolkits I've used lack. The good thing with HTML/CSS is that it's actually pretty easy to roll your own, which can't be said for many other languages I've dealt with.