Fwiw @hipertracker Ember has public stated support for IE6. And ember metal-views works with IE8, probably IE6. HTMLBars needs a little work but I don’t see that as our most painful blocker. But still, looking forward to 2.0 when we can liberate ourselves from IE6. Unsure about IE8.
Actually, most of what I stated 23 days ago has gone according to plan. 1.8 is stable on IE8, @mmun’s streams PR landed. @fivetanley is in progress on saucelabs. J Jackson has a prototype of a precompiler and is working in a release ready version. The focus right now is probably solidifying metal-views before 1.8 goes out and catching edge case problems with streams. HTMLBars helpers should be in progress within a handful of weeks, and we will be refactoring the Handlebars helpers as we go. No branch yet, and if you want something to try with your app please don’t ask, just watch Ember’s repo for a PR.
It’s easy to say that when you’re working for a hip startup, but once you enter the world of enterprise, you need to support whatever customers pay for. Here’s how that conversation will go.
Customer: Do you support IE8?
Us: No.
Customer: What if we paid you $500k?
Us: We’ll have it next month.
Yes, IE sucks. Yes, supporting old versions is bad. But when somebody pays you oodles of money to do it, you do it. (See: Microsoft and XP support.)
We still need IE8 support until January 11, 2016.
Beginning January 12, 2016, the following operating systems and browser version combinations will be supported by Microsoft:
Windows Platform|Internet Explorer Version
| -
Windows Vista SP2|Internet Explorer 9
Windows Server 2008 SP2|Internet Explorer 9
Windows 7 SP1|Internet Explorer 11
Windows Server 2008 R2 SP1|Internet Explorer 11
Windows 8.1|Internet Explorer 11
Windows Server 2012|Internet Explorer 10
Windows Server 2012 R2|Internet Explorer 11
I think @eviltrout picked up some severe performance regression with Discourse when moving from 1.6 to 1.8, is this on the roadmap for 1.8 proper release, we would love to move to metal views but can not afford a perf regression (maybe 1-2% but not 50%)
I know that @eviltrout has done a bunch of digging already, but I would love to see an issue reported for this so we have a place to track it (and the solutions) more formally.
@adriaaaaan Please open a ticket with your specific issue! Followup on @sam’s issue showed that 1.8 renders faster than 1.7, but still a bit slower than 1.6. Nothing like the 50% number originally tossed around. The discussion is on the issue at GitHub.
1.8 is scheduled to ship as stable this weekend, and there has been lots of review. Nothing should be “unusably” slow.
Unfortunately I don’t have time to look into it in detail as our application doesn’t yet work on this build (theres some legacy ember code present which breaks but thats my fault) but I was seeing around 100-150ms extra compared to the build I was using when rendering a list of around 50 items. So perhaps I was exaggerating by saying “unusable” but an extra 150ms is around 50% worse performance. Its perfectly possible that a later build has resolved this?
I’ll try and do a quick test later and see if this is still the case
@mixonic okay I was originally have awful performance on this build but I noticed a nasty evil bug in my code that was causing the view to be rendered twice (an old hack for the previous implementation of query params) which caused the noted 10-20percent perf regression to be doubled. That accounts for the issues I was having. Its still noticable slower but not crazy like it was before
I noticed that there is an Ember2.0 RFC github article on hacker news today. In it I did not mention when HTMLBars is going to be released. Does this mean HTMLBars will only become available in Ember2.0?
We’ve started using the term HTMLBars to mean a collection of changes to the Ember rendering pipeline. In the current release (1.8) we’ve added metal-views (a renderer refactor), in the next release (1.9) we will be adding Streams (a data-binding refactor), and in 1.10 we hope to land parts of the new syntax and the DOM-based templating engine.
We’ve worked very hard to make HTLMBars an incremental release, and not a Big Bang rewrite. Partially because of this, it has taken longer to ship than was planned. However I’m personally very happy about how smoothly the transition is going thus far, and if you are a user of Ember.js I think you should feel the same way.
Getting Ember to work with IE8 is indeed actually trivial. It just works. IE7 is not supported.
However, building an application of any significant complexity on IE8 is a challenge. I agree with you there. For a modern developer the tooling feel archaic and the list of missing features in JS and HTML is quite long. I have not advised any client of ours to support IE8 for a little over a year because of this.
Ember might do itself some justice by being honest about this.
There is no dishonesty.
Ember 1.x supports IE8.
Ember’s support of a browser does not magically make developing for that browser simple.
I don’t mean to be argumentative @More_Spinach, but we do in fact work extremely hard to support IE8 in Ember. Personally I don’t want to support it, but the Ember core team and community committed to it when we hit 1.0. We’ve kept up our commitment to semantic versioning, something we are proud of.
For 2.x, we will support IE9. This is all very transparent and clear, and certainly honest. Maybe I don’t grasp your response though.
Honesty is subjective. IE8 support by jumping through multiple hoops while standing upside down and holding a bucket of workarounds, is not quite “support”. By this token every new thing supports IE6 too, but, fine print: “if you spend enough time tearing your hair out to get that support built.”
IE9 is anyway the future, so hope this becomes a non-issue in some time. It’s painful how both people and enterprises keep sticking to age-old technology.
