Why are browsers so slow?

I understand why rendering a complicated layout may be slow. Or why executing a complicated script may be slow. Actually, browsers are rather fast doing these things. If you studied programming and have a rough idea about how many computations are made to render a page, it is surprising the browsers can do it all that fast.

But I am not talking about rendering and scripts. I am talking about everything else. Safari may take a second or two just to open a new blank tab on a 2014 iMac. And with ten or fifteen open tabs it eventually becomes sluggish as hell. Chrome is better, but not much so.

What are they doing? The tabs are already open. Everything has been rendered. Why does it take more than, say, a thousandth of a second to switch between tabs or create a new one? Opening a 20-megapixel photo from disk doesn’t take any noticeable amount of time, it renders instantaneously. Browsers store their stuff in memory. Why can’t they just show the pixels immediately when I ask for them?

You may say: if you are so smart, go create your own browser — and you will win this argument, as I’m definitely not that smart (I don’t think any one person is, by the way).

But I remember the times when we had the amazing Opera browser. In Opera, I could have a hundred open tabs, and it didn’t care, it worked incredibly fast on the hardware of its era, useless today.

You may ask: why would a sane person want a hundred open tabs, how would you even manage that? Well, Opera has had a great UI for that, which nobody has ever matched. Working with a hundred tabs in Opera was much easier back then than working with ten in today’s Safari or Chrome. But that’s a whole different story.

What would you do today if you opened a link and saw a long article which you don’t have time to read right now, but want to read later? You would save a link and close the tab. But when your browser is fast, you just don’t tend to close tabs which you haven’t dealt with. In Opera, I would let tabs stay open for months without having any impact on my machine’s performance.

Wait, but didn’t I restart my computer or the browser sometimes? Of course, I did. Unfortunately, modern browsers are so stupid that they reload all the tabs when you restart them. Which takes ages if you have a hundred of tabs. Opera was sane: it did not reload a tab unless you pressed Reload. To show you the tab, it just reopened everything from its disk cache. Which took a couple of seconds.

Modern browsers boast their rendering and script execution performance, but that’s not what matters to me as a user. I just don’t understand why programmers spend any time optimising for that while the chrome is laughably slow even by ten-years-old standards.

I want back the pleasure of fast browsing.

You should follow me on Twitter, here

 568   2016   browsers   programming   rants   software   web

Ångström Style System for Cocoa

While developing Ångström, the unit converter for the iPhone (check it out!), Alex Babaev and I have come up with the Ångström Style System.

ÅSS (hey, why not) is a JSON-driven styling engine for Cocoa with Dropbox synchronization and shake-to-refresh. It is a great way to separate the code of the app from its look and feel. It helped me try out different aspects of the color scheme, the fonts, the spacings and, most importantly the animations, without making Alex rebuild the app every time I wanted to change something.

Playing with the text caret

One of the many things we were obsessing over in Ångström was the text caret animation:

This is an animated gif, make sure to download the app and look at the real thing.

I wanted the caret to stick out much below and above the text. I wanted it to move like an elastic and bouncy string (whatever that is). I wanted to make it stretch and squeeze, not just blink. There was no way I could explain this in technical terms to Alex. How far the line should stretch? How fast the animations should be? Who knows. I needed a way to play with all the parameters until it felt right.

So I wrote Alex a letter explaining my idea in vague terms. I asked for a way to control the length and the opacity of both the long and the short states of the caret and the transition times between them. After having played with this parameters for some time I figured out I could not make the caret behave exactly as I wanted. Six variables were not enough. We have gradually added the variables for animation easing, the delays and the caret width.

This is the final “stylesheet” for the caret, after hours of tweaking:

