5 ms·
The Transition to Ember 2.0 in Detail
- k__ 11y agoWhat are the plans with Ember-CLI? I use my own build-chain with Gulp/LiveScript, but I found that some Plugin-Devs mentioned that supporting non-CLI-users was getting harder[0] Now I have the fear that Ember will become a huge Rails like code generator blob in the future :\ [0] http://ef4.github.io/liquid-fire/#/installation
- atonse 11y agoAny particular reason why you chose to roll your own workflow instead of using ember-cli? (in most use cases I read about, people already had this before ember-cli matured).
- k__ 11y agoIt seems like it prescribed too much. I want to use LiveScript, Emblem and Stylus with the build modules of my choosing. Also I don't need any of these code generators. Broccoli feels also like they are running their own stuff just because they can.
- girvo 11y agoThat's pretty much what ember is now. Which is not a bad thing per se, but can be frustrating and was one of the reasons we chose React/Flummox over Ember; plugging in non-Ember specific tools into the build system becomes more difficult vs having a pipeline you have control over!
- sshillo 11y agoIf Ember is going to borrow so heavily from React, why not just use React and Flux instead?
- adamnemecek 11y agoReact is a library, Ember is a framework.
- ubercore 11y agoI think maybe the parent comment is wondering "Why Glimmer and not React for the rendering library?"
- wycats 11y agoWe talk about this a bunch in https://www.youtube.com/watch?v=qwIyenCaSXk https://www.youtube.com/watch?v=qwIyenCaSXk The TLDR is: * We like templates, and were able to implement a more efficient algorithm using them (even more than the recent improvements in Babel). * Compatibility is important to us, so HTMLBars was going to be a much better transition story for Ember 1.x than JSX. * We prefer an HTML-centric templating story (copy/paste valid HTML and it works) over an XML strategy that requires camelCasing, className/htmlFor, etc. * We optimized Glimmer for a hybrid (rerender + subscriptions to the model or service layer) model that can opportunistically avoid work based on knowledge we have from the whole stack.
- seivan 11y agoThe Youtube video just says "Please stand by.".
- wycats 11y agoWhoops: https://youtu.be/msS-3zqKKUI?t=51m5s https://youtu.be/msS-3zqKKUI?t=51m5s
- mrcwinn 11y agoFair enough, but I would argue JSX is just as "HTML-centric" as anything Ember has implemented, so long as we agree "HTML-centric" means, practically speaking, "not HTML."
- ffn 11y agoLooks great, I can't wait for 2.0... In case anyone from the core team is looking through these comments, why did you guys change up Ember's initializer API? I mean even new addon projects freshly generated by ember-cli are now hit with a deprecation warning regarding initializers. Considering all the things affected by the initializer change, it makes it extremely challenging to ride canary when literally even canon boilerplate code by the tomster (to say nothing of the 1k addons out there) is deprecated.
- wycats 11y agoThe changes were the only change we needed to make in 1.x to be compatible with FastBoot. It sucks that new Ember CLI apps trigger the deprecation. We should get that fixed :)
- seivan 11y agoI hope it adds easier and better integration with Typescript, in fact I would love that for Ember 1 as well.
- tamebadger 11y agoDoubt anything will change in ember to accommodate any specific transpiler , or (transcompiler) if you would. Do have a look at https://code.visualstudio.com/ https://code.visualstudio.com/, ember is used in that first example, so using specific tools for better integration will be a better option at this stage.
- seivan 11y agoActually typescript already works fine in Atom, which this light weight Visual Studio is based on. I already got Atom-TypeScript working fine, but I am having issues with ember-cli-typescript not working, I was hoping for an official way of working with it.
- purephase 11y agoWhile I have yet to finish a project with Ember (I've been trying!), the amount of attention to backwards compatibility in this upcoming release is astounding. Great work by all those involved.
- steveax 11y agoYep, kudos to the backwards compatibility. Our original stack was Ember and ember-model and we have made the transition to ember-cli and have been tracking ember-cli and are slowly moving the legacy features to ember-data while implementing the new bits in ember-data. While it has not been entirely pain free, we haven't run into any show stoppers and I really like the way the ember ecosystem is shaping up. Big thanks to all the contributors for the attention to minimal breakage.
- Osiris 11y agoI'm confused by this example: export default Component.extend({ keyUp(event) { if (event.which === 13) { this.attrs['on-enter'](this.$().val()); } } }); This is invalid ES5. I assume this is new ES6 module syntax, specifically the `keyUp(event) {`?
- jjjjjosh 11y agoyeah, it's ES6 shorthand for `keyUp: function (event) {`; the new syntax is valid both in objects and class definitions.
- deleted 11y ago[deleted]
- girvo 11y agoHaving been rewriting a large system that was a disgusting jquery mishmash of terrible code in React/Flummox, all in ES6/ES7 classes and compiled down with Browserify, I'd never want to write JavaScript any other way. ES6 syntax like what you've pointed out is simply brilliant in everyday usage :)