Trying out Mimosa

[Joe Abbate]

Hello,

My background: mostly Python web frameworks (CherryPy, Werkzeug/Jinja),
discovered AngularJS less than a year ago, and almost concurrently
Brunch (which seemed like a saviour compared to Grunt/Yeoman), in last
few months dabbled with Ractive, Backbone and Ember.

I found Mimosa yesterday and the initial impression was encouraging
enough to prompt a deeper look. I briefly experimented with
mimosa-ember-emblem-templates, mimosa-minimal and a barebones set up
(mimosa new) with pure HTML/CSS/JS.

Maybe it's because I haven't quite yet wrapped my head around
AMD/CommonJS (bad pun), but what I found most confusing about Mimosa is
that the public/build directory only has .js and .css files, *no* .html.
In the barebones case, there's a couple of index*.html files in
'views'. In the other two, the index.jade compiled content doesn't
appear to be in files under public. It seems a webserver would have to
serve the index.* from 'views' while keeping the root at 'public' or a
manual step would be required to place the index.html under public.

I had some trouble running 'mimosa build -op' in
mimosa-ember-emblem-templates (e.g., "Error: Module loading did not
complete for: app/models/TabModel, controllers/tabListController,
models/TabModel") and in the barebones area (probably because it doesn't
have a server). In mimosa-minimal, build -op doesn't seem to do
anything different than plain build. So I don't know if Mimosa can
achieve something comparable to Brunch, where by default all CSS ends in
one file (app.css) and the JS ends in vendor.js and app.js. In
development mode, perhaps file concatenation isn't that critical, but if
there are many JS files, it's a useful optimization. I haven't been
able to determine if that's possible with Mimosa.

I'm currently using Brunch in a site that has little JS, but it
compiles, packages and optimizes Stylus files nicely (JS and CSS are
served by nginx, although HTML comes from a Python backend). There will
be more JS coming, so I'm wondering if Mimosa is a good fit. Mimosa's
use of a plain makefile doesn't inspire confidence in that respect
because I could replace Brunch with my own makefile for deployment (but
would lose live reload for development).

I don't want to sound all negative: I like convention over
configuration, a somewhat flatter directory structure, Bower
integration, most of the Mimosa "favorites" (CoffeeScript, Stylus,
Express), and test integration.

Joe

[Ken Carpenter]

Hi Joe,

I'm pretty new to Mimosa myself, but from what I know, I can say that all the things you want to do (and a lot more) are possible in Mimosa.

Mimosa is definitely capable of obfuscating/minifying your Javascript into a single file, as well as compiling all your SASS/LESS/native CSS into a single CSS file.

If you install some additional modules with:

  mimosa mod:install mimosa-web-package  (you might need to sudo)

  mimosa mod:install mimosa-combine

Then you can run build -op and Mimosa will optimize and package your app in a dist folder that you can upload to a server.

See these resources for help:

    http://mimosa.io/optimization.html

    https://github.com/dbashford/mimosa-combine

That folder contains a public folder with a javascripts folder and stylesheets folder that will contain your merged scripts and styles respectively.

Well, in theory it does that, but I'm having some trouble making mimosa-combine work actually. :-)

The use of a "plain makefile" is just a convenience so that people unfamiliar with Mimosa can still build and/or deploy your app.  You could delete the makefile and still have all the goodness of Mimosa at your command.  Makefiles are not part of the standard Mimosa configuration.

Mimosa can also help you deploy your app, although I haven't tried that yet.

Ken

[dbashford]

I'll end up echoing some of his answers.

1. makefile, Ken nailed it, purely a convenience.  I've never used it myself.  Someone asked for it over a year ago so I tossed it in as something that gets included with "mimosa new".

2. There are ton of options with .html files.  If you are using Angular, you are probably using .html files as your templates?  In that case they'll just be copied over if you put them in assets.  Or are you talking about server assets?  The layout of a mimosa new project is based on the layout of an Express application, see below.  It seems you are new-ish to node?  So it makes sense that that layout doesn't make sense to you.  node often IS what is serving assets. 

If you don't like having your server views outside of your client assets, you can put them in assets and point mimosa at them.  Again, nothing stopping you, but because all the server options are node ones, the project layouts you see are node application layouts.  We have a project at my 9-to-5 that has jade views in a /views for the Express app we run in dev.  But we deploy to a non-node enviroment and we use mimosa-server-template-compile which by default dumps the compiled jade files into public.  (And none of this has anything to do with AMD/CommonJS)

$ express bar

   create : bar
   create : bar/package.json
   create : bar/app.js
   create : bar/public
   create : bar/routes
   create : bar/routes/index.js
   create : bar/routes/user.js
   create : bar/views
   create : bar/views/layout.jade
   create : bar/views/index.jade
   create : bar/public/images
   create : bar/public/javascripts
   create : bar/public/stylesheets
   create : bar/public/stylesheets/style.css

3. "-p" is a flag to let packaging modules know that they need to do their stuff.  mimosa-minimal, mimosa-ember-emblem-templates, and "mimosa new" apps do not have a packaging module.  So -p will do nothing.  The only packaging module that I know of is mimosa-web-package.  You have to have that in your project to get packaging.  Just add "web-package" to your modules array.

4. I'm not sure why you aren't seeing your JavaScript files concated and minified.  "mimosa new" projects should have no trouble having all the .js packaged into a single file with mimosa build -o.  Most of the mimosa skeleton projects use requirejs and its the "require" module that is responsible for understanding your requirejs app and how to optimize it.  If you prefer to not use AMD/require, there is a mimosa-browserify module that will optimize your commonjs apps.  It's not as "smart" as the require module, so it requires more config.

