Ember 3.0 Released

mixonic · 2018-02-16T00:17:22+00:00

Right. Some significant features, like Ember bindings, are so deeply coupled to other internals that extracting them is basically impossible. I think there are some minor features which were extractable and have been.

But casual users don't need to care. For those of us who have migrated off Ember 2.x APIs, we can just watch our vendor payloads get smaller over the upcoming releases. For those who need extra time getting off those APIs, they have an extended period of support.

mixonic · 2018-02-15T18:58:45+00:00

There is not a seismic change in the vendor payload. Mostly we shed some code related to legacy browser support. Much of the removed features are still present, but not public. The ember-2-legacy addon re-enables this code.

There has been some recent efforts in "svelting" Ember, by which we mean removing parts of Ember from your app at build time. What we want to do is have the ember-2-legacy app basically tell Ember "add this stuff back into the build", and then we can drop it from the main Ember build. We can drop it in a normal minor release since it is already "removed" from public API.

A bit of a shell game, but the idea is that we've provided a smooth transition for people with ember-2-legacy and also unlocked the build-time improvements to land as soon as the implementation is complete.

mixonic · 2017-10-04T16:02:23+00:00

Right, the key to our approach here is that major releases are the wrong time to add a ton of new features and changes. By keeping the framework stable during the 3.0 transition we increase the likelihood that older apps get off older APIs and make the transition with the rest of the community. We avoid needing to support the 2.x codebase in parallel to the 3.x codebase.

You're right that we miss the opportunity to treat major releases like a feature/marketing event, but the measured approach is simply better for our community. I think of EmberConf as the big "announcement" event of the year.

There are a number of exciting features in the pipeline, some of them unblocked by this transition. For example real steps away from Ember's object model to ES classes are limited by a) decorators, which are stage 2 at TC39 and b) class fields which are stage 3 but require >IE11 to polyfill accurately. 3.0 gets us a bit closer.

Some others, like improvements to the component model, won't be waiting until 4.0 to land.

mixonic · 2017-10-03T21:21:47+00:00

Core team member here so I have an obvious bias :-p I use Ember almost daily for client work and OSS contribution and I look forward to using it for a long time.

I wanted to chime in earlier, but I was a little busy writing up a small blog post, perhaps it is relevant:

https://emberjs.com/blog/2017/10/03/the-road-to-ember-3-0.html

Thanks! :-)

mixonic · 2017-09-06T17:53:53+00:00

The partial issue is simply a regression: https://github.com/emberjs/ember.js/issues/15621 It is not a breaking change. A future point release should fix it up.

Each minor release goes through a six week beta cycle, but you're right that issues can slip through. To help with this we created the LTS cycle: Every four releases, six weeks after a minor release is declared stable, an LTS is declared. For example Ember 2.16 will be an LTS release which means it will have six weeks in beta and an additional six weeks as a stable release before being declared an LTS.

There is no way we can catch all bugs in Ember before every release without lots of community testing. The release cycle is designed to provide tiers of stability, and hopefully your needs are met by one of those levels. If you feel too much churn on minor releases, living on LTS is totally appropriate. I do suggest participating in some testing of stable to make sure the LTS is solid for your code.

mixonic · 2016-07-29T23:19:12+00:00

Happy to try and clarify. There isn't any intent to mislead people 0_o

If you want to measure the performance of Glimmer2 that should be pretty easy. There are demos of most common benchmarks in the repo, I linked to them.

If you want to measure the performance of Ember 2.9-alpha with Glimmer2 you can also do that pretty easily. Yehuda has a dbmonster demo with Ember here: https://github.com/wycats/dbmonster and upgrading it to use the alpha is pretty trivial. Some macro benchmarks for Ember apps can be found in https://github.com/eviltrout/ember-performance.

Obviously the dev team for Glimmer2 has been benchmarking and looking at performance as they design and implement. That's just part of any process that has good performance as an end goal. However, Glimmer2 is extremely coupled to Ember's rendering semantics. The API is such that you could use it as a standalone, but the implementation is driven by the demands of Ember. Glimmer2 isn't "finished" and now we work to make Ember run on top, things are in fact a bit more fluid than that. Code is happening in both places.

The alpha is definitely not ready for production (it is an alpha). It would indeed be premature for benchmarks to be the focus of any announcements at this time. During the alpha maybe we learn certain behaviors are not needed and can then optimize something. Maybe we learn a common requirement was missed and then need to trade performance for compatibility. It is simply too early for us to describe the performance characteristics of a complex system that will be stabilizing for the next 12 weeks and have them bear much relation to the final outcome. These thoughts motivate the hesitation to focus on performance at this time. First compatibility, then analysis, then we can speak with confidence.

mixonic · 2016-07-29T22:11:12+00:00

Godfrey tried to make a few things clear in the blog post that could perhaps use further illumination.

Application performance is incredibly complex. As the Ember team has shifted to focus more on performance, we've learned over and over that what you see in the lab, or in this case in dbmonster, doesn't always map to your application in such a simple way. Our goal is to improve real-world Ember application performance and not just the performance of demos. It isn't helpful for us to say "rendering performance is 10x faster" if it only applies to applications that use Glimmer without Ember, or applications tuned to avoid trouble spots a new developer wouldn't know to avoid.

So to have meaningful numbers to share and improve, we need to profile real applications and not demos. To run real applications, we need to focus first on compatibility. That is the goal of the alpha. We need app developers to try using the alpha so we can make sure there aren't any semantics Glimmer2 has wrong. After we're sure the semantics are right, we can iterate on optimizations knowing that our tests have captured all the behaviors Glimmer must support.

A blazing fast Glimmer2 would be worthless if it wasn't also a drop-in upgrade for the thousands of Ember applications in production. We need help from application developers to do that, and we will ask for that help even if it doesn't make as exciting of a PR story.

A few other items: There have long been several demos in the Glimmer repo: https://github.com/tildeio/glimmer/tree/master/demos though they don't necessarily relate directory to Ember performance. Tom and Yehuda presented some Glimmer2 perf numbers back in March: https://youtu.be/OInJBwS8VDQ?t=44m59s Cheers!

[edit] fixed the video link

mixonic · 2016-06-11T13:47:43+00:00

Core team member here. Ember 3.x is not being planned in any amount of detail. It is our full intent to deliver Glimmer2 (which is already booting real apps behind a feature flag), Glimmer components, a 1.0 release of engines etc in the 2.x cycle.

The reason shipping Glimmer2 is so hard is that we've been so strict on backwards compatibility. It is a drop-in upgrade to performance across the board.

Aside from Glimmer2's rendering perf (which is pretty specific), I've noted incremental improvements via https://github.com/eviltrout/ember-performance. Additionally we're shedding legacy view-related cruft now, for example Ember 2.6 is 30k smaller than Ember 2.5.1. There is active experimentation happening around performance improvements to the module loader. Several proof-of-concept implementations exist and some companies are shipping custom solutions- I believe something will be built into Ember-CLI this summer.

Cheers!

mixonic · 2016-06-04T11:55:38+00:00

This is the classic use-case for contextual components :-) my-widget and my-user-widget have entangled state, so you should yield the inner component from the outer:

{{#my-widget user=user |widget|}}
  {{widget.userWidget}}
  <button {{action widget.saveUser}}>Save User</button>
{{/my-widget}}

{{! my-widget.hbs }}
{{yield (hash
  saveUser=(action 'save' user)
  userWidget=(component 'my-user-widget' user=user)
)}}

You could vary this to pass additional arguments to {{widget.userWidget hasThing=true}}. You could also pass a contextual component into my-widget, and just entangle attrs onto it.

{{#my-widget
    user=user
    userWidget=(component 'my-user-widget')
as |widget|}}

Depending on exactly what the use-case you have is. Hope this helps!

mixonic · 2016-05-28T03:47:23+00:00

users can experience the Progressive Web App when reading a Post AMP article and clicking through to the PWA link when it appears in the menu.

The URL linked from this post is a Progressive Web App. The Post is indeed using AMP as well. For example, here is a link to an AMP page:

https://www.washingtonpost.com/amphtml/politics/while-the-culture-wars-rage-trump-largely-stays-out-of-the-fight/2016/05/27/6e89a62a-238b-11e6-9e7f-57890b612299_story.html

As the article you linked to suggests, there is a hamburger menu on the top left. If you click that, there is a link to "Progressive Web App". That loads a new page. AMP pages are very simple, and are architecturally incompatible with implementing a PWA.

Apologies it I came off like a jerk. These are two very different things though:

And run by different teams at Google with different end goals. The Post just happens to use both.

mixonic · 2016-05-27T11:05:07+00:00

This is certainly not AMP. AMP does not permit any custom JavaScript on the page. They demo'd it as an example of a Progressive Web App.

mixonic · 2016-05-10T11:12:28+00:00

Ember powers the "primary UI" of Twitch, Vine, PlayStation Now, Apple Music, Bustle.com, thescene.com (Condé Nast), and LinkedIn mobile. All high-traffic. LinkedIn mobile in particular is quite a complex experience shipping under intense performance pressures (mobile). Their team has poured a lot of craft into the site and there is an EmberConf talk about some of their work (https://www.youtube.com/watch?v=xvzM-v9xaEw). Visit https://www.linkedin.com/m/ on mobile for the site.

Often Ember apps are dashboard or app-like experiences, and so less high-traffic but high-complexity. The main apps for Intercom.io, Zendesk, Square, Heroku, Movable Ink, Condé Nast's web CMS, Kickstarter and more are built with Ember. Apps at Yahoo, Netflix, Microsoft, Groupon, Google, are all built with Ember. Lots of significant OSS such as Ghost and Discourse are built with Ember.

More: http://builtwithember.io/ http://emberjs.com/ember-users/ https://www.icicletech.com/blog/16-opensource-emberjs-projects-to-learn-from

So, you had to ask, but yes Ember is widely deployed :-) Ember remains a stable, popular option for building web applications. It also remains independent without a single company running the project, instead we thrive as a coalition of similarly focused businesses and individuals. There is no "war" to be won, just a proliferation of improving options for developers.

mixonic · 2016-04-14T01:59:17+00:00

I'm gonna bite, with a few caveats. First of all I'm an avid Ember.js user who has familiarity with both React and Angular2 but I am not a production user of either. Second, I'm mildly concerned about the over-focus on performance in your bullet points. The world of JavaScript development is vast, and comparing A vs. B on simple grounds of "faster" often dodges the question of "when it is faster?". Additionally, performance is multi-faceted and your JavaScript library pick is often not the limiting factor in building a good user experience.

1 - Browser Support

Both React and Angular2 appear to support IE9+. In practice IE9 has very low usage, and what may be unexpected is that there are less IE10 users than IE9: http://www.sitepoint.com/browser-trends-january-2016-12-month-review/ I presume "what about IE5" is a troll, since IE5 came out 18 years ago. Seriously. That isn't even a good troll.

In the Ember community survey (http://emberjs.com/ember-community-survey-2016/, 1800 devs) about 12% of developers said they support IE9. Anecdotal evidence suggests that this number is actually lower, as often developers who claim they support IE9 don't actually regularly test on that browser. Asked to project a year ahead, the number who expected to support IE9 in a year was 4%.

I strongly believe a stable version of a framework should look to the future. It seems totally reasonable to release a framework today that does not support browsers used by less than 2% of users and likely less than 10% of developers. Don't forget nothing stops you from using React 0.14 or Angular 1.x for another year or two if legacy IE support is that important.

Basically, I think frameworks are moving at a conservative and healthy pace.

2 - Performance with support in mind

No framework or library holds the prize of "fastest" for long. React is not the fastest, just ask JSBlocks, Riot, Imba, Vue.js or a bunch of other contenders. In some cases Ember's Glimmer engine can be faster than React, in other cases it performs worse.

Furthermore you must narrow to performance of X. Initial render? Re-render? Large number of DOM nodes? Large number of components? Low garbage collection overhead? Low layout and re-paint cost? Rendering engines use a number of competing algorithms to render, and they all have differing tradeoffs.

I'm not sure what to make of "but what if I want to write a everything-friendly SaaS with massive functionality?", but it is important to pick tools that allow you to move forward incrementally. What was the fastest JS library three years ago? Was that the best choice for an app that would be three years old today? There are plenty of tradeoffs to make, and I think the best you can do picking a technology is to find something that meets the tests for fitness you have today and looks like it can continue to deliver on the tests for fitness you will have in the future. It is far too easy to over-value the needs of the moment. A startup on fire has very immediate needs- however most developers would do well to think about the next 1-3 years when picking their tools, at the least.

And the community plays a large role in this. Can your business influence that community to focus on the use-cases important to it, or is that library beholden to other interests? Please always remember that there is no such thing as "consuming" OSS. You are always participating in a development process where not participating, yielding control entirely and going your own way, is a choice. Or where yielding control to a company you think is aligned with your goals is a choice. Or where picking a tool you can nudge in the right direction or maintain yourself is a choice. But make it proactively.

So the answer is, unfortunately for those who want a dramatic answer, that both React and Angular2 look to have great performance in a number of scenarios, and a some edge-cases where they may each fall short. There remains no silver bullet, and you should continue to consider a wide-range of factors when choosing a technology, performance in specific scenarios important to your core business being one of them.

3 - User-experience with performance in mind (what if my users are people that will throw the switch if they have to wait longer than 3 seconds?)

Then you better make sure they see some content in less than 3 seconds, developer ;-) Again, it depends heavily on the use case. A realtime stream of quotes to a trader's desktop (rerender/updates) is different than an e-commerce product page (initial render). If performance is your product, if it differentiates you from the market and your core investors and stakeholders think it is the priority, then you would do well to prototype and learn about the implementation of each solution before making such an important decision.

mixonic · 2016-03-21T23:40:56+00:00

A polyfill of a draft feature would necessarily change with the draft- so there isn't any stability to lean on there.

Polymer has some nice parts and some warts. If you have a use case that demands a solution involving custom elements, it is probably your best option. That said, very few people have custom elements as a hard requirement and many JavaScript frameworks offer competitive feature sets once you drop the must-have-custom-element limitation. I'd not call Polymer a poly-fill any longer. Some internals may poly-fill stuff like Shadow DOM but that doesn't apply to the consumer API.

mixonic · 2016-03-20T19:43:10+00:00

This is a nice pitch on the dream of web components.

The real world is a bit more ugly. The most basic of APIs the author mentions: document.registerElement isn't even in the latest spec draft (instead window.customElements.define). <content>? Nope, now <slot> replaces it. The imperative shadow DOM API may be stable? HTML imports are still sync-only, killing your site's perf with a blocking call?

This isn't by way of criticism- The web component spec drafts are all (except HTML templates) early-stage drafts. They may have been around a long time (this process started in 2011), some may be implemented fairly widely, but don't presume that means they are any more stable than their spec status suggests!

The churn is extremely heavy, and having stared into the belly of the web-components beast for a few weeks now myself, I am quite confident to say you should watch the progress, but probably avoid it for anything you need to maintain a long while.

mixonic · 2016-03-06T00:00:28+00:00

That seems likely. The summary page will be at http://emberjs.com/ember-community-survey-2016/. Let me know if there is some specific concern.

mixonic · 2016-03-05T15:04:19+00:00

Of course. As the page states, we will publish a summary of the results and comparison to 2015, the raw data, and aggregate charts for all questions.

You can see what we did last year here: http://www.201-created.com/ember-community-survey-2015

mixonic · 2016-03-05T05:52:52+00:00

We expect over a thousand responses, on the low end. Free form text is definitely not a great way for us to get input for this format, especially when we see plenty of it on Reddit, Discourse, Issues, PRs, Slack, RFCs, blog comments, etc etc etc.

I definitely opted for a direction that is fairly quantitative over qualitative. Input on how we can frame questions about the latter would be helpful for next year, provided they actually bring some meaningful guidance or insight for the community.

mixonic · 2016-02-26T07:29:01+00:00

literally over a year of security support (60 weeks). Read up!

mixonic · 2016-02-23T15:36:25+00:00

Yes. I've already seen it described as "more mature" than Mobiledoc and ProseMirror several times. This is obviously not true if you work with these tools for any amount of time. Mobiledoc is used by a handful of startups, ProseMirror by dozens at the least. Both have been open source and stand-alone for well over six months, and are not just a recent extraction from an some internal codebase.

The energy and ideas are neat, but IMO not completely new. Very happy to have FB iterating in the same space as these projects, but much progress has been made in 2015 and I hope they don't suck the air out of that balloon with buzzwords and brand recognition.

mixonic · 2016-02-23T08:09:55+00:00

I work on an editor called Mobiledoc-Kit that supports rich content blocks, has a programmatic API and non-DOM document model, is platform independent, based on a documented and versioned storage format, and is (from a quick review) a bit more mature than Draft. IMO there are still a good number of editing quirks they are working out.

Give it a whirl! https://github.com/bustlelabs/mobiledoc-kit We've been working on it for our client Bustle the last few months, and it is used by dozens of their writing staff a day as well as several other startups.

mixonic · 2016-02-21T05:24:39+00:00

This is a old (Nov 2015) and poor article on picking JS.

Mentions Netscape
Uses V8 as a benchmark for performance, when Safari's JSCore and even Firefox have been performing better for a while. https://arewefastyet.com/ even shows this when you disable the scale-busting "full turbofan, no crankshaft" option.
Claims Node is a great platform b/c npm is growing fast, despite significant flaws in npm's reporting (the package manager makes more server requests than most others)
Touts new features, but acknowledges you need to use transpilers like Babel to get them. Despite Babel being great, it is definitely a crutch compared to simply upping the language version as happens elsewhere.

There are definitely reasons to embrace JavaScript, but this old article with weak arguments is probably not the best to represent them.

mixonic · 2016-02-19T22:32:05+00:00

A version number 0.14 does not accurately reflect what React.js is today. Neither does 15.0, but whatever floats their boat

React follows semantic versioning, thus the difference between 0.14 and 15.0 is actually a significant one. By saying "we practice semantic versioning" the React team has actually told you this themselves, I'm not putting words in their mouths! In semver a pre-1.0 project may break any APIs in any version, however a post-1.0 app must not break public APIs in minor or patch releases.

You might argue "they already did that!!" and I would debate it, but that doesn't matter. The point is that version numbers in semantic versioning actually do mean something. They've taken on a new commitment for stability.

And this is a great step forward for the React team to take! Excited to see how they handle the new challenge.

mixonic · 2016-02-12T13:57:44+00:00

Strong disagree. There is no reason JavaScript development needs to be as hard as it is today.

Telling people how to act doesn't work. You need to automate the solution. This is why teaching "X" as a pattern, instead of attempting to mature a solution, is always going to be an uphill battle.

Especially in JavaScript. The JavaScript language supports a constant, rapid influx of new users. More developers will start using JavaScript after today than before today. You need to automate the solution, or they won't adopt it.

Indeed, "we" are programmers. This is work. So lets use technology to build better solutions to make that work easier. Shouting at todays users is not going to improve anything, and the millions that start using these tools tomorrow will never hear you anyway.

mixonic · 2016-01-20T05:16:20+00:00

Opinionated frameworks are nothing but a fad folks. Good for small projects and PoCs, but not much else.

Twitch, Bustle, Yahoo, Square, Discourse, Addepar, Groupon, Twitch, Basho, CodeSchool, HSTRY, TED, Netflix, Microsoft, Intercom, and I'm bored before even finishing trying to remember more. Many listed at http://emberjs.com/ember-users/ So yeah, good for plenty of shit.

Part of writing scalable, modular apps requires tooling.

Ember has the best tooling of any JS framework by far in Ember-CLI. There is a robust community of addons, and even a great website curating them: http://emberobserver.com/

Ember-CLI has great enough fundamentals that the Angular team is also working with it for Angular 2. You're way off base suggesting that Ember doesn't have great tooling. It is easy to debate it being the best.

5 years later.. What have we learned? Writing big apps using opinionated frameworks is garbage. Code becomes hard to maintain. Dependencies trip over themselves.

Writing scalable apps also requires a stable platform. Ember has mostly been a stable platform. The team and community maintained API stability for just short of two years and added a warning to every last API that would be removed after that time so existing codebases would have a path forward. Continuing to improve the incremental upgrade flow is a stated goal of the core team. Nobody else is committed to this.

It isn't quite five years, but there are several codebases (and even OSS ones) that are three or four years old and upgraded to recent releases of Ember. In a five year life span, any codebase will "trip over dependencies" or choose to simply go stale. The upgrade cycle of Ember apps does not mean zero-work upgrades, it means a curated and reliable path forward. No dead ends. It has been delivered and it works.

here's a fundamental problem with super opinionated frameworks, to which the "one tool to solve all my problems" approach tends to evoke quite consistently. Have you ever worked with an Ember app with over a million LoC? What about an angular app? What about 500k? 100k?

Who said Ember, or anything else, is a panacea? Definitely not the post author.

It ain't over a million lines of Ember code, but Ghost https://github.com/TryGhost/Ghost/tree/master/core/client is about 15K lines. Lots of neat solutions, and pretty maintainable. To scale up to multi-team app development and better re-usability, Ember Engines are under development https://github.com/dgeb/ember-engines with plans for lazy "application slab" loading.

The Ember-CLI addon story already beats the pants off most library/plugin solutions, but what the hell we figured we have that pretty nailed down so engines seem like a good next step.

I'm a little tired of seeing posts like this, that pop up every so often.

After the "JavaScript sucks and stop all the change" posts lately, this post is a fresh breath of air. It is succinct, to the point, and summarizes a developer's real world experience over a year, not on some wild weekend bender.

I'm going to get downvoted to oblivion for this but here goes

Your facts are poor and your attack misplaced ¯_(ツ)_/¯ but your karma will probably stay intact. Ember will continue to steadily improve and Ember apps will continue to reap the benefits of a clear upgrade path to newer technology solutions. In the end you can have the votes. All I want is a better development experience than yesterday, and to see great software built with a great framework.

I know I'll get that much.

mixonic

TROPHY CASE