9 ms·

React-Boilerplate v3: The “JS Fatigue Antivenin” Edition

112 points by neuling 10y ago

mxstbr 10y ago
Thanks for sharing this here neuling! We've been working on this complete overhaul of react-boilerplate for several months. Based on the combined experiences of tons of collaborators, we've created the strongest foundation to build your next React.js application with. The biggest changes are: - Revamped architecture: Following a bunch of incredible discussions (thanks everybody for sharing your thoughts!), we now have a weapons-grade, domain-driven application architecture. - Scaffolding: Generate components, routes and more parts of your application directly from the command line, skipping all the boilerplate writing! - Performance: We've got the best code splitting setup currently available, giving you the leanest, meanest payload. (The fastest code is the one you don't load!) - JS utilities: We now include redux-saga, ImmutableJS, reselect and react-router-redux to make sure your application scales to the size it needs. - CSS improvements: We use CSS modules for truly modular and reusable styles, code split your styling based on the page the user is on and make sure your code style is in order automatically! I think this is by far the best boilerplate currently available, both for starting your next project and for simply getting inspiration into what's possible. Let me know what you think everybody, I'm beyond excited to finally share this with the world!
- msmith 10y ago
  I've built a small project using v2 and it really helped me get up to speed and learn some of the best practices for React front-end development. I'm looking forward to trying v3, because it addresses a several things that I felt could be improved in my current project. Specifically, Component tests, CSS organization, & integration with utilities like ImmutableJS & reselect.
  - mxstbr 10y ago
    That's so great to hear, you're going to love v3! v2 to v3 is like stone age to modern times. :)
- ClayM 10y ago
  Does this provide universal/isomorphic rendering?
  - mxstbr 10y ago
    Not yet, but it's the next big feature on our roadmap! We've actively been working towards it, we realise it's a really important one too, so it won't be long. Chime into the discussion here if you have thoughts about it: https://github.com/mxstbr/react-boilerplate/issues/174 https://github.com/mxstbr/react-boilerplate/issues/174
  - JoeCortopassi 10y ago
    We added that to https://github.com/TrueCar/gluestick https://github.com/TrueCar/gluestick. Plus it gives you a cli and much better upgrade path when you need to change things in the future
- aidos 10y ago
  So far this feels really nice, kudos! Quick question - what does the HMR work with? If I change a component it seems ok, if I change a reducer it blows up in my face. EDIT is there a walkthrough of getting set up with this anywhere? After about 30 minutes playing I think I'm going to put this down until there's an obvious way of building a simple app with it.
  - mercer 10y ago
    I ran into this same issue when setting up my own Redux/React with Hot reloading. The solution I found involved adding this to the store initializer: if (process.env.NODE_ENV !== 'production' && module.hot) { module.hot.accept('./reducer', () => { store.replaceReducer(require('./reducer')); }); I still have issues with getting actions to hot reload, but from what I understand this will work once Hot Reloader 3 is released, so I'll just wait for that.
    - aidos 10y ago
      Thanks! I've decided to skip on boilerplate for the moment. I found that it wasn't very clear as to how to manage the code and I didn't find any obvious walkthroughs. Maybe for people with a little more experience it's useful but I found that it made everything a little murky for me. Since yesterday I've made good progress on my own app and I have have a much better understanding of how everything fits together. It might well be that boilerplate has the answers to some of my questions on how to manage the codebase but I just need to go through the process of figuring it all out for myself.
      - mercer 10y ago
        Yeah, I found that approach to be much better even if it feels like it takes longer. Only now that I've got a working todo app (based on a particular system) working, with a decent understanding of every part, I might look into this boilerplate (or another) to see what might be some 'best practices' and to see where I might've taken a suboptimal approach. I find that this generally is the best approach. Of course, the mistake I usually end up making, and one I made in this case, is that I try to learn too many things at once. For the current project: Redux, React (+ router stuff), Flowtype, Typescript, hot reloading, and something else I forget. Certainly didn't make things easier or more efficient, but it was hella fun! (Flowtype in particular is going to stick around for future projects where I don't want to go all-in on types. Typescript seems like a better long-term bet though, FWIW).
