Add an option to parse FTL during build

Demivan commented 1 week ago

Description

Add an option to do FTL parsing during build instead of during runtime on component initialization.

Option parseFtl?: boolean for both SFC and External plugins.

Linked Issues

Closes #101

Additional context

pkg-pr-new[bot] commented 1 week ago

Open in Stackblitz

pnpm add https://pkg.pr.new/fluent-vue/unplugin-fluent-vue@107

commit: 33d9616

rangermeier commented 5 days ago

Thanks @Demivan for preparing this PR. I just tried the parseFtl option on the project I'm currently working on. It's a small project, it uses only two locales and there are currently ~150 strings in each FTL file.

My observations:

File size of parsed FTL files is larger, in my case it went from 13.58kb to 24.46kb uncompressed. With GZIP compression it's 4.97kb vs. 5.51kb.
With parsed FTL file resource.js from fluent-bundle is not packaged anymore, which saves 17.56kb (GZIP 4.6kb)
Performance: There is a measurable but very small performance improvement when loading parsed FTL files, see the table below.

Method	raw FTL	parsed FTL	note
static import	0.21-0.26ms	0.09-0.15ms	`import strings from './locales/en.ftl'`
dynamic import	6-18 ms	5-15ms	`const strings = await import('./locales/en.ftl')`

So, all in all I think it's hard to draw an decisive conclusion which approach should be preferred. For projects with little strings there is in total a small advantage in file size. With more strings, the savings from omitting the FluentResource class will be shadowed by the larger FTL files.

During build I get the following warning, if parseFtl: true is set:

src/locales/en.ftl (1:0): A comment

"/*#__PURE__*/"

in "src/locales/en.ftl" contains an annotation that Rollup cannot interpret due to the position of the comment. The comment will be removed to avoid issues.

Demivan commented 5 days ago

@rangermeier Thanks for such an extensive testing.

I get similar results on my project too. We have a lot more translations, so size diff was +14Kb (Gzip) instead of a reduction, and performance improvement was ~3ms for an average page.

So for small projects, this is clearly a nice addition. You get a smaller bundle size and slightly better performance. For big projects, time to download a bigger bundle would, most likely, negate the runtime performance gain. One benefit I see for big projects is that after a browser caches the bundle, you just get a performance gain with no downside.

I think, I will polish this PR, fix the warning that you got, and merge it. But I'm on the fence whether this should be enabled or disabled by default.

fluent-vue / unplugin-fluent-vue