Add kind of streaming template compilation

[JGantner]

Hi,
i recently added this awesome gulp plugin to one of the apps i'working on. I realized that the slim file compilation is kind of slow. It takes around 7 seconds to compile 9 templates on my MacBookPro.
I guess most of the time is used to start the ruby interpreter and load the gems (i'm using the bundle option). Unfortunately i have no idea how to benchmark the issue.

In my opinion it should be possible to write a command line executable that can compile templates in a streaming fashion (like gulp handles the files) which can be hooked up to the gulp process via a unix pipe.

Does anyone think this may be a good idea? Or has any suggestions?

I'd like to discuss the idea before investing my time and just get my PR's rejected.

Thanks

[jvmccarthy]

Yes, please! A coworker and I have been racking our brains over this exact same thing. The performance is slow, and it seems like starting ruby is taking most of the processing time. I've been kicking around a few ideas here. In a streaming solution, the trick seems to be communicating end of file and detecting a file delimiter in the output stream.

I've taken a few hacks at this and keep getting blocked. Ideally, I would like to work with stdin and stdout communicating with slimrb. Slimrb by default appears to look for an end of file (\x04) to begin processing the input stream. It then prints the output and quits. I've toyed around with the idea of putting in a file delimiter in an html comment, something like <!-- gulp-slim: EOF -->; however, this doesn't work because slimrb won't process stdin until EOF is sent. I could still try to use a file delimiter, but that would require reading all the output into memory and splicing it up to the correct file object in gulp-slim.

It seems like we'll have to write a ruby script to invoke the slim engine through the ruby API. Then, we can coordinate the stream to determine file delimiters.

I've got another issue specific to my usage of slim. I'm used to have slim search the same directory as the file being processed for includes. With streams, slim doesn't know the directory of the file currently being processed. So, I introduced the chdir option in PR #26. I'd like to see a solution that supports the same functionality.

In a number of ways, the plugin is well suited to invoke slimrb for each file. I just wish we didn't have to incur the performance penalty of starting ruby for each file. I hate to say it, because I prefer slim, but this issue is causing me consider Jade. Because the Jade engine is invokable from the node instance running gulp, I imagine it will be much faster to process files.

I think this is a necessity to the usability of this plugin, and I encourage @cognitom to consider this issue.

[JGantner]

... i totally missed your comment. Just read it today. At least i'm not alone with the problem. I'll try to free some time to work on this.

[jvmccarthy]

@JGantner We actually decided to go to jade instead. Slim just isn't well supported or performant for use with node.js based tooling. Jade isn't as robust as slim, but the syntax is fairly similar. The conversion from slim to jade wasn't that difficult for our team. As a further example, we're now using webpack as well, and jade support is a simple add-on. I doubt we'll ever see a slim loader for webpack.

[arkarkark]

might want to look at slm it's nice and fast

[JGantner]

i wasn't able to free up some time so i'm abandoning this idea. Slm looks promising.