Processing web assets

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Processing web assets

uris77
My thoughts and attempt at streamlining the processing of web assets:  
http://blog.stumblingoncode.com/posts/2014-09-11-ratpack-asset-processing.html
Reply | Threaded
Open this post in threaded view
|

Re: Processing web assets

danhyun
There's definitely talk about this and exciting things are happening https://twitter.com/davydotcom/status/510185423298387968 which I think you mentioned at the end of your post.

I don't know if you already saw but ratpack.io is has some sass watching stuff https://github.com/ratpack/ratpack/blob/master/ratpack-site/ratpack-site.gradle.

I think people will be very happy once the asset-pipeline standalone is ready.
Reply | Threaded
Open this post in threaded view
|

Re: Processing web assets

uris77
Yeah, that is an option. My only issue with it is that it needs to be 'embedded' in ratpack. I think asset processing should not be part of Ratpack. I think it is a build process. So ideally, if the asset pipeline can be converted into a gradle plugin that can be used in any java project, then that would be best (imho). That would give us a universal way of organizing our javascripts.

Another reason I want to treat the web assets (especially javascript) as a project(or subproject) is because it enables us to easily try out different backend frameworks. For example, I could just dump my javascript project into a spring boot project and only implement the web services so I can get a feel for it. I don't have to learn any new way of building or organizing the assets.

The build should also be flexible enough that I can use any new front end technology without too much effort. For example, swap out ng-annotate for ngmin, use recess instead of grunt-less, etc. Having this baked into something like spring boot or ratpack will make this very difficult and lead to unnecessary bloat.


I did look at the sass plugin. It seemed to me that it started the jruby process in a different process, which is what enabled it to be sent to the background. The watch plugin is not that decoupled, so couldn't do that. Would have to fork the project (maybe this weekend) and try out some stuff. Ideally tho, I think gradle should give us that option, or at least a give us the ability to grab a task and run it programmatically anytime we want. This way we can just spin a task inside a thread.

Reply | Threaded
Open this post in threaded view
|

Re: Processing web assets

Luke Daley
Administrator
I’m not very keen on any runtime asset management based solution for the reasons you point out Roberto. I think it should be done at the build layer. Hopefully, some of the asset-pipeline stuff can be integrated at that level.

One thing that does need a runtime component is eternally cacheable link generation. I’ve made a start on this (i.e. have done some experiments) for the Ratpack site itself: https://github.com/ratpack/ratpack/blob/master/ratpack-site/src/main/groovy/ratpack/site/SiteModule.groovy#L54

The idea is that something like this will ship with Ratpack core. It simply provides checksums of the files in the Ratpack base dir.