Question
If you've used RequireJS with a Rails 3 (esp 3.1) app, how is that working for you? Any configuration tricks or other gotchas that I need to watch out for?
Background
I'm contemplating using RequireJS over the Sprockets-based Asset Pipeline in Rails 3.1, specifically for JavaScript code. I have two motivators for this choice:
I want to leverage RequireJS' module management for my JS client-side code.
I'd like a precompilation system that can follow my JS library code into other contexts. To my surprise, the Asset Pipeline precompiler is a baked-in part of Rails, not a part of Sprockets itself.
All feedback appreciated, thanks!
For posterity, here's where I've come to on this question:
RequireJS provides an implementation of the Asynchronous Module Definition API. RequireJS' Why AMD? page lays out the case as to why you'd want to use this.
Sprockets and the Rails 3 Asset Pipeline allow for simple structuring of JavaScript/CoffeeScript code, but don't provide any true module support. For example, there's no namespace control whatsoever in Sprockets.
jQuery (as of 1.7), Underscore, Dojo and numerous other major libraries have implemented AMD support. Several other major JS libraries seem to have AMD support on the near-term horizion (e.g. Backbone.js).
It's certainly possible to create a Rails app that integrates RequireJS. To simplify that process, I've created the requirejs-rails gem on github, with straightforward configuration and Asset Pipeline-aware precompilation for AMD-based code via r.js. The current release is available via:
gem install requirejs-rails
Related
I am beginning to use Go for web development, but I am having issues with asset management. I would prefer to have a tool like Rails' Asset Pipeline for managing (and compressing) css/js files (as well as SASS), but I am still able to work with css and js files.
While I am able to work with css and js, I am not able to work with SASS. Is there a way to use SASS in a Golang project? I am not using a framework.
Thank you!
I'm not familiar with Ruby on Rails but, I assume, that ruby on rails gave you some sort of tools for managing the source to distribution client-side asset transition (polyfills, transpiling, minification, compiling of SASS/SCSS to CSS, compiling of XScript to JavaScript ... etc).
While a web development framework might do that to try and ease in developers quickly (I assume rails does that, not ruby) its not exactly the way Go does stuff.
Go is a language, not a framework + language, just a compiler, a few build tools and a set of standards for how to write, test, document and indent stuff (with the indent,test and document part being optional).
A go server, at least the way I built servers with go, is somewhat decoupled from the client. It server static assets when they are needed (e.g. it serves the minified JavaScript and the stylsheets and the html, and jsons with info from the databases... etc), but it doesn't really care about what those are, its a server. The go toolchain is made for building golang applications (e.g. said server), but its not made for building client-side web applications (those consisting of js, css and html).
Now, you may use a framework similar to rails written in go that helps "pack up" css, js, html. But I'm unaware if there are any.
You may use a compiler which turns go into client-side code (i.e. javascript) https://github.com/gopherjs/gopherjs , if you enjoy the go toolchian and want to use it for client-side development. But, go-like performance isn't something this gives you AND you are working with a subset of go. Its really just a different way to write javascript.
However, what you most likely need in your case is a "build-chain" for your client side. Here there are 3 tools which (in my opinion) stand out in 2016:
npm
webpack
bower
I could write an essay about using this tools but here's the summary:
Webpack is used to create a "pipeline" for your code which does thing like, calling babel on javascript, compiling sass to css, minifying assets, allowing js to be written with import syntax... etc, really, its a swis army knife in your js development arsenal and probably matches the functionality of whatever you were using before.
Npm is the node package manager BUT even if you are not using node for your server. It can be useful to keep tracks of dependencies for building your application (like webpack) and for downloading modules. Its also useful for running various scripts and deployment, its a bit of an overkill to use both npm and weback though you will probably have an easier time setting up the webpack enviornment if you have a package.json (config file for npm) with each of your project.
Bower is one I actually don't use for small projects. But its basically a repository for javascript libraries (among other things), so you can easily say, write "bower install jquery" and you've downloaded jQuery for your current project.
Again, there are many other tools out there, these are just some of the ones I like, but, check some of them out. They can help you replaces your previous pipeline. Don't think of client and server side code as being the same, they are decoupled and having a strong separation between them might help you a lot.
I'm writing a Sinatra app and I'm quite tired of Sprockets (because it's hard to configure and doesn't support some libs). I'm thinking of moving to Compass for stylesheet management but I haven't found anything similar to it when it comes to scripts. Now I can manually compile coffeescript into Javascript and concatenate the resulting files, but how do I compress them for less size? Thank you very much.
You may take a look at Gulp. Here is the good article about using Gulp with Rails (but it would work for Sinatra too).
Web Essentials for VS20XX offers a bundling feature which I've used. I haven't ever really used the MVC bundling feature. Are there any major differences in functionality? Is it best practice to use the MVC?
In the actual case in question, I'm using OWIN/Katana, MVC 5.
In addition to Shoe's answer, I think these are also worth mentioning:
Less, Sass plugins often require extra work and problems: I have tried dotless, but it couldn't compile Bootstrap Less source, as it's engine was outdated. I have tried other plugin, which required JavaScript engine, which required installing C++ Redistributables on the server.
WebEssentials compiles, minifies and bundles files on save and build, while MVC bundling does that on AppStart. The effect is longer application start time, what can be a problem when IIS kills application often in a favour of other applications
There are a few differences. I don't think a "best practice" exists beyond what you want to work for. Obviously Web Essentials isn't going to be as integrated into MVC as the MVC bundler is. A few points on the MVC bundler.
The MVC bundler won't bundle Less, Sass, CS etc. without a plugin.
So if you have less files for example, you need something like
dotless.
It won't bundle images into sprites.
It supports file versioning so no action is required when jquery
goes from 2.0.0 to 2.0.1, though since bundles are generated on
application start it's a little harder to manage bundle versioning.
There is no manual building of bundles besides defining the Bundle
config file
Turning bundling and minification on/off is as easy as turning
on/off debug mode in the web config or enabling optimizations in the
bundle config.
It supports bundling of CDNs
When your server is running you can make edits to individual files and the bundle will regenerate at runtime
I have seen many questions and differing answers on using the jQuery plugins in the Rails 3.1 asset pipeline, which leads me to believe that this is new enough that it isn't settled science. I have tried using my jQuery plugins in the pipeline, but ran into issues when it came to incorporating the plugin stylesheets.
Now I am trying to back out of that solution, and only put my jQuery plugins and their associated themes and stylesheets in the traditional locations under "public". So, a sort of mixed solution. Then I put the tags back in my layout file to reference these directly.
Of course, now my problem is that Rails only knows to use the asset pipeline, and it's looking in "/assets" for them. They ain't there no more though.
Is there a right way to do this? I don't want to modify these plugins at all, so no changing of the stylesheets or anything else, I want them to just work at this point. Barring a correct way to use jQuery plugins in the Rails 3.1 asset pipeline, is there a way to make Rails use the traditional paths in addition to /assets?
I'm using a tiny gem sprockets-urlrewriter. Citing the readme:
Rewrites relative CSS urls to absolute ones, which means that you can include, for example jQuery UI, without any modifications into the asset pipeline.
So you can put the files in their respective directories and the gem will care about the asset pipeline.
I love compass (SASS) and HAML. I've been using staticmatic for building static web pages. Staticmatic seams outdated (no updates, bugs). What are the alternatives?
What I would like:
$ preview .
> Server started ad port XXXX
> Now you can use Compass and HAML
:). So... no configuratio, no directory structure, just haml and sass files.
I am currently using Compass/Sass/Haml with middleman. https://github.com/tdreyno/middleman It is very easy to use, and runs a sinatra in the background so you can see your changes live in your web browser.
After you are done editing and previewing your markup it builds static HTML from your stack of Compass/Sass/Haml. See https://github.com/tdreyno/middleman/wiki for usage.
This requires no conf at all except to tell it which templating engines you are using at setup so I think it is exactly what you are looking for.
You can try jekyll. I think it doesn't work with sass and haml out of the box but you can look at plugins
Don't forget Nanoc. While it is a little involved, it has some slightly more powerful features than StaticMatic. It does depend on a directory however. :/
There are just a ton of static generators around, most of them in Ruby. I'm planning to use Frank for the next few static projects.
It uses Tilt to support a ton of template engines
It has a concept of layouts, which go in a separate layouts folder, and templates can have a metadata header, but other than that it's very minimal.