The road to Ember 2.0 RFC(github.com)
github.com
The road to Ember 2.0 RFC
https://github.com/emberjs/rfcs/pull/15
62 comments
The RFC process sounds very nice but be careful. PHP has been doing it for a while now and while it's working out nicely for them in some regards - pretty much every php person I talked to involved with it hates 'internals' with a passion.
We do development of new features behind feature flags, and have automated tools to help enable, disable and strip them. We're planning on moving to a model where we do an approximately annual "garbage collection" pass on the framework (corresponding with a major version bump) and simply nuke all of the code that has been deprecated since the last major version release.
Maybe a process similar to Django's would be helpful? https://docs.djangoproject.com/en/dev/internals/release-proc...
Fun fact: Python's PEP process influenced Rust's RFC process, which influenced Ember's.
There is a long history behind the hating of 'internals' in PHP land. The RFC process has improved matters, but can't get rid of all the poison that already existed.
[deleted]
Is Ember really the right path forward? Or simply a stepping stone to a better (yet to be discovered) solution?
Specifically, I remember first picking up Rails and how productive I could be in that environment. I haven'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.
Don'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?)
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?
Specifically, I remember first picking up Rails and how productive I could be in that environment. I haven'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.
Don'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?)
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?
I'm not an Ember dev (I generally can't justify a clean slate project) but I do have opinions on the web development landscape:
The primary source of incidental complexity in frontend development is synchronizing state. The two main places that'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 (/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).
I believe the vDOM/diffing approach is the end of the line in the model->DOM chain. The only place I've found where it doesn'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's possible to screw this up but that's not the fault of the approach). Once the view layer is written, data goes in, DOM is in the correct state.
Server synchronization remains a problem. The current approaches like Meteor/Derby/Firebase aren't unreasonable but they're rooted in the same place-oriented temporal logic as two way data binding. I don't know what the solution is here. The most promising lead I've run across is Convergent/Commutative Replicated Data Types (CRDTs) from the distributed systems researchers.
In the shorter term, I expect CSP (go channels) to gain acceptance as a replacement for callbacks/promises. It'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.
I'm not particularly bullish on Web Components. Having scoped CSS will be very nice but the rest is focused on problems I don't see as important. I believe the core problem with widgets on the web is customization. There's a lot of web components material on encapsulation but I haven'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't anticipate. I'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't do a whole lot for this, I've implemented drop down combo boxes a dozen times. The x-tags/polymer interoperation demos are neat and I think that's the goal but the parochial nature of js libs means it's not something I'd really like to put into one of my projects. Smart people work on this effort so I feel like I'm missing something or not the target audience.
The primary source of incidental complexity in frontend development is synchronizing state. The two main places that'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 (/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).
I believe the vDOM/diffing approach is the end of the line in the model->DOM chain. The only place I've found where it doesn'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's possible to screw this up but that's not the fault of the approach). Once the view layer is written, data goes in, DOM is in the correct state.
Server synchronization remains a problem. The current approaches like Meteor/Derby/Firebase aren't unreasonable but they're rooted in the same place-oriented temporal logic as two way data binding. I don't know what the solution is here. The most promising lead I've run across is Convergent/Commutative Replicated Data Types (CRDTs) from the distributed systems researchers.
In the shorter term, I expect CSP (go channels) to gain acceptance as a replacement for callbacks/promises. It'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.
I'm not particularly bullish on Web Components. Having scoped CSS will be very nice but the rest is focused on problems I don't see as important. I believe the core problem with widgets on the web is customization. There's a lot of web components material on encapsulation but I haven'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't anticipate. I'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't do a whole lot for this, I've implemented drop down combo boxes a dozen times. The x-tags/polymer interoperation demos are neat and I think that's the goal but the parochial nature of js libs means it's not something I'd really like to put into one of my projects. Smart people work on this effort so I feel like I'm missing something or not the target audience.
There's a lot of stuff here that I agree with.
I feel the web components hype in particular to be pretty bizarre, though I feel it's died down recently. Too often the current generation of web people refuse to acknowledge how much has come before as far as Dojo/YUI etc.
What use is a component when every design wants it to look different? Consider the effort it would take to make the native chrome [type=date] datepicker styled however your site desires. That's a relatively low-controversy component compared to tab selectors, pill selectors, who knows what. At some point, it feels better to just write your own and have full control over the style and the lifecycle.
I feel the web components hype in particular to be pretty bizarre, though I feel it's died down recently. Too often the current generation of web people refuse to acknowledge how much has come before as far as Dojo/YUI etc.
What use is a component when every design wants it to look different? Consider the effort it would take to make the native chrome [type=date] datepicker styled however your site desires. That's a relatively low-controversy component compared to tab selectors, pill selectors, who knows what. At some point, it feels better to just write your own and have full control over the style and the lifecycle.
> What use is a component when every design wants it to look different?
You can do a lot with CSS, particularly if the component's CSS has a clean divide between structure and appearance. It's pretty common to want a component to do everything but that one thing, to trigger an event here, to need a wrapper div around the search results, etc. The problem is that everybody's just one thing is different and trying to accommodate them all gets you YUI2.
Re-implementing things winds up being the easiest route but I don't want to re-implement things. Building a business analytics or admin CRUD screen does not fill me with joy. I've been thinking about this problem for years. I really want to solve the problem, at least for my own use, so that I can slap boring stuff together without backing myself into a corner. The dream is to be able to slap everything together then customize and not have it suck.
My best attempts thus far have been in React where I can build override points into my components by having them take additional classes and optional subcomponents. It works (hoorah for composition) but the problem is in describing the input data and events so that you don't need to know the internal implementations of everything. I think the solution there is something along the lines of go interfaces or clojure's protocols and that there's a similar separation of concerns available in sass for the CSS side of things. I poke at it every so often but get distracted by other things.
You can do a lot with CSS, particularly if the component's CSS has a clean divide between structure and appearance. It's pretty common to want a component to do everything but that one thing, to trigger an event here, to need a wrapper div around the search results, etc. The problem is that everybody's just one thing is different and trying to accommodate them all gets you YUI2.
Re-implementing things winds up being the easiest route but I don't want to re-implement things. Building a business analytics or admin CRUD screen does not fill me with joy. I've been thinking about this problem for years. I really want to solve the problem, at least for my own use, so that I can slap boring stuff together without backing myself into a corner. The dream is to be able to slap everything together then customize and not have it suck.
My best attempts thus far have been in React where I can build override points into my components by having them take additional classes and optional subcomponents. It works (hoorah for composition) but the problem is in describing the input data and events so that you don't need to know the internal implementations of everything. I think the solution there is something along the lines of go interfaces or clojure's protocols and that there's a similar separation of concerns available in sass for the CSS side of things. I poke at it every so often but get distracted by other things.
I've been using both Ember and Ember Data for almost two years now for pretty much everything (mostly contract work and personal projects).
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'd say it was worth it, regardless. I can'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.
Comparatively, Ember has its own built-in conventions for routing, views, models, etc, similar to Rails. Once you know how it all works, it's fairly obvious what "the right approach" 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.
As for the back-end, the last few projects I've worked on with Ember, I'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.
So, to answer your question, yes, Ember is fulfilling its promises for me, and I think it's likely to be the right long-term approach. I haven't used Meteor, yet, but it's hard for me to see it being vastly superior to something like Ember+Firebase. And if it doesn't put a lot of thought into handling things like views (and views within views (and views within views within views)), then I can't see it being much of a step forward for writing front-end code.
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'd say it was worth it, regardless. I can'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.
Comparatively, Ember has its own built-in conventions for routing, views, models, etc, similar to Rails. Once you know how it all works, it's fairly obvious what "the right approach" 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.
As for the back-end, the last few projects I've worked on with Ember, I'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.
So, to answer your question, yes, Ember is fulfilling its promises for me, and I think it's likely to be the right long-term approach. I haven't used Meteor, yet, but it's hard for me to see it being vastly superior to something like Ember+Firebase. And if it doesn't put a lot of thought into handling things like views (and views within views (and views within views within views)), then I can't see it being much of a step forward for writing front-end code.
You seem to be as good a person as any to ask:
What are you building? Are these apps? Are these just blog sites? Portfolios? Admin sites?
What are you building? Are these apps? Are these just blog sites? Portfolios? Admin sites?
I'm building apps. The projects I'm currently working on are a heavy-duty collaborative task manager (think Asana), a task manager + email client (think Mailbox, but with tasks and for the web instead of mobile), and a note-taking app (think Evernote).
Before that, I worked on other apps using Ember, as well as one or two more "website-like" projects that are mostly static, but had a few interactive widgets. FWIW I think Ember was overkill for those, and I would've been better off just going with normal HTML/CSS delivered from the server and Backbone for the widgets.
Ember bills itself as "a framework for creating ambitious web applications", and I agree with that use-case completely.
Before that, I worked on other apps using Ember, as well as one or two more "website-like" projects that are mostly static, but had a few interactive widgets. FWIW I think Ember was overkill for those, and I would've been better off just going with normal HTML/CSS delivered from the server and Backbone for the widgets.
Ember bills itself as "a framework for creating ambitious web applications", and I agree with that use-case completely.
Having reflected on my own question for the past 20 minutes I'll add the following.
For decades programming languages struggled with how to persist object state. We built custom file formats, tried to serialize object graphs, built ORMs to map to SQL databases, but it took us three generations or so to get ORMs right.
Today's struggle is how to program a distributed application. First we built the server to render dumb html, then got smarter and added some glue like JQuery to the client, now we are onto full fledged client side frameworks. But we haven't fundamentally solved the productivity challenge to generate a rich client experience that leverages the work done on the server. I can't help to think that a unified programming model between the server and client frameworks could become a significant step forward.
For decades programming languages struggled with how to persist object state. We built custom file formats, tried to serialize object graphs, built ORMs to map to SQL databases, but it took us three generations or so to get ORMs right.
Today's struggle is how to program a distributed application. First we built the server to render dumb html, then got smarter and added some glue like JQuery to the client, now we are onto full fledged client side frameworks. But we haven't fundamentally solved the productivity challenge to generate a rich client experience that leverages the work done on the server. I can't help to think that a unified programming model between the server and client frameworks could become a significant step forward.
I'm excited to see where concepts from isomorphic JS and stuff like browserfy will end up. Obvious stuff aside, imagine what you could do with a fully-baked unified model and a bit of P2P glue...
https://github.com/voltrb/volt is a new ruby framework that does exactly what you described
We began rebuilding Intercom with Ember.js in April this year. We now have 12 engineers working with Ember and both the pace of development and the quality of our output has been amazing. Ember bills itself as 'A Framework for creating ambitious applications' and we've found this to be very true. We upgrade to the latest point release every six weeks or so and this process has been painless.
This isn't exactly the question you asked, but I recently accepted that client-side applications are the future and spent some time with Ember (which as a Rails developer I wanted to like) and AngularJS (about which I was skeptical because it looked like nothing I'd seen before).
After two weeks in each, only AngularJS was paying off (I got architectural and productivity benefits in return for the time I spent learning all those framework things which seem arbitrary at first) so I stopped looking at Ember and haven't looked back.
After two weeks in each, only AngularJS was paying off (I got architectural and productivity benefits in return for the time I spent learning all those framework things which seem arbitrary at first) so I stopped looking at Ember and haven't looked back.
Two weeks...
Same boat as you. I wanted to like Ember; everything on paper looked great. But with Angular, things just clicked and have allowed me to be more productive than ever.
I would advise both of you to give Ember another chance!
I like to think of things as lying a spectrum: On one end, you have completely hand-rolled framework-less JavaScript. This requires no learning curve whatsoever, but things may get slow and messy as time progresses and you miss out on the cumulative benefits of a framework. At the other end of the spectrum is something like Ember, which takes a while to learn is is just plain overkill for small projects, but which for big projects starts to pay dividends in the long run.
I like to think of things as lying a spectrum: On one end, you have completely hand-rolled framework-less JavaScript. This requires no learning curve whatsoever, but things may get slow and messy as time progresses and you miss out on the cumulative benefits of a framework. At the other end of the spectrum is something like Ember, which takes a while to learn is is just plain overkill for small projects, but which for big projects starts to pay dividends in the long run.
I would consider coupling your server and client a major step backwards (again) for application architecture.
I love how they didn't do what Google did with Angular and did a big rewrite.
The fact it's possible to easily migrate a current day Ember code base incrementally is a big win.
I don't blame Google - but this is a nice win for Ember.
The fact it's possible to easily migrate a current day Ember code base incrementally is a big win.
I don't blame Google - but this is a nice win for Ember.
Google doesn't have a choice with Angular. They have to rewrite it because the original is a wrong approach.
I'm curious, could you expand on this?
Automatically 2-way binding everything is a serious mistake since most elements don't need it and it's a performance hit. Scope and ControllerAs are in conflict (particularly with ng-if/ng-repeat). Dependency injection is needless, since Javascript module requires (via Browerify or Webpack) handle this much better and sensibly. Extremely hard to debug since stacktraces are useless. Module factories, services, and values are unnecessary, since Javascript already has established design patterns for these concepts.
If you haven't tried React, please give it shot. Particularly if you are about to make a decision on what frontend framework you will use, or if you are using AngularJS already and recognize that it's approach leads you to ugly workarounds.
I can't emphasize enough that AngularJS is bunk.
If you haven't tried React, please give it shot. Particularly if you are about to make a decision on what frontend framework you will use, or if you are using AngularJS already and recognize that it's approach leads you to ugly workarounds.
I can't emphasize enough that AngularJS is bunk.
I love Angular for how it allows to seprate concerns cleanly. You view logic goes to templates and directives. Your data/bisness logic goes to controllers. When developer writes controller he thinks in terms of data he works with. When developer writes view he thinks in temrs of how to represent data available to him from scope.
I hate how in Backbone or just jQuery way you have mess of html, javascript and data manipulation in same class... Reminds of how messy frameworkless PHP looks...
Now looking at some React examples I see jsx files that do same mess... Model manipulation, some logic and html code in same file... WTF? How is that good? May be someone can point me to a good example app of using React with good speration of concerns? Classical TODO MVC looks horrible... https://github.com/tastejs/todomvc/blob/gh-pages/examples/re...
I hate how in Backbone or just jQuery way you have mess of html, javascript and data manipulation in same class... Reminds of how messy frameworkless PHP looks...
Now looking at some React examples I see jsx files that do same mess... Model manipulation, some logic and html code in same file... WTF? How is that good? May be someone can point me to a good example app of using React with good speration of concerns? Classical TODO MVC looks horrible... https://github.com/tastejs/todomvc/blob/gh-pages/examples/re...
Reinventing control structures in an expression language and placing that in HTML attributes should tell you everything you need to know about AngularJS foolishness. Why should users incur the penalty of download something some needless as an express ssion language when JavaScript is already richly expressive? Why cause developer anguish by having an expression language which can not be statically checked and throws silly stacktraces? It makes zero sense.
The only thing you need is the last mile transformation from view model to DOM, everything else that AngularJS provides is unnecessary and foolish.
The only thing you need is the last mile transformation from view model to DOM, everything else that AngularJS provides is unnecessary and foolish.
I haven't faced any of the issues that you talked about. That said, we sort of "get" angular and write proper angular code because we actually understand it well enough. I have seen code in projects which are outright crap. For example, we don't do any DOM manipulations whatsoever in any of our controller code. There were no major hacks that I can recall of.
One thing I agree with is the useless stack traces which made is extremely hard to debug Angular.
One thing I agree with is the useless stack traces which made is extremely hard to debug Angular.
Wait. Is the new AngularJS rewrite bunk?
They mention HTMLBars in passing, but mostly emphasize the fact that support for the current Handlebars syntax won't go away in 2.x. Three cheers for JavaScript frameworks with reasonable attitudes toward backwards-compatibility (!)... but as someone who HATES the current Handlebars syntax, I'm wondering if they've also committed to having HTMLBars fully ready-to-go at 2.0's launch? I know that "pieces of it are in place" in the beta right now, but will 2.0's date depend on it being fully ready?
We've started using the term HTMLBars to mean a collection of changes to the Ember rendering pipeline. In the current release (1.8) we've added metal-views (a renderer refactor), in the next release (1.9) we will be adding Streams (a data-binding refactor), and in 1.10 we hope to land parts of the new syntax and the DOM-based templating engine.
We've worked very hard to make HTLMBars an incremental release, and not a Big Bang rewrite. Partially because of this, it has taken longer to ship than was planned. However I'm personally very happy about how smoothly the transition is going thus far, and if you are a user of Ember.js I think you should feel the same way. :-D
We've worked very hard to make HTLMBars an incremental release, and not a Big Bang rewrite. Partially because of this, it has taken longer to ship than was planned. However I'm personally very happy about how smoothly the transition is going thus far, and if you are a user of Ember.js I think you should feel the same way. :-D
HTMLbars will land well before 2.0, most likely in the next release. We've been doing the integration piecemeal to ensure that we don't break production apps; we want everyone to get to experience the new awesome.
It's worth noting that the very next release (1.9) is already locked and loaded (it branched to beta). So when Tom says "next release" he means 1.10.
Also, some of the points in the RFC are features that depend on the new templating engine but will likely not land in 1.10. We give guesstimates for when we think things will land in the RFC :)
Also, some of the points in the RFC are features that depend on the new templating engine but will likely not land in 1.10. We give guesstimates for when we think things will land in the RFC :)
> You should begin moving your app to Ember CLI as soon as possible.
While I'm using ember-cli for thick clients I'm using the ember-rails gem for sites which use a mix (mainly older projects). Has anyone figured out a good way to embed an ember-cli app inside rails?
While I'm using ember-cli for thick clients I'm using the ember-rails gem for sites which use a mix (mainly older projects). Has anyone figured out a good way to embed an ember-cli app inside rails?
Yes, we do exactly this at Tilde and it works well. This sounds like a good blog post and possibly some released code that people can use.
Because the division of labor with Ember CLI is relatively clear, I expect build tool ecosystems to build integrations with Ember CLI, that shell out to the Ember CLI tools for specific tasks as part of a larger process. We'd of course love to work with anybody trying to do this :)
Because the division of labor with Ember CLI is relatively clear, I expect build tool ecosystems to build integrations with Ember CLI, that shell out to the Ember CLI tools for specific tasks as part of a larger process. We'd of course love to work with anybody trying to do this :)
Yes a blog post on that would be great! (Personally I'd love to see rails move to broccoli instead of the asset pipeline but I guess that won't be for a while if ever).
+1 I would love to see better rails integration with Ember CLI. It seems pointless to use ember-rails with the direction of ember relying on ES6 modules.
I'd love a blog post about this, I've struggled with it and given up in the past, but I'd love to migrate our ember-rails app over to cli!
another +1 - a blog post on this would be great, we are using Ember CLI with Rails too.
Author of ember-cli here (and previously the maintainer of ember-rails), this is essentially how my team uses ember-cli at work. Purely as a development harness and deployed to work nicely alongside a rails app.
One of my co-workers has a great related talk: https://speakerdeck.com/lukemelia/lightning-fast-deployment-...
And another related blog post: http://blog.abuiles.com/blog/2014/07/08/lightning-fast-deplo...
I suspect we will want to migrate the ember-rails story to be officially more aligned with the above approaches.
One of my co-workers has a great related talk: https://speakerdeck.com/lukemelia/lightning-fast-deployment-...
And another related blog post: http://blog.abuiles.com/blog/2014/07/08/lightning-fast-deplo...
I suspect we will want to migrate the ember-rails story to be officially more aligned with the above approaches.
I'm not familiar with Ember but just skimming this document highlighted something - they're going to have a dependency on Ember CLI, a commandline tool for with generators, dependency management, asset management, etc.
This dismays me a little. Another approach to this kind of thing, but looking at the docs it seems to be an npm+bower+custom magic. In some ways it reminds me of the clusterfuck that is Sencha Command, though at least this is open source.
Can anyone involved in the project shed any light on how this is implemented? It would be good if it was just a thin interface to some standard scripts.
edit: I know this comes across as a little negative, that wasn't really my intention. Sorry about that!
This dismays me a little. Another approach to this kind of thing, but looking at the docs it seems to be an npm+bower+custom magic. In some ways it reminds me of the clusterfuck that is Sencha Command, though at least this is open source.
Can anyone involved in the project shed any light on how this is implemented? It would be good if it was just a thin interface to some standard scripts.
edit: I know this comes across as a little negative, that wasn't really my intention. Sorry about that!
Hey Colin,
Not negative at all!
Ember CLI is a relatively small layer on top of a bunch of other open source modules. The core of the build system uses Broccoli[1], which is like a more powerful Gulp.
Dependencies are managed with bower and npm, and we use off-the-shelf npm modules to do the post-processing.
Basically, you should think of it as a curation of what we think are the best-of-breed tools for Ember developers, with a layer of developer ergonomics applied on top. At the same time, we don't do anything to hide the implementation from you. (Each new Ember app generated by Ember CLI includes the Brocfile.js right in the root directory.)
[1]: https://github.com/broccolijs/broccoli
Not negative at all!
Ember CLI is a relatively small layer on top of a bunch of other open source modules. The core of the build system uses Broccoli[1], which is like a more powerful Gulp.
Dependencies are managed with bower and npm, and we use off-the-shelf npm modules to do the post-processing.
Basically, you should think of it as a curation of what we think are the best-of-breed tools for Ember developers, with a layer of developer ergonomics applied on top. At the same time, we don't do anything to hide the implementation from you. (Each new Ember app generated by Ember CLI includes the Brocfile.js right in the root directory.)
[1]: https://github.com/broccolijs/broccoli
Cool, that's what I was hoping for then - just a bit of glue for some best-of-breed tools and not re-inventing the wheel!
ember-cli is such a vast usability improvement that you would be hard-pressed to find a single developer who's tried it and would prefer not to use it.
It's in-line with Ember's whole philosophy: anything that we can solve once together in a standard way, we should. Most of the time you are not a special snowflake and you can benefit from the same build stack as everybody else. If you need more, ember addons expose a standardized interface to sharing whatever feature you need.
It's in-line with Ember's whole philosophy: anything that we can solve once together in a standard way, we should. Most of the time you are not a special snowflake and you can benefit from the same build stack as everybody else. If you need more, ember addons expose a standardized interface to sharing whatever feature you need.
‘One-way data binding by default, with opt-in to mutable, two-way bindings’. It looks like React’s emphasis on unidirectional dataflow has made converts!
They specifically refer to React a number of times in the text, yes.
it has!
Hi Tom, I have been a long time supporter of Ember. I been using it since 2012 and I really like the way its going. However, most companies are looking for Angular.js developer these days. As a result, I am using Angular.js for work and Ember.js for my own projects. Hopefully the 2.0 release will bring new momentum to the framework. I am really looking forward to it!
Thanks! We know how important stability is, especially for companies that are not technical by nature. We hope this announcement demonstrates our commitment to stability without stagnation, and allows people to make the case to their boss that we'll be around for a long time.
I really appreciate all the work the Ember core team put into the framework. It is definitely an uphill battle competing with Angular.js and React.js which has the support of Google and Facebook. The problem is that Ember and Angular both have similar features and management would need a compelling reason to switch to Ember :(
Change your company, or "change your company"
I love the new attribute binding just working like you expect. It took me a fair while when I was first learning Ember to find the bind-attr helper, and things like using variables as part of URLs is a bit annoying currently.
[deleted]
Looking forward to all the great new features. Your commitment to the regular release cycle has made a huge difference to our team. We're backing ember all tge way.
Great to see that Ember core is not suffering from the Not Invented Here syndrome and is inspired by good things from React. Kudo's and love for Ember.
No mention of how htmlbars will affect famo.us integration?
In love w/ Ember. i kind of liked habdlebars tho..
The reason this is so long is that we’re doing the 2.0 release through our community RFC process[1]. Change can be scary when you’ve made serious investment in an open source tool, so we want to provide as much detail as we can while leaving open the opportunity to incorporate feedback.
I’d like to thank the members of the Ember core team, who paid out of pocket to spend this past weekend with me in Chicago for the face-to-face meeting where we banged out all of these details. Maintaining an indie open source project can be painful at times, but I think history demonstrates there’s no better way to foster a project that is as aligned with the goals of its users as possible.[2]
[1]: https://github.com/emberjs/rfcs
[2]: http://blog.endpoint.com/2010/01/state-of-postgres-project.h...