9 ms·

Ember.js Octane Edition

187 points by wycats 7y ago

chancancode 7y ago
For those of you aren't particularly interested in Ember or frontend development in general, here is a tidbit that may be of interest to you. While revamping the tutorial[1] to showcase the new features and idioms, I worked on this tool[2] to automate the generation of the tutorial. Every page of the tutorial you see is the output from markdown source files (like this one[3]) which contains executable instructions for the steps. The build[4] system will run these commands and edits the same way an end-user would, capture the output of the commands and put them in the tutorial. It also takes the screenshots by opening a real browser (via puppeteer) and navigating to the actual app that we are building as part of the tutorial. All of these ensures that the tutorial content and screenshots are up-to-date with the latest blueprints (the files used by the generators), config files, etc, and that everything really works as-expected. It makes it much easier to maintain and QC the teaching materials, but also servers as a very useful end-to-end smoke test to ensure all the moving pieces in the ecosystem (including external components like npm, node, etc) are all working together. Right now the tool and the tutorial content are in the same GitHub repo, but the code is actually written to be completely agnostic to Ember.js (or JS even). It just runs shell commands, edit files etc. My intention is to separate out the tool to its standalone thing, so more communities can benefit from this approach. [1]: https://guides.emberjs.com/release/tutorial/ https://guides.emberjs.com/release/tutorial/ [2]: https://github.com/ember-learn/super-rentals-tutorial/ https://github.com/ember-learn/super-rentals-tutorial/ [3]: https://raw.githubusercontent.com/ember-learn/super-rentals-tutorial/master/src/markdown/tutorial/part-1/05-more-about-components.md https://raw.githubusercontent.com/ember-learn/super-rentals-... [4]: https://github.com/ember-learn/super-rentals-tutorial/commit/785115a55168b2871d76072a465b9acbfeb6e0c8/checks?check_suite_id=367677990 https://github.com/ember-learn/super-rentals-tutorial/commit...
- thebenedict 7y ago
  Love it. Keeping documentation screenshots and code snippets in sync with development has been a headache for me on past projects. This is clever!
gavinjoyce 7y ago
At Intercom, we've been incrementally upgrading our almost 6 year old Ember app to Octane as the features have landed over the past 8 months. Our app continues to be in great health and we continue to ship hundreds of times a day with a constant stream of features that our customers love [1] Octane is a huge leap forward for Ember. Its APIs are extremely well designed, composable and cohesive. The new Glimmer components and @tracked properties have resulted in waves of negative diffs as we refactor parts of our app to Octane and, IMO, are an advancement in the state-of-the-art component state tracking / reactive UI. If you've tried Ember before and were turned off by some of its slightly weird APIs (computed properties, component APIs like tagName, classNames & event handling, the ember object model), you should take a second look. With Octane, Ember is a framework for rapidly building high quality web applications that will remaining healthy over time as the web platform and JS ecosystem rapidly changes. [1]: https://www.intercom.com/changes/en https://www.intercom.com/changes/en
- social_quotient 7y ago
  Can you shed a little light on the sorts of things that are shipped hundreds of times a day? curious if you could share some use cases or examples. Intercom is pretty awesome - congrats!
  - gavinjoyce 7y ago
    Sorry, I meant to say we ship to production about a hundred times per day, not hundreds of times per day. We've shipped continuously since the very early days of Intercom. [1] We have a solid CI/CD pipeline meaning that every good merge to master hits production a small number of minutes later. Most of these changes are pretty small, focused and routine, adding a new button behind a feature flag, a db migration, a bug fix. These small changes add up over time to a steady stream of highly polished features and improvements. [1] https://www.intercom.com/blog/shipping-is-your-companys-heartbeat/ https://www.intercom.com/blog/shipping-is-your-companys-hear...
  - itwy 7y ago
    Definitely a gross exaggeration.
nullvoxpopuli 7y ago
Yaaaaas. Octane looks so much nicer. This is the lift codebases that have been using Ember for 6+ years will greatly appreciate. And! It'll be great to show off ember at local meetups with the nice new syntax!
anm89 7y ago
It is such a tragedy that ember did not gain more traction. It's incredibly elegant, powerful and ergonomic. Once you got into the groove, writing ember code was so intuitive. Glad to see they are pushing through
- gavinjoyce 7y ago
  I think this is fresh opportunity for Ember to become mainstream again, modern Ember is so clean and productive
  - deleted 7y ago
    [deleted]
  - artsyca 7y ago
    So many frameworks have borrowed from Ember more than Ember itself becoming mainstream I'd like to see the idiomatic approach become widespread whatever the idiom
- artsyca 7y ago
  It's no tragedy Ember is a niche product and the community is unique and hasn't gone the way of angular or react with all the false corporate stereotypes
  - karmelapple 7y ago
    Outside of the solid technical foundation and pedigree, the organization of how Ember is managed is one of its best aspects. There is no single massive company that may decide to drive development in a major breaking way. Ember has always focused on ensuring upgrades are fairly easy to do, and has only gotten better over time.
    - deleted 7y ago
      [deleted]
    - artsyca 7y ago
p45please 7y ago
I like Ember.js, been using it since version 1.12, through to 2.x and now 3.x. Had been playing with the beta builds of Octane on the side, glad to see it all coming over to the main build!
liketostayanon 7y ago
Like the decorator syntax for tracking observables. Is the under the hood implementation an inspiration from mobx? Basically, the use of Proxy.
- pzuraq 7y ago
  We definitely looked at MobX and Vue as we were designing the final user facing API! The implementation under the hood is pretty significantly different, ours is not based on pub/sub or observables/streams, it’s based on a pull-based mechanism which we’ve found to be much more efficient at propagating changes in UI driven apps. But the end result is definitely similar, and we learned a lot from their implementations
