Message compilation in v9

[rchl]

I'd like to understand better the reason for introducing message compilation in v2 of this loader / v9 of vue-i18n.

I can see that when using the loader a small JSON with 3 strings like:

{
    "home": "Strona glowna",
    "about": "O stronie",
    "posts": "Artykuly"
}

gets compiled to something like:

      var J = {
        home: e => {
          const {normalize: t} = e;
          return t(['Strona glowna'])
        },
        about: e => {
          const {normalize: t} = e;
          return t(['O stronie'])
        },
        posts: e => {
          const {normalize: t} = e;
          return t(['Artykuly'])
        }
      },

One disadvantage with that seems to be the sheer size of compiled code - it's much bigger than a JSON file.

What are the advantages though? Is it only about the performance or maybe it can also provide some better typing when used with TS?

BTW. Is it possible to optimize the const {normalize: t} = e; import so that it's not repeated for each translation? That would reduce the size considerably.

[kazupon]

Thank you for your discussion!

One disadvantage with that seems to be the share size of compiled code - it's much bigger than a JSON file.

What are the advantages though? Is it only about the performance or maybe it can also provide some better typing when used with TS?

BTW. Is it possible to optimize the const {normalize: t} = e; import so that it's not repeated for each translation? That would reduce the size considerably.

Yeah!
I recognize that is issue when pre-compiling json with Vue-i18n message compiler can cause bloat in the case of big JSON.

As mentioned in my slide at the following URL, the purpose of pre-compilation is to improve rendering performance.
https://speakerdeck.com/kazupon/state-of-vue-i18n?slide=35

I’ll plan to optimize messages function generation.

[rchl]

As mentioned in my slide at the following URL, the purpose of pre-compilation is to improve rendering performance.

Hmm, I wonder if optimizing rendering performance outweighs the cost of the initial compilation. I guess it might vary per case.

Also, for simple strings that are just used with a $t call, I feel that the compiled version won't be faster but will add cost to the initial parsing time.

Just a thought...

[kazupon]

Hmm, I wonder if optimizing rendering performance outweighs the cost of the initial compilation. I guess it might vary per case.

Yes! Although it is not mentioned in this slide, rendering performance will also be optimized. :)

I feel that the compiled version won't be faster but will add cost to the initial parsing time.

Good point!
Yes, I'm recognizing that issue too.

In the case of simple strings, it would be better to return it as a string when $t is called, instead of compiling it into message functions, so that there is no performance cost for the browser to parse the message functions.

In any case, there is room for optimization of i18n resources such as JSON for code generation by message compiler, and runtime improvements.

[kazupon]

I recently learned about typesafe-i18n.
https://github.com/ivanhofer/typesafe-i18n

I was reading the code, I got the following inspiration.

• i18n resources typesafe
• typesafe message functions

I will be extending vue-i18n-next in the near future.