diggan 10y ago
I've never understand what these kind of boilerplates are for. Well, kinda understand if you're doing projects that takes just a few weeks to complete. Otherwise, you're just better off starting with your own boilerplate. I mean, how does updating work? If you improve the scaffolding, people need to merge in their changes? Why is this not a CLI tool that would be effortless to update? Although I must say it's impressive work made on this, and that it's cool to be able to generate many things, I fail to see any big value in using these kind of boilerplates.
- bshimmin 10y ago
  Given this is a complete rewrite, I guess updating doesn't work at all. But at least in that sense it gives you an authentic experience of modern web development!
- mxstbr 10y ago
  Updating doesn't work with boilerplates at all, but a CLI tool wouldn't really fix that — what you'd really want is a codeshift[1] for each new version, which we're looking into right now! (you probably also don't need to update them at all) We've added tons of removal guides for each major feature, so people can take the parts they want from react-boilerplate and discard the ones they don't want! I see it more as a reference implementation that gets many small details right, a thing you clone and the cut to your liking to keep all those small details intact. Does that make sense? [1]: https://github.com/facebook/jscodeshift https://github.com/facebook/jscodeshift
  - k__ 10y ago
    So it's not like a library or framework, it's just a conglomerate of useful things that will diverge into "your own stack" after starting to develop and you have to update your deps like you would with your own boilerplate, the only thing that it saves you is starting a new project. Which is enough I think :)
    - mxstbr 10y ago
      Exactly, that's an excellent summary. :)
mintplant 10y ago
If this is under the MIT license, doesn't every project that uses it for initial scaffolding have to keep its license around?
- stenius 10y ago
  The MIT license is not copy-left. https://en.wikipedia.org/wiki/Copyleft https://en.wikipedia.org/wiki/Copyleft
  - mintplant 10y ago
    No, but it stipulates that the copyright notice and license text must be retained.
- dvcc 10y ago
  You can basically do anything at all with it, including include it in a more restrictive licensing setup. The only constraint is that you must include the original license/copyright notices. https://tldrlegal.com/license/mit-license https://tldrlegal.com/license/mit-license
  - mintplant 10y ago
    > The only constraint is that you must include the original license/copyright notices. Right, that's exactly what I mean.
deleted 10y ago
[deleted]
atonse 10y ago
Not to beat a dead horse but this boilerplate issue is one of the biggest values of ember-cli, and the main reason I advocate for it over most of the other frameworks. I don't want to spend days figuring out my asset pipeline, build scripts, and implementation of flux/gulp/grunt/webpack/broccoli blah blah. It's good those choices exist, but I don't care about the differences enough anymore, I just want to build my app. Plus, you lose the sense of common solutions when there's this much variance. angular has adopted ember-cli into angular-cli – any plans by the react community to do this?
- sotojuan 10y ago
  The problem is that the core React team doesn't seem interested in this (which is funny because they did a CLI tool for React Native).
- insin 10y ago
  > angular has adopted ember-cli into angular-cli – any plans by the react community to do this? First, you would need to define what a React framework looks like, which libraries it needs and which conventions it should use while wiring them together, then build tools around that. Version 3 of React Boilerplate takes steps towards that by deciding on a set of tools, libraries and conventions and providing code generators for adding to them in a compatible way, but the initial wiring is still done as boilerplate (like it says on the tin). react-project [1] was heading towards something more like managing this wiring behind the scenes as a dependency rather than a boilerplate, but it's not being actively developed any more at the time of writing. --- I think React and view libraries like it also necessitate a slightly different approach in that there's no overarching thing to hook into behind the scenes - you just write a bunch of JavaScript and what it returns (plus side effects) is exactly what you get. For example, to use Font Awesome icons with Ember via ember-cli, you install ember-font-awesome and the next time you run ember-cli it does... something... such that an fa-icon component is now magically available in your templates. [2] In React, you install react-fa, import it into module scope where you need it and use it as part of what a render() function returns - your build tools handle it the same as any other JavaScript and CSS you've imported. [3] [1] https://github.com/ryanflorence/react-project https://github.com/ryanflorence/react-project [2] https://github.com/wycats/github-issues-demo/commit/a3358026a42b3438227cff9a3aabb620ce3c09a0 https://github.com/wycats/github-issues-demo/commit/a3358026... [3] https://github.com/insin/react-nwb-github-issues/commit/cad3abd4ec47f78bf50194ec1bd7cbfb1068e733 https://github.com/insin/react-nwb-github-issues/commit/cad3...
