Hacker News Reader

Comment by hoodoof | Hacker News Reader

There really should be a "this month's boilerplate/starter kit" site that has a starter kit using the current state of the art technology set.

Whilst this comment might sound facetious, it isn't intended to be.

The JavaScript ecosystem moves quickly and starter kits are outdated almost immediately as the JS world develops better ways to do things.

At any given month there tends to be a community accepted (to a greater or lesser extent) set of technologies that are the "current best". It would be great to be able to go there and pick up a "January 2016" ReactJS starter kit built around the "current best".

Another related idea is a website listing JavaScript technologies and every month a new poll shows how many people favor one technology over another.

Or a list that allows people to use checkboxes to select the JS technologies, with a grid showing which starter kits use that tech.

View on HN

This is more a React community thing. It actually moves faster and re-invents wheels at a more rapid pace than the broader JS ecosystem.

A lot of this re-invention happens when a community "celebrity" decides it's time to (yet again) move to the latest new and shiny way of doing state management or data fetching. It's pretty annoying and exhausting at this point to attempt to keep up.

We need a developer "celebrity" to make a CLI tool like ember-cli for React.

I've heard this term "new and shiny" used many times as a derogatory term.

"New and shiny" implies that there is no real value in the newest tool, that it's just a trend for hipsters to follow.

IMO developers rapidly move to new tools and technology because they are better - simpler, more full featured, easier to use or take a new approach that solves problems in existing approaches.

The "celebrity" suggestion here appears to be that sheep like developers just go and do something ecause some known person has built something. This suggests that developers are stupid. Who has time to learn something only because of the name of the developer? Developers use things because it makes sense to do so.

Not exactly "no value", but risk-aversion is a valuable trait. Balance the small additional value the new shiny brings against the potential fail if it doesn't live up to its promises.

I think that's in opposition to "battle hardened". A wiseman wouldn't take "new and shiny" over "battle hardened".

With that said even with some years under its belt yet the react community is still in a state of flux (no pun intended), and one is signing up for new and shiny for the next couple of years. One should know that and embrace it going in. There is nothing wrong with that. I feel like we are currently in the "walking" phase with React and have stepped out of "crawling". These tools are helping us learn to "run".

I've resorted to subscribing to the atom feed of the package.json file on a few boilerplate projects that look interesting (este, react-boilerplate [1], etc) and researching new packages that are added in. Redux is the in flux implementation right now, and react-router has been great. But just found out there's a redux-simple-router package that binds them together!

  [1]: https://github.com/mxstbr/react-boilerplate/commits/master/package.json.atom

I'm hard at work on v3.0, you might want to use the v3.0.0 branch! :-)

> https://github.com/mxstbr/react-boilerplate/commits/v3.0.0/p...

Subbed, awesome thanks!

> Whilst this comment might sound facetious, it isn't intended to be.

Yep, it's dizzying how fast the JS ecosystem is changing; hell, even just the React ecosystem on its own. I went back to a React-based side project I had been working on at the beginning of this year to try to get it up to date with current best practices and tooling, and SO much has changed (Babel/ES6, Webpack, the maturation of the Flux pattern, the React/React DOM split, etc) that I've decided to rewrite it more or less from scratch.

I don't even need a lot of the stuff this particular boilerplate kit has, as my app is designed to run as a static site on Github pages, but having one place to go just to find out what libraries and practices are currently considered the state of the art (or flavor of the month, depending on your level of cynicism) would be wonderful.

Them's the breaks, I guess.

Rewriting a side project app with the latest boilerplate generator and toolkit, IMHO, is an obsession that is just a great way to avoid doing work.

There comes a point in a side project where it gets too big for the usual sole developer to deal with and they think, "If I just upgrade to the next magic stack I'll be able to manage this complexity."

What's usually happened is that the QA load for adding new features has gotten too high and the usually sole developer can't add new features to anything without breaking stuff and at least going through a long test cycle. With a larger team, QA can help patch up the holes. However, if a project has solid TDD, this doesn't become a problem because, if the tests all pass, everything works.

Just my two cents, but that was my experience before I got really into TDD.

It's not the JS ecosystem. Just the React one.

Ember's ember-cli remains the easiest way to avoid all the build tool/boilerplate annoyances.

Somebody posted about gluestick yesterday (https://www.drivenbycode.com/gluestick-the-future-is-here/) which helps create boilerplates...but also keeps them updated (a next gen Yeoman if you will).

Reply on news.ycombinator.com