Spent a fair amount of time benchmarking the Go code against Sprockets (I was curious.) The Go Javascript serving isn't as fast as the Sprockets implementation currently. One thing that I can think of that could get it closer to that speed would be last modified checks and serving the preprocessed version. Overall though, as far as on my desktop, I wasn't too disappointed with the results. 20ms to serve the Ember.js app (including the debug ember.js & jquery.js files.) compared to 8ms from Rails with Unicorn. Somewhat interesting was the BeagleBone Black took roughly 1400ms to serve the same files from Go. I wasn't able to run the Rails test on BeagleBone Black hardware because...
A good portion of my time was spend trying to figure out why ember-rails on the BeagleBone Black was throwing an "undefined method 'ember'" error when trying to run rails generate ember:bootstrap.
I finished the night off writing unit tests for the template code. I got to about 60% code coverage (of ~150 lines.) Overall, I was pretty happy with how well the code behaved when I started writing tests. A few things that I expected to throw errors or junk output, ended up being handled gracefully. It's likely because I did a fair amount of iterative testing before this point.
Implementing the require_tree was fairly trivial since everything else was basically in place. I was able to make use of filepath.Walk to just walk the files and then run the Javascript processor over the files, one by one.
There are still a few issues with the implementation. For instance, using a require_tree .. is likely going to crash. The easy solution would be to disallow going up directories. A perhaps better solution would be to checksum the files, store that in a hash, and only process files that don't match a processed checksum. This is going to be slower, but should provide a better experience when using it.
Other things that still need to be done are:
Other things that might be interesting. Getting the baseline application layout from ember-rails, getting the uncompressed jQuery, HTMLBars, & Ember.js, and then loading them from application.js with appropriate requires; everything seems to work as expected. It'll be faster, to include these normally, but it's a slightly interesting point of reference that it processed 2020288 bytes in about 20ms. Honestly, this was the end goal I was really hoping to accomplish with this project. I was really wanting to play with Ember from a non-Rails application (specifically in Go) that had Sprockets-like autoloading of Javascript files for quick iterations. The project will likely be going on Github in the next few days after I write some documentation & tests for it.