fauria 10y ago
This is an excellent tool to compare different React starter kits: Find your perfect React starter project http://andrewhfarmer.com/starter-project/ http://andrewhfarmer.com/starter-project/
- pbreit 10y ago
  I don't want 60-odd random repos. I'd like to see 3-7 well-chosen options with a few pithy sentences about each.
msy 10y ago
The adoption of the approach ember-cli took over a year ago by both React & Angular (angular-cli) is to me the strongest validation of the relative architectural maturity of Ember over its competitors. Ember has demonstrated singular organisational maturity - stable and consistent release process, standardised build tools, high quality documentation, excellent deprecation warnings & clear upgrade paths. It allows teams to focus on delivering value without prevaricating about build pipelines and trust that the whims of the maintainers won't result in months of rewriting at arbitrary intervals. Equally it's been pressure and progress from React on render speed that's helped push along Ember's Glimmer engine, long may the ecosystem and healthy competition drive innovation!
riebschlager 10y ago
I want to understand the appeal of React, I really do. But I open a project like this in my editor and my linter starts going nuts from all the markup in the JS. And my built-in biological linter starts getting queasy just looking at it. Ugh. I just don't get it. Am I just old and curmudgeonly? And what's with the 200+ line package.json. That's a helluva lot of tooling for a simple web app. GET OFF MY LAWN!
- onewaystreet 10y ago
  > Am I just old and curmudgeonly? Yes
  - dewyatt 10y ago
    To be fair, when I see "Yet moar tweaks" as a commit message, I start to wonder if I am old and curmudgeonly too.
- epmatsw 10y ago
  What linter are you using? ESLint handles JSX fine as far as I know. And with eslint-plugin-react it actually does some pretty neat validation on it as well. I will say that I initially disliked the inline markup as well, but it honestly just makes practical sense. When we used Handlebars still, I always had the template open in a split when I was editing a view anyway, why not just keep it all as one contained unit?
  - riebschlager 10y ago
    I'm using JSHint. I know it's just complaining because of the way I have my .jshintrc set up, but this markup-in-scripts thing is a big mental shift for me. But hey, I'll try anything once.
    - aidos 10y ago
      It's definitely a big mental shift, but it's worth giving it a proper go. For those of us who have been coding since before there was even JS, it's hard to let go of the Html / JS split but honestly, it's so much nicer when you just grab the React approach and run with it.
