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.
Intercom is pretty awesome - congrats!
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-hear...
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/
[2]: https://github.com/ember-learn/super-rentals-tutorial/
[3]: https://raw.githubusercontent.com/ember-learn/super-rentals-...
[4]: https://github.com/ember-learn/super-rentals-tutorial/commit...
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!
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.
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.
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.
Glad to see they are pushing through
Ember has always focused on ensuring upgrades are fairly easy to do, and has only gotten better over time.
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.
[1] Apparently this is the development size. The production size is 712.29 KB (180.80 KB gzipped). My point still stands though.
With Octane, we focused on landing broad ergonomic improvements in a compatible release of Ember.
At the same time, we've been working on updating the way that Ember builds JavaScript so that it can make better use of tree shaking and code splitting tools in modern bundlers. That project is called Embroider[1] and it currently builds substantial Ember codebases.
Wrapping up Embroider and shipping it by default is a substantial part of the work we have planned for 2020[2].
Also, now that Octane idioms fully replace the need for Ember's original object model (designed in 2012!), I would expect it to become an optional feature, meant to be used primarily as a transition path. When combined with tree shaking, that should substantially change the default byte size of Ember.
It's too early to say exactly how that will shake out (no pun intended), but it's a big priority for the Ember community next year.
[1]: https://github.com/embroider-build/embroider
[2]: https://github.com/emberjs/rfcs/blob/2018-2019-roadmap/text/...
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.
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`
fwiw, here is a small-medium sized app's bundle: https://emberclear.io/bundle.html (ignore the fact that ember is in that report twice, that's a problem with my analysis, and not the actual bundle)
Over the next year, the framework team is focusing _hard_ on reducing bundle size. Including: stripping deprecated features (which will be huge... at least 20kb (min+gzip), iirc)
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!
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!
I definitely encourage you to check it out sometime, a lot has changed!
One thing worth calling out: MobX requires you to mark getters as `@computed`:
class OrderLine {
@observable price = 0
@observable amount = 1
@computed get total() {
return this.price * this.amount
}
}
class OrderLine {
@tracked price = 0
@tracked amount = 1
get total() {
return this.price * this.amount
}
}
Here's what happens when you try to add methods with arguments to MobX:
import { observable } from "mobx"
import { computedFn } from "mobx-utils"
class Todos {
@observable todos = []
getAllTodosByUser = computedFn(function getAllTodosByUser(userId) {
return this.todos.filter(todo => todo.user === userId))
})
}
import { tracked } from "@glimmer/tracking";
class Todos {
@tracked todos = [];
getAllTodosByUser(userId) {
return this.todos.filter(todo => todo.user === userId))
}
}
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).
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/0...
[2]: https://github.com/glimmerjs/glimmer-vm/blob/master/guides/0...
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-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.
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>
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 :-)
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-upd...
This series of articles is also immensely helpful: 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/
[2] https://github.com/salsify/ember-css-modules
[3] https://www.ember-cli-mirage.com/
[4] https://discord.gg/emberjs
Edit: Formatting.
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.ht...
Also, in that link check how Glimmer fares in start-up metrics (very bad). And it's not even the complete Ember framework.
something else to keep in mind is that both the glimmer and ember benchmarks in that test are full framework-level apps. Not just the view layer. This is largely what impacts the startup time and memory usage.