4 ms·

I don't agree. Recently I started to work with node.js and after switching from Rails where you have a pre-configured ready-to-go project within seconds, with

• kragen 15y ago
  > Recently I started to work with node.js and after switching from Rails where you have a pre-configured ready-to-go project within seconds, with node you need to assemble the whole thing yourself. I haven't used Rails in a while, but last time I used it, the "boilerplate" in the newly created project was something like 20 lines, not 1000. But I object to that, too. If you need 1000 lines of text to have a ready-to-go software project, your development tools suck. > Am I supposed to just choose something for myself re-inventing the wheel again? The things that you aren't inventing shouldn't be in your project; they should be in a library. Your project should have only the stuff you're inventing. (Subject to "eliminate dependencies", of course.) That way, you can upgrade to a new version of the stuff you're not inventing later, fixing bugs and adding features in it; and somebody looking at two of your projects can see what's the same and what's different between them without resorting to running diff. I mean, seriously, this is one of the two most fundamental things about programming. If you disagree with it, it's not a matter of us having different subjective opinions. It's a matter of you being completely sodding ignorant about how to program. Of course, there are overall similarities in structure; lots of C projects, for example, have a main.c, a .h file corresponding to each other .c file, and a Makefile. But generating a "boilerplate" project with stuff you edit doesn't save you any significant time over just giving you an example project you can look at and then type.
  • Vitaly 15y ago
    First of all, the stuff you are not inventing NOT always should be in the library. sometimes the best a library can do is to have a generator, let people run it and modify the resulting code. > I haven't used Rails in a while, but last time I used it, the "boilerplate" in the newly created project was something like 20 lines, not 1000. But I object to that, too. "config" directory alone in the newly generated Rails project is 330 lines. and another 60 in "app", 25 in "test". Those are mostly comments and configuration variables, but thats the whole idea. > If you need 1000 lines of text to have a ready-to-go software project, your development tools suck. you completely missed the point. The reason I'm looking for the boilerplate is because the library "sucks", not the tools. expressjs doesn't provide me with what I need. had express js generated a full featured project for me ready to customize like rails does, I wouldn't be looking at boilerplates. Where am I supposed to put my models? I'll go with app/models but thats ONLY because I've used such layout with Rails. I'm sure a lot of express developers are "sticking" their models somewhere else. With express you need to decide where to put every single thing you need in your project instead of just 'lets use the standard layout which is ok for like 99.99% of all apps' In case of rails I get (out of the box): - standard layout for files, e.g. where to put models, controllers, helpers, views, external libraries, test files etc. The directories are already added to the load path etc. I don't need to do shit. just write my code. - standard initialization sequence, nicely separated into boot.rb, application.rb, environment.rb, a file for every config environment, a directory of initializers and configs for various parts of the stack. (in the latest version the whole setup greatly simplified, but the idea still holds) - standard "example" testing framework. - standard Rakefile with a bunch of tasks - standard way to localize Some of those files you rarely need to change, but they still do not belong in the library. if I go with the 'default' ORM I need to only put user/password into config/database.yml (and not even that since my mysql's root has empty password locally) and I'm ready to go. With express I get almost none of this stuff. Well, the generated app.js certainly does some of the things but it does it in a kind of 'split it up as you wish into logical files' kind of way. i.e. for any non-trivial production application app.js will be split into files and it will probably be in a non-standard-just-invented-here kind of way. I'm pretty sure if you look at currently running production express.js applications you will see much more wheel reinvention with how to configure/start/layout the app then you will find in any Rails project. So until the standard generator will do this people will keep looking for boilerplates.