Niksko 10y ago
Advice please: I tried to wade into the weird and complicated world of web development a few months ago, but eventually I gave up. At first I used a boilerplate (in fact I think it was a previous version of this one), but it felt like I was jumping in the deep end. I didn't know what anything was, I didn't understand the configuration or the setup, and nothing was making sense. So instead I decided "I'll start from scratch, introduce dependencies as I need them, and I'll actually understand what's happening". But then as I started to try and introduce dependencies and pieces of the toolchain and stack (Babel, GraphQL/Relay etc.) and that was a whole different type of confusing. I found it really hard to follow tutorials unless they were written for EXACTLY the stack I was using, because small changes seemed to radically change how I had to go about things. How do you start? Both situations seem perilous. Bottom up is really difficult unless you follow a tutorial that exactly matches your stack. Starting with boilerplate means that if anything breaks you have no idea how to fix it or how anything works.
- rdoherty 10y ago
  I agree and I'm also curious how someone would integrate all the React ecosystem into an already exiting app (Rails specifically). Starting a new project is easy, rewriting one is a huge challenge.
  - RobertKerans 10y ago
    React Rails[1] works fine: you just get React, and it's difficult to integrate other shiny React-associated stuff like Redux, but it makes it incredibly easy to build out an app, or even just sprinkle components throughout an existing Rails app. It's dead simple to get started, and I've found it generally Just Works; the whole team I work on has been using it for the last 4-5 months without any issues. Just add to Gemfile -> it sets up a components folder + a file that imports the file tree -> then optionally set initializer options (like include React Addons, or use stage-0 stuff). All exposed globals though, which is a pain, but that's generally expected with the asset pipeline unless you're very disciplined. There's a pretty complete tutorial, but it's a bit out of date + uses CoffeeScript rather than JSX - I made a copy of the original, with updates, for one of my colleagues, the gist is here (sorry, might be a little rough): https://gist.github.com/DanCouper/b6953544a34606617eb5 https://gist.github.com/DanCouper/b6953544a34606617eb5 To get a bit deeper, there's React on Rails[2], which retains the same entry point, but moves all the JS to a separate folder at root, and uses Node to handle that side of things during development. The setup is batteries included, and pretty flexible, but I haven't used it a huge amount so can't give much detailed feedback. 1. https://github.com/reactjs/react-rails https://github.com/reactjs/react-rails 2. https://github.com/shakacode/react_on_rails https://github.com/shakacode/react_on_rails
kimar 10y ago
Thanks for this Max! We used it recently to migrate a Backbone/Marionette app[1] to React/Redux and it saved us a great deal of time. We hope to write a full writeup on the migration itself soon but meanwhile we've released the code here: https://github.com/thebakeryio/openmic https://github.com/thebakeryio/openmic [1]: https://openmic.io https://openmic.io, a MediaRecorderAPI experiment
aidos 10y ago
I've been reading through / trying redux etc over the last couple of days. This has come at the right time where I know what all the components they're talking about do and I'm interested in seeing more of how redux apps are architected. For people coming to this area fresh it's really daunting. There's a new library for every little thing you can think of and it's almost impossible to know where to start. Fortunately Redux itself is such a simple model that it's easy to build on your understanding of it (vs, say, Angular that has a huge surface area - I know, they're different things, but people are probably going to start with one or the other). Will try this out now to see how I get on. Great timing, thanks!
deleted 10y ago
[deleted]
todd3834 10y ago
We have been working on solving similar problems. Isomorphic rendering was very important to our needs, as was rails like generators. What started as an experiment has actually turned into a really amazing tool. If anyone is interested, in a more full stack solution, check out https://github.com/TrueCar/gluestick https://github.com/TrueCar/gluestick
- jeremy_k 10y ago
  If anyone is interested in seeing a small project built with Gluestick, I have one here https://github.com/jer-k/phoenix_gluestick_example https://github.com/jer-k/phoenix_gluestick_example. The Gluestick portion is under the _web/ directory. As a note, Gluestick has been iterating and this project is obviously a few months old, but it does show the basic structure of a Gluestick built application. Disclaimer: I work for TrueCar.
rapind 10y ago
But... It doesn't have horizon.io
RichH 10y ago
Just Fng use clojurescript its 1000 times simpler.
drinchev 10y ago
Where's the boundary between boilerplate and framework? I think people have hard times pronouncing framework these days, because it sounds offending in terms of learning curve. Why would you spend X amount of days to learn a framework, when you can spend that time learning about the core technologies and make yourself no-dead-code code base? That's why I dislike frameworks. With React-boilerplate, having a CLI tool that helps you modify the "boilerplate" I think we are getting more or less to the framework definition. In any case I've never used a boilerplate without having to use `rm` command after installing it. That's why I dislike boilerplates and avoid them.
leshow 10y ago
This boilerplate will have to be rewritten again in a few weeks when react-hot-loader 3 comes out and makes the hmre babel plugin obsolete

