Replace Sprockets with Half Pipe

rubyonrails-core
1

Hi,

Is there any chance of one day replacing Sprockets with Half Pipe?

It looks like such a great project but seems to be lacking the resources to bring it to its prime.

Thanks!

Frank

2

Why would the community do that? What are the benefits? Why is Sprockets bad? Why would we replace it with something that is not up to its prime? Wouldn’t we have to rewrite a whole bunch of Rails code and documentation?

So many questions.

I’m pretty hard -1 on this.

3

As someone who uses Bower and thinks it’s pretty cool, I think requiring a default out-of-the-box Rails app to have node.js as a dependency is a non-starter. Folks who want to get that functionality can customize their own apps without dramatically expanding the web of dependencies for folks building apps on the default stack.

4

Rails already has a Node dependency in CoffeeScript.

5

În data de Tue, 10 Jun 2014 01:36:57 +0300, Ryan Bigg <radarlistener@gmail.com> a scris:

Why would the community do that? What are the benefits? Why is Sprockets bad? Why would we replace it with something that is >not up to its prime? Wouldn't we have to rewrite a whole bunch of Rails code and documentation?

Also consider the fact that developers who started using already a JavaScript build tool (grunt, gulp, broccoli) will unlikely consider switching back to a Ruby based tool. I also believe splitting JavaScript from Ruby became one of the best practices lately (see the same ember-appkit-rails).

6

To be exact, you need one of the supported ExecJS runtimes: https://github.com/sstephenson/execjs#execjs.

7

That’s right, you can run CoffeeScript without Node or V8 on Windows, Mac or JRuby

8

I believe the main frustration about Sprockets (not really its fault) is about JS dependencies management.

People often don't want to embed their JS libraries and frameworks in their source code. Some will prefer doing this due to the way how it integrates to their flow using JS tools.

Personally I'm using rails-assets.org for managing most of my JS dependencies.

What I'm saying is that there *is* the need for better dependencies management of JS code and there are lots of people trying many alternatives in order to overcome this lack of integrated dependencies management for the client-side code.

You'll find lots of gems that are only bundling JS assets with almost no Ruby code on them. This is one of the approaches. The one jquery-rails uses for instance.

The rails-assets project tries to automatically convert Bower dependencies to gems in their own repository rather than polluting the main RubyGems repo with tons of JS wrapper gems. It's not a perfect solution since there are several cases that it can't deal with, but it usually works great for many JS libraries and frameworks. Also, it has to deal with assets paths when converting the bower packages to gems so that they integrate well with Rails.

While I can see how Sprockets is not a good enough solution, I don't think that forcing users to convert their libraries in a RequireJS module is a good thing.

I'd love to see some solid integrated JS dependency management tool to play well with Rails but I'm not sure if this is gonna happen any time soon. Even for JS ecosystem it doesn't seem there is any consensus about what dependency management tool to use (in Ruby RubyGems is the de-facto standard for sure),

I'll keep using rails-assets.org until a better alternative comes up.

9

Right, I guess I've had enough troubles with the 'builtin' JS runtimes in Mac/Windows that I always end up installing Node anyway. :confused:

10

Why would the community do that? What are the benefits? Why is Sprockets bad?

I’m no expert, but what I like about it is:

Why would we replace it with something that is not up to its prime?

I’m not saying let’s replace it right away. Unless we can recruit more devs, bringing it to its prime might take a while as right now it’s just one guy, Mr Joe Fiorini.

11

“No more ExecJS” isn’t a big benefit on my opinion, as I mentioned in other email, there are a lot of people using Rails without Node.js using the alternatives supported by ExecJS. Sprockets also supports live-reload and you can integrate it with Bower [1][2]

We’re already discussing the idea of integrate Rails with Bower by default, Sprockets already have some support for it. Our main concern about Bower is making Node.js a dependency of Rails.

[1] http://dev.af83.com/2013/01/02/managing-rails-assets-with-bower.html

[2] http://joelencioni.com/blog/2014/01/03/integrating-bower-with-rails/

12

This is not just a matter of preferences. When I was investigating why compiling my CoffeeScript files was so slow with Sprockets when compared to the "coffee" command I realized the overhead of spawning a new process for every CS file was the culprit.

