Who needs it? The entire world is on 4G/LTE :D

I think that both are going to be remarkably confusing without some understanding/prior usage of a Javascript MV*-esque framework (or how to architect those applications in general). That said, I can only speak to the challenges you'd actually face with React (as I've never done anything with Angular in practice).

The biggest challenges you'll face with React are:

1. Architecture
2. Tooling

The practical aspect of building components is straightforward, and arguably the easiest thing to pick up with React. The rest, unfortunately, is a bit chaotic.

When Backbone apps were at their peak, many dev had issues figuring out where to put all the puzzle pieces. Oftentimes, it led you to make your own framework (I believe Rdio did this for their apps--at Trunk Club we used one that sat atop Backbone called Chaplin). But even then, you often ran into the paralysis that comes with having a feature/application to build and not knowing where to insert the new pieces.

This is sort of where the React community is right now. There are some great patterns and libraries out there, and a great deal of smart developers working away to make the experience even better. Simultaneously, we're watching this happen in real-time. It's exciting, but scary for a company consuming the library to support & trust.

Similarly with choosing appropriate tooling, you are left to your own devices. This is unfortunate, because React effectively needs you to inject the Babel transpolar into your build process (not only that, but you need a build process!). Now, just like Backbone, you can make your own meta-framework that sits atop the current suite of in-fashion flashy tooling, but that is entirely at your own risk, and oftentimes an activity that a product manager is not going to allot time for you to handle.

I'm conflicted--I'm incredibly productive with React (more so than I was when working in Backbone) and really enjoy working with it on a day-to-day basis. But I think there's problems around abstraction & tooling that Ember and Angular handle with greater ease. At the end of the day, that would likely matter more if you are on a larger team. And especially if you are working for a company that expects reliability, features out-of-the-box, and strong community support, a custom-baked React solution is likely not your best bet.

As far as I can remember, a lot of Angular+React projects/examples popped up from Angular folks that wanted to slowly transition their projects away from being so intimately tied to Angular (e.g. using React as the base component while still routing + fetching with Angular). Whether or not they're practical? No idea.

They very well might be dead, but knowing some people that have worked for companies in similar acquisition situations, there's a very real, gigantic, unpredictable chunk of work that comes from integrating your systems with the parent company's systems.

There very well might be internal struggles with regards to how to position the product within the family, but I'd be more willing to bet that they just entered a company with a "don't comment on closed-source stuff that isn't done yet" policy and have a lot of technical debt to manage and reorchestrate.

Fascinating! I really like this strategy, especially in an application that bridges teams.

Seconded. I just bought one in Wolf Grey and it's already the best bag I've ever owned.

Thanks Andy! For the 3rd question, it's more of a soapbox for designers answering to vent against crappy things engineers do to/with the work that they're designing. Does that make more sense?

Dribbble the site is great! Dribbble the community is a bit problematic.

It's tough because it really hits the sweet spot of being engaging and fun to browse; if it was truly an uber design-salon where everyone is tearing up mockups with hyper-critical feedback, no one would share, remix, or recreate the work they see. Would I love it if everyone was 100% honest and critical 100% of the time? Probably. Will that happen? Oh hell no. And that's totally fine.

So while I understand the criticism (and have somewhat perpetuated it myself), I also know that you have to separate the platform from the creators. There are many times where showing a peek of your creative work and getting an impulse of feedback is highly rewarding and really useful, and there are times where you need to put up giant flow diagrams and walk through/rationalize a redesign with product owners and stakeholders.

Just because Dribbble doesn't afford the second as well as the first doesn't mean it's inherently valueless.

Nice job! I'd love to hear about the good/bad of building an application like this in Om/React.

I'm flabbergasted that they didn't minify most of those files, nor did they concatenate anything.

Try spoofing 3G internet speeds and changing your Chrome debugger to show an iOS6 viewport; it's sad how bad it performs.

I have to imagine that there was an institutional reason that this sort of redesign didn't get the engineering help needed to make it efficient and fast.