112 points by neuling 10y ago

Thanks for sharing this here neuling! We've been working on this complete overhaul of react-boilerplate for several months. Based on the combined experiences of tons of collaborators, we've created the strongest foundation to build your next React.js application with. The biggest changes are: - Revamped architecture: Following a bunch of incredible discussions (thanks everybody for sharing your thoughts!), we now have a weapons-grade, domain-driven application architecture. - Scaffolding: Generate components, routes and more parts of your application directly from the command line, skipping all the boilerplate writing! - Performance: We've got the best code splitting setup currently available, giving you the leanest, meanest payload. (The fastest code is the one you don't load!) - JS utilities: We now include redux-saga, ImmutableJS, reselect and react-router-redux to make sure your application scales to the size it needs. - CSS improvements: We use CSS modules for truly modular and reusable styles, code split your styling based on the page the user is on and make sure your code style is in order automatically! I think this is by far the best boilerplate currently available, both for starting your next project and for simply getting inspiration into what's possible. Let me know what you think everybody, I'm beyond excited to finally share this with the world!

msmith 10y ago
I've built a small project using v2 and it really helped me get up to speed and learn some of the best practices for React front-end development. I'm looking forward to trying v3, because it addresses a several things that I felt could be improved in my current project. Specifically, Component tests, CSS organization, & integration with utilities like ImmutableJS & reselect.
- mxstbr 10y ago
  That's so great to hear, you're going to love v3! v2 to v3 is like stone age to modern times. :)
ClayM 10y ago
Does this provide universal/isomorphic rendering?
- mxstbr 10y ago
  Not yet, but it's the next big feature on our roadmap! We've actively been working towards it, we realise it's a really important one too, so it won't be long. Chime into the discussion here if you have thoughts about it: https://github.com/mxstbr/react-boilerplate/issues/174 https://github.com/mxstbr/react-boilerplate/issues/174
- JoeCortopassi 10y ago
  We added that to https://github.com/TrueCar/gluestick https://github.com/TrueCar/gluestick. Plus it gives you a cli and much better upgrade path when you need to change things in the future
aidos 10y ago
So far this feels really nice, kudos! Quick question - what does the HMR work with? If I change a component it seems ok, if I change a reducer it blows up in my face. EDIT is there a walkthrough of getting set up with this anywhere? After about 30 minutes playing I think I'm going to put this down until there's an obvious way of building a simple app with it.
- mercer 10y ago
  I ran into this same issue when setting up my own Redux/React with Hot reloading. The solution I found involved adding this to the store initializer: if (process.env.NODE_ENV !== 'production' && module.hot) { module.hot.accept('./reducer', () => { store.replaceReducer(require('./reducer')); }); I still have issues with getting actions to hot reload, but from what I understand this will work once Hot Reloader 3 is released, so I'll just wait for that.
  - aidos 10y ago
    Thanks! I've decided to skip on boilerplate for the moment. I found that it wasn't very clear as to how to manage the code and I didn't find any obvious walkthroughs. Maybe for people with a little more experience it's useful but I found that it made everything a little murky for me. Since yesterday I've made good progress on my own app and I have have a much better understanding of how everything fits together. It might well be that boilerplate has the answers to some of my questions on how to manage the codebase but I just need to go through the process of figuring it all out for myself.
    - mercer 10y ago
      Yeah, I found that approach to be much better even if it feels like it takes longer. Only now that I've got a working todo app (based on a particular system) working, with a decent understanding of every part, I might look into this boilerplate (or another) to see what might be some 'best practices' and to see where I might've taken a suboptimal approach. I find that this generally is the best approach. Of course, the mistake I usually end up making, and one I made in this case, is that I try to learn too many things at once. For the current project: Redux, React (+ router stuff), Flowtype, Typescript, hot reloading, and something else I forget. Certainly didn't make things easier or more efficient, but it was hella fun! (Flowtype in particular is going to stick around for future projects where I don't want to go all-in on types. Typescript seems like a better long-term bet though, FWIW).

