Do we need another ReasonReact boilerplate?

reasonreact
#1

First, let’s me be clear that I’m not trying to sell my boilerplate or discredit the current boilerplates, the maintainers are doing pretty good jobs of maintaining them.

[According to the docs], there are 2 recommended ways for creating a new ReasonReact:

  • bsb -theme react
  • reason-scrips (with CRA)

I don’t personally use any of them because I’m used to setting up my own webpack config. But I can list a few limitations

  • bsb -theme react: not production ready, simplest webpack config that you can find. It promotes a workflow with no server, just open a local index.html and you’re good to go. This is actually a good thing because when you’re getting started and not familiar with webpack and all the crazy Javascript toolings.
  • reason-scripts: this is a fork of react-scripts from create-react-app. But it currently has bugs that swallow last line of the error message from Bucklescript [1] . There has been some works on making a new version of reason-scripts. Most of development efforts come into this package . What I disagree about reason-scripts is that it hides the complexity of bsb .

And now we come to my own boilerplate. It based on bsb -theme react with a few touches for production ready bundle. I created it mainly because I repeat the same process when I need to make some quick demo (aka throwaways projects). Some folks on Discord discover it and request for react-hot-loader. I added it in this PR [2] but I feels it adds bloats to the boilerplate. I’m looking for feedbacks whether I should merge the PR or not and what you think about this subject?

[1]: If you’re in fixing bs-loader bug of swallowing the last line of bug, you should look here https://github.com/reasonml-community/bs-loader/blob/7512df81fb9ca83236143a131d6f64dcede77c5f/packages/bsb-js/index.js#L18-L21
[2]: https://github.com/thangngoc89/reason-react-boilerplate/pull/1

#2

I wonder how easy or difficult it would be to distribute BuckleScript themes that set up different kinds of projects. For example if you could distribute your boilerplate as a theme, and it was supported by bsb, people could do e.g.

bsb -init my-proj -theme https://github.com/thangngoc89/reason-react-theme

That might make things a bit easier to maintain because you just conform to a theme type and users don’t have to worry about two different ways to set up projects.

#3

I’m not sure we do. Here’s my reasoning:

bsb themes are very good at what they do, which is create a simple boilerplate. The unfortunate part is that these boilerplates can get out of date (i.e. webpack version) and then we have to PR changes into bsb to update the themes. Additionally, those PR’d changes aren’t reflected to new projects. But, they’re simple! And really easy because they’re all shipped with BuckleScript.

CRA (and reason-scripts) provide a much more full-fledged setup, and follow the general philosophy of Not Boilerplate ™. This is good because users can upgrade Webpack versions by just updating the reason-scripts version, just like CRA does. Unfortunately, this results in a much more complicated setup than most other tools.

I think this creates a good duality of tools, and by recommending and supporting both we let users pick what is right for them to use. This pain is felt a lot in the JS community as well (too high level or too low?), but I think there’s good hope on the horizon :slight_smile: Parcel is a pretty new bundler that has built-in reason support that we as a community can mostly control because it depends on the package bsb-js. Once Parcel becomes a bit more stable, I think it would be a good recommendation. It exposes how BuckleScript works and requires no configuration, meaning we don’t need to ship a boilerplate for it!

To wrap it up, I don’t think we need a new boilerplate because it wouldn’t solve the problems we have, but some solutions may be on the horizon.

#4

The usual default answer, from me at least, is no, for the reason above. There’s an established theory on why extra boilerplate generators with very little differentiators are harmful, but I’ll spare you the hand-wavy philosophizing. The last thing a newcomer needs is “btw, before you start, here’s my own opinion of how this advanced part of the build pipeline should look like. Don’t listen to the others”.

That being said, nuance & implementation matters. I’ve seen the diff; it’s just this: https://github.com/thangngoc89/bsb-theme-react/commit/3a4378c5eabeb28ca9348e1a56b057746441db72
Basically 3-4 extra lines of code for a production build. So I think very little concession is needed on the bsb -init side. So I think adding those lines to bsb -init is fine!

#5

I completely agree with you and @rrdelaney on this. Boilerplate are bad and it’s hard to keep it up with upstream. I’m refactoring my apps (1 serious and ton of toys) to use a single shared set up.