Whilst this comment might sound facetious, it isn't intended to be.
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".
Or a list that allows people to use checkboxes to select the JS technologies, with a grid showing which starter kits use that tech.
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.
"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.
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".
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.
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.
Ember's ember-cli remains the easiest way to avoid all the build tool/boilerplate annoyances.
On the other hand, the fact that apps end up being a stack of loosely integrated libraries can make the process of developing in the ecosystem rather overwhelming. It's hard to keep up with the progression of microlibraries and features.
One thing's for sure though: it's a fun time to be a Web developer.
v3 will make this seperation even more pronounced, with a new application structure that hides a lot of the magic and gets out of the way.
While I haven't tried it out yet, it seems that Meteor is pretty close to what I think of as ideal, and the news that they are going to integrate React is great. (Now if only they announced native RDMBS support. Also, I care about server-side rendering and would have to double-check whether that's possible in Meteor.)
Unbundling these takes a lot of effort, and for me, probably more than the gain from using the boilerplate in the first place.
I take care of setting up Babel and Webpack with hot-reloading, add linting rules that make sense, write a working ServiceWorker script, etc., so you only have to worry about writing your application.
* Disclaimer: I made the boilerplate this post is about.
I'm the main contributor behind this boilerplate. I'm currently hard at work getting v3 out, which you can see in the v3.0.0 branch of the repo.
The biggest changes are: A new application structure to keep most of the webpack magic hidden from users, stateless components across the board, a npm run pagespeed command and much better documentation.
This was posted while I was sleeping (thanks tilt!), so I'll go through this thread to answer any questions/concerns. If you can think of any more questions you have, reply to this comment so I get a notification!
Minor Edit: You can also follow me on twitter under the same handle stay up to date with changes to the boilerplate!
How would I set them so it works on Windows as well? I'll change it asap!
: See this commit: https://github.com/mxstbr/react-boilerplate/commit/ea5794333...
Instead I Object.freeze the state, so developers get a warning when they mutate the state directly.
I'm happy to change this though, what do you see as the main benefits of including Immutable(JS or other)?
Generally Immutable makes the reducers syntax much cleaner and allows to more easily "query" the state.
I am myself torn between using it and thus asked..
I feel that simplicity, and ease of use should rain supreme over features. The fact that this takes such a huge amount of other files to setup worries me.
Am I the only one with this concern?
It's just that these additions are things you end up wanting once a project grows, so you might as well start with them.
You don't need any of these things, but they make it so much nicer and easier to write an application. You can easily write a React app without them, but it's less fun and it takes more time.
The point of the boilerplate is to let you focus on writing your application, and let the boilerplate take care of making that experience a very nice one.
If you have any other ideas how to make this boilerplate even more performance orientated, hmu!
Server-side: HTML starts loading with component markup already initialized, (other stuff continues.)
Might have to revisit that again though...
I have a lot of legacy YUI code in a Rails app (using Rails' asset pipeline) that I want to rewrite. Anyone have resources on how to get setup and refactor in pieces?
When you write React code (whether for a single-page React application or a mostly-legacy application), there is a point where you need to tell React to start rendering a root component inside a given, existing DOM element. Your legacy application should NOT mess with anything under this DOM element, as this will be solely managed by React. However, it is entirely possible to have several of these root components on the same HTML page. It makes it possible to refactor a complex page progressively. You're still going to run into issues if you need communication between legacy and Reactified UI elements, though. You will need to setup, eg, listeners manually. In the case where you need to update parts of a form, just tell your React store to write to hidden input fields instead of doing Ajax with the server.
Fair warning though, React is focused on rendering and initializing, so it doesn't come with a bunch of handy JS functions like YUI or jQuery. But you can use React & other JS libs together, as long as you're careful that the other JS lib doesn't change the markup of a React component (which would take it out of sync.)
I take care of running webpack with the right envs, linting and building your application, you use the npm commands and write a great app!
: See: https://github.com/mxstbr/react-boilerplate/blob/master/docs...
Production: npm run build