React-Starter-Kit – Open Source Universal React Redux GraphQL Boilerplate | Hacker News Reader

React-Starter-Kit – Open Source Universal React Redux GraphQL Boilerplate

github.com

43 pointsreactkit25 comments

Am I wrong in thinking that the fact that there are so many starter kits (which all contain a _lot_ of boilerplate code) indicates some sort of fundamental problem in the ecosystem?

With so much fragmentation in tooling and constant churn, it's often discouraging to start any new project.

I've been using Parcel because of its zero-config functionality, and it always amazes me how much boilerplate it actually takes care of for you behind the scenes. It's a lot.

You’re not wrong. Also using Parcel and love the fact that I can get real work done without having to worry about build tool churn and having to configure tens of plugins which are all badly documented.

This one using parcel, and I love parcel too https://github.com/codeaholicguy/rerepa-starter-kit

> it actually takes care of for you behind the scenes

Reminds me of the early days of the Spring Framework in Java when the entire language required sacrificing goats to get all the XML configuration, environment variables, and boilerplate code right. I checked up on the project last year and was pleasantly surprised to find Spring Boot made the process as simple as Rails.

Starter kit that lacks documentation of how it works, what's it used for and why is a bit inadequate starter kit in my mind. It's nice of you to put it out there but I'd seriously hope you'd focus on explaining the problems you are solving and why rather than just pumping out code like no tomorrow.

And as a personal note I think you should switch to TypeScript and Styled Components.

For anyone interested on creating a custom starter template, I would highly recommend Ben Awad's series on Youtube. He is a youtuber who shows how he pieces together different starter templates. So you can follow along / customize your templates to your own needs

https://www.youtube.com/user/99baddawg/playlists

Last year he did a very basic slack clone which has both graphql server and client (on Node) https://www.youtube.com/watch?v=0MKJ7JbVnFc&list=PLN3n1USn4x...

Lately he is heavily into Typescript and he has put together a series on how to put together a Typescript graphql server https://www.youtube.com/watch?v=2eWIr6bbons&list=PLN3n1USn4x...

Currently he is putting together a series on Full stack Airbnb clone which has both Graphql server and client (on Node) using Typescript and packaging using yarn workspaces.

I would highly recommend all these series from a learning perspective. If you just want to get started and learn later, you can download the code from the referenced github repos for each series.

Edit: Watching his series has also peaked my interest in Vim

Thank you for your code, I will be definitely be referring to this as I build the base of my current project.

Diving back into Node though, just so I can get my current portfolio up to par and job-ready, it makes me realize how broken this whole process is.

It seems like bi-annually, either Node.js is changing, Webpack is changing, React is changing, or possibly all three have changed. What you learned just a year ago has been modified and 'updated', usually with configuration and API changes. This leads to a whole slew of new articles and tutorials and boilerplate GitHub projects being created, only to be somewhat legacy less than a year down the road.

Then the plugins you have to learn, all of which separately might have configuration and API changes from one version to the next... Then you have to learn server side rendering because all of this is built for the client, so it's time to incorporate some weird page loading query string hacks to get that working...

All of this feels like it's just one hack put on top of another, to try and achieve what browsers have been doing since the 90's, just without reloading the page.

I think the updates to JavaScript in ES6 like arrow functions, classes, the spread operator, etc are great, but even this I could see going down the C++ route of just trying to add every single feature a programmer can think of to the language.

This is why I prefer Go so heavily. The core language keywords and features have not really changed since its inception. I hope one day this can all be condensed and simplified, much like Go is doing for backend languages.

I upvoted thinking it was this identically named project (but with 17k star) which I've found extremely helpful in the past: https://github.com/kriasoft/react-starter-kit

Am I the only one who wishes Starter Kits come up with a tutorial on how to build them up from scratch?

Most of the work is in the package.json and the webpack.config.js

Yes. Most of the work is spent figuring out hell that is webpack config etc.

It would be extremely helpful to document why the configs are the way they are. See this long twitter thread on what I discovered by ejecting create-react-app configs: https://twitter.com/dmitriid/status/908677755046449154