dstaley 7y ago
One of the things I really wish Ember would focus on is reducing the amount of JavaScript shipped to the browser. I just tried out the included project with ember-cli, and the default JavaScript bundle is 2.7 MB (591 KB gzipped)[1] for an app that doesn't have any functionality. I know that you get a lot with that 591 KB (Ember's router, the Glimmer VM, etc.), but it's still much more than what you can get your React app down too, especially on initial load. For comparison, my _entire_ React application (which includes emotion, react-router, and a full data synchronization library) is only 356 KB (104 KB gzipped). Don't get me wrong: there's certainly applications where the size of the JavaScript doesn't matter, and I think Ember is _great_ for those use-cases. I just wish it could be used for smaller, mobile-focused applications without being several times larger than an equivalent React app. [1] Apparently this is the development size. The production size is 712.29 KB (180.80 KB gzipped). My point still stands though.
- gavinjoyce 7y ago
  Perhaps you're measuring a development build? I just tried a new ember 3.15 app production build, the JS payload comes in at 712.29 KB (180.80 KB gzipped) `ember new myapp && cd myapp && ember build --environment='production' && ls -la dist/assets`
  - dstaley 7y ago
    Ah yes, I didn't realize "ember build" produced a development build. For comparison, create-react-app always builds in production mode to eliminate this exact scenario!
    - wycats 7y ago
      I think that's probably a good change to the default. Today, `ember build` is analogous to `ember s`, and most people deploy to production with `ember-cli-deploy`. But that's not a good enough reason :) Thanks for surfacing this!
- pzuraq 7y ago
  This is actually going to be my next project, now that we’ve shipped Octane there’s a lot of code that we can slowly start to move away from! The plan is to move toward optional features and then deprecations for many of the classic features, allowing Octane users to opt-in to the benefits progressively, while still supporting Classic users for some time as they transition. Definitely curious how you got these numbers though. Our current estimate of Ember’s size is ~160kb after min/gzip, and Ember Data (the only other large library installed by default) should be less than that. Jquery should not be included by default anymore, which would be a large chunk. Were you building a production build? `ember build —env=production`? That will cut out a significant chunk of debug code and assertions that are only used for development builds as well.
jchw 7y ago
With a cursory glance, a lot of these changes make Ember look more familiar for React users, w.r.t. not treating root specially (versus Angular for example) and with moving away from mixins for more functional composition. All in all I think this is great and would like to take a look at Ember and see what it has to offer nowadays.
- wycats 7y ago
  You got that right. We got a lot of inspiration from the React ecosystem, both in terms of component design (the root element is just another element) and composition. Those changes played out differently in the context of Ember, because of the way our APIs work, but the core ideas are sound, and I'm happy that the React community paved the way.
- k__ 7y ago
  Yes, basically all frameworks became React-like after the success of React. In my opinion, the only one that got a really interesting take on components was Cycle.js, the rest simply tried to bend their APIs to look more Reactish.
  - nullvoxpopuli 7y ago
    good ideas are good ideas. The world only gets better when we let ourselves be inspired by others' success
  - preommr 7y ago
    More like everything is seen from the viewpoint of react. I've seen people lump in frameworks like angular and vue with react while comparing them in a way that don't make sense for the first two.
  - DigitalSea 7y ago
    Aurelia is a framework that didn't rewrite their API's to try and become Reactish either. They have been over in their own lane, while Vue seemingly becomes React Lite.
  - jchw 7y ago
isodev 7y ago
Coming from other frameworks the Octane approach definitely seems more familiar. I am looking forward to my first Ember app :).
- nullvoxpopuli 7y ago
  if you have any questions, feel free to join the ember discord: https://discord.gg/emberjs https://discord.gg/emberjs <3
sergiotapia 7y ago
Superficially, Glimmer reactivity looks very much like Mobx in a very good way. Any significant differences?
- lf-non 7y ago
  After trying out almost most of the major libraries in the frontend ecosystem I feel that MobX-style observables (in combination with a state-tree abstraction like MST) simply offer the best combination of developer experience and performance. It is not hard to write readable code with hooks (and hook based state management solutions), but it takes a lot more ramp up time and I see junior members in our team struggle with the nuances around closures (what value was captured when in the component lifecycle) frequently. Adopting MobX has been a huge productivity boost for our team. At the same time, I feel the full potential of MobX is not fully realized in react ecosystem because the React core team does not recommend Object oriented state management with observables - the ecosystem would be so much better if popular components accepted observable data-structures and were built with implicit change tracking in mind (rather than the usual combination of controlled+uncontrolled props and callbacks which ends up being verbose and repetitive). I hope octane results in Ember gaining traction in the community. It would be nice to have a framework that embraces reactive observable models, without also resorting to weird monkey patching (angular zones).
