I'm going to go against the JS ecosystem grain and say that boilerplates are a total anti-pattern. And not because you should be doing this stuff by hand either, which is probably the second most popular answer.
"Boilerplate" implies copying a bunch of code into your project that should be library code but isn't because it's too poorly designed to have an API cleaner than "just fork it, YOLO". It's dramatically harder to update than something with well-designed API boundaries.
Your web app really isn't a unique snowflake. Shared, standardized toolchains are harder to build but once you do they're a dramatically better long-term investment.
In Javascript it's really just ember-cli that operates this way, which started in the Ember community and has now also been adopted by Angular.
> "Boilerplate" implies copying a bunch of code into your project that should be library code but isn't because it's too poorly designed to have an API cleaner than "just fork it, YOLO". It's dramatically harder to update than something with well-designed API boundaries.
In most of these cases, "boilerplate" implies a choice of frameworks, libraries, build and test tools, with a minimal or recommended configuration, all tested for interoperability. The actual code advancing your application is minimal.
In the case of megaboilerplate, it appears to be a mix of configuration files plus a mini hello world built on top of the technologies. The mini hello world seems to be mostly a demo of how the chosen technologies can interoperate, not really something that "should be library code".
> Shared, standardized toolchains are harder to build but once you do they're a dramatically better long-term investment.
Possibly, but I think you underestimate the effort required to create and distribute a toolchain that would become shared and standardized. In effect, a specific team might choose a particular boilerplate, tweak it to its needs, and the tools and libraries within that boilerplate become their "standardized" toolchain.
> "Boilerplate" implies copying a bunch of code into your project that should be library code but isn't because it's too poorly designed to have an API cleaner than "just fork it, YOLO".
That's a bit too simplistic. Even if the majority of the boilerplate code live in libraries, you don't need all the libraries for all your cases. Then your options would be either something like this or adding unnecessary dependencies for the sake of reducing boilerplate. To me this is the lesser evil between those two options.
As always, there are trade-offs between the two approaches. Libraries may be a great approach, but they lock you into the implementation they chose, and the individual components they chose.
With many boilerplate/scaffolding solutions (yeoman, for example), you're given some quick templated code and left to implement logic yourself. You're free to swap out implementations anytime you want, without having to fork the library, or force library developers to maintain overbearingly abstract interfaces so that dependents are free to swap in some other component.
Neither is a perfect approach. The best solution will vary with the flexibility you need for a given system. Anecdotally, the best projects I've worked on were built using a combination of libraries, frameworks, and scaffolding tools. I attribute this to the fact that the tools we used were (at least among) the best at doing one specific thing (render the app, scaffold, build, serve, etc.) and worked well together by not trying to do all things equally well.
Agreed. I get so sad when I see this happen in the JS ecosystem (being used to python), but it's pretty easy to not fall into that trap. Use bower on the browser side, and npm on the server side. At that point, the only fight you have left is finding the stack of components that will play nicely together, which is the labor of architecture anyways.
Thanks for the feedback! Agreed, it makes sense to refactor those routes into its own Auth controller. I will open a GitHub issue. However, some of the code is intentionally written that way to keep things stupid simple and easy to understand for developers of all skill levels, which you would normally encapsulate into a service in your own app.
I hate to sound negative, but what does it offer over yeoman and the individual generators out there? If I use a Mega Boilerplate setup, I lose scaffolding post-setup stage, so what do I gain?
I agree that it serves almost the same purpose, but for a beginner, seeing all the layers, what they do, and choosing them piecemeal is a great way to learn quickly before graduating to the yeoman ecosystem.
It's more intuitive for beginners and if more stacks(Django/Laravel etc) are added, this would be a good way to select stacks and generate boilerplate.
For me(I maintain a purely platonic relationship with JS) it offers an easy choice. An example: I don't have to choose MongoDB over Postgres just because the Yeoman generator that actually has all the items I want, decided to go with NoSQL.
Wow, as a long time RoR dev set in my ways, you may have finally given me the tool to overcome my laziness and check out this new fangled "server-side javascript" thing.
The server-side JavaScript hype is real and it is awesome! React option comes with Redux, React Router and with server-side rendering enabled. I have also gone through all the obstacles of setting up authentication with server-side rendering. If the code doesn't make sense, I will try to create a small diagram of the user auth flow.
That's really cool. Even if you don't find the project itself all that useful, bounce on over to the github and have a look. This is a good example of how to put a project together and share it with the world. Kudos.
This is so awesome, great way to understand the current options and common choices in the ecosystem at a glance. I've been choosing Meteor recently precisely to avoid having to write a bunch of boilerplate Gulp/Grunt code to piece all the tools together and run the code and asset files through the pipeline.
Wow! As someone who struggles to configure all of these dependencies, I love this. I also have difficulty learning new stacks by following the hello world/todo examples in the documentation so having a real boilerplate app built helps tremendously. Maybe I'll finally try and learn React ;)
It's not exactly how I would do it (of course!), but close enough for me to try it on my next project! I love the choice of modules on the server side. Seems like a lot of thinking went into this boilerplate. I'm curious how it will work out for me in practice.
I had originally started working on Hapi generator (there are still some leftover files in the Git repo), but decided against it after running a quick Node.js Framework survey among my Twitter followers. Given the amount of effort it would take to add a second Node.js framework and the low demand for it, it was simply not worth it.
Looking forward to Angular 2 myself! I have actually started with swig template engine until seeing NO LONGER MAINTAINED notice on their GitHub page. Many have recommended to use Mozilla's Nunjucks instead.
Last time I have used AngularJS was in 2014, so that's why the project structure looks a bit dated. I am open to suggestions on how to improve it, or even simplify it further.
I will consider adding it in the near future. It was originally on the roadmap, but don't have any experience with either Relay or GraphQL. In any case, I will open an issue on GitHub for this and do some research later.
Requests per second were going through the roof during initial announcement due to a lot of images, css, and javascript being served by the main Node.js app. Assets are now served from CDN, albeit hardcoded, but that I can fix later.
[+] [-] ef4|9 years ago|reply
"Boilerplate" implies copying a bunch of code into your project that should be library code but isn't because it's too poorly designed to have an API cleaner than "just fork it, YOLO". It's dramatically harder to update than something with well-designed API boundaries.
Your web app really isn't a unique snowflake. Shared, standardized toolchains are harder to build but once you do they're a dramatically better long-term investment.
In Javascript it's really just ember-cli that operates this way, which started in the Ember community and has now also been adopted by Angular.
[+] [-] Sacho|9 years ago|reply
In most of these cases, "boilerplate" implies a choice of frameworks, libraries, build and test tools, with a minimal or recommended configuration, all tested for interoperability. The actual code advancing your application is minimal.
In the case of megaboilerplate, it appears to be a mix of configuration files plus a mini hello world built on top of the technologies. The mini hello world seems to be mostly a demo of how the chosen technologies can interoperate, not really something that "should be library code".
> Shared, standardized toolchains are harder to build but once you do they're a dramatically better long-term investment.
Possibly, but I think you underestimate the effort required to create and distribute a toolchain that would become shared and standardized. In effect, a specific team might choose a particular boilerplate, tweak it to its needs, and the tools and libraries within that boilerplate become their "standardized" toolchain.
[+] [-] pmelendez|9 years ago|reply
That's a bit too simplistic. Even if the majority of the boilerplate code live in libraries, you don't need all the libraries for all your cases. Then your options would be either something like this or adding unnecessary dependencies for the sake of reducing boilerplate. To me this is the lesser evil between those two options.
[+] [-] andrewstuart2|9 years ago|reply
With many boilerplate/scaffolding solutions (yeoman, for example), you're given some quick templated code and left to implement logic yourself. You're free to swap out implementations anytime you want, without having to fork the library, or force library developers to maintain overbearingly abstract interfaces so that dependents are free to swap in some other component.
Neither is a perfect approach. The best solution will vary with the flexibility you need for a given system. Anecdotally, the best projects I've worked on were built using a combination of libraries, frameworks, and scaffolding tools. I attribute this to the fact that the tools we used were (at least among) the best at doing one specific thing (render the app, scaffold, build, serve, etc.) and worked well together by not trying to do all things equally well.
[+] [-] barkingdog|9 years ago|reply
[+] [-] kristiandupont|9 years ago|reply
[+] [-] sahatyalkabov|9 years ago|reply
[+] [-] fredwu|9 years ago|reply
A small feedback: I just generated a React-based stack with a few Auth options - Email, Facebook, Google and Twitter.
The resulting `user.js` controller is 550 LoC.
It would be great if by default some of these logic are encapsulated in a service layer rather than littered in the controller itself. :)
[+] [-] sahatyalkabov|9 years ago|reply
[+] [-] dvcc|9 years ago|reply
[+] [-] projectramo|9 years ago|reply
[+] [-] vthallam|9 years ago|reply
[+] [-] aavotins|9 years ago|reply
[+] [-] rosalinekarr|9 years ago|reply
[+] [-] sahatyalkabov|9 years ago|reply
[+] [-] pssdbt|9 years ago|reply
[+] [-] noonespecial|9 years ago|reply
[+] [-] rblstr|9 years ago|reply
[+] [-] sahatyalkabov|9 years ago|reply
[+] [-] neil_s|9 years ago|reply
[+] [-] dimxasnewfrozen|9 years ago|reply
[+] [-] Jean-Philipe|9 years ago|reply
[+] [-] kaimaoi|9 years ago|reply
[+] [-] sahatyalkabov|9 years ago|reply
[+] [-] joeyspn|9 years ago|reply
Express tip: add swig template engine
Angular tip: use a feature per folder structure for better componentization and "controller as" syntax (checkout John Papa's styleguide).
[+] [-] sahatyalkabov|9 years ago|reply
[+] [-] rufus42|9 years ago|reply
[+] [-] sahatyalkabov|9 years ago|reply
[+] [-] anonymous_shoe|9 years ago|reply
[+] [-] sahatyalkabov|9 years ago|reply
[+] [-] wigster|9 years ago|reply
[+] [-] sahatyalkabov|9 years ago|reply
[+] [-] sleepychu|9 years ago|reply
[+] [-] sahatyalkabov|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] AbraKdabra|9 years ago|reply
[+] [-] hookshot|9 years ago|reply