Some highlights:

- Because of course you need to write your own webpack message formatter

- Because of course you have to manually set up listeners for SIGINT and SIGTERM to tear down the dev server

- Because of course you have to manually write a module resolution helper that basically replicates node's resolution mechanism

- Because of course dev server spits tons of crap, so you silence it and manually write a custom message emitter

- Because of course you have to write your own error overlay for a dev server

- Because of course you have to pretend your structured folders are flat for some tools, and you have to write manual overrides

etc. etc. etc.

Simply because some poor soul spent countless hours and never documenting the journey we have the crappy tools that we have. All these horrendously inane configs should not be hidden behind a wrapper, but called out, created as issues and fixed.

Because it took the webpack team several years to even acknowledge that simplified configs with default values are a good thing. I mean, in 2017 they said that webpack will always be crap because it can't provide defaults because "that's how Javascript is": https://twitter.com/dmitriid/status/920542261020160000

etc. etc. etc. etc.

I didn't see anything related to GraphQL in this repo, whether in the readme or in the code or in the package.json. Did I miss something or it's just clickbait?

Also why choose Redux over Apollo or Relay if it's intended to be used with GraphQL? Did you document your choice?

https://github.com/sysgears/apollo-universal-starter-kit is another I've been working with

I prefer kyt[0].

[0]: https://github.com/NYTimes/kyt

At least this one makes the server part optional.

Each time I look at these bootstrap/start-kit/boilerplate projects to start a new project I get frustrated by the intertwined client & server code, deps & config.

Is there any starter kit using rest without redux out there?

Actually I’m using react with js-data for a rest backend. I have made some simple forms and list components that abstract a lot of communication with the server.

Great to see more starter templates.

Why that? I think the number of starter/boilerplate projects for React is already overwhelming.

I wish create-react-app was the only one way to start a React project, but it has its own limits:

- not intended for server-side React apps

- not intended for React components library

- not intended to be used with TypeScript but Flow (could change with the next major version tho)

Still, there are already so many alternatives, some of them just reinventing the wheel. Do we really need another one? I'm not sure.

- https://github.com/facebook/create-react-app (50k stars)

- https://github.com/react-boilerplate/react-boilerplate (19k stars)

- https://github.com/kriasoft/react-starter-kit (18k stars)

- https://github.com/davezuko/react-redux-starter-kit (10k stars)

- https://github.com/insin/nwb (3k5 stars, support Preact & Inferno & components libraries)

- https://github.com/zeit/next.js (26k stars, server-side support, very opinionated)

- and so on… just type "react boilerplate/starter/toolkit" on google. Most of them are out-of-date and not maintained, making the process of choosing one ever more overwhelming.

> not intended to be used with TypeScript

Microsoft maintains the Typescript plugin. Works great.

https://github.com/Microsoft/TypeScript-React-Starter

Oh looks good, didn't know this one. But that's my point: another React boilerplate, this one with TypeScript.

Also why they include Redux? It's not like adding Redux manually is that long or difficult. I guess some guy who doesn't want Redux will just fork this one and publish his own React-TypeScript boilerplate but including MobX, or some other state management library, or none. So another one…

Redux isn't in the boilerplate itself I think, just in the docs for how to add it

It's in the package.json.

Do we really need another...? The answer is yes. We are an open source community, we share code and ideas and we build on those ideas and they lead to implications that weren't thought of before and someone releases a new library or framework that does something that works better for particular use cases and then the whole cycle starts over again.

Some of these experiments will not stand the test of time, they'll be replaced by other things. Create-React-App is a great starter kit for React but you answered your own question: it doesn't cover all use cases.

Bring on more starter kits, more libs, more frameworks, more languages, more experimentation and innovation because that's how we discover new paradigms that improve productivity, performance, etc.

Software development is still a super young field and if we think we've already figured out the "best way" to make it, we're kidding ourselves.

Yet another

Tech changes. Even since react-create-app came out, there's been a ton of adoption in GraphQL and Redux, to the point where starting a CRA app still requires you to do pretty significant setup to get started.

Reply on news.ycombinator.com