Prepare for v3.5 release

[justingreenberg]

i created a milestone to aggregate outstanding PRs we want to include in next release... i think we're a little overdue :) please let me know what you guys think

cc @react-boilerplate/core

edit: raw link - https://github.com/react-boilerplate/react-boilerplate/milestone/4

[blling]

I think #1746 should be include:)

[Aftabnack]

I think #1720 should also be part of it.

[mydearxym]

server side render(#1236) wanted !

[justingreenberg]

Aftabnack #1720 is included

@VicBell @mydearxym unfortunately #1746 and #1236 are incompatible with one another

a great deal of effort has been put into both of these PRs, as maintainers we owe it to these contributors to make a decision sooner than later

simple fact is that the "js ecosystem" is evolving faster and faster... create-react-app is more than enough for most basic frontend (browser only) use cases. the team is world-class, they ship non-stop and the dependency-based model makes maintenance very easy.

at the same time, next.js is changing the game in SSR, has awesome DX, and another world class team solving complex problems and shipping daily. even as one of the authors of react-boilerplate, CRA and next cover 90% of my use cases these days.

that said, we probably need to reflect a bit on where RBP fits in this brave new world. we need to keep project dependencies up to date, so for posterity i'm inclined to upgrade react router but with the understanding going forward: this project is for creating large, high-performance enterprise-grade frontend applications with advanced/custom requirements, statically delivered by CDN.

my opinion is mostly based on recent experience... i'm currently using RBP for a complex application with security requirements which make SSR less than ideal. i chose RBP for scalability, fast rebuilds with DLLs, scaffolding with i18n, sagas, code-splitting, etc.

i'm keen to know how you all feel about this. please leave your comments below! would love to hear thoughts from community, maintainers and the creator (@mxstbr 🙇)

if you just want to "vote" for one or the other, please thumbs up 👍 comment above...

• react router v4 suggested by vicbell
• SSR support suggested by mydearxym

feedback from the community will help drive a decision and is much appreciated! 🙏 feel free to evangelize one way or the other, but no "+1" comments ;)

---

edit: open PRs not currently included in milestone, but worth considering:

• Dockerize #753 - Dockerize (very old, shouldn't be too hard to wrap up tho)
• Switch out hmre preset for react-hot-loader v3. #1207 - RHL v3 (hmre preset has been deprecated forever)

[anuraaga]

Thanks for starting this discussion - I agree with @justingreenberg's mission statement (large, high performance...CDN) completely. Personally, the biggest reason for using RBP for me among the many boilerplates that exist is that most boilerplates are designed for use with nodejs and isomorphic rendering - RBP has many great features and encourages best practices for a purely static site, which is perfect for me who uses a static site that hits a Java API server; I have no plans on moving API development to nodejs for a variety of reasons. I hadn't looked at create-react-app recently and it looks like it has a lot of good features now, but not enough for production apps I think, and after adding such features in, we'd be back at RBP.

Also, FWIW, I had mostly done server-side development in the past, with just a bit of raw React before Flux was a think, but thanks to having RBP to mimic best practices from, I was able to jump into high quality, production-level web client development very easily and learned a lot about the JS ecosystem. I imagine if I had started with create-react-app, the result would have been of a lot worse quality. Perhaps I would extend the mission statement to include , with an eye for encouraging best practices for high quality web development.

[Dattaya]

I would vote for #1746. If my memory serves me right, last @mxstbr's decision regarding SSR was to split #1236 into multiple PR's and bring react-boilerplate closer to supporting universal rendering gradually. Last such PR that requires our attention is: #1591. Ideally SSR support would be easily removable not everyone needs it and the complexity it introduces.

[samit4me]

You make some great points @justingreenberg, I too have been asking myself where does RBP fit in this brave new world with the likes of create-react-app and next.js.

I haven't contributed much of late due to a lack of free time, but I certainly get the feeling we need to decide on the future direction of this project. I do remember a discussion with Max (can't find it now, could find this one) discussing the options of creating a fork of create-react-app but applying some of the best features from RBP, for example:

• i18n
• styled-components
• redux state management
• scafolding tools

The above list is what I found to be the most usefull from RBP as it fits my usecase very well, but another developer might want / need Flow or TypeScript or server-side rendering. The point I'm trying to make is that it's impossible to create a silver bullet and I believe the best we can do is decide on a minimal feature set and do it very well.

If it's possible we should try and architect it in a way that allows the project to be extended so requested features that fall outside the "minimal feature set" can be easily added. That feature could then be documented or forked in another repo.

Maybe this is a little out of scope for this issue, but would like to hear what others think. Should we open another issue to come up with a minimal feature set?

As for version 3.5 can we add:

• Migrate to react router v4. #1746 Migrate to react router v4
• Add Debugging section in Docs + VS Code instructions #1698 Add Debugging section in Docs + VS Code instructions
• Update README.md #1785 Update README.md

[Dattaya]

I do remember a discussion with Max (can't find it now, could find this one) discussing the options of creating a fork of create-react-app

I was searching for it but couldn't find that discussion either.
This is what I was thinking to try to do, but my opinion might change once I start experimenting:

• Create CRA fork with
  • webpack dll,
  • some other important features but not everything,
  • a simple way to extend a webpack config instead of ejecting: ({ config, mode }) => { config.module.loaders.push(...) .... I've seen Neutrino and their plugin system (presets), on one hand I like it because I wanted to do something like this myself, on the other I can't decide if it's over-engineering or not.
• Extract useful components like ProgressBar into a separate repository in this organization and publish on npm
• Extract generators into a separate package or add them to a CRA fork? Instead of clean script create two: 'generate basic app' and generate 'example app'. Example app is what we ship by default now.

Added #1746 to the milestone as it got more votes.

[mxstbr]

I'm in the middle of starting a company and building a product, so I haven't been able to do much work on react-boilerplate recently. (gotta get that app shipped so I make some money again! )

Just wanted to chime in that a) go forth and release, don't wait for me and be blocked, and b) I agree with everything @justingreenberg said.

I love love love @Dattaya's plan above, it's exactly what I was planning on doing but haven't had the time to. (and won't have for another good few months) create-react-app is a superb base to build upon, and if we can showcase some of the great ideas the amazing minds in the React community have come up with based on that minimal base that'd be (imo right now) the best way forward for react-boilerplate.