Replacing Node.js with therubyracer gem saved us 15s when compiling the assets. Running "time rake assets:clobber assets:precompile" takes about 15s for our application. If I use EXECJS_RUNTIME=Node it takes about 30s.

I don't have any experience on Mac or Windows though.

13

I’m curious (mostly afraid of, actually) about what this mean. Are you talking about automatically refreshing the page when the assets change? If so, I hope this is not enabled by default. I wouldn’t use something like this while developing my application. Well, I was never really very fond of RequireJS and haven’t used it yet as I much prefer the approach taken by the Rails Asset Pipeline/Sprockets (this and automatic code reloading are the main reasons I prefer Rails over other alternatives). I think Sprockets directives a much better alternative to overcome the lack of a require/import statement in JS. RequireJS (and similar approaches) seems like an unnecessary complication from my point of view. I haven’t spent any fair amount of time thinking about alternatives, but I’m pretty sure a better solution than using AMD exists until we target ES6. I must be blind then as I can’t see it :wink:

14

As the creator and maintainer of Half Pipe, I feel I should weigh in here. I agree with the overall sentiment here that it is not ready to be a general-purpose Sprockets replacement, nor am I convinced that it should be. Obviously I have some opinions around using Sprockets, but at the end of the day the Rails asset pipeline got people talking/caring about better asset management, which is what matters most.

I do believe that the Asset Pipeline is currently a little short-sighted. The term itself is a misdirection, as “Asset Pipeline” really means “Sprockets”. In order to use anything else, you are essentially monkey-patching, which is what the whole Rails/Merb merge was trying to get rid of. To make something else the default in Rails only exacerbates that problem, it doesn’t solve it. I would rather see easier ways to hook into the asset pipeline with our own tools, and make Sprockets optional. I have only just begun to think of what that would look like, so I unfortunately can’t propose anything specific right now.

This is an important issue though. Now that Rails is a default choice for so many teams, we’re seeing more and more specialists needing to code on projects who don’t have a competency in Ruby. In fact, many of them are already familiar with the plethora of choices in the Node ecosystem. For them, using Sprockets only slows them down, and makes it harder to reuse existing code. In fact, that’s the very reason I looked to Rails as inspiration when building Half Pipe: it generates an opinionated, default Grunt setup, but makes it easy to change that to anything else it needs to be (I have a project right now where I’m using Broccoli & ES6 modules without requirejs, but still used Half Pipe to set it all up).

For me, and many other developers I’ve worked with, using Sprockets (or rails-assets) to abstract away the systems I already use in other projects is more of a curse than a blessing. I know the systems, so I’d rather just use them.

At the end of the day, the question of “should Half Pipe replace Sprockets” is not the one we should be asking. The right question is “how do we make it easier for anything to replace Sprockets”.

Would the core team consider approaches that make the asset pipeline more configurable?

15

Sure, but I think we need to be more explicit what means more configurable.

Right now rails doesn’t have anything about the assets pipeline and everything related to it (configurations and even the code that make the assets helper works) lives on the sprockets-rails repository. As far I know if you don’t require the sprockets/railtie you should be able to not use sprockets at all and use any custom assets pipeline you want. Of course Rails will only be able to server asset on the public folder but I think you could make grunt/gulp to generate the result assets there.

Rafael Mendonça França http://twitter.com/rafaelfranca https://github.com/rafaelfranca

​

16

This is not that simple if you take into account the whole ecosystem. For instance if you want engines to be able to share assets, like JQuery…

I don’t really know how to properly handle those cases but I guess it would be possible if Rails could provide a minimum API somehow to allow that in some way it would be independent from the assets pipeline implementation. But since dependencies are handled so differently among the available approaches I have no idea on how such API could look like if it’s possible to exist…

17

Interesting discussion you guys. Keep Going.

18

Hi Flori, can you provide some details about what problems are you having replacing Sprockets in Rails apps?

In new apps you can disable Sprockets with --skip-sprockets flag:

rails new foo --skip-sprockets

in existing apps you need to edit the config/application.rb file and comment this line:

require ‘rails/all’

And instead require the frameworks you want to use:

require “active_record/railtie”

require “action_controller/railtie”

require “action_view/railtie”

require “action_mailer/railtie”

require “rails/test_unit/railtie”

require “sprockets/railtie” # comment to disable sprockets

That’s the same procedure people use to replace other components like ActiveRecord with alternatives like Mongoid.

Best Regards.