Posting my feedback here as I was asked by Gandalf to do so. I work on [browser.html] (https://github.com/browserhtml/browserhtml), which is built with an [immediate mode rendering](https://en.wikipedia.org/wiki/Immediate_mode_(computer_graphics)) architecture similar to React. In fact our renderers (that we refer to drivers) are swappable and react is one of the options. One of the reasons we've settled on swappable driver architecture was because react was not fast enough in our experience and swappable drivers allowed us to try alternatives (which in turned out to perform better). Trying different drivers is still on a plate & what I mean by that is that is driver may actually render into canvas or webgl or something even wilder.
Points I'm trying to make is: 1. Hooking localization at the DOM layer is not great option for us, because it can operates on the same stuff (DOM) as a driver that can cause problems, as driver assumes full control of the target. 2. We are trying hard to achieve native performance that is already challenging, adding extra DOM mutations and observers is going to make things worse. 3. We invested a lot of effort into making drivers swappable such that no changes are required other than plugging different driver. Doing localization at the DOM layer conflicts with this if we would like to do non DOM driver. 4. Our architecture allows us to do deterministic session record / reply (similar to [rr](http://rr-project.org). Doing any IO outside of the app code means deterministic reply isn't possible. Give above context, I think that proving JS api to fetch localization bundle and then doing localizations as simply as `bundle.localize(....):string` would be most ideal solution. That would work regardless of rendering method and without conflicting with any of the other tooling mentioned above. _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