- pzuraq 7y ago
  The underlying implementation is the largest difference. Where MobX relies on pub/sub and observables to propagate dirty state, Glimmer’s autotracking uses a lazy system that incurs minimal cost until render occurs. We’ve found the overall performance of this system to be much better, and the primitive easier to optimize.
  - wycats 7y ago
    And on top of that, the fact that we use a simple reactivity primitive under the hood[1][2] means that we have been able to transition from an API designed for 2012-era two-way bindings to a unidirectional data-flow model with minimal disruption, and with free interoperability between code written with the two APIs (even in the same object). This also means that we can design new functionality (like Octane's modifiers, and other upcoming reactive APIs) without worrying about how the parts of the system will work together. [1]: https://github.com/glimmerjs/glimmer-vm/blob/master/guides/04-references.md https://github.com/glimmerjs/glimmer-vm/blob/master/guides/0... [2]: https://github.com/glimmerjs/glimmer-vm/blob/master/guides/05-validators.md https://github.com/glimmerjs/glimmer-vm/blob/master/guides/0...
sudders 7y ago
We have been using Ember for the last 5 years, and have been continuously shipping new features and updates on a daily basis. Our different applications have been following every upgrade path, and because of that we have not required a rewrite of our codebase. Ember has been a great choice for our business, and has given us the opportunity to punch well above our weight class. Ember is a wonderful front-end framework and deserves a lot more credit than it is currently getting. Great job Ember Team, keep it up, the community loves you!
rubyn00bie 7y ago
Wow. I really didn't realize it was so close! I've just today finished up what took me away from my Ember project. Ember has been freakin' amazing to use, and Octane really, really, makes it shine. I love ember because it includes everything you need to manage state in your application, install and you're ready to go. I don't have to pick my view renderer, state/history management, storage system, networking stack etc... I also don't have to maintain the dependencies between them, like I would with something built using React. Ember also favors convention over configuration; which, I find to be a godsend when visiting the world of JavaScript. Yeah, it's a bit painful sometimes not knowing the convention, but that's just good ol' fashion learning. I also think the opposite, configuration, is incredibly painful in JavaScript, because the ecosystem moves so fast. The Ember team (and community) also have fixed, and continue to fix, a ton of issues from making module loading easier to better support of Typescript. I'd like to give a few getting started tips for anyone about to jump in (as I did the same a few months ago): * Glimmer templates give you nice HTML-esque looking components while separating the HTML from the JavaScript itself (which I like versus embedding it like JSX does) * Use the decorators. Seriously, they're awesome, they're a MUST if you use typescript. * Ember modifiers are really a big improvement over the previous hooks/lifecycle management. It's just the constructor and willDestory (I think), it also to me, makes it a lot easy to commit to ol' "data down, actions up" philosophy. * Ember Concurrency [1] is a brilliant tool and can pretty much prevent any UI blocking you ever find yourself doing. * Some things are automagically created for you unless you explicitly create them (with the right names) like the application controller and application router. Use the Ember debugger browser plugin to see what controllers and routes are being rendered if you're at all unsure. * Ember CSS modules [2] helped me quite a lot encapsulating css (and wiring it up correctly for that matter). * Use Mirage [3] to mock out your data from the beginning, don't hard code things you intend to query for later. You'll have trouble, plus Mirage is super easy to use. * Make sure guides you're reading are relevant to the current version. Octane has been coming for a while so there's a fair bit of information, it's just something to be aware of (especially from results in google). * If you're reading an older article that's relevant, but using older syntax try reading this: https://blog.emberjs.com/2019/01/26/emberjs-native-class-update-2019-edition.html https://blog.emberjs.com/2019/01/26/emberjs-native-class-upd... This series of articles is also immensely helpful: https://www.pzuraq.com/coming-soon-in-ember-octane-part-1-native-classes/ https://www.pzuraq.com/coming-soon-in-ember-octane-part-1-na... Finally, I've found the Ember community to be incredibly nice and welcoming. Their Discord [4] is very active and full of helpful folks. Huge props and thanks to everyone who worked on this, it's super exciting and I'm gonna go hack on my Ember project now. ---- [1] https://ember-concurrency.com/ https://ember-concurrency.com/ [2] https://github.com/salsify/ember-css-modules https://github.com/salsify/ember-css-modules [3] https://www.ember-cli-mirage.com/ https://www.ember-cli-mirage.com/ [4] https://discord.gg/emberjs https://discord.gg/emberjs Edit: Formatting.
Hlektana 7y ago
Classes, inheritance, getters/setters. Uggh, just cannot do it.
miguelmota 7y ago
Ember does a ton of magic under the hood that when something goes wrong it's the hardest thing to debug. Ember is also strongly opinionated which some people like I guess. Ever since I've switched to React + Redux I've never looked back.
- pzuraq 7y ago
  A big part of Octane is reducing the amount of "magic" under the hood for a lot of features. For instance, autotracking and tracked properties now allow you to use plain JS for most computed values, which means that every stack trace that you have while debugging a getter will be a standard stack trace, without confusing computed property code in between! I definitely encourage you to check it out sometime, a lot has changed!
dmzza 7y ago
I've been building new product from scratch with Ember Octane and TypeScript since March 2019, and it's been a great experience. I will be able to launch the app I spent 10 months building without any substantial refactoring. I would say the Octane API has essentially been stable for almost a year, if not longer. I even had a preview of the rewritten documentation to learn from the entire time. Ember has really come a long way from the early days. The last time I built an Ember app was before 1.0 was released. Building with Octane before it was released has been spectacular.
atonse 7y ago
I've been using Ember in some capacity for 6+ years now I think. And have been using ember on about 5-8 different production-shipped projects (with Elixir backends) and it's been a great combination for our company from a tech standpoint. The bigger issue has been finding contracting talent that's more affordable. Since there's a real dearth of talent in general (and freelance contractors) in the Ember world since the community is already so small, the few that are there are too expensive for us to hire for more than a couple week bursts. I hope Octane helps bring more people to the Ember ecosystem and introduces more variance into the contractor rates, since I want to keep using Ember for future projects.
pier25 7y ago
The ergonomics look nice but Ember still needs to make a lot of progress in bundle size and performance. Glimmer is certainly much faster than previous Ember versions but it's barely competitive by today's standards. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht... Also, in that link check how Glimmer fares in start-up metrics (very bad). And it's not even the complete Ember framework.
- HatchedLake721 7y ago
  Why spread fud? Glimmer beats react on re-rendering thanks to bytecode and virtual machine architecture https://engineering.linkedin.com/blog/2017/06/glimmer--blazing-fast-rendering-for-ember-js--part-2 https://engineering.linkedin.com/blog/2017/06/glimmer--blazi...
  - pier25 7y ago
    Those are tests from 2017. The link I posted uses more current versions.
    - mixonic 7y ago
      The results there are using Ember 3.11, not Octane, so I'd also say those results are out of date :-p I will try to get the benchmarked Ember codebase updated over the winter holidays. I've always love looking at these microbenchmarks. At large app scale Ember apps perform very well, and I would happily pit the performance of a full-complexity Ember app against any other framework. At the end of the day the goal of the Ember project is not to be the fastest, especially at microbenchmarks, but to have competitive performance with an API that any level of developer can be successful with. To have a fast Ember app there aren't any special tricks or APIs to learn, it is simply fast out of the box with performance that scales. Thanks for the reminder about this benchmarking project!
      - pier25 7y ago
        I was referring to the glimmer results, not the ember ones.
snewcomer24 7y ago
Gotta love this. Great job everyone! Looking forward to what we build!
DigitalSea 7y ago
I kind of hoped that Ember would ditch Handlebars for templating and move towards something a bit nicer. I find Handlebars syntax to be quite annoying and tedious to write. Kudos to the Ember team for persisting with the framework, I know LinkedIn is using it (and learned in this thread that Intercom is as well). If this latest Ember release excites people, I highly recommend that people check out what the Aurelia team have been working on with Aurelia 2 https://aurelia.io/blog/2019/10/31/aurelia-vnext-2019-fall-update https://aurelia.io/blog/2019/10/31/aurelia-vnext-2019-fall-u.... I have always seen Aurelia being similar to Ember, except the syntax is cleaner (especially templating) and is conventions based. There are a lot of similarities between the two. One thing that Aurelia are doing in Aurelia 2 is an option to shake it down to a tiny app. The problem with frameworks like Angular, Ember and Aurelia 1 is they ship a lot of code to the browser and startup time can be quite slow. In Aurelia 2 they're working on quite a nice and promising AOT compiler. I really wish the Ember team would focus on bundle size, what I have seen with Octane, the bundles are huge. My money is on Aurelia 2 when it launches in 2020, so it is nice to see Ember firing back as well, great timing given the recent State of JS survey yielded people are really frustrated with Angular.
- nullvoxpopuli 7y ago
  CrowdStrike also uses ember and loves it. Handlebars isn't really what ember uses. And it's unfortunate that the extension is shared. there are tons of improved semantics with Octane's Ember Templates that the handlebars you're thinking of could never dream of representing -- mainly @args vs attributes (like html attributes can be forwarded via ...attributes) <MyComponent class='foo' // any html attribute @arg={{this.value}} // @ = arg // this = owned by the current context /> (and inside that) <div ...attributes> // gets the class attribute {{@arg}} // you *know* that @ means it was passed in </div> is there anything in particular you don't like?
wildchild 7y ago
Hopefully Ember Data will be purged one day as something that will never fulfil any more or less reasonable application except TodoLists. It sucks off a lot of resources which otherwise would be assigned to different weak places of this project.
someonedamaged 7y ago
This is an awesome update, really like the new component APIs and the ergonomics for manipulating the DOM! I mostly worked with React and Vue, since Ember had quite a learning curve in the past and wasn't really an option for me. But this new edition seems to be much more straightforward to start working with. Looking forward to build my first Ember app over the holidays :-)
vdrizzle 7y ago
At coschedule.com we’ve been using EmberJS since 2013. We look at EmberJS as one of the strengths of the development team. It has been rock solid, stable, and progressive. We began our transition to Octane about 3 months ago, and while still very much a work in progress but it has been a delight. We just finished refactoring the oldest section of our app, and on average we’ve seen a 50% render performance increase, this in part to the leaner glimmer components. The future is bright EmberJS is fun and easy to develop on. The learning curve has been drastically reduced and new devs should not have a hard time getting up and going. The guides have been completely redesigned and the super rentals tutorials is an excellent tool to get started.
nivenhuh 7y ago
On using Ember I’ve been using ember since 0.9.5.1, so for 8 years or so? (I have 6 biggish apps that are still under active development today) At the time — there was no router, Ember.View was a thing, there were multiple types of views and controllers, JSON:API wasn’t a thing, ember-data was wild, etc. Most of the contributions depended on tomhudakatzdale, as well as a number of other core contributors (dgeb, tchak, and others I’m leaving off — sorry!). The framework frequently had breaking changes, patterns were moving around rapidly (we had to rewrite one of our pre 1.13 apps), it was a bit of a mess. (Then again, at the time, a lot of other frameworks were in the same state.). I think these times gave Ember a bit of a bad rap. The thing that stood out to me then, and still holds true today, is that the community has been committed to bringing in the best ideas forward in a community-driven way. Even though much of the initial framework had growing pains, it was able to do a few significant things: establish a community model for managing changes (RFC/RFP process), delegate core responsibilities to a broader team of people (not based on corporate interests), create consistent release intervals, follow semantic versioning, establish json:api as a specification, and really take community feedback in as development priority / direction. Octane is the cultivated result of years of decision making by the community. (And, I believe, that’s why folks say “Ember is great tech”). I continue to use and recommend Ember to others. Happy to answer any questions for folks!

187 points by wycats 7y ago

For those of you aren't particularly interested in Ember or frontend development in general, here is a tidbit that may be of interest to you. While revamping the tutorial[1] to showcase the new features and idioms, I worked on this tool[2] to automate the generation of the tutorial. Every page of the tutorial you see is the output from markdown source files (like this one[3]) which contains executable instructions for the steps. The build[4] system will run these commands and edits the same way an end-user would, capture the output of the commands and put them in the tutorial. It also takes the screenshots by opening a real browser (via puppeteer) and navigating to the actual app that we are building as part of the tutorial. All of these ensures that the tutorial content and screenshots are up-to-date with the latest blueprints (the files used by the generators), config files, etc, and that everything really works as-expected. It makes it much easier to maintain and QC the teaching materials, but also servers as a very useful end-to-end smoke test to ensure all the moving pieces in the ecosystem (including external components like npm, node, etc) are all working together. Right now the tool and the tutorial content are in the same GitHub repo, but the code is actually written to be completely agnostic to Ember.js (or JS even). It just runs shell commands, edit files etc. My intention is to separate out the tool to its standalone thing, so more communities can benefit from this approach. [1]: https://guides.emberjs.com/release/tutorial/ https://guides.emberjs.com/release/tutorial/ [2]: https://github.com/ember-learn/super-rentals-tutorial/ https://github.com/ember-learn/super-rentals-tutorial/ [3]: https://raw.githubusercontent.com/ember-learn/super-rentals-tutorial/master/src/markdown/tutorial/part-1/05-more-about-components.md https://raw.githubusercontent.com/ember-learn/super-rentals-... [4]: https://github.com/ember-learn/super-rentals-tutorial/commit/785115a55168b2871d76072a465b9acbfeb6e0c8/checks?check_suite_id=367677990 https://github.com/ember-learn/super-rentals-tutorial/commit...

thebenedict 7y ago
Love it. Keeping documentation screenshots and code snippets in sync with development has been a headache for me on past projects. This is clever!

gavinjoyce 7y ago

At Intercom, we've been incrementally upgrading our almost 6 year old Ember app to Octane as the features have landed over the past 8 months. Our app continues to be in great health and we continue to ship hundreds of times a day with a constant stream of features that our customers love [1] Octane is a huge leap forward for Ember. Its APIs are extremely well designed, composable and cohesive. The new Glimmer components and @tracked properties have resulted in waves of negative diffs as we refactor parts of our app to Octane and, IMO, are an advancement in the state-of-the-art component state tracking / reactive UI. If you've tried Ember before and were turned off by some of its slightly weird APIs (computed properties, component APIs like tagName, classNames & event handling, the ember object model), you should take a second look. With Octane, Ember is a framework for rapidly building high quality web applications that will remaining healthy over time as the web platform and JS ecosystem rapidly changes. [1]: https://www.intercom.com/changes/en https://www.intercom.com/changes/en

social_quotient 7y ago
Can you shed a little light on the sorts of things that are shipped hundreds of times a day? curious if you could share some use cases or examples. Intercom is pretty awesome - congrats!
- gavinjoyce 7y ago
  Sorry, I meant to say we ship to production about a hundred times per day, not hundreds of times per day. We've shipped continuously since the very early days of Intercom. [1] We have a solid CI/CD pipeline meaning that every good merge to master hits production a small number of minutes later. Most of these changes are pretty small, focused and routine, adding a new button behind a feature flag, a db migration, a bug fix. These small changes add up over time to a steady stream of highly polished features and improvements. [1] https://www.intercom.com/blog/shipping-is-your-companys-heartbeat/ https://www.intercom.com/blog/shipping-is-your-companys-hear...
- itwy 7y ago
  Definitely a gross exaggeration.

nullvoxpopuli 7y ago

Yaaaaas. Octane looks so much nicer. This is the lift codebases that have been using Ember for 6+ years will greatly appreciate. And! It'll be great to show off ember at local meetups with the nice new syntax!

anm89 7y ago

It is such a tragedy that ember did not gain more traction. It's incredibly elegant, powerful and ergonomic. Once you got into the groove, writing ember code was so intuitive. Glad to see they are pushing through

gavinjoyce 7y ago
I think this is fresh opportunity for Ember to become mainstream again, modern Ember is so clean and productive
- deleted 7y ago
  [deleted]
- artsyca 7y ago
  So many frameworks have borrowed from Ember more than Ember itself becoming mainstream I'd like to see the idiomatic approach become widespread whatever the idiom
artsyca 7y ago
It's no tragedy Ember is a niche product and the community is unique and hasn't gone the way of angular or react with all the false corporate stereotypes
- karmelapple 7y ago
  Outside of the solid technical foundation and pedigree, the organization of how Ember is managed is one of its best aspects. There is no single massive company that may decide to drive development in a major breaking way. Ember has always focused on ensuring upgrades are fairly easy to do, and has only gotten better over time.
  - deleted 7y ago
    [deleted]
  - artsyca 7y ago

p45please 7y ago

I like Ember.js, been using it since version 1.12, through to 2.x and now 3.x. Had been playing with the beta builds of Octane on the side, glad to see it all coming over to the main build!

liketostayanon 7y ago

Like the decorator syntax for tracking observables. Is the under the hood implementation an inspiration from mobx? Basically, the use of Proxy.

pzuraq 7y ago
We definitely looked at MobX and Vue as we were designing the final user facing API! The implementation under the hood is pretty significantly different, ours is not based on pub/sub or observables/streams, it’s based on a pull-based mechanism which we’ve found to be much more efficient at propagating changes in UI driven apps. But the end result is definitely similar, and we learned a lot from their implementations

dstaley 7y ago

One of the things I really wish Ember would focus on is reducing the amount of JavaScript shipped to the browser. I just tried out the included project with ember-cli, and the default JavaScript bundle is 2.7 MB (591 KB gzipped)[1] for an app that doesn't have any functionality. I know that you get a lot with that 591 KB (Ember's router, the Glimmer VM, etc.), but it's still much more than what you can get your React app down too, especially on initial load. For comparison, my _entire_ React application (which includes emotion, react-router, and a full data synchronization library) is only 356 KB (104 KB gzipped). Don't get me wrong: there's certainly applications where the size of the JavaScript doesn't matter, and I think Ember is _great_ for those use-cases. I just wish it could be used for smaller, mobile-focused applications without being several times larger than an equivalent React app. [1] Apparently this is the development size. The production size is 712.29 KB (180.80 KB gzipped). My point still stands though.

