4 ms·

So the fundamental problem is the DOM is too inefficient to do applications on it. No surprise there, considering the original design of HTML was for presenting

So the fundamental problem is the DOM is too inefficient to do applications on it. No surprise there, considering the original design of HTML was for presenting information, not for interactive applications.

deleted 2y ago
[deleted]
LordHeini 2y ago
That is not the case anymore. React and many other SPA frameworks use an additional virtual DOM which gets mapped onto the real DOM. This used to be faster 10 years ago and allowed for a unified interface. Any addon manipulating the DOM forces the virtual DOM to go out of sync thus crashing the app. As shown be the likes of Svelte, the virtual DOM is just legacy modern browsers are fast enough to get by without.
- jtsiskin 2y ago
  It’s not that modern browsers are faster - Svelte is a different approach and figures out how to update at compile time rather than using a runtime virtual DOM. 10 years ago it would also have been faster
- whizzter 2y ago
  Virtual DOM or not doesn't matter, even Svelte has the potential to be disrupted by these Google translate shenanigans since it manipulates the DOM. Actually it seems they got hit also, https://github.com/sveltejs/svelte/issues/15090 https://github.com/sveltejs/svelte/issues/15090
aqueueaqueue 2y ago
I doubt it. Say you write a native app and some other side app swoops in and changes all your UI state while running. That is going to cause problems.
- zelphirkalt 2y ago
  But only, if the DOM is used in other ways than being an output of whatever is done to calculate its update. If the framework uses the DOM for other things than directly updating it or respresentation of internal state, then that's on the framework. Is it reasonable to assume DOM itself is part of the state? Would it not be more reasonable to have an internal state? But we have this with virtual DOM. So maybe the issue is in the way it makes use of the DOM in conjuction with virtual DOM internally. Maybe it is an optimization "hack" that goes badly in this scenario.
  - kelnos 2y ago
    That sounds pretty arbitrary. Upon what grounds do you feel it's appropriate to say that the DOM is only allowed to be used in the way you describe?
- LorenPechtel 2y ago
  Disagree. I've swooped in on programs and done major changes to their filesystem behind their back. Programs that had no concept of working with externally supplied data in a network world. The programs happily went along doing their job, completely unaware that every label was a phantom whose meaning would always change if selected. The contents were appropriate (everything was simple CSV), the proper commands would be sent to the attached machinery. It's the responsibility of the swooper to ensure everything's put back sane.
bryanrasmussen 2y ago
I think the fundamental problem is you have two applications, the primary application and google translate altering the application state of the primary application at the same time, without any possible communication between the two regarding locking or alterations or anything. I'm pretty sure most applications in the history of computing would not fare any better if you constructed that situation.
- nottorp 2y ago
  Both Google and React are guilty here if i read the article right. Google replaces an element with a different element (Text with Font containing Text?), and React's virtual DOM keeps the old, deleted elements alive because the virtual DOM still references them. React "applications" would crash when Google Translate changes their stuff from under them if they didn't accidentally keep the old elements alive. Which would be much better behaviour.
  - zelphirkalt 2y ago
    Yeah, Google translate shouldn't have to "research"/reverse engineer, what kind of framework is being used on any random website it translates. It assuming, that it simply interacts with static information would still be a reasonable assumption. While Google translate is also at fault, if it changes the DOM structure. Why not leave things the same and just exchange textnodes? Seems silly.
    - bryanrasmussen 2y ago
      I am just supposing, but have not checked, that if they change the text they must also change the DOM by at least changing the lang attribute on nodes affected, meaning probably the lang attribute on the html element, but could also be a lang attribute on each element wrapping a textNode. on edit: I figured the article must have said something about this and I missed it, and yes, it shows that the DOM is changed to be lang="nl" on the html element, which means obviously if React rerenders but does not rerender the HTML element (which many React applications do not control) then the language would be out of sync, of course.
mdhb 2y ago
That hasn’t been true for at a minimum half a decade now and much longer in practice I think.
lobsterthief 2y ago
> No surprise there, considering the original design of HTML was for presenting information, not for interactive applications. Even in this we’re just HTML displaying information, there’s effectively this second application (Google Translate) changing the structure of the original application’s XML, which would still break display (or XPATHs) in a “normal HTML presenting information” scenario.
pier25 2y ago
No. It's not an issue with efficiency at all.

