Should we build handlebar assets into templating_assets (or better name)

[AlexRiedler]

I am submitting this issue to promote discussion...

Mainly wondering if it would make more sense to build a more generic Adapter interface for various libv8/javascript rendered asset pipelines (e.g. merge handlebar_assets and mustache_assets etc...)

Any thoughts?

[eddietejeda]

Given that I recently submitted #64, I think this makes sense. I am curious to know what the concerns are of moving in this direction.

[AlexRiedler]

my only concerns are performance overhead actually; but I don't really think that will be an issue if we think about it carefully.

I am also slightly scared that some incoming requirement will be needed only on one-adapter that might hurt the others... I could try to do this as a separate gem if there is enough interest and maybe we can combine efforts!

[leshill]

Hi @eddietejeda, @AlexRiedler,

Yes, this is a good idea. I have been considering extracting the commonality from handlebars_assets and hogan_assets for some time. I am going to take a pass at making this into a generic javascript asset compiler gem. I will post back here (later today?) once I have it up on github.

[AlexRiedler]

https://github.com/AlexRiedler/tilt_action_view and https://github.com/AlexRiedler/handlebars_assets might be of interest in that case (recent stuff I have been starting to work on); basically have implemented handlebars_assets with server-side rendering -- but there is a fair bit off odd code added as a result of how handlebars_assets was originally implemented. I think the best option is to just build a generic Tilt JS module (I started one in tilt_action_view but it is pretty broken right now); then I can do the rest of the patching.

[leshill]

Hi @AlexRiedler,

Cool! Yup, there are a number of competing factors here. Support for additional processing (i.e. haml and slim), better support for views and reuse from within Rails, etc…

The initial approach (which should be ready this evening) is to allow you to register and precompile with a JavaScript tool chain, like handlebars.js.

[leshill]

Hi @AlexRiedler, @eddietejeda,

I put up my rough WIP here https://github.com/leshill/js_assets/tree/initial_implementation . This is just a refactored extraction of just the JS machinery without the handlebars specific features. Next step is loading the JS compiler (source files) just once per asset pipeline invocation.

[AlexRiedler]

nice work 👍; I refactored both my repository and the fork again (you might want to check them out again, especially some of the TODOS). it also appears I have got it compiling in my repos for shared handlebars_assets by adding those gems (and fixing up the Sprockets::Context for Rails Helpers).

(maybe I should start posting these on the new repo?)
Should we separate into two ExecJS runtimes; or two-per-thread?

1. Consider runtime performance if the backend is rendering; and performance for threaded applications.
2. Having a runtime instance + compile instance (e.g. in the case it can be precompiled)

I think the bigger trick here is going to be sharing precompiled assets with the ActionView and Sprockets pipelines... I have not figured out exactly what to do here exactly (I think you could ask Sprockets for the precompiled potentially, at least in newer versions).

Things I am still trying to solve (possibly outside the scope of this gem)

• Internationalized Assets (is this even possible?), basically generate NUM_LANG * ASSET_FILES; and then a tag helper to include the correct one based on the users internationalization.

FYI you can contact me on irc.freenode.net username: ariedler if that is useful