gavinjoyce 7y ago
Perhaps you're measuring a development build? I just tried a new ember 3.15 app production build, the JS payload comes in at 712.29 KB (180.80 KB gzipped) `ember new myapp && cd myapp && ember build --environment='production' && ls -la dist/assets`
- dstaley 7y ago
  Ah yes, I didn't realize "ember build" produced a development build. For comparison, create-react-app always builds in production mode to eliminate this exact scenario!
  - wycats 7y ago
    I think that's probably a good change to the default. Today, `ember build` is analogous to `ember s`, and most people deploy to production with `ember-cli-deploy`. But that's not a good enough reason :) Thanks for surfacing this!
pzuraq 7y ago
This is actually going to be my next project, now that we’ve shipped Octane there’s a lot of code that we can slowly start to move away from! The plan is to move toward optional features and then deprecations for many of the classic features, allowing Octane users to opt-in to the benefits progressively, while still supporting Classic users for some time as they transition. Definitely curious how you got these numbers though. Our current estimate of Ember’s size is ~160kb after min/gzip, and Ember Data (the only other large library installed by default) should be less than that. Jquery should not be included by default anymore, which would be a large chunk. Were you building a production build? `ember build —env=production`? That will cut out a significant chunk of debug code and assertions that are only used for development builds as well.

