Hacker News Reader

Comment by Kiro | Hacker News Reader

I don't understand why people need all this. Setting up the boilerplate for a web app manually doesn't take any time at all and only needs to be done once so what is there to automate? Am I the only one still doing it the old school way? Please enlighten me.

View on HN

Yeoman sets up boilerplates for many different kinds of applications, with many different kinds of requirements, and gives you all the tools you need to get started.

This can be as convenient as typing in "yo bootstrap" to set up a generic bootstrap site, to "yo phonegap-backbone" to set up a workflow for a backbone and phonegap application. It not only sets up the directory structures for you, it also manages requirements inside of your project from external parties, test environments, and gives you a nice little live-preview setup with grunt automatically.

For me, it takes a lot of that project setup time out of the way, so I can get started coding rather quickly.

I keep trying Yeoman every couple of versions but so far, it breaks A LOT. It (used?) to set things up in a way that was hard to move to it another backend like rails. Oh, and it breaks a lot.

So I still do most things the old school way. Then I'm done and writing code instead of trying to figure out why Yeoman is broken or the app it generates isn't loading.

That has been my experience too. But to be fair, half the breakages was Grunt, half was Yeoman. Then I figured that the tools I use (coffe, jade, stylus, Flask) all support live-reloading anyway so Yeoman was not useful for me. A simple 20 line bash/powershell script was enough.

Same here. I was going to use it for a recent Angular project, but was greeted with such an enormous list of warnings that I wasn't sure if my project was configured properly and didn't have time to investigate. So far I prefer initializing projects with Compass, then doing the rest manually. Open to checking this out again eventually, but I need more straightforward and reliable results.

Generators can be used for more than initial project scaffolding. Take the backbone[0] or ember[1] generators for models, views, templates, etc. that automatically generate the scaffolding work of creating dirs and files.

To get a the scaffolding for a backbone app, and the pieces of a "blog" MVC module:

    yo backbone # generates your application base and build workflow
    yo backbone:model blog
    yo backbone:collection blog
    yo backbone:router blog
    yo backbone:view blog
    grunt server

[0] https://github.com/yeoman/generator-backbone

[1] https://github.com/yeoman/generator-ember

Bower for package management. JS needs a better package manager for browser packages. (NPM is great for Node-style packages, but bower is becoming the defacto standard for distribution of browser packages.)

Why do you think npm can't be used for browser apps? I publish all my browser code on npm and then use it via browserify. That way I started to write a lot more code which works both in browser and in node.

Simple: Not all node packages work in the browser. It'd be great if I could just say "ok this package will work for the browser, period." Also, with a module format that the browser can use (ie ECMAscript 6)

I haven't understood the need for Bower either. If I want say jQuery or Angular I just go to their websites and copy the CDN url. I don't see the problem to be honest.

The need for something like Bower or Browserify comes when you have complicated projects with lots of dependencies, some more than one level deep.

For example, app A depends on library B which depends on library C. If C is jQuery and those are all the dependencies you have, it's fine; but when a project grows a little larger, you do want a proper system.

This is not an uncommon thing; modularizing an app or library into many small, independent parts is simply good practice.

Concrete example: Our company has a library which is currently monolithic and too big for its own repo, so it needs to be broken up into many different modules.

For this we have to have a dependency system because every module in the library needs to be able to say that it needs another module to run.

Plus, if you are developing an app that uses (a bunch of modules from) the library, you want to be able to work on the module code concurrently. Having to minify/package library code and copy it into the app every time you make a change is very inconvenient.

Plus, eventually you need to bundle a single file, eg. mylib.min.js, that combine all the modules. Also a chore without a dependency system. Might be fine for just isolated one case, gets stupidly annoying for the next project, and the next, and so on.

What I like about Browserify is that you just require libraries in your code where you need them, and that way all dependencies are expressed in code; whereas Bower has explicit metadata, separate from the code, which may get out of sync over time.

Well, I can see it being useful if you're already on the command line or if you have to set up a lot of different projects with different configurations.

From what I understood is:

For normal approach:

1. Google CDN jquery

2. Get the CDN link of jQuery

3. Add it to your template

For Yeoman/Bower:

1. bower install jquery

2. Get the link/path where bower installed jQuery

3. Add it to your template

I'm personally a big fan of component [1]. It acts a lot like NPM, but uses an actual Makefile behind the scenes (I always though Grunt was a tad ugly...).

[1] https://github.com/component/component

Reply on news.ycombinator.com