Everything about Google Translate crashing React (and other web apps)

&gt; When I first ran into this issue back in 2017, I posted in the React issue tracker that I had ”fixed” my app by blocking translation entirely.<p>Please do not do this! In almost every instance I&#x27;ve encountered severe Translate-related broken-ness, it&#x27;s still worked well enough to get me a snapshot of the current page translated. Fighting through this is still less cumbersome than the alternatives.<p>&gt; The only alternative solution that I can think of, is to implement your own localization within your app (i.e. internationalization)<p>I will add, please make sure that language is an independent setting, and not derived from locale! I sometimes have to use translate on sites that have my preferred language available, but won&#x27;t show it to me because it&#x27;s tied to locale and that changes other things that I don&#x27;t want, like currency.<p>On one such site I used a browser extension to rewrite the request for the language strings file.

I had to learn this the hard way when a React app I built showed random crashes I couldn&#x27;t explain.<p>&quot;Fortunately&quot; it also auto-translated the &quot;I happily accept the terms of use&quot; checkbox in one case into (back-translated) &quot;I happily dying die perish&quot;, which also couldn&#x27;t be clicked. That lead to a very high priority ticket and made us realize that all DOM manipulators might break the site.

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.

Another solution would be a React-native machine translation implementation that updates the TextNodes without replacing them. It would still have the issues of merging adjacent nodes to get a proper translation, but at least it could update on any state change.

I ran into this. We worked around it with solution 2 from the article i.e. never render text by itself next to another element, always wrap the text in it&#x27;s own element. Not that much of an inconvenience since we have a Text component that controls font size etc anyway.

How does Firefox translation interact with React?

Not sure if this has the same root cause, but some websites &#x27;break&#x27; with Firefox translate, as if the visible text in an HTML element is somehow being used as an identifier in the website&#x27;s application logic.

I don&#x27;t like the way React updates subtrees. Other frameworks get it wrong, too, by using the same incorrect model. Employing professional opinion, it&#x27;s just wrong. The document should be considered the source of truth, not some internal private state.<p>e.g. Input values on the HTMLInputElement are the real input, not some clone to a private object in JavaScript.<p>As a result of React&#x27;s blatantly wrong treatment of the document.body, you have ensure that when it reuses element siblings within an arbitrary tree, that it&#x27;s values are squashed to whatever private fields you&#x27;re using in your component.<p>It screams wrong, and side effects like the one in this article make it obvious why.<p>No one is going to go out of their way to touch your special internal state, we&#x27;re all going to use the web API to touch nodes and events from standard interfaces. You can&#x27;t take the ball into a private court and expect the rest of the game to function.

The substack.com is a typical example of a problem where the Google Translate extension can crash or cause parts to explode.

This is essentially a bug in React VDOM which blindly assumes it is the only one updating DOM nodes. Imho, it&#x27;s long overdue to remove VDOM from react as other renderes have shown that it&#x27;s not needed for performance.

Knowing Google they&#x27;d build a private extension of the Web standard to fix this in Chrome.

Just out of curiosity, what web apps are effected? I tried to find the &quot;other web apps&quot; and can&#x27;t find anything (quick scan of the article)

It strikes me that a straightforward solution to this problem would be to have Google Translate dispatch a new CustomEvent with a particular &quot;type&quot; and a reference to the new element in the detail field. So React and other frameworks could listen to this event and instead of dealing with Text node X, they could instead refer to the translated element Y.

I use Google translate all the time, and I definitely noticed you have to kick it to update.

The real fix is to have a new web feature which is to have the &#x27;page dom&#x27; and the &#x27;display dom&#x27;,.<p>By default there would be a 1:1 mapping, but things like browser extensions could write code to define how a particular bit of page dom would display to the user.

React is not the right way to build webapps, so I see no problem here.

How about react get on with times and support everyday needs of people instead?

So the web is basically broken. Can WASM provide a solution?

Last part of the post hints at a possible future for SPAs: wasm. No DOM modified by browser extensions so no surprise.

Therefore, I prefer svelte (besides superior ergonomics &amp; web-standards compliance): It&#x27;s not a framework, but a compiler that outputs only pure JS. Svelte simply has no virtual DOM that can be messed up. Just Simplicity &amp; efficiency.