I suspect that we didn't get enough Ember responders, because I do think they have a reasonable sized community. 9k responses is likely not enough to draw a reasonable conclusion that it isn't popular. I wish we could have paired up npm downloads or some other stat besides some of this data...
Ember has a pretty large community—the framework has a few conferences every year that are filled up. Most Ember devs don't seem to participate in a lot of JS community things and are very quiet compared to say, the React community.
Trouble is with angular 1 is a lot of people are probably still installing via bower, angular 2 might have a lot of people installing via jspm, elm uses scoped packages which still don't have stats...
What kind of was a head scratcher for me was that Ember had such a high rate of "heard of it, not interested" from the responders. Especially when I looked a couple columns over at the Angular 1 data where a lot of people tried it but would never try it again.
I don't know how a sample of 9k maps to the developer community at large but I found it puzzling that so many people were dismissive of Ember. What makes Ember unappealing enough to not warrant being tried out in a side project? Personally, I saw it and thought "boy, a framework that wants to be stable for several years - sign me up."
I think it's because Ember forces you to do everything The Ember Way. Sure they're technically writing JavaScript, but it only works in the context of Ember. Ember makes it extremely painful to use standard JavaScript libraries so it's not surprising that Ember developers don't respond along with the rest of the JavaScript community.
Offline support is tricky because each app needs to implement what happens in the case of data conflict. Meteor already has the groundDB package that allows for offline support in local storage. I would imagine you could implement a read only option into local storage once they release reactive graphQL.
We have some thoughts about how the new invalidation system will make offline a lot more feasible. In pub/sub based Meteor apps you would need to reload all of the data if you took too long to reconnect, in the new system you will hopefully be able to get just the diff after a much longer reconnect gap, or possible indefinitely depending on implementation details. This is because the app server doesn't need a copy of all of the client's data anymore.
Well said! I actually think the community has done a ton of work on Electron and we will see the desktop option soon too.
This announcement is exciting on many levels and I think some of the unspoken bits will be interesting later too. I hear they are working directly with people at Facebook on this project.
I think when you look at the companies using React now, you start to understand why it is gaining ground quickly. Couple that with the fact that Facebook has dumped a lot of efforting into the tooling around it, it makes sense to me.
