library - build-time optimizations

[ivanhofer]

What optimizations are reasonable?

[wvanrensselaer]

Curious if/how you've thought about code splitting dictionaries for exceptionally large apps. I've worked in a couple where a single dictionary approach can be 100kb+ of messages. But code splitting/loading/updating context adds some complexity. Example (in Next.js):

Home.tsx with loading and greeting translations:

import dynamic from 'next/dynamic';
import i18n from '$i18n';

const Footer = dynamic(() => import('@/ui/Footer', {
  loading: () => i18n.loading()
});

export default function Home() {
  return (
    <div>
      <h1>{i18n.greeting()}</h1>
      <Footer />
    </div>
  );
}

Code-split Footer.tsx with copyright translation.

import i18n from '$i18n';

export default function Footer() {
  return <div>{i18n.copyright()}</div>
}

Would need bundler context here to group translations (possibly more transitive translations) at the code split point and load them into context when loading the Footer.tsx module.

[ivanhofer]

I haven't really thought deeply about all the possible optimizations. But once, the whole setup using a build-time transformation is done, any optimizations can be added on top quite easily.
E.g. for meta-frameworks like Next.js dictionaries for each route could be created automatically.
Since storage is relatively cheap even each component could have a variant for each locale and the correct one then get's loaded. This would slightly increase the build-time, but then we could get rid of dictionaries (almost) at all.
The good thing is that developers don't really have to care about optimizing the code by themself. Tooling can do everything automatically for them.