61–70 of 88 posts
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.
Earlier quoted context omitted.
> In your browser's settings you can configure a list of languages (country-specific if desired) which get send with every request. Customising this list at all makes your browser fingerprint thousands of times less common than it was before you did this, and many websites you visit could then probably uniquely identify you as the same user across all of your sessions.
That and a thousand other things. A highly privacy focussed browser could offer to enable this setting only on whitelisted websites (and send 'en' plus a bunch of random language codes on others).
This is an easier fingerprint signal than just not sending anything.
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.
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.
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 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.
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.
> 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 alternat…
> I will add, please make sure that language is an independent setting, and not derived from locale! Websites already have exactly what they need to provide you with the language you want via the Accept-Language header your browser sends. In your browser's settings you can configure a list of languages (country-specific if desired) which get send with every request. E.g.,: en-GB en nl (Prefer British English, fall ba…
If a website is made by an English speaking team, as I understand English I'd like it to be English first and not a possibly broken French version. If a website is developed with French language first I'd like to have it in French and not a second-rate English translation.
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.
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 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 othe…
Earlier quoted context omitted.
They both do reasonable things, so I wouldn't really blame either. Google Translate was there first and is a big accessibility advantage for the web. At the same time, Google Translate is the user-specific browser extension that is executed last, on top of existing apps. It affects not just React[1], so even if React were to implement a fix, Google Translate would continue to interfere with other webapps. I think any…
I don’t see why Google Translate wrapping all text in elements is reasonable. Why is an extra element required, and why is it of all things? Translate is swapping text for text, so this shouldn’t be necessary. It also breaks a lot more than just JavaScript frameworks. Things like the child combinator in CSS selectors will break too.
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 even for languages other than those two.