jchw 7y ago

With a cursory glance, a lot of these changes make Ember look more familiar for React users, w.r.t. not treating root specially (versus Angular for example) and with moving away from mixins for more functional composition. All in all I think this is great and would like to take a look at Ember and see what it has to offer nowadays.

wycats 7y ago
You got that right. We got a lot of inspiration from the React ecosystem, both in terms of component design (the root element is just another element) and composition. Those changes played out differently in the context of Ember, because of the way our APIs work, but the core ideas are sound, and I'm happy that the React community paved the way.
k__ 7y ago
Yes, basically all frameworks became React-like after the success of React. In my opinion, the only one that got a really interesting take on components was Cycle.js, the rest simply tried to bend their APIs to look more Reactish.
- nullvoxpopuli 7y ago
  good ideas are good ideas. The world only gets better when we let ourselves be inspired by others' success
- preommr 7y ago
  More like everything is seen from the viewpoint of react. I've seen people lump in frameworks like angular and vue with react while comparing them in a way that don't make sense for the first two.
- DigitalSea 7y ago
  Aurelia is a framework that didn't rewrite their API's to try and become Reactish either. They have been over in their own lane, while Vue seemingly becomes React Lite.
- jchw 7y ago

isodev 7y ago

Coming from other frameworks the Octane approach definitely seems more familiar. I am looking forward to my first Ember app :).