deleted 2y ago

[deleted]

LordHeini 2y ago

That is not the case anymore. React and many other SPA frameworks use an additional virtual DOM which gets mapped onto the real DOM. This used to be faster 10 years ago and allowed for a unified interface. Any addon manipulating the DOM forces the virtual DOM to go out of sync thus crashing the app. As shown be the likes of Svelte, the virtual DOM is just legacy modern browsers are fast enough to get by without.

jtsiskin 2y ago
It’s not that modern browsers are faster - Svelte is a different approach and figures out how to update at compile time rather than using a runtime virtual DOM. 10 years ago it would also have been faster
whizzter 2y ago
Virtual DOM or not doesn't matter, even Svelte has the potential to be disrupted by these Google translate shenanigans since it manipulates the DOM. Actually it seems they got hit also, https://github.com/sveltejs/svelte/issues/15090 https://github.com/sveltejs/svelte/issues/15090

aqueueaqueue 2y ago

I doubt it. Say you write a native app and some other side app swoops in and changes all your UI state while running. That is going to cause problems.

zelphirkalt 2y ago
But only, if the DOM is used in other ways than being an output of whatever is done to calculate its update. If the framework uses the DOM for other things than directly updating it or respresentation of internal state, then that's on the framework. Is it reasonable to assume DOM itself is part of the state? Would it not be more reasonable to have an internal state? But we have this with virtual DOM. So maybe the issue is in the way it makes use of the DOM in conjuction with virtual DOM internally. Maybe it is an optimization "hack" that goes badly in this scenario.
- kelnos 2y ago
  That sounds pretty arbitrary. Upon what grounds do you feel it's appropriate to say that the DOM is only allowed to be used in the way you describe?
LorenPechtel 2y ago
Disagree. I've swooped in on programs and done major changes to their filesystem behind their back. Programs that had no concept of working with externally supplied data in a network world. The programs happily went along doing their job, completely unaware that every label was a phantom whose meaning would always change if selected. The contents were appropriate (everything was simple CSV), the proper commands would be sent to the attached machinery. It's the responsibility of the swooper to ensure everything's put back sane.

bryanrasmussen 2y ago

I think the fundamental problem is you have two applications, the primary application and google translate altering the application state of the primary application at the same time, without any possible communication between the two regarding locking or alterations or anything. I'm pretty sure most applications in the history of computing would not fare any better if you constructed that situation.

nottorp 2y ago
Both Google and React are guilty here if i read the article right. Google replaces an element with a different element (Text with Font containing Text?), and React's virtual DOM keeps the old, deleted elements alive because the virtual DOM still references them. React "applications" would crash when Google Translate changes their stuff from under them if they didn't accidentally keep the old elements alive. Which would be much better behaviour.
- zelphirkalt 2y ago
  Yeah, Google translate shouldn't have to "research"/reverse engineer, what kind of framework is being used on any random website it translates. It assuming, that it simply interacts with static information would still be a reasonable assumption. While Google translate is also at fault, if it changes the DOM structure. Why not leave things the same and just exchange textnodes? Seems silly.
  - bryanrasmussen 2y ago
    I am just supposing, but have not checked, that if they change the text they must also change the DOM by at least changing the lang attribute on nodes affected, meaning probably the lang attribute on the html element, but could also be a lang attribute on each element wrapping a textNode. on edit: I figured the article must have said something about this and I missed it, and yes, it shows that the DOM is changed to be lang="nl" on the html element, which means obviously if React rerenders but does not rerender the HTML element (which many React applications do not control) then the language would be out of sync, of course.

mdhb 2y ago

That hasn’t been true for at a minimum half a decade now and much longer in practice I think.

lobsterthief 2y ago

> No surprise there, considering the original design of HTML was for presenting information, not for interactive applications. Even in this we’re just HTML displaying information, there’s effectively this second application (Google Translate) changing the structure of the original application’s XML, which would still break display (or XPATHs) in a “normal HTML presenting information” scenario.

pier25 2y ago

No. It's not an issue with efficiency at all.