> Just so that a couple of snowflakes can use their fad of the day or can stay in their comfort zone.
Or because the DOM is a piece of technology designed for rendering documents and not web apps and with limitations which has been severely gimping proper rendering of web apps for the past decade despite a slew of libraries trying to fill the cracks with various amount of success. Whichever you prefer.
> Or because the DOM is a piece of technology designed for rendering documents and not web apps
IDK, it seems to have been pretty successful at it to me, being of the most popular GUI frameworks currently, probably the most popular by a wide margin.
Being designed for documents it should exceed at rendering documents.
The problem isn’t on the DOM itself, it’s in mapping other frameworks to it. Of course it‘d be hard to port LibreOffice‘s rendering to the web, it‘d be a crazy amount of work to reach parity.
And it’s fine to argue that it doesn’t make sense at all to use the DOM for non-web document editing: OnlyOffice doesn’t do it either, as far as I’m aware.
It’s just a bummer to me since documents are exactly what the web was made for.
The fact that there are so many alternative languages for the JVM or which transpile to Javascript suggests that (at least to many people) that neither were ideal choices for their current uses.
That is like saying the existence of cargo trucks, pick-ups, minivans, campers, and rv's shows that the underlying 'internal combustion engine' technology is flawed.
I think it rather shows that the technology is so useful that it is able to spawn different implementations aimed at slightly different use cases.
They're much harder to "disassemble" and applications written in them are much harder to modify and a relatively open DOM + JS model. Looks like a very promising technology for an ad company that's been pushing to make ad blockers significantly less effective, and has never let you install an adblocker into the most popular browser on the most popular platform in the world.
In the case of Google Docs kt might be because it is really convenient to use canvas because then it gets much harder for clients to do things Google don't like, i.e. interoperability.
In other cases, like in IE^h^hChrome and large Google products like Calendar and YouTube there have been some interesting cases I think.
A div element is a node in a tree which will be rendered by a very opiniated rendering engine adhering to a fairly strict set of standards, and which can be manipulated using a limited subset of technologies which are themselves fairly opinionated.
A class Rectangle can be pretty much whatever you want.
> A class Rectangle can be pretty much whatever you want
In what way can an `HTMLDivElement` not emulate a `class Rectangle`?
- Both are rectilinear
- Both have width, height
- Both can have borders, backgrounds
- Both can be positioned in various grid/layout systems
- Both can contain child instances
- Both can contain a variety of child nodes like `Text`
- Both can be clipped and masked
- Both can be layered
What can you do with a `class Rectangle` from a GUI perspective that you can't do with an `HTMLDivElement`?
A class Rectangle can be whatever you want. You can overload it. You can change everything including how it’s rendered. It doesn’t have to be any of the things you list.
A div element is a node in a tree which will be rendered by your browser in the way specified by the spec. You absolutely can’t freely do most of the actions you list to a div. There are severe limitations.
A div doesn’t at all emulate a class. Its semantically something completely different.
> A Rectangle component is a node in a component tree which will be rendered by your OS graphics library in the way specified by the spec. You absolutely can’t freely do most of the actions you list to a div. There are severe limitations.
No?
It seems like you're just talking about a `Rectangle` in the abstract rather than the real limitation that even `class Rectangle` is subject to the rules of the runtime engine that renders said `Rectangle`...in a component tree...with the restrictions of the OS/GUI framework...
Rendering outside of a web browser gives you a lot more freedom when it comes to how you layout and render. Rendering engines don’t necessarily use components tree by the way.
Even gui frameworks (which is what I think you are talking about with OS graphic library) have layout engines which are a lot more powerful than css. Flexbox is a step in the right direction but still inferior to what some frameworks could do 20 years ago.
So instead of standardized element that works pretty much the same on every browser, that can be inspected and controlled by virtually every tool that works with web I, as a user, get a binary blob, correct?
> And you can’t even control zoom/scale on desktop.
I must note (in the interest of factual accuracy, though as you see I loathe the approach) that this is not a fundamental limitation, just something that Flutter and probably ZetaOffice have chosen not to support. You can block such things in a DOM world too, and it’s stupidly common for app-like things to try to do so.
You just need to be one of the critical projects for BigTech. Easy peasy, compared to <editor_command> index.html.
> This wasm application renders to canvas and works fine for me: https://bandysc.github.io/AvaloniaVisualBasic6/
Trying to select text on mobile Safari just selects whole canvas. Same for your Flutter example.
What a regression for web. Just so that a couple of snowflakes can use their fad of the day or can stay in their comfort zone.