Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Mega Boilerplate

megaboilerplate.com

Post reply on HN
Print view View original

31–40 of 57 posts

Re: Show HN: Mega Boilerplate

#31

Post by ef4 »

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.

Re: Show HN: Mega Boilerplate

#32

Post by pmelendez »

ef4 wrote: post #31

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 harde…

> "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.

Re: Show HN: Mega Boilerplate

#34

Post by dinosaurs »

sahatyalkabov wrote: post #23
rosalinekarr wrote: post #5

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.

I wouldn't mind seeing that diagram. Just downloaded the React option and I'll definitely be going through the code as a learning process; server-side rendering still doesn't really click with me. Thanks!

Re: Show HN: Mega Boilerplate

#36

Post by sahatyalkabov »

joeyspn wrote: post #29

Good Job. Hope it gets traction... Looking forward to Angular2 and Meteor additions. 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).

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.

Re: Show HN: Mega Boilerplate

#37

Post by sahatyalkabov »

anonymous_shoe wrote: post #30

Would love to see an option to use Relay and GraphQL

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.

Re: Show HN: Mega Boilerplate

#38

Post by Jean-Philipe »

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.

Re: Show HN: Mega Boilerplate

#39

Post by andrewstuart2 »

ef4 wrote: post #31

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 harde…

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.

Re: Show HN: Mega Boilerplate

#40

Post by rhizome »

sahatyalkabov wrote: post #26
fredwu wrote: post #22

Awesome effort! I love the folder structure, very easy to follow. 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. :)

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.

You can call it "refactor-ready." ;)
Post reply on HN