And, btw, I would argue that in development mode there is 0 value in concatenating files.  We have require apps that locally load up in seconds, and which take seconds to bundle when we do build them.  So you can have your app re-bundled every time you change a file, which itself takes time, or you can serve up individual files, a much faster build and a little longer load time, but with a much easier debugging experience.

5. There are two ways to merge CSS.  On one hand, things like Stylus/LESS/SASS do that themselves.  It's easy to have a base Stylus file that pulls in everything else.  Mimosa works hard to understand which files are the "base" CSS files and only compiles those.  If you have vendor CSS that you want to package together as a "vendor.css", the mimosa-combine module is what you'd need for that.  This is an example config from one of our prod apps, it combines all the stylesheets in vendor (order is unimportant in this case) and excludes some from the output.

  combine: {
    folders:[
      {
        folder:"stylesheets/vendor",
        output:"stylesheets/vendor.css",
        exclude: [
          "foundation/foundation.css",
          "foundation/normalize.css",
          "leaflet/leaflet.css",
          "leaflet.draw/leaflet.draw.css",
          /\.png$/
        ]
      }
    ]
  },

6. Mimosa does have a single "install" module, for deploiying to s3.  It's not mine but I've used it with success.  Most of our apps have very custom install needs so for those we use adhoc-modules, https://github.com/dbashford/mimosa-adhoc-module, which all you to toss in very specific code to do anything you want at any step of Mimosa's various workflows.  We use it to SCP the output of web-package to specific folders on specific servers in our prod env.  I created the "adhoc" meta-module a month or so ago and its been huge for us.  Sometimes you want to build something very specific and hard-coded to your app and not have to worry about it being publicly usable or configurable.  I hope to blog about this soon as it is very powerful.  It's also a great great way to build new modules you actually intend to distribute, just to get started.

Hope that all helps.  If you have any questions left, please feel free to ask em.  I hope that narrowed your list down some. =)

[dbashford]

Did a quick check on github, found this one being edited recently, it has a lot of things that vary from the basic mimosa set up.  Among other things It has .html in the assets directory and no server.

https://github.com/warricksothr/Web-App-Seed

[Joe Abbate]

Hello David,

On 15/05/14 23:09, dbashford wrote:
> 2. There are ton of options with .html files. If you are using Angular,
> you are probably using .html files as your templates? In that case
> they'll just be copied over if you put them in assets. Or are you
> talking about server assets? The layout of a mimosa new project is
> based on the layout of an Express application, see below. It seems you
> are new-ish to node?

Yes, that's a fair assessment.

> So it makes sense that that layout doesn't make
> sense to you. node often IS what is serving assets.
>
> If you don't like having your server views outside of your client
> assets, you can put them in assets and point mimosa at them. Again,

This may be a bit of terminology differences. I don't think I've seen a
definition of "assets", except that in the context of Brunch
configuration conventions "assets" refers to anything that "won't be
compiled and will be just moved to public directory instead." So I
tend not to think of .coffee, .styl, etc. as "assets".

> nothing stopping you, but because all the server options are node ones,
> the project layouts you see are node application layouts. We have a
> project at my 9-to-5 that has jade views in a /views for the Express app
> we run in dev. But we deploy to a non-node enviroment and we use
> mimosa-server-template-compile which by default dumps the compiled jade
> files into public. (And none of this has anything to do with AMD/CommonJS)

OK, I added mimosa-server-template-compile to the mimosa-minimal config
and that indeed created a build/index.html from the views/index.jade.
But if I understand correctly from the first para above, I could just
put .html files under assets/ and they'll be copied over to public/ so
that they can be served by nginx or some other server instead of, say,
express.

> $ express bar
>
> create : bar
> create : bar/package.json

> [...]
> create : bar/public/stylesheets/style.css

I wasn't familiar with the express-generator (which is where this comes
from), only with the API.

> 3. "-p" is a flag to let packaging modules know that they need to do
> their stuff. mimosa-minimal, mimosa-ember-emblem-templates, and "mimosa
> new" apps do not have a packaging module. So -p will do nothing. The
> only packaging module that I know of is mimosa-web-package. You have to
> have that in your project to get packaging. Just add "web-package" to
> your modules array.

Actually, mimosa-ember-emblem-templates *does* include web-package.
Hence, the errors I mentioned.

> 4. I'm not sure why you aren't seeing your JavaScript files concated and
> minified. "mimosa new" projects should have no trouble having all the
> .js packaged into a single file with mimosa build -o. Most of the
> mimosa skeleton projects use requirejs and its the "require" module that
> is responsible for understanding your requirejs app and how to optimize
> it. If you prefer to not use AMD/require, there is a mimosa-browserify
> module that will optimize your commonjs apps. It's not as "smart" as
> the require module, so it requires more config.

I didn't try very hard to get them concat'd, thinking that -o or -p
would do the trick but as I said I ran into errors.

> And, btw, I would argue that in development mode there is 0 value in
> concatenating files. We have require apps that locally load up in
> seconds, and which take seconds to bundle when we do build them. So you
> can have your app re-bundled every time you change a file, which itself
> takes time, or you can serve up individual files, a much faster build
> and a little longer load time, but with a much easier debugging experience.

I agree that concat'ing in dev mode probably has negligible value but I
guess it depends on using Require/CommonJS. If not using one of those,
using a couple of script tags as Brunch does, vs. maintaining multiple
ones may be advantageous (note that I'm *not* arguing in favor of the
un-modularized approach).

> [snip]

>
> Hope that all helps. If you have any questions left, please feel free
> to ask em. I hope that narrowed your list down some. =)

Yes, indeed. Thank you.

Joe