nullvoxpopuli 7y ago
if you have any questions, feel free to join the ember discord: https://discord.gg/emberjs https://discord.gg/emberjs <3

sergiotapia 7y ago

Superficially, Glimmer reactivity looks very much like Mobx in a very good way. Any significant differences?

lf-non 7y ago
After trying out almost most of the major libraries in the frontend ecosystem I feel that MobX-style observables (in combination with a state-tree abstraction like MST) simply offer the best combination of developer experience and performance. It is not hard to write readable code with hooks (and hook based state management solutions), but it takes a lot more ramp up time and I see junior members in our team struggle with the nuances around closures (what value was captured when in the component lifecycle) frequently. Adopting MobX has been a huge productivity boost for our team. At the same time, I feel the full potential of MobX is not fully realized in react ecosystem because the React core team does not recommend Object oriented state management with observables - the ecosystem would be so much better if popular components accepted observable data-structures and were built with implicit change tracking in mind (rather than the usual combination of controlled+uncontrolled props and callbacks which ends up being verbose and repetitive). I hope octane results in Ember gaining traction in the community. It would be nice to have a framework that embraces reactive observable models, without also resorting to weird monkey patching (angular zones).
pzuraq 7y ago
The underlying implementation is the largest difference. Where MobX relies on pub/sub and observables to propagate dirty state, Glimmer’s autotracking uses a lazy system that incurs minimal cost until render occurs. We’ve found the overall performance of this system to be much better, and the primitive easier to optimize.
- wycats 7y ago
  And on top of that, the fact that we use a simple reactivity primitive under the hood[1][2] means that we have been able to transition from an API designed for 2012-era two-way bindings to a unidirectional data-flow model with minimal disruption, and with free interoperability between code written with the two APIs (even in the same object). This also means that we can design new functionality (like Octane's modifiers, and other upcoming reactive APIs) without worrying about how the parts of the system will work together. [1]: https://github.com/glimmerjs/glimmer-vm/blob/master/guides/04-references.md https://github.com/glimmerjs/glimmer-vm/blob/master/guides/0... [2]: https://github.com/glimmerjs/glimmer-vm/blob/master/guides/05-validators.md https://github.com/glimmerjs/glimmer-vm/blob/master/guides/0...

sudders 7y ago

We have been using Ember for the last 5 years, and have been continuously shipping new features and updates on a daily basis. Our different applications have been following every upgrade path, and because of that we have not required a rewrite of our codebase. Ember has been a great choice for our business, and has given us the opportunity to punch well above our weight class. Ember is a wonderful front-end framework and deserves a lot more credit than it is currently getting. Great job Ember Team, keep it up, the community loves you!

rubyn00bie 7y ago

Wow. I really didn't realize it was so close! I've just today finished up what took me away from my Ember project. Ember has been freakin' amazing to use, and Octane really, really, makes it shine. I love ember because it includes everything you need to manage state in your application, install and you're ready to go. I don't have to pick my view renderer, state/history management, storage system, networking stack etc... I also don't have to maintain the dependencies between them, like I would with something built using React. Ember also favors convention over configuration; which, I find to be a godsend when visiting the world of JavaScript. Yeah, it's a bit painful sometimes not knowing the convention, but that's just good ol' fashion learning. I also think the opposite, configuration, is incredibly painful in JavaScript, because the ecosystem moves so fast. The Ember team (and community) also have fixed, and continue to fix, a ton of issues from making module loading easier to better support of Typescript. I'd like to give a few getting started tips for anyone about to jump in (as I did the same a few months ago): * Glimmer templates give you nice HTML-esque looking components while separating the HTML from the JavaScript itself (which I like versus embedding it like JSX does) * Use the decorators. Seriously, they're awesome, they're a MUST if you use typescript. * Ember modifiers are really a big improvement over the previous hooks/lifecycle management. It's just the constructor and willDestory (I think), it also to me, makes it a lot easy to commit to ol' "data down, actions up" philosophy. * Ember Concurrency [1] is a brilliant tool and can pretty much prevent any UI blocking you ever find yourself doing. * Some things are automagically created for you unless you explicitly create them (with the right names) like the application controller and application router. Use the Ember debugger browser plugin to see what controllers and routes are being rendered if you're at all unsure. * Ember CSS modules [2] helped me quite a lot encapsulating css (and wiring it up correctly for that matter). * Use Mirage [3] to mock out your data from the beginning, don't hard code things you intend to query for later. You'll have trouble, plus Mirage is super easy to use. * Make sure guides you're reading are relevant to the current version. Octane has been coming for a while so there's a fair bit of information, it's just something to be aware of (especially from results in google). * If you're reading an older article that's relevant, but using older syntax try reading this: https://blog.emberjs.com/2019/01/26/emberjs-native-class-update-2019-edition.html https://blog.emberjs.com/2019/01/26/emberjs-native-class-upd... This series of articles is also immensely helpful: https://www.pzuraq.com/coming-soon-in-ember-octane-part-1-native-classes/ https://www.pzuraq.com/coming-soon-in-ember-octane-part-1-na... Finally, I've found the Ember community to be incredibly nice and welcoming. Their Discord [4] is very active and full of helpful folks. Huge props and thanks to everyone who worked on this, it's super exciting and I'm gonna go hack on my Ember project now. ---- [1] https://ember-concurrency.com/ https://ember-concurrency.com/ [2] https://github.com/salsify/ember-css-modules https://github.com/salsify/ember-css-modules [3] https://www.ember-cli-mirage.com/ https://www.ember-cli-mirage.com/ [4] https://discord.gg/emberjs https://discord.gg/emberjs Edit: Formatting.

Hlektana 7y ago

Classes, inheritance, getters/setters. Uggh, just cannot do it.

miguelmota 7y ago

Ember does a ton of magic under the hood that when something goes wrong it's the hardest thing to debug. Ember is also strongly opinionated which some people like I guess. Ever since I've switched to React + Redux I've never looked back.

pzuraq 7y ago
A big part of Octane is reducing the amount of "magic" under the hood for a lot of features. For instance, autotracking and tracked properties now allow you to use plain JS for most computed values, which means that every stack trace that you have while debugging a getter will be a standard stack trace, without confusing computed property code in between! I definitely encourage you to check it out sometime, a lot has changed!

dmzza 7y ago

I've been building new product from scratch with Ember Octane and TypeScript since March 2019, and it's been a great experience. I will be able to launch the app I spent 10 months building without any substantial refactoring. I would say the Octane API has essentially been stable for almost a year, if not longer. I even had a preview of the rewritten documentation to learn from the entire time. Ember has really come a long way from the early days. The last time I built an Ember app was before 1.0 was released. Building with Octane before it was released has been spectacular.

atonse 7y ago

I've been using Ember in some capacity for 6+ years now I think. And have been using ember on about 5-8 different production-shipped projects (with Elixir backends) and it's been a great combination for our company from a tech standpoint. The bigger issue has been finding contracting talent that's more affordable. Since there's a real dearth of talent in general (and freelance contractors) in the Ember world since the community is already so small, the few that are there are too expensive for us to hire for more than a couple week bursts. I hope Octane helps bring more people to the Ember ecosystem and introduces more variance into the contractor rates, since I want to keep using Ember for future projects.

pier25 7y ago

The ergonomics look nice but Ember still needs to make a lot of progress in bundle size and performance. Glimmer is certainly much faster than previous Ember versions but it's barely competitive by today's standards. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht... Also, in that link check how Glimmer fares in start-up metrics (very bad). And it's not even the complete Ember framework.

HatchedLake721 7y ago
Why spread fud? Glimmer beats react on re-rendering thanks to bytecode and virtual machine architecture https://engineering.linkedin.com/blog/2017/06/glimmer--blazing-fast-rendering-for-ember-js--part-2 https://engineering.linkedin.com/blog/2017/06/glimmer--blazi...
- pier25 7y ago
  Those are tests from 2017. The link I posted uses more current versions.
  - mixonic 7y ago
    The results there are using Ember 3.11, not Octane, so I'd also say those results are out of date :-p I will try to get the benchmarked Ember codebase updated over the winter holidays. I've always love looking at these microbenchmarks. At large app scale Ember apps perform very well, and I would happily pit the performance of a full-complexity Ember app against any other framework. At the end of the day the goal of the Ember project is not to be the fastest, especially at microbenchmarks, but to have competitive performance with an API that any level of developer can be successful with. To have a fast Ember app there aren't any special tricks or APIs to learn, it is simply fast out of the box with performance that scales. Thanks for the reminder about this benchmarking project!
    - pier25 7y ago
      I was referring to the glimmer results, not the ember ones.

snewcomer24 7y ago

Gotta love this. Great job everyone! Looking forward to what we build!

DigitalSea 7y ago

I kind of hoped that Ember would ditch Handlebars for templating and move towards something a bit nicer. I find Handlebars syntax to be quite annoying and tedious to write. Kudos to the Ember team for persisting with the framework, I know LinkedIn is using it (and learned in this thread that Intercom is as well). If this latest Ember release excites people, I highly recommend that people check out what the Aurelia team have been working on with Aurelia 2 https://aurelia.io/blog/2019/10/31/aurelia-vnext-2019-fall-update https://aurelia.io/blog/2019/10/31/aurelia-vnext-2019-fall-u.... I have always seen Aurelia being similar to Ember, except the syntax is cleaner (especially templating) and is conventions based. There are a lot of similarities between the two. One thing that Aurelia are doing in Aurelia 2 is an option to shake it down to a tiny app. The problem with frameworks like Angular, Ember and Aurelia 1 is they ship a lot of code to the browser and startup time can be quite slow. In Aurelia 2 they're working on quite a nice and promising AOT compiler. I really wish the Ember team would focus on bundle size, what I have seen with Octane, the bundles are huge. My money is on Aurelia 2 when it launches in 2020, so it is nice to see Ember firing back as well, great timing given the recent State of JS survey yielded people are really frustrated with Angular.

nullvoxpopuli 7y ago
CrowdStrike also uses ember and loves it. Handlebars isn't really what ember uses. And it's unfortunate that the extension is shared. there are tons of improved semantics with Octane's Ember Templates that the handlebars you're thinking of could never dream of representing -- mainly @args vs attributes (like html attributes can be forwarded via ...attributes) <MyComponent class='foo' // any html attribute @arg={{this.value}} // @ = arg // this = owned by the current context /> (and inside that) <div ...attributes> // gets the class attribute {{@arg}} // you *know* that @ means it was passed in </div> is there anything in particular you don't like?

wildchild 7y ago

Hopefully Ember Data will be purged one day as something that will never fulfil any more or less reasonable application except TodoLists. It sucks off a lot of resources which otherwise would be assigned to different weak places of this project.

someonedamaged 7y ago

This is an awesome update, really like the new component APIs and the ergonomics for manipulating the DOM! I mostly worked with React and Vue, since Ember had quite a learning curve in the past and wasn't really an option for me. But this new edition seems to be much more straightforward to start working with. Looking forward to build my first Ember app over the holidays :-)

vdrizzle 7y ago

At coschedule.com we’ve been using EmberJS since 2013. We look at EmberJS as one of the strengths of the development team. It has been rock solid, stable, and progressive. We began our transition to Octane about 3 months ago, and while still very much a work in progress but it has been a delight. We just finished refactoring the oldest section of our app, and on average we’ve seen a 50% render performance increase, this in part to the leaner glimmer components. The future is bright EmberJS is fun and easy to develop on. The learning curve has been drastically reduced and new devs should not have a hard time getting up and going. The guides have been completely redesigned and the super rentals tutorials is an excellent tool to get started.

nivenhuh 7y ago

On using Ember I’ve been using ember since 0.9.5.1, so for 8 years or so? (I have 6 biggish apps that are still under active development today) At the time — there was no router, Ember.View was a thing, there were multiple types of views and controllers, JSON:API wasn’t a thing, ember-data was wild, etc. Most of the contributions depended on tomhudakatzdale, as well as a number of other core contributors (dgeb, tchak, and others I’m leaving off — sorry!). The framework frequently had breaking changes, patterns were moving around rapidly (we had to rewrite one of our pre 1.13 apps), it was a bit of a mess. (Then again, at the time, a lot of other frameworks were in the same state.). I think these times gave Ember a bit of a bad rap. The thing that stood out to me then, and still holds true today, is that the community has been committed to bringing in the best ideas forward in a community-driven way. Even though much of the initial framework had growing pains, it was able to do a few significant things: establish a community model for managing changes (RFC/RFP process), delegate core responsibilities to a broader team of people (not based on corporate interests), create consistent release intervals, follow semantic versioning, establish json:api as a specification, and really take community feedback in as development priority / direction. Octane is the cultivated result of years of decision making by the community. (And, I believe, that’s why folks say “Ember is great tech”). I continue to use and recommend Ember to others. Happy to answer any questions for folks!