Show HN: Mega Boilerplate
megaboilerplate.com
megaboilerplate.com
"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.
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.
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.
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.
Not really, because we're already doing it. It's definitely hard, but it's also definitely possible.
ember-cli has unlocked major community-wide sharing that is otherwise not possible. Like a healthy addon ecosystem (https://emberobserver.com) where things are far more likely to _just work_.
And this has kicked off a virtuous cycle. Big engineering organizations with long-term vision are joining in.
> become their "standardized" toolchain.
That's exactly the problem: once you create _your own_ standardized toolchain, you are the only one who can document it, teach it, ensure other things are compatible with it, and integrate upstream upgrades. When a community works together to decide on a much broader set of standardization, that burden is shared and everybody goes faster. And developer knowledge is much more portable.
Nobody making iOS apps thinks it's smart or necessary to write their own XCode. People writing ambitious web apps shouldn't either. (And I say that as someone who finds XCode annoying -- it's _still_ better than trying to build it yourself from scratch for each app).
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. :)
As a predominantly backend developer, If I just want to have a 2016-style workflow for the frontend part of my site, it's really hard!
With the boilerplate I was locked into the questionable decisions and brittle implementation of the original author. Changing anything usually broke my app and because I had taken the starter kit shortcut I didn't have the understanding of how to fix it.
What I like about the site is the visualization.
So, for instance, you know that Express is an alternative to Meteor, not a complement. And that Jade/Handlebars work with Express and are alternatives to each other.
Just having that for all the combination of names is valuable.
Basically, it helps you understand the taxonomy.
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).
But I would love to see it with a testing framework, a css pre-processor and a production build script.
I'll track the issue and see how I can help.
B. "iPhone 6" says nothing about what browser or iOS version you are using.