In a different note, I think if you write it yourself from scratch you'll have more control and knowledge down the road when it comes to nasty bugs but I won't blame you for choosing this over spending weeks setting up a React app.
In a different note, I think if you write it yourself from scratch you'll have more control and knowledge down the road when it comes to nasty bugs but I won't blame you for choosing this over spending weeks setting up a React app.
I think most boilerplates add way too much and are overly opinionated. I like that this is simple, and "eject" gives power users an even better starting point.
Right now, I'm going through the Om.next tut series, and it is pretty awesome so far. I think I'm going to pass on datascript, though. This is total skunkworks though, if people at work found out that was using clojurescript on the front end, they would be very concerned about me.
The killer feature for Om.next, imo, is using a reader function to define the relationship between a component and the one application state atom. Combine that with an identifying function that associates a component with a field in the application state, and you enable the framework to make very precise component updates.
React Starter Kit comes with GraphQL as its API layer. I love GraphQL, and have written tons of it when writing Relay code, but I wouldn't ever expect someone getting up to speed on React to use it.
You have to limit the number of things you throw at newcomers.
Furthermore, the Eject feature (https://github.com/facebookincubator/create-react-app#conver...) allows someone to move from the default configuration to their own when they feel comfortable.
Off the top of my mind:
- Server or Universal rendering - Hot Module Reloading (refreshing is fine!) - (early stage) proposed JS syntax
The main thing that is missing from this package is testing, but that's a very opinionated kettle of fish.