81–85 of 85 posts
Most of the performance issues people see on mobile (and desktop!) with javascript isn't with javascript performance itself anymore (unless you're doing some crazy stuff), but with the relatively expensive repaint/reflow browser operations.
This is good. Many frameworks are just too freaking huge for mobile but even when you use tiny frameworks and you dump a bunch of images into them you're going to have similar issues (at least on load). Honestly using the DOM API isn't all that hard. Yes it awkward, verbose and sometimes cumbersome but it's still pretty straight forward. I'm actually really liking react lately but if I want something done well for a…
> Another thing this article didn't touch on was latency. When I was doing work for vehicles that had poor internet access via satellite every single http call just killed the load (this included fetching css, javascript, etc). I can't stress enough how much better your page can load if you combine as much stuff as possible, even images if you can display them as backgrounds.
This, so much this. Particularly with the growing marketplace out side of 1st world countries. Fewer calls of any type are of significant value. Reduce DNS calls, host everything from the same domain where possible, etc. etc.
Use sites like https://developers.google.com/speed/pagespeed/insights/ to help you
Rule #1 for optimisation: "You can't make code run faster. You can only make it do less." It's true for mobile devices as much as everything else.
Fortunately a lot of what these libraries do is spin bloated wheels so there is a lot of opportunity to do less without losing features. This is why I write mobile web apps with vanilla JS only. It takes a little more time up front, but the result is vastly superior to what any library can offer.
I think Ember is ahead of the curve on this one. Ember 2.0 introduced no new features, and instead only focused on stripping out deprecations, dead code, or platform specific stuff for browsers they don't support any more. (Disclaimer: I'm heavily invested in Ember.)
The article showed Ember 1.9 coming in dead last because of code size. 2.0 is supposed to be a little better but do you really think it's going to be ahead of the curve? It seems pretty unlikely... I hope you'll say more.
1.13 added a bunch of deprecation warnings to all the features they were going to strip out, and 2.0 only removed code previously marked as deprecated. So maybe not far ahead of the curve, but they're at least taking steps to reduce their imprint.
Earlier quoted context omitted.
Persona is not deprecated. It was moved to "community ownership", which is not "deprecated" just as much as the average open source project is not deprecated. It's a bit like saying that if Red Hat stopped paying it's developers to work on the Linux kernel then Linux itself must be deprecated. I wish more sites would use Persona and so I'm heartily disappointed to hear someone expecting to strip it out of an existing…
I'd love to continue using it... but I don't want to run an instance as I want to point at someone else's instance. If I have to run my own instance then I need to know I can maintain it and keep it secure, and I am not a Node guy and I find the code and all of it's dependencies to be too much for me to say that I am the man to keep an instance secure and maintained. The thing is that I want it to perform as well as…
Also, from your waterfall you've posted here, most of the Persona stuff is happening in background/parallel anyway: the big slowness in getting to render start certainly appears to me to be your fonts more so than Persona, which is what I would expect to see. That is, I'm wondering if you are scapegoating a bit here as the impression that I get looking at your waterfall is that you won't gain as many milliseconds as you might think by removing Persona.