diggan 10y ago

I've never understand what these kind of boilerplates are for. Well, kinda understand if you're doing projects that takes just a few weeks to complete. Otherwise, you're just better off starting with your own boilerplate. I mean, how does updating work? If you improve the scaffolding, people need to merge in their changes? Why is this not a CLI tool that would be effortless to update? Although I must say it's impressive work made on this, and that it's cool to be able to generate many things, I fail to see any big value in using these kind of boilerplates.

bshimmin 10y ago
Given this is a complete rewrite, I guess updating doesn't work at all. But at least in that sense it gives you an authentic experience of modern web development!
mxstbr 10y ago
Updating doesn't work with boilerplates at all, but a CLI tool wouldn't really fix that — what you'd really want is a codeshift[1] for each new version, which we're looking into right now! (you probably also don't need to update them at all) We've added tons of removal guides for each major feature, so people can take the parts they want from react-boilerplate and discard the ones they don't want! I see it more as a reference implementation that gets many small details right, a thing you clone and the cut to your liking to keep all those small details intact. Does that make sense? [1]: https://github.com/facebook/jscodeshift https://github.com/facebook/jscodeshift
- k__ 10y ago
  So it's not like a library or framework, it's just a conglomerate of useful things that will diverge into "your own stack" after starting to develop and you have to update your deps like you would with your own boilerplate, the only thing that it saves you is starting a new project. Which is enough I think :)
  - mxstbr 10y ago
    Exactly, that's an excellent summary. :)

mintplant 10y ago

If this is under the MIT license, doesn't every project that uses it for initial scaffolding have to keep its license around?

stenius 10y ago
The MIT license is not copy-left. https://en.wikipedia.org/wiki/Copyleft https://en.wikipedia.org/wiki/Copyleft
- mintplant 10y ago
  No, but it stipulates that the copyright notice and license text must be retained.
dvcc 10y ago
You can basically do anything at all with it, including include it in a more restrictive licensing setup. The only constraint is that you must include the original license/copyright notices. https://tldrlegal.com/license/mit-license https://tldrlegal.com/license/mit-license
- mintplant 10y ago
  > The only constraint is that you must include the original license/copyright notices. Right, that's exactly what I mean.

deleted 10y ago

[deleted]

atonse 10y ago

Not to beat a dead horse but this boilerplate issue is one of the biggest values of ember-cli, and the main reason I advocate for it over most of the other frameworks. I don't want to spend days figuring out my asset pipeline, build scripts, and implementation of flux/gulp/grunt/webpack/broccoli blah blah. It's good those choices exist, but I don't care about the differences enough anymore, I just want to build my app. Plus, you lose the sense of common solutions when there's this much variance. angular has adopted ember-cli into angular-cli – any plans by the react community to do this?

sotojuan 10y ago
The problem is that the core React team doesn't seem interested in this (which is funny because they did a CLI tool for React Native).
insin 10y ago
> angular has adopted ember-cli into angular-cli – any plans by the react community to do this? First, you would need to define what a React framework looks like, which libraries it needs and which conventions it should use while wiring them together, then build tools around that. Version 3 of React Boilerplate takes steps towards that by deciding on a set of tools, libraries and conventions and providing code generators for adding to them in a compatible way, but the initial wiring is still done as boilerplate (like it says on the tin). react-project [1] was heading towards something more like managing this wiring behind the scenes as a dependency rather than a boilerplate, but it's not being actively developed any more at the time of writing. --- I think React and view libraries like it also necessitate a slightly different approach in that there's no overarching thing to hook into behind the scenes - you just write a bunch of JavaScript and what it returns (plus side effects) is exactly what you get. For example, to use Font Awesome icons with Ember via ember-cli, you install ember-font-awesome and the next time you run ember-cli it does... something... such that an fa-icon component is now magically available in your templates. [2] In React, you install react-fa, import it into module scope where you need it and use it as part of what a render() function returns - your build tools handle it the same as any other JavaScript and CSS you've imported. [3] [1] https://github.com/ryanflorence/react-project https://github.com/ryanflorence/react-project [2] https://github.com/wycats/github-issues-demo/commit/a3358026a42b3438227cff9a3aabb620ce3c09a0 https://github.com/wycats/github-issues-demo/commit/a3358026... [3] https://github.com/insin/react-nwb-github-issues/commit/cad3abd4ec47f78bf50194ec1bd7cbfb1068e733 https://github.com/insin/react-nwb-github-issues/commit/cad3...

