<story><title>The road to Ember 2.0 RFC</title><url>https://github.com/emberjs/rfcs/pull/15</url></story><parent_chain><item><author>josho</author><text>Is Ember really the right path forward? Or simply a stepping stone to a better (yet to be discovered) solution?&lt;p&gt;Specifically, I remember first picking up Rails and how productive I could be in that environment. I haven&amp;#x27;t felt the same happen with Ember. Instead it continues to feel like more work, as I have to build a client side domain model, as well as a server side model, and often have to think carefully where the logic should be placed.&lt;p&gt;Don&amp;#x27;t get me wrong, Ember is a step in the right direction, and there is a lot to love about it, but at the same time it feels like a local maximum and that there is a better paradigm to be discovered (Meteor perhaps?)&lt;p&gt;So, for those past the initial Ember hurdles, is Ember fulfilling its promises for you with your projects? Do you disagree with me and see Ember as the right long term approach for rich web applications?</text></item></parent_chain><comment><author>grayrest</author><text>I&amp;#x27;m not an Ember dev (I generally can&amp;#x27;t justify a clean slate project) but I do have opinions on the web development landscape:&lt;p&gt;The primary source of incidental complexity in frontend development is synchronizing state. The two main places that&amp;#x27;s happened is synchronizing state between the model and the server and between the DOM and the model. You can see this in the whole history of web development: cookies, sessions, continuations (&amp;#x2F;wave Seaside), the shift client side (not having to sync viewmodel state, just model state), the MVC shift (restricts where you state interacts), componentization (ditto).&lt;p&gt;I believe the vDOM&amp;#x2F;diffing approach is the end of the line in the model-&amp;gt;DOM chain. The only place I&amp;#x27;ve found where it doesn&amp;#x27;t work cleanly is when the output has to be looped back into the model (Rich Text Editor and DnD layout builder) and even that is workable. Otherwise the abstraction has not leaked and reasoning about component behavior has remained local to the component  (it&amp;#x27;s possible to screw this up but that&amp;#x27;s not the fault of the approach). Once the view layer is written, data goes in, DOM is in the correct state.&lt;p&gt;Server synchronization remains a problem. The current approaches like Meteor&amp;#x2F;Derby&amp;#x2F;Firebase aren&amp;#x27;t unreasonable but they&amp;#x27;re rooted in the same place-oriented temporal logic as two way data binding. I don&amp;#x27;t know what the solution is here. The most promising lead I&amp;#x27;ve run across is Convergent&amp;#x2F;Commutative Replicated Data Types (CRDTs) from the distributed systems researchers.&lt;p&gt;In the shorter term, I expect CSP (go channels) to gain acceptance as a replacement for callbacks&amp;#x2F;promises. It&amp;#x27;s reasonable to implement the model in javascript on top of generators and is roughly as powerful as functional reactive (FRP) approaches but more accessible to non-functional programmers. There are other efforts like the js streams effort so this might not be the answer but I do expect the community to stumble into a stronger async model than promise chaining.&lt;p&gt;I&amp;#x27;m not particularly bullish on Web Components. Having scoped CSS will be very nice but the rest is focused on problems I don&amp;#x27;t see as important. I believe the core problem with widgets on the web is customization. There&amp;#x27;s a lot of web components material on encapsulation but I haven&amp;#x27;t seen a good explanation of how I can tweak the classList on a node in the shadow DOM for a use case the author didn&amp;#x27;t anticipate. I&amp;#x27;ve used widget systems (netWindows, Dojo, Ext, YUI, Sproutcore) and have re-implemented many components for this and similarly minor reasons. Encapsulation by itself doesn&amp;#x27;t do a whole lot for this, I&amp;#x27;ve implemented drop down combo boxes a dozen times. The x-tags&amp;#x2F;polymer interoperation demos are neat and I think that&amp;#x27;s the goal but the parochial nature of js libs means it&amp;#x27;s not something I&amp;#x27;d really like to put into one of my projects. Smart people work on this effort so I feel like I&amp;#x27;m missing something or not the target audience.</text></comment>
<story><title>The road to Ember 2.0 RFC</title><url>https://github.com/emberjs/rfcs/pull/15</url></story><parent_chain><item><author>josho</author><text>Is Ember really the right path forward? Or simply a stepping stone to a better (yet to be discovered) solution?&lt;p&gt;Specifically, I remember first picking up Rails and how productive I could be in that environment. I haven&amp;#x27;t felt the same happen with Ember. Instead it continues to feel like more work, as I have to build a client side domain model, as well as a server side model, and often have to think carefully where the logic should be placed.&lt;p&gt;Don&amp;#x27;t get me wrong, Ember is a step in the right direction, and there is a lot to love about it, but at the same time it feels like a local maximum and that there is a better paradigm to be discovered (Meteor perhaps?)&lt;p&gt;So, for those past the initial Ember hurdles, is Ember fulfilling its promises for you with your projects? Do you disagree with me and see Ember as the right long term approach for rich web applications?</text></item></parent_chain><comment><author>csallen</author><text>I&amp;#x27;ve been using both Ember and Ember Data for almost two years now for pretty much everything (mostly contract work and personal projects).&lt;p&gt;Ember had a very high learning curve when I first started using it. Admittedly, I immediately jumped into a huge project with it, which is worse for learning than starting with lots of small ones. Still, it took me months before I felt truly productive. Hopefully things have improved since then, but I&amp;#x27;d say it was worth it, regardless. I can&amp;#x27;t imagine writing a substantial Javascript-heavy app without it or something like it. I did that several times in the past, and I always ended up having to basically construct my own ad hoc framework, which takes a ton of time and maintenance.&lt;p&gt;Comparatively, Ember has its own built-in conventions for routing, views, models, etc, similar to Rails. Once you know how it all works, it&amp;#x27;s fairly obvious what &amp;quot;the right approach&amp;quot; is to using these features. The result is that your code is more easily navigable and maintainable, both by yourself and by other Ember developers seeing your code for the first time.&lt;p&gt;As for the back-end, the last few projects I&amp;#x27;ve worked on with Ember, I&amp;#x27;ve spent very little time worrying about it. One has a Rails back-end that basically serves a REST API for the Ember app. After I finished building the REST API, I almost never had to touch the back-end again. The other two projects use Firebase and the Dropbox Datastore Sync API, both of which store data and feed it into the Ember app in real time in a Meteor-esque fashion. And again here, I spend 99% of my time working with front-end code.&lt;p&gt;So, to answer your question, yes, Ember is fulfilling its promises for me, and I think it&amp;#x27;s likely to be the right long-term approach. I haven&amp;#x27;t used Meteor, yet, but it&amp;#x27;s hard for me to see it being vastly superior to something like Ember+Firebase. And if it doesn&amp;#x27;t put a lot of thought into handling things like views (and views within views (and views within views within views)), then I can&amp;#x27;t see it being much of a step forward for writing front-end code.</text></comment>