Really a nice idea. In your opinion React delivers the promise to get out all the business logic of the UI? And how much time to develop the site? Any tutorials or resources recommended?
I think it does, although you're always free to hack it :P I've definitely thrown some ternary operators in my render methods for simple conditionals in order to avoid heavier solutions.
Re: time;
The team is me and my cofounder. I'm full time dev, my co-founder splits his time between ops, dev, and business stuff. First commit was March 18, but we were splitting time with our previous product attempt for about a month of that. So maybe call it 3 months of full time dev work? That included quite a bit of learning beyond React; the whole stack is new to us (Node/Express, Neo4j, Socket.io, ShareJS, SimpleWebRTC).
For coming up to speed on React, I definitely spent a lot of time with the Facebook documentation, which is decent. For flux I hit pretty much every resource linked on the flux github repo, but I think the best overview I came across was this video by Jing and Bill from FB: https://www.youtube.com/watch?v=i__969noyAM
Also, keep an eye out on Stack Overflow. It looks like Bill spent a lot of time answering flux questions. You might find it worthwhile to read through his answers to flux things: http://stackoverflow.com/users/395379/fisherwebdev
Before Angular I was coming from knockoutjs, and most of Angular made sense to me pretty immediately out of the box. It felt very quick to get going.
The community/tooling around it was also pretty great. For example, angular-material is miles ahead of material-ui (the most popular react material UI framework). I've definitely missed having access to so many great off the shelf libraries.
The downsides were mainly around architecture; we ended up littering state all over the place as a result of two-way bindings, and it always felt a little like we were missing an important abstraction. Even on an MVP, it started to feel like we were nervous about touching components because we weren't sure what would break elsewhere in the system.
Flux stores/dispatcher is that abstraction we were missing. We've made an effort to follow the model closely with all of our DB data and it pays off wonderfully. The code is easier to reason about and I have more confidence about which changes could produce downstream effects.
The downside is following the pattern tightly requires a whole lot of boiler plate. For simple things like flipping a bit in a component in response to a user action, angular was incredibly easy. Doing it following the Flux pattern is much less so (dom element calls a callback in the component which calls an action creator which calls the dispatcher which is listened to buy a store which is observed by the component..). In Angular you touch two files with one line of code, with React the same change might involve changes across five or six files with a lot more boilerplate.
I do think that extra work pays for itself in future maintenance costs, but for a scrappy start up trying to move fast, it can at times feel painful.
Which brings me to testing; The short answer is: we don't. I think testing is important for a product with an established user base. I think it's less important when you're trying to get an MVP out there to see what people think. We know that what we showed today will need to change, we're just not sure how yet. Assuming that pretty much everything in the product will churn in the next six months, setting up a robust test suite felt too expensive for the value it returns. As the product consolidates we'll fill in tests, but not while the feature churn is as high as it is.
I've tried this out in a meeting with a couple of other people. It worked pretty well! I work remotely and this is definitely shaping into something really great.
Audio-only chat would be nice - we use skype, and audio only is our default. If there was a way to make the notes area be a code editor, or have two tabs - one for notes, one for code, that would be really nice. We use google docs a lot, but its terrible for code, so sometimes we use collabedit. Finally, it would be really nice if the notes/todos could integrate with something like an issue tracker or project management tool.
I second pretty much everything in here.In my meeting we were essentially working together grooming a github issue- I could imagine that issue being addable as a tab behind or instead of the notepad.