"cursor": {
  "showTime": 0.2,
  "hideTime": 0.2,

  "color": "@colors.textNumberColor",

  "period12": 0.4,
  "timingType12": "linear",

  "period21": 0.2,
  "timingType21": "easeOut",

  "height1": 48.0,
  "width1": 2.0,
  "delay1": 0.3,
  "alpha1": 1.0,

  "height2": 78.0,
  "width2": 1.0,
  "delay2": 0.1,
  "alpha2": 0.33

This fragment is actually about 3% of the whole Ångström’s stylesheet.

Dropbox sync and shake-to-refresh

The two things that make ÅSS particularly awesome are Dropbox sync and shake-to-refresh.

Moving the style variables from the code to an external file is a useful idea all by itself: I could have been playing with the parameters and rebuilding the app having no clue about Objective-C. As far as I understand, this is how Brent Simmons’s DB5 works.

But we wanted to make ÅSS a real pleasure to use (no pun intended), eliminating the need not only to rebuild, but even to restart the app. Here is how the process of refining something looked for me thanks to ÅSS:

  1. Open the app on my iPhone and go to the screen I want to adjust.
  2. Open the app’s ÅSS stylesheet from the Dropbox folder with Sublime Text on my Mac.
  3. Change the parameters in the file and save it.
  4. Shake my iPhone to see the change immediately.

So this is literally live tuning of a running app.

There is a different approach to styling: put sliders with the parameters to the Settings app during development. While this may look nice, we think it is very counter-productive. You don’t want to be constantly switching between the app you are designing and the Settings app. You don’t want to be scrolling through tens or hundreds of variables on the iPhone screen. You don’t want to struggle entering a color’s #rrggbb value on the iPhone keyboard. Sublime Text on a computer synced with the iPhone via Dropbox works so much better.

Alex has written a post on the internals of the system, check it out. It explains the architecture and features some code examples.

 54   2014   Ångström   design   programming
 10   2013   design   programming

RocketDocs and web app wrappers

I’ve tried RocketDocs, a wrapper for Google Docs, and was quite disappointed:

  1. It does not recover my open documents after restart. What’s more, it presents me with a list of accounts instead of showing my anything resembling a web view. Every time is like first time.
  2. For unknown reason it takes RocketDocs about five times more time to load Google Docs pages than Safari or Chrome (makes no sense, but true, at least for me).
  3. You have to sign in twice. First you sign in to RocketDocs, then it opens the web view for your Google Docs, and Goole wants you to sign in again. Weird.

RocketDocs wants to be a better wrapper for Google Docs than a browser, but fails to deliver.

The killer feature for a web app wrapper: reopen my content instantaneously. Unfortunately, no one does this (please prove me wrong). We hate web apps for the Blank Screen Of Wait. So the only reason for an alternative wrapper to exist is to remove the wait. Namely, deliver me from the white background which I have to look at instead of actual content. Pre-load everything from cache, from saved screenshot (like iPhone Springboard), do whatever it takes to show me my stuff fast.

 19   2013   design   programming

Got Git

I’ve always loved programming and hated source control. Source control is about baby-sitting your code instead of actually producing it. It’s like time management instead of actual work. Complicated and boring process that requires discipline, attention to and knowledge of things unrelated to the real project you are making. That has always stopped me from even considering source control. Believe it or not, but for seven years I’ve been developing my blogging system, E2, without source control (still, it’s the best blogging system in the world).

I am also not a big fan of the command line. I know how to spell “sudo apachectl restart”, and that’s pretty much sums it up. So all that svn / git / hg command line incomprehensible crap only added to my frustration. Friends said there were GUI clients, showed me Tower. Oh my god, so much stuff to look at, so many buttons to understand, so many rites to learn. For some reason, I can’t just commit stuff, I need to stage it first. No, I said, please, guys, let me just do my projects. And those “remote repositories”? Hate that. Everything is already here, on my machine. Why bother even thinking about putting it somewhere else? See, I didn’t like anything about source control.

Everyone was trying to convert me. They said hey, but how do you work in a team without source control? And I said, I either work alone, or I separate pieces of code into independent files. They said hey, but how do you revert changes if you’ve accidentally broken something, without source control? And I said, I use Time Machine. They said hey, how do you branch your code without source control? And I said, what the hell is that?

But there’s always been something I did want, and I knew source control could do it for me. First, I wanted to see what has changed in a project from a previous revision (to write a full changelog, primarily). Second, ability to comment the changes would be nice. Third, I wanted to be sure no code gets deleted just because Time Machine runs out of disk space. Finally, I wanted to seamlessly merge changes I’ve made on my notebook with the ones I’ve made on my main machine, if I’ve accidentally forgotten to sync them before doing something.

I was lucky enough to get the author of Gitbox, Oleg Andreev (who I happen to know personally), to spend some time on Skype with me and explain how to start using git with Gitbox. It turned out to be way easier than I had thought. You just drag a folder to Gitbox to put it under its control. Whenever something changes, it shows you the changed files (on the right):

To commit changes, you put checkboxes next to the files you want and write a comment in the field above the list. To see changes inside a file, you double-click its name. The project and its commit history looks like mail. Oleg explained to me how to “link” the project folders on the notebook and on the main machine: I had to set up the two copies as remote repositories for one another. This was the only non-obvious thing. Still, done in the UI with drag and drop.

So if you are like me and want to continue hating source control but still use some of its benefits, try Gitbox. Or if you are not like me and you’ve been a source control fan all your life, try Gitbox. You’ll love it.

 37   2012   programming