fauria 10y ago

This is an excellent tool to compare different React starter kits: Find your perfect React starter project http://andrewhfarmer.com/starter-project/ http://andrewhfarmer.com/starter-project/

pbreit 10y ago
I don't want 60-odd random repos. I'd like to see 3-7 well-chosen options with a few pithy sentences about each.

msy 10y ago

The adoption of the approach ember-cli took over a year ago by both React & Angular (angular-cli) is to me the strongest validation of the relative architectural maturity of Ember over its competitors. Ember has demonstrated singular organisational maturity - stable and consistent release process, standardised build tools, high quality documentation, excellent deprecation warnings & clear upgrade paths. It allows teams to focus on delivering value without prevaricating about build pipelines and trust that the whims of the maintainers won't result in months of rewriting at arbitrary intervals. Equally it's been pressure and progress from React on render speed that's helped push along Ember's Glimmer engine, long may the ecosystem and healthy competition drive innovation!

riebschlager 10y ago

I want to understand the appeal of React, I really do. But I open a project like this in my editor and my linter starts going nuts from all the markup in the JS. And my built-in biological linter starts getting queasy just looking at it. Ugh. I just don't get it. Am I just old and curmudgeonly? And what's with the 200+ line package.json. That's a helluva lot of tooling for a simple web app. GET OFF MY LAWN!

onewaystreet 10y ago
> Am I just old and curmudgeonly? Yes
- dewyatt 10y ago
  To be fair, when I see "Yet moar tweaks" as a commit message, I start to wonder if I am old and curmudgeonly too.
epmatsw 10y ago
What linter are you using? ESLint handles JSX fine as far as I know. And with eslint-plugin-react it actually does some pretty neat validation on it as well. I will say that I initially disliked the inline markup as well, but it honestly just makes practical sense. When we used Handlebars still, I always had the template open in a split when I was editing a view anyway, why not just keep it all as one contained unit?
- riebschlager 10y ago
  I'm using JSHint. I know it's just complaining because of the way I have my .jshintrc set up, but this markup-in-scripts thing is a big mental shift for me. But hey, I'll try anything once.
  - aidos 10y ago
    It's definitely a big mental shift, but it's worth giving it a proper go. For those of us who have been coding since before there was even JS, it's hard to let go of the Html / JS split but honestly, it's so much nicer when you just grab the React approach and run with it.

Niksko 10y ago

Advice please: I tried to wade into the weird and complicated world of web development a few months ago, but eventually I gave up. At first I used a boilerplate (in fact I think it was a previous version of this one), but it felt like I was jumping in the deep end. I didn't know what anything was, I didn't understand the configuration or the setup, and nothing was making sense. So instead I decided "I'll start from scratch, introduce dependencies as I need them, and I'll actually understand what's happening". But then as I started to try and introduce dependencies and pieces of the toolchain and stack (Babel, GraphQL/Relay etc.) and that was a whole different type of confusing. I found it really hard to follow tutorials unless they were written for EXACTLY the stack I was using, because small changes seemed to radically change how I had to go about things. How do you start? Both situations seem perilous. Bottom up is really difficult unless you follow a tutorial that exactly matches your stack. Starting with boilerplate means that if anything breaks you have no idea how to fix it or how anything works.

rdoherty 10y ago
I agree and I'm also curious how someone would integrate all the React ecosystem into an already exiting app (Rails specifically). Starting a new project is easy, rewriting one is a huge challenge.
- RobertKerans 10y ago
  React Rails[1] works fine: you just get React, and it's difficult to integrate other shiny React-associated stuff like Redux, but it makes it incredibly easy to build out an app, or even just sprinkle components throughout an existing Rails app. It's dead simple to get started, and I've found it generally Just Works; the whole team I work on has been using it for the last 4-5 months without any issues. Just add to Gemfile -> it sets up a components folder + a file that imports the file tree -> then optionally set initializer options (like include React Addons, or use stage-0 stuff). All exposed globals though, which is a pain, but that's generally expected with the asset pipeline unless you're very disciplined. There's a pretty complete tutorial, but it's a bit out of date + uses CoffeeScript rather than JSX - I made a copy of the original, with updates, for one of my colleagues, the gist is here (sorry, might be a little rough): https://gist.github.com/DanCouper/b6953544a34606617eb5 https://gist.github.com/DanCouper/b6953544a34606617eb5 To get a bit deeper, there's React on Rails[2], which retains the same entry point, but moves all the JS to a separate folder at root, and uses Node to handle that side of things during development. The setup is batteries included, and pretty flexible, but I haven't used it a huge amount so can't give much detailed feedback. 1. https://github.com/reactjs/react-rails https://github.com/reactjs/react-rails 2. https://github.com/shakacode/react_on_rails https://github.com/shakacode/react_on_rails

kimar 10y ago

Thanks for this Max! We used it recently to migrate a Backbone/Marionette app[1] to React/Redux and it saved us a great deal of time. We hope to write a full writeup on the migration itself soon but meanwhile we've released the code here: https://github.com/thebakeryio/openmic https://github.com/thebakeryio/openmic [1]: https://openmic.io https://openmic.io, a MediaRecorderAPI experiment

aidos 10y ago

I've been reading through / trying redux etc over the last couple of days. This has come at the right time where I know what all the components they're talking about do and I'm interested in seeing more of how redux apps are architected. For people coming to this area fresh it's really daunting. There's a new library for every little thing you can think of and it's almost impossible to know where to start. Fortunately Redux itself is such a simple model that it's easy to build on your understanding of it (vs, say, Angular that has a huge surface area - I know, they're different things, but people are probably going to start with one or the other). Will try this out now to see how I get on. Great timing, thanks!

deleted 10y ago

[deleted]

todd3834 10y ago

We have been working on solving similar problems. Isomorphic rendering was very important to our needs, as was rails like generators. What started as an experiment has actually turned into a really amazing tool. If anyone is interested, in a more full stack solution, check out https://github.com/TrueCar/gluestick https://github.com/TrueCar/gluestick

jeremy_k 10y ago
If anyone is interested in seeing a small project built with Gluestick, I have one here https://github.com/jer-k/phoenix_gluestick_example https://github.com/jer-k/phoenix_gluestick_example. The Gluestick portion is under the _web/ directory. As a note, Gluestick has been iterating and this project is obviously a few months old, but it does show the basic structure of a Gluestick built application. Disclaimer: I work for TrueCar.

rapind 10y ago

But... It doesn't have horizon.io

RichH 10y ago

Just Fng use clojurescript its 1000 times simpler.

drinchev 10y ago

Where's the boundary between boilerplate and framework? I think people have hard times pronouncing framework these days, because it sounds offending in terms of learning curve. Why would you spend X amount of days to learn a framework, when you can spend that time learning about the core technologies and make yourself no-dead-code code base? That's why I dislike frameworks. With React-boilerplate, having a CLI tool that helps you modify the "boilerplate" I think we are getting more or less to the framework definition. In any case I've never used a boilerplate without having to use `rm` command after installing it. That's why I dislike boilerplates and avoid them.

leshow 10y ago

This boilerplate will have to be rewritten again in a few weeks when react-hot-loader 3 comes out and makes the hmre babel plugin obsolete