7 ms·

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

108 points by MartijnHols 2y ago

arkh 2y ago
Last part of the post hints at a possible future for SPAs: wasm. No DOM modified by browser extensions so no surprise.
- Aldipower 2y ago
  Or switching back to desktop apps? Also no DOM manipulation there. :-)
  - jillesvangurp 2y ago
    WASM enables us to bring what we were doing there to the web. The distinction always was a bit artificial. This notion that you can only have DOM/CSS/Javacript on the web did not age well. There's a whole generation of programmers that built their careers on targeting that and are confusing that status quo with something that is set in stone for good reasons. Those reasons never really existed. Javascript was a bit shit but it was there so people used it. Fast forward 30 years and you still have people proving that point on a daily basis by creating very mediocre and underwhelming things with it. WASM opens up the web to 30 years of progress in UI development elsewhere (mobile phones, game consoles, VR/AR, desktop, etc.). What people will do with that is of course an open question. There are a few frameworks emerging but they are still kind of niche. And there are lots of attempts to bring retro UIs to the web unmodified. Links to e.g. Winamp in a browser, VB 6 running in a browser, etc. are easy to find. Some people even boot entire operating systems in a browser. I think I came across windows 95 at some point. A few versions of Linux, and some other stuff. Cool, but I'm more interested in new stuff. The web has bit of an imagination deficit. Creativity on the web mostly died along with Flash. HTML + Javascript never managed to fill that void. Just the wrong tech for that job.
    - arkh 2y ago
      > Creativity on the web mostly died along with Flash. Even being anti flash sites at the time, I can't deny it allowed many fun experiences with browser games which look absent today.
nottorp 2y ago
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
rjprins 2y ago
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.
- dgoldstein0 2y ago
  One idea that crossed my mind while reading the article: for websites that already use react-intl, have react-intl implement an API to allow supplying machine translations of messages into languages otherwise not supported by the app. The problem with this is that it will only help sites that already put in effort to internationalization. Whereas the main target of Google translate are the sites that do not bother with i18n. Still, it'd be quite valuable to the sites early in their internationalization journeys to get support for tons of languages right upon introducing internationalization.
  - Raed667 2y ago
    that requires google to care about this issue
barlog 2y ago
The substack.com is a typical example of a problem where the Google Translate extension can crash or cause parts to explode.
rjst01 2y ago
> 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. Please do not do this! In almost every instance I've encountered severe Translate-related broken-ness, it'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. > The only alternative solution that I can think of, is to implement your own localization within your app (i.e. internationalization) 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't show it to me because it's tied to locale and that changes other things that I don't want, like currency. On one such site I used a browser extension to rewrite the request for the language strings file.
- dgoldstein0 2y ago
  When you say locale, you mean your current location, e.g. as detected by geoip?
  - pwagland 2y ago
    Sometimes, but not always. Sometimes it is also based on the locales in your browser.
  - pta2002 2y ago
    A locale is a combination of several things, including a language, but not only. E.g. I'm from portugal. I'm visiting an american site, which does not have professional portuguese translations, but does have auto-generated ones. I don't like the auto-generated ones and can read english just fine, so I want to have the language set to english (en-US in this case). However, I still want it to apply some locale-specific things from Portugal, e.g.: - Units (Metric vs. Imperial vs. Whatever mess countries like the UK do) - Date formatting (DD/MM/YYYY vs MM/DD/YYYY) - Time formatting (AM/PM vs. 24hr clock) - Currency formatting (10€ vs. 10 € vs. 10 EUR vs. €10) - Number formatting (10,000.00 vs 10.000,00) - When the week starts (Monday vs. Sunday) If you take a look at the windows locale options, it mostly lets you mix-and-match whatever you want (which is great! Now if only the MS apps let me stop using the localized keyboard shortcuts...): https://learn.microsoft.com/en-us/globalization/locale/language-settings https://learn.microsoft.com/en-us/globalization/locale/langu...
mentalgear 2y ago
Therefore, I prefer svelte (besides superior ergonomics & web-standards compliance): It'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 & efficiency.
- gr__or 2y ago
  You are confused about the issue, and the OP does its part in contributing to the confusion. It's not a VDOM issue, it's not React exclusive (that part the post is explicit about) and indeed Svelte is affected as well: https://github.com/sveltejs/svelte/issues/15090 https://github.com/sveltejs/svelte/issues/15090 When seeing issues like this one pop up with React in the title, one should really have a good think whether this is solved principally different in other fws OR, and this should be the null hypothesis, is React in the title because it is more widely used than all the others combined
  - mentalgear 2y ago
    Fair. The svelte sites I tried it out on had no issues, so I assumed it might be limited on React.
- tehbeard 2y ago
  Svelte breaks just the same... Go, get down off your high horse and try it yourself, finish the counter in their tutorial, put a console log in the handler, and translate the page to French... C'est tres borked.
- Raed667 2y ago
  [flagged]
- BtM909 2y ago
  But wouldn't it be the same when Google translate is actively replacing nodes?
CrimsonRain 2y ago
How about react get on with times and support everyday needs of people instead?
- deleted 2y ago
  [deleted]
itronitron 2y ago
Not sure if this has the same root cause, but some websites 'break' with Firefox translate, as if the visible text in an HTML element is somehow being used as an identifier in the website's application logic.
eptcyka 2y ago
How does Firefox translation interact with React?
cutler 2y ago
So the web is basically broken. Can WASM provide a solution?
cmenge 2y ago
I had to learn this the hard way when a React app I built showed random crashes I couldn't explain. "Fortunately" it also auto-translated the "I happily accept the terms of use" checkbox in one case into (back-translated) "I happily dying die perish", which also couldn't be clicked. That lead to a very high priority ticket and made us realize that all DOM manipulators might break the site.
- shadowgovt 2y ago
  Very early on in my career, I was working on a greeting-card app in Facebook (back when Facebook apps were a thing). Got a bug report from one of our own team members that some of her greeting cards didn't show up in the list. The link appeared, but no image. We figured out that the difference was she was running an ad-blocker. We couldn't figure out precisely what rule the blocker was applying, but it seemed to be: - image - within some particular size bounds - with the consecutive letters 'ad' in the URL. ... and we were using hexadecimal encodings to track individual entities in the UI. We solved the problem by replacing 'a' with 'g' in our hex encoding. And then I had to take a long walk and accept that if I was going to do web development on the public Internet, I'd be sharing the space with intentionally-modified user agents forever, and would have to account for every such modification as we discovered it. I still won't run my own ad-blocker for this reason.
  - MatthiasPortzel 2y ago
    > I still won't run my own ad-blocker for this reason. I maintained an extension for a public website for a couple years. (It did things like, for example, adding information that was available in the API to the page, for power users.) I eventually gave up with the conclusion that the concept of a browser extension was fundamentally unsound. So I also don’t use an-blocker.
  - LorenPechtel 2y ago
    Which is why a decent ad blocker has the option to selectively permit things it thinks are ads. Without blocking I've had multiple occasions of encountering a website that was completely unusable, it would be completely overlaid with ads as soon as they loaded.
aj7 2y ago
I use Google translate all the time, and I definitely noticed you have to kick it to update.
sebazzz 2y ago
Knowing Google they'd build a private extension of the Web standard to fix this in Chrome.
mindaslab 2y ago
React is not the right way to build webapps, so I see no problem here.
jppope 2y ago
Just out of curiosity, what web apps are effected? I tried to find the "other web apps" and can't find anything (quick scan of the article)
- MartijnHols 2y ago
  Anything that affects the DOM and relies on TextNodes behaving predictably. It could be as simple as `e.target` of a click event being different (the `font` element gets in between what was actually clicked), but the main issues are when apps try to update or replace what used to be TextNodes. Imagine you're building a framework, and a consumer renders a clock. The only thing that changes every tick, is the text value; `00:00` becomes `00:01`. In an attempt to be as efficient as possible, it's only natural for the framework builder to decide to keep a reference to the `TextNode` and only update its `textContent` every frame. This scales the best for even the most complicated app, but it leads to interference from Google Translate as the article shows.
forgotusername6 2y ago
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's own element. Not that much of an inconvenience since we have a Text component that controls font size etc anyway.
sufianrhazi 2y ago
It strikes me that a straightforward solution to this problem would be to have Google Translate dispatch a new CustomEvent with a particular "type" 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.
andrewmcwatters 2y ago
I don't like the way React updates subtrees. Other frameworks get it wrong, too, by using the same incorrect model. Employing professional opinion, it's just wrong. The document should be considered the source of truth, not some internal private state. e.g. Input values on the HTMLInputElement are the real input, not some clone to a private object in JavaScript. As a result of React's blatantly wrong treatment of the document.body, you have ensure that when it reuses element siblings within an arbitrary tree, that it's values are squashed to whatever private fields you're using in your component. It screams wrong, and side effects like the one in this article make it obvious why. No one is going to go out of their way to touch your special internal state, we're all going to use the web API to touch nodes and events from standard interfaces. You can't take the ball into a private court and expect the rest of the game to function.
londons_explore 2y ago
The real fix is to have a new web feature which is to have the 'page dom' and the 'display dom',. 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.
silverwind 2y ago
This is essentially a bug in React VDOM which blindly assumes it is the only one updating DOM nodes. Imho, it's long overdue to remove VDOM from react as other renderes have shown that it's not needed for performance.

108 points by MartijnHols 2y ago

arkh 2y ago

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

Aldipower 2y ago
Or switching back to desktop apps? Also no DOM manipulation there. :-)
- jillesvangurp 2y ago
  WASM enables us to bring what we were doing there to the web. The distinction always was a bit artificial. This notion that you can only have DOM/CSS/Javacript on the web did not age well. There's a whole generation of programmers that built their careers on targeting that and are confusing that status quo with something that is set in stone for good reasons. Those reasons never really existed. Javascript was a bit shit but it was there so people used it. Fast forward 30 years and you still have people proving that point on a daily basis by creating very mediocre and underwhelming things with it. WASM opens up the web to 30 years of progress in UI development elsewhere (mobile phones, game consoles, VR/AR, desktop, etc.). What people will do with that is of course an open question. There are a few frameworks emerging but they are still kind of niche. And there are lots of attempts to bring retro UIs to the web unmodified. Links to e.g. Winamp in a browser, VB 6 running in a browser, etc. are easy to find. Some people even boot entire operating systems in a browser. I think I came across windows 95 at some point. A few versions of Linux, and some other stuff. Cool, but I'm more interested in new stuff. The web has bit of an imagination deficit. Creativity on the web mostly died along with Flash. HTML + Javascript never managed to fill that void. Just the wrong tech for that job.
  - arkh 2y ago
    > Creativity on the web mostly died along with Flash. Even being anti flash sites at the time, I can't deny it allowed many fun experiences with browser games which look absent today.

nottorp 2y ago

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

rjprins 2y ago

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.

dgoldstein0 2y ago
One idea that crossed my mind while reading the article: for websites that already use react-intl, have react-intl implement an API to allow supplying machine translations of messages into languages otherwise not supported by the app. The problem with this is that it will only help sites that already put in effort to internationalization. Whereas the main target of Google translate are the sites that do not bother with i18n. Still, it'd be quite valuable to the sites early in their internationalization journeys to get support for tons of languages right upon introducing internationalization.
- Raed667 2y ago
  that requires google to care about this issue

barlog 2y ago

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

rjst01 2y ago

> 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. Please do not do this! In almost every instance I've encountered severe Translate-related broken-ness, it'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. > The only alternative solution that I can think of, is to implement your own localization within your app (i.e. internationalization) 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't show it to me because it's tied to locale and that changes other things that I don't want, like currency. On one such site I used a browser extension to rewrite the request for the language strings file.

dgoldstein0 2y ago
When you say locale, you mean your current location, e.g. as detected by geoip?
- pwagland 2y ago
  Sometimes, but not always. Sometimes it is also based on the locales in your browser.
- pta2002 2y ago
  A locale is a combination of several things, including a language, but not only. E.g. I'm from portugal. I'm visiting an american site, which does not have professional portuguese translations, but does have auto-generated ones. I don't like the auto-generated ones and can read english just fine, so I want to have the language set to english (en-US in this case). However, I still want it to apply some locale-specific things from Portugal, e.g.: - Units (Metric vs. Imperial vs. Whatever mess countries like the UK do) - Date formatting (DD/MM/YYYY vs MM/DD/YYYY) - Time formatting (AM/PM vs. 24hr clock) - Currency formatting (10€ vs. 10 € vs. 10 EUR vs. €10) - Number formatting (10,000.00 vs 10.000,00) - When the week starts (Monday vs. Sunday) If you take a look at the windows locale options, it mostly lets you mix-and-match whatever you want (which is great! Now if only the MS apps let me stop using the localized keyboard shortcuts...): https://learn.microsoft.com/en-us/globalization/locale/language-settings https://learn.microsoft.com/en-us/globalization/locale/langu...

mentalgear 2y ago

Therefore, I prefer svelte (besides superior ergonomics & web-standards compliance): It'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 & efficiency.

gr__or 2y ago
You are confused about the issue, and the OP does its part in contributing to the confusion. It's not a VDOM issue, it's not React exclusive (that part the post is explicit about) and indeed Svelte is affected as well: https://github.com/sveltejs/svelte/issues/15090 https://github.com/sveltejs/svelte/issues/15090 When seeing issues like this one pop up with React in the title, one should really have a good think whether this is solved principally different in other fws OR, and this should be the null hypothesis, is React in the title because it is more widely used than all the others combined
- mentalgear 2y ago
  Fair. The svelte sites I tried it out on had no issues, so I assumed it might be limited on React.
tehbeard 2y ago
Svelte breaks just the same... Go, get down off your high horse and try it yourself, finish the counter in their tutorial, put a console log in the handler, and translate the page to French... C'est tres borked.
Raed667 2y ago
[flagged]
BtM909 2y ago
But wouldn't it be the same when Google translate is actively replacing nodes?

CrimsonRain 2y ago

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

deleted 2y ago
[deleted]

itronitron 2y ago

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

eptcyka 2y ago

How does Firefox translation interact with React?

cutler 2y ago

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

cmenge 2y ago

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

shadowgovt 2y ago
Very early on in my career, I was working on a greeting-card app in Facebook (back when Facebook apps were a thing). Got a bug report from one of our own team members that some of her greeting cards didn't show up in the list. The link appeared, but no image. We figured out that the difference was she was running an ad-blocker. We couldn't figure out precisely what rule the blocker was applying, but it seemed to be: - image - within some particular size bounds - with the consecutive letters 'ad' in the URL. ... and we were using hexadecimal encodings to track individual entities in the UI. We solved the problem by replacing 'a' with 'g' in our hex encoding. And then I had to take a long walk and accept that if I was going to do web development on the public Internet, I'd be sharing the space with intentionally-modified user agents forever, and would have to account for every such modification as we discovered it. I still won't run my own ad-blocker for this reason.
- MatthiasPortzel 2y ago
  > I still won't run my own ad-blocker for this reason. I maintained an extension for a public website for a couple years. (It did things like, for example, adding information that was available in the API to the page, for power users.) I eventually gave up with the conclusion that the concept of a browser extension was fundamentally unsound. So I also don’t use an-blocker.
- LorenPechtel 2y ago
  Which is why a decent ad blocker has the option to selectively permit things it thinks are ads. Without blocking I've had multiple occasions of encountering a website that was completely unusable, it would be completely overlaid with ads as soon as they loaded.

aj7 2y ago

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

sebazzz 2y ago

Knowing Google they'd build a private extension of the Web standard to fix this in Chrome.

mindaslab 2y ago

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

jppope 2y ago

Just out of curiosity, what web apps are effected? I tried to find the "other web apps" and can't find anything (quick scan of the article)

MartijnHols 2y ago
Anything that affects the DOM and relies on TextNodes behaving predictably. It could be as simple as `e.target` of a click event being different (the `font` element gets in between what was actually clicked), but the main issues are when apps try to update or replace what used to be TextNodes. Imagine you're building a framework, and a consumer renders a clock. The only thing that changes every tick, is the text value; `00:00` becomes `00:01`. In an attempt to be as efficient as possible, it's only natural for the framework builder to decide to keep a reference to the `TextNode` and only update its `textContent` every frame. This scales the best for even the most complicated app, but it leads to interference from Google Translate as the article shows.

forgotusername6 2y ago

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's own element. Not that much of an inconvenience since we have a Text component that controls font size etc anyway.

sufianrhazi 2y ago

It strikes me that a straightforward solution to this problem would be to have Google Translate dispatch a new CustomEvent with a particular "type" 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.

andrewmcwatters 2y ago

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

londons_explore 2y ago

The real fix is to have a new web feature which is to have the 'page dom' and the 'display dom',. 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.

silverwind 2y ago

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