This initial RFC is being replaced with individual issues.

The work on v2 has officially begun! Check out the v2 release PR!

Checklist

• API & code changes
  • exported Vavilon instance (Export Vavilon instance #24)
  • removed for class="vavilon" (Remove the required vavilon CSS class #25)
  • string interpolation (String interpolation #26)
  • dropped ES3 support (Drop ECMAScript 3 support? #27)
  • new dictionary format
• Documentation
  • API docs
  • Docs translation
  • README cleanup
• Performance
  • Keep it under 1KiB
  • Speed of operations
• New packages
  • @vavilon/renderer
  • @vavilon/cli
  • Plugins

This issue will introduce my vision and thoughts on how vavilon.js should be rebuilt, how it could be enhanced and what other packages should there be in the vavilon family. Any comments, thoughts, and ideas are welcome here.

API & code changes

The problem with vavilon.js' API is the lack of such. v2 is about to change that.

Exported Vavilon instance

See #24.

Removed for class="vavilon"

See #25.

String interpolation

See #26.

Dropped ES3 support

See #27.

New dictionary format

I want to rethink how dictionaries are stored and loaded. The current way of loading dictionaries per XHR is not that bad, but I kinda feel like it could be better, like, being more native to browsers. Maybe the object structure will have to change, maybe it should be a different format. I also have not yet tested that the dictionaries are loading asynchronously and not stop the page loading.

Documentation

API Docs

Since vavilon.js is getting an API upgrade, there should be a more detailed API description.

Docs translation

Since vavilon.js is all about i18n, I better translate the docs to other languages, at least to languages I know.

README cleanup

The logo in the readme doesn't work for a while now, and the badges are too excessive. I believe that README has to be compact and clear.

Browser support

I believe we'll need to define the browser stack we want vavilon.js to work on and test the hell out of it. Users have to be sure that it's not just "ES5", but "IE9".

Performance

Keep the size under 1 KiB

The size is very important since vavilon.js has to be loaded as soon as the page has started to load. The new version will probably not be able to keep the size at the same level, but 1 KiB (1024 bytes) is the largest I want to go for.

Speed of operations

vavilon.js is working with DOM, large objects and cookies. We need to check whether all of the operations being executed are the fastest way to do stuff. We might have to sit through a lot of benchmarking for this.

New packages

These are independent of the v2 of vavilon.js and will probably be released later

@vavilon/renderer

vavilon.js is not the best bet for SEO, as the search engines will only see the website in its original language. Websites are also prone to flashing the original language. Both of these features can be combatted without the need for SSR.

Serverless platforms like Zeit Now or Netlify let you use serverless functions, that render the HTTP response based on parameters, thus creating a simple backend.

vavilon-renderer is a package that would turn the string, containing HTML with vavilon data-tags into translated HTML based on the user cookies and the dictionary files.

@vavilon/cli

vavilon-cli is a CLI with a set of tools that can help speed up the work process:

• vavilon extract — takes the HTML with vavilon data-tags and produces the default dictionary for that website
• vavilon convert — converts dictionaries between vavilon-formats (old and new) and other formats, like .po (gettext), .strings (iOS/macOS) or .xml (Android)
• vavilon render — utilizes the vavilon-renderer package to render multiple HTML-files

Plugins

There are also plans to include renderer plugins for popular build engines, such as Webpack, Parcel, Gulp, Grunt, Rollup and maybe others.