Thoughts on Yeoman/Frontend Assets/etc

[Dylan Hassinger]

Hi everybody -

I have been reading the threads on Github about Yeoman integration and the asset manager, and doing some research into the various libraries that are out there. Here's an attempt to provide some background info, and share my thoughts.

* I am new to a lot of this stuff, so feel free to correct any misunderstandings!

It gets weird quick because Yeoman is really 3 pieces:

• Grunt - task manager
• Yo - scaffolding generator
• Bower - frontend package manager

Which reveals that there's really several different systems we're talking about:

• Task launcher/build maker
• Scaffolding generator
• Frontend package manager
• Frontend asset pipeline bundler
• Frontend template/component system

I'll run through each of these, one step at a time.

Builder/Task Launcher/Scaffolding

Grunt has become a standard, so it would be sexy to integrate it. Potentially, the whole "sails lift" action could be driven by Grunt.  Perhaps the asset minification could also be driven by grunt, however most of the asset pipeline tools already do that step themselves.

Similarly, the initial "new testProject" buildout could be rebuilt to be driven by Yo. This Github comment describes Grunt and Yo integration, sounds cool but not world-changing. Either way.

Alternative tools that do building and scaffolding are Jake (more light-weight) and Volo (heavier, see below).

Frontend Package Manager

The frontend package manager's job is to let us specify external modules to include, and download them into our codebase. There's a few different frontend package managers out there. They all do things that a little differently:

• JamJS - uses their own special repo, includes JS only. 
• Bower - uses Github repos, includes full page JS/CSS/HTML.
• Component.io - uses Github repos, includes modular components with JS/CSS/HTML
• Volo - uses special repo, full page JS/CSS/HTML package manager, plus does building/scaffolding
  

Of these, I like JamJS, because it's the simplest and most modular. It has a lot of packages in its registry, and any of them can be inserted into the frontend by simply adding a line to package.json. 

How beautiful this can be :)

The package managers that include CSS and HTML in them make it much more difficult to integrate, because those things are meant to be edited. But JamJS is Javascript-only, and the included files are meant to be untouched.

I am currently working on a modification to asset-rack that would automatically include JamJS libraries into the bundling process. However I am a newb so it's coming along slowly! ha

Here's another great breakdown of frontend package managers.

Asset Pipeline

The asset manager's job is to apply pre-processors, then bundle JS and CSS, minify them, and insert into the browser. There's a few different asset managers out on the market, here's a quick rundown:

• Asset-Rack - Current sails implementation is based on this? It does the job
• Nap - this is a little heavier than Asset-rack, but I love the syntax that lets you specify the order of files.
• RequireJS - an emerging standard for frontend JS bundling. It's cool, but a little heavy for my tastes
• Snockets - lighter weight JS bundler, based on Rails' Sprockets
• Browserify - pulls backend Node modules into the frontend
• RequireCSS - more than just a bundler, this tries to be a whole frontend component system and fails

To me, it's a battle between Asset-Rack and Nap.   Asset-Rack includes more addons, but it's a little more complicated too - and it's not quite as active.  Nap is leaner, has a prettier syntax, and is being updated every week. 

The current system is pretty good, but I'd like to modify it in 3 ways:

1. be able to specify order of files
2. add JamJS integration to the Javascript bundler
3. be able to specify header or footer location for Javascript

Because of Nap's simple syntax, I think all 3 would be pretty easy to do there (Nap already does #1). On the other hand, I bet they'd all be do-able with Asset-Rack too.

One other thing - it would be nice if we can break out the asset manager into an included module, so that it's not in the core. I have no idea if this would be easier with one choice or the other.

The good news is, none of these big changes need happen immediately. Asset-rack is doing a pretty good job now.

Frontend Template/Component System

Moving to the actual frontend view system, the options suddenly explode. I think there could be a lot of advances here - but that they should be balanced with a frontend-agnostic, modular approach. Component and Bower trouble me, because they sink their teeth too deep into the frontend architecture.  

The good news is, we're starting from a great base that is easy to understand and very flexible.  (Which means, maybe we could have different competing solutions - each of which can bolt onto the existing foundation.)

I have some ideas of my own to contribute here, some that would be low-impact and might fit into Sails core - and some that would be best as an add-on. In general, I think we should tread lightly; but over time, we can create the most badass view system of any framework.

TL;DR

• Grunt and Yo are whatever
• For now, what if we integrate JamJS into the current Asset Rack?
• We should either modify Asset-Rack to allow specifying the order of JS files, or switch to Nap
• We can improve the view system more, but let's keep it modular and do it one step at a time

Okay that's it for now.  Love to hear any feedback! 

Apologies again for any place where I'm misunderstanding or just plain wrong. And thanks to whoever pointed out Nap, it's new to me but I like it a lot.

dylan

[Prajwal Manjunath]

JamJS is terrible at the moment. Bower is better in every way.

See http://abjecterror.wordpress.com/2013/04/14/the-problem-with-jamjs/

As for Sails lift() being driven by grunt, you must understand Grunt was designed specifically for use outside the typical node/express environment. 90% of the things grunt is currently being used for is already done in Sails by connect-assets. What's left of Grunt may be useful for Sailers, by automating the test-running and maybe watching for changes and reloading the app, which most people already have cake files for. So all in all, a fairly minor improvement.