I can honestly say the problems I see in OSS land, are the same shape as those in paid, and the enterprise installation.
The difference is, due to the volume of usage the enterprise installation suffers from these same issues even more.
Now, we may not see +1 DOS often (on the enterprise side of this), largely because its seen as bad manners and/or the goals are already shared via some other disjoint medium. But this doesn't mean the issue isn't present.
Being able to enforce additional semantics (such as priority/interest, reviewers, blocked by etc.) would be a big win
No one is saying that the issue does not exist. However,th author is suggesting that since it hardly impacts paying customers, it is going to get low priority.
Just a pedantic touchup, ember does not use Handlebars (it once, several years ago did) Now it uses something (Glimmer) which shares some syntactic similarities, but usage/implementation have diverged.
First of all, let me share a wonderful (and performant) mobile app, written in ember. It uses ember-data to connect/normalize the iTunes api, and provide a slick fast mobile experience.
Disclaimer, I work on & with Ember.js (and I didn't work on https://fnd.io)
I've worked on several mobile web apps using ember, and performance did require being careful, but often "being careful" was nicely aligned with the mobile UX people expect. Small screen, put less stuff on it. etc.
Often times, we do see issues with ember on mobile, typically this is due to deeply nested loops of UI components being rendered. And most often, performance on mobile was an after-thought.
PSA: Regardless which framework (or no framework) you use, if you are shipping to mobile. Test/develop on your target mobile devices from day 1, you will not have any surprises, and you can catch performance related issues before they fester.
As for the discourse post, there are some issues ember is working to improve. If one reads further, it outlines the largest concern being the growing gap between JSC (Safari, which offers near desktop performance for discourse on mobile) and V8 (which doesn't do so well on mobile for discourse) performance. Year over year, the iOS experience is improving, but the android/v8 experience does not appear to.
The TL;DR of the issue (as is currently understood), is JSC handles dynamic code better, whereas v8 does not (yet) and Ember should both reduce the dynamism and continue to do less work. Which will continue to improve the experience for all consumers.
This is actually quite an interesting issue with lots of details, I could go on, but this is likely not best place for anything in depth.
The important part being, all parties involved are working towards (and together) on a better faster more wonderful future.
Ember with another (faster) iteration if its rendering engine: https://github.com/tildeio/glimmer (written in TypeScript),
V8 with turbofan
and the team, working together to improve JavaScript in the browser for everyone.
I agree, async/await is very nice. Though it is worth pointing out async/await is quite literally syntactic sugar on top of promises. Essentially adding language syntax for common promise idioms.
Agreed, it's syntactic sugar over es6 generators. But I don't agree that it's just syntactic sugar over promises, which is what the parent comment asserted.
The DOM is slow meme confuses me. Yes, if one isn't careful, one can get into trouble. But the same is true for all platforms/frameworks/concepts/religions.
As it turns out, the fastest way to build + update DOM, is with the DOM... #mindblown (its also the only way ;))
I believe the actual pain felt, is one of ergonomics. This is largely related to what MrBra mentioned, it turns out a complex stack is complex I suppose we just need to keep fighting the entropy us developers like to add.
Traditionally those sites may have also consider
I am sure they will continue to be happier as the byte size shrinks, but in the interim they are able to deliver what appears to be a great user experience, in-light of your concerns.
and shrinking :) We have some fun related work planned to continue the shrink.
One thing to note, often we must trade-off bytes for supporting older features. As those go away, we shrink. But moving forward the plan it to have more of a pay-as-you-go model. Utilizing ember-cli to do the r.js optimize esq step, to strip unused portions etc.
Nothing ground breaking, its tried tested and true in many other ecosystems. But when it lands it will provide nice value for our ember apps.
CLI will be following closely with a relevant release. To ensure trying ember 2.0 is as smooth as possible.
my apologies for any lag between the two project releases.
For those interested (or concerned) the CLI is not coupled to the ember versions, it actually enables interested users to switch between versions. Obviously we believe in more curated experience (hence the in-bound CLI release)
We take advantage of this version switching via https://github.com/kategengler/ember-try which enables ember-addons to automatically test against multiple relevant versions of ember.
* OSS user (and signee of the Dear Github letter)
* paid user
* user of an enterprise installation of Github
I can honestly say the problems I see in OSS land, are the same shape as those in paid, and the enterprise installation. The difference is, due to the volume of usage the enterprise installation suffers from these same issues even more.
Now, we may not see +1 DOS often (on the enterprise side of this), largely because its seen as bad manners and/or the goals are already shared via some other disjoint medium. But this doesn't mean the issue isn't present.
Being able to enforce additional semantics (such as priority/interest, reviewers, blocked by etc.) would be a big win