Re Questioning Ember:
I've questioned it many times (and vocally, but within the community itself where I'm an active member). This article is about something much bigger than my framework of choice.
On the comparison above:
I've called this one out before, it's a very poorly built Ember app that's also running a version from nearly 2.5 years ago, before Ember invested a ton of time in building a very fast rendering engine, there's no end of dbMon demos showing Ember at or above the speed of the other major frameworks, and we'll be seeing a new one soon with Glimmer2 landing.
On Ember:
Ember does take an initial performance hit, but unlike other frameworks it tends to give you fairly constant time performance as your apps and features grow. This initial hit is something Ember is working furiously to fix (and I might add a lot of that is directly due to Mobile Chrome performance). Glimmer2 (the brunt of the v8 focus), app shell architecture, code splitting, and tree shaking are all concepts that will be built into every Ember app within a few months.
On a more "app specific" note, I've been working on making occlusion, recycling, and parallelism simple and easy to work with at the framework level in Ember apps, much of which enabled entirely because of Ember's conventions and approach. Generally speaking, I've been able to build mobile and hybrid apps in Ember that are more performant than anything I've seen so far via other mobile and hybrid approaches... except for Android.
On The Article:
I didn't talk about Ember much because my experience with this goes far beyond Ember (or Angular, the other framework that hits these problems more often). The point is that for anything other than simple JS applications, building a great app for Mobile Chrome is extremely difficult to pull off, and it becomes a large cost for app developers and has led to the rise of huge investments in OS solutions just for dealing with it alone.
A point that I didn't talk about much, but which is something you see more in SPAs and hybrid (ala Ember/Angular) is that honestly, 1MB and even 2MB JS apps shouldn't scare us the way they do right now.
Yes, I do agree that it's a lot of JS to ship to a browser, and tree shaking, code splitting, and app-shell will help us deal with that. Yes, I also agree that we shouldn't be asking our users to download 2mb of Javascript to see one page.
But the bet on this architecture goes beyond one page, the moment you hit page 2, every page hit is a performance win over the last. And with ServiceWorkers, this story will only get better. While progressive enhancement is awesome, and will always have a place, full blown apps delivered by the web do too, and full blown apps are very rarely 250kb of Javascript.
What was the last native app you downloaded that was 250kb? And (just name names), when was the last time you looked at how big Facebook's native app is? When it comes to JS apps, we're competing with native, it's naive to think we'll be keeping our JS to such a tiny payload for all time.
In some ways, yes. But the ranking is really where I slide various browsers in terms of ease of getting an app working well, and I think it's important to note that I generally find desktop Chrome more troublesome than Mobile Safari.
The article is primarily about mobile Chrome vs mobile Safari, but the issue is only partially Android's fault. Chrome performs just as bad in JS and render benchmarks on desktop as it does on mobile, and it's memory leaks are present in both; but this matters less on desktop because powerful machines mask this for us.
I wasn't expecting this to be a "thing", I wrote it for people I help out in the Ember community that struggle because of their jQuery background. I may update the title now that this is more widespread.
A lot of it is, but I spend so much time teaching people how to CPU Profile, take heap snapshots, diagnose leaks..
Things that ought to be fundamental, but which were left unlearned while the web was allowed to be lazy. With static pages, GC concerns weren't very large, because soon enough the user is going to click ahead to a new page and wipe the slate anyway.
Yes, some of this is from the misuse of jQuery. But I fix that misuse a lot, so I felt it needed explicitly pointed out.
But many of these complaints have nothing to do with misuse and everything to do with either a lack of awareness about selector consequences, or a decade of built up code debt in the jQuery plugin ecosystem.
All of these examples are true for all JS frameworks, even non-SPA frameworks. Dynamic DOM is a problem for code that wasn't designed to clean up.
There is a real reason to avoid jQuery, that reason is that you want your app to work well. Blindly reaching for a tool from the static age will bite you.
> But unless you made a meaningful discovery that can add to the conversation, you don't need to make another blog post about it. Ugh.
I whole heartedly agree, which is why with each point I made I did more than just list what was bad, but how to do better, even with jQuery. The real reason not to use jQuery isn't because jQuery is bad, it is because as a tool it / it's ecosystem is poorly prepared for dynamic html, so if you are going to use it, you need to know the limitations and challenges it brings.
While his claim is anecdotal, the idea is not. There are psych and drug studies that suggest the same. Also, my own anecdotal evidence says that both working late and the Balmer Peak are effective for just this reason.
By the legal definition of fraud, yes, they are currently guilty of it.
Is 48 hours too short a period of time to wait before calling them out on it? I debated. What ultimately swayed me to write this vs not write this was that I got another email from their system this morning about a deal I'd expressed interest in.
I selected that deal in the same user session as I paid for the event. I received no email confirmation or receipt for my purchase, am told an account for my email address doesn't exist, yet get marketing emails about deals I selected during the same user session.
My post exists because when someone else goes to interact with HowAboutWe, they ought to know in advance that this is a company with poor customer support, poor technical development, and poor billing practices.
Even if HAW refunds me, or does eventually respond to me, new users have a right to know that this is the experience they could receive too.
In some regards, yes. In the larger sense, no. I chose HN because I'm a developer, HN is where I typically stop first for tech news, and the technical issues here are a good lesson for new startups.
When we build apps we need to be aware of "best practices". This includes customer service, feedback within the app when an error occurs, and billing standards. Login issues 4 years into development? Either their framework wasn't properly unit tested or their apps integration to it wasn't.
One thing I should probably have mentioned in my piece and which I'll likely add; despite the tons of email HowAboutWe sends, the only email I didn't get was one confirming my purchase or containing a receipt, although my CC was billed.
Re Questioning Ember: I've questioned it many times (and vocally, but within the community itself where I'm an active member). This article is about something much bigger than my framework of choice.
On the comparison above: I've called this one out before, it's a very poorly built Ember app that's also running a version from nearly 2.5 years ago, before Ember invested a ton of time in building a very fast rendering engine, there's no end of dbMon demos showing Ember at or above the speed of the other major frameworks, and we'll be seeing a new one soon with Glimmer2 landing.
On Ember: Ember does take an initial performance hit, but unlike other frameworks it tends to give you fairly constant time performance as your apps and features grow. This initial hit is something Ember is working furiously to fix (and I might add a lot of that is directly due to Mobile Chrome performance). Glimmer2 (the brunt of the v8 focus), app shell architecture, code splitting, and tree shaking are all concepts that will be built into every Ember app within a few months.
On a more "app specific" note, I've been working on making occlusion, recycling, and parallelism simple and easy to work with at the framework level in Ember apps, much of which enabled entirely because of Ember's conventions and approach. Generally speaking, I've been able to build mobile and hybrid apps in Ember that are more performant than anything I've seen so far via other mobile and hybrid approaches... except for Android.
On The Article: I didn't talk about Ember much because my experience with this goes far beyond Ember (or Angular, the other framework that hits these problems more often). The point is that for anything other than simple JS applications, building a great app for Mobile Chrome is extremely difficult to pull off, and it becomes a large cost for app developers and has led to the rise of huge investments in OS solutions just for dealing with it alone.
A point that I didn't talk about much, but which is something you see more in SPAs and hybrid (ala Ember/Angular) is that honestly, 1MB and even 2MB JS apps shouldn't scare us the way they do right now.
Yes, I do agree that it's a lot of JS to ship to a browser, and tree shaking, code splitting, and app-shell will help us deal with that. Yes, I also agree that we shouldn't be asking our users to download 2mb of Javascript to see one page.
But the bet on this architecture goes beyond one page, the moment you hit page 2, every page hit is a performance win over the last. And with ServiceWorkers, this story will only get better. While progressive enhancement is awesome, and will always have a place, full blown apps delivered by the web do too, and full blown apps are very rarely 250kb of Javascript.
What was the last native app you downloaded that was 250kb? And (just name names), when was the last time you looked at how big Facebook's native app is? When it comes to JS apps, we're competing with native, it's naive to think we'll be keeping our JS to such a tiny payload for all time.