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.
I'm pretty sure most applications in the history of computing would not fare any better if you constructed that situation.
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.
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.
I think any real fix to Google Translate would be very complicated. I fear the only solution might be to elevate Google Translate to be part of the browser's rendering engine instead of acting like an extension. This would allow it to work in the rendering pipeline without modifying the DOM, but even that will probably run into site-bugs because of things like text being longer or shorter.
[1]: https://martijnhols.nl/blog/everything-about-google-translat...
They're so terse, two Unicode characters can be like 10+ letters lol
Sometimes I translate to understand the page then refresh to use it unborked in the original language
I don't know, but perhaps due to the fact that due to the CJK unification in unicode, rendering Chinese or Japanese without explicitly setting a font designed for that particular language can output incorrect characters (of the other language, which are considered "the same character" despite being different). Thus, a translation tool would have to explicitly set a font in order to display these languages correctly in a reliable manner, because the surrounding context certainly cannot be assumed to have the appropriate font. And I could easily imagine that someone would choose to keep the same code path for all languages instead of branching for this particular case, resulting in a <font> even for languages other than those two.
What React could do is to catch that there have been changes made to the structure of the DOM by someone other than them and then re-render the full page. Which would probably not be the most performant solution for anyone.
But anyway then people would complain that React was breaking Google Translate.
Essentially you have two applications fighting to control rendering of the application state of one of them.
It would be fine if Translate was just modifying text, but changing the actual structure of the HTML goes too far.
The problem here is that react "application" builds its own state of the web page, fails to reconcile it with changes to actual state, ends up in a detached state with stale information and then proceeds to alter actual state based on the corrupted information it has.
If there is such a thing as web apps, then the primary application is the web app, and that primary application runs in the browser.
Then the browser, via an extension, is corrupting that application's internal state and is then surprised when that application stops working correctly. Well, duh.
If Translate were to only modify the text on the website, I'd think React would be able to deal with it better. But it seems to be modifying the structure too (adding <font> tags); I think it's not reasonable to expect every JS framework to be able to deal with that properly.
> I think it's not reasonable to expect every JS framework to be able to deal with that properly.
It would be unreasonable to call any framework out of pre-alpha prototype stage, much less production ready, if it can't handle such basic stuff, sorry.
Translators for specific chunks of the screen, yes. Selectable translators, sure. Translators you can configure to work with one application at a time.
But rewriting all text in the entire windowing environment? While preserving selection, copying, and editing? Without hooks to the underlying apps? Functionally preposterous as a proposition.
It's the responsibility of the swooper to ensure everything's put back sane.
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.
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.
Actually it seems they got hit also, https://github.com/sveltejs/svelte/issues/15090