Compilation slow?

[der-flo]

I'm interested in your idea of UI components, especially the handover to JavaScript. So I check out your rails sample app. It worked as expected but it was quite slow, at least in the eyes of a Rails developer.
The rendering of your demo#index took ~1900 ms. There are two components involved, demo/index.jsx and layouts/application.jsx. The rendering took >900 ms each.
I was able to track it down further to the call of the faucet compiler/pipeline in https://github.com/complate/complate-ruby/blob/master/lib/complate/compiler.rb#L53 which consumes almost exactly these 900 milliseconds.

Could someone the the maintainers clarify this situation?

[FND]

Hi Florian, thanks for the feedback. That's certainly not the behavior I'd expect.

It's been a while since I've dug into the details here, so would have to refamiliarize myself with the implementation - or better yet, wait for one of the resident experts to respond. Currently that might take a while though.

However, it looks like there are undocumented configuration options:

complate-ruby/lib/complate/template_handler.rb

Lines 32 to 35 in 77ea7ad

	if !Rails.configuration.complate.autocompile
	[id, File.new(Rails.configuration.complate.bundle_path)]
	elsif Rails.configuration.complate.autorefresh
	[id, compile(id, src_file_name)]

Does this address your immediate issue?

(FWIW, there are discussions about replacing the underlying JS engine to improve rendering performance beyond compilation, but nobody's actively working on that right now.)

[der-flo]

However, it looks like there are undocumented configuration options:

complate-ruby/lib/complate/template_handler.rb

Lines 32 to 35 in 77ea7ad

	if !Rails.configuration.complate.autocompile
	[id, File.new(Rails.configuration.complate.bundle_path)]
	elsif Rails.configuration.complate.autorefresh
	[id, compile(id, src_file_name)]

I'm not sure. In development (env) I want to get immediate feedback, so compilation seems unavoidable.

complate-ruby/lib/complate/railtie.rb

Lines 7 to 8 in b63eac8

	config.complate.autocompile = !Rails.env.production?
	config.complate.autorefresh = Rails.env.development?

The defaults of the plugin make sense in my opinion.

(FWIW, there are discussions about replacing the underlying JS engine to improve rendering performance beyond compilation, but nobody's actively working on that right now.)

Jep, I'm aware of the mini_racer limitations. You can't call Ruby methods in the JS world. Being able to call the Rails URL helper methods is one of the compelling features of complate.

[FND]

I typically use a background job for the JavaScript compiler, i.e. faucet --watch (usually launched from a Procfile with the respective application). That gives you incremental (i.e. fast) compilation; would that work for you?

[der-flo]

The sample application is missing a faucet.config.js which makes it a bit hard for me. I'm not that familiar with node and especially faucet.

[FND]

Oh, I didn't realize (or had forgotten) that all happens automagically:

complate-ruby/lib/complate/compiler.rb

Line 40 in b63eac8

tmp_config_file = Tempfile.new(['faucet-config', '.js'])

I can guess why, but would rather wait for our resident experts; I've set myself a reminder to talk to them next week. Thanks for your patience here.

[FND]

So, the idea here was that in dev mode, you'd have a separate JS bundle per view - which should only recompile when the respective view has changed. I'm not quite sure how this maps to the behavior you describe.

However, since nobody is currently using this adaptor (in part due to the aforementioned engine issue), I'm afraid it's effectively unmaintained. While it's possible that someone might revisit this in the future, there's no indication of that right now.

[der-flo]

I'm watching the project. If it leaps forward, I'll get reminded.