Browsers

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 asked for it. It just reopened everything from the 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

2016   browsers   programming   rants   software   web

The future of the web and native apps

Apple loves native apps: they are faster, interact with the system better, work offline and feel real. Google loves web apps: they don’t require installation, work on any OS and get all the browser features for free.

In the future, there will be no distinction between native and web apps. The two worlds will merge.

Google is heading into the future much faster than Apple. Apple, it seems, doesn’t even see what’s wrong with native apps. Google, on the other hand, does see what’s wrong with the web, and gradually fixes it.

While I mostly prefer native apps to web apps, I feel like this is about to change. One should not be blinded with the current state of the web. I believe, it will become the universal platform of the future, and native apps will die.

Performance and access to system

Native apps are fast because they are written in a low-level language and work with the hardware in a more direct way. The web is slow because of the multiple layers of abstraction (it’s especially bad when reflow hits).

But these are just historical limitations. We will get over them. Performance-critical parts of the web could be written in C instead of JS, if needed. The same way as performance critical parts of server code could be written in C instead of PHP (or whatever).

The web will gain access to the system. It will use my camera and gyroscope the same way as native apps do. Insecure? But how is it less secure than for the native apps? The risks are the same. Apple is dealing with it with sandboxing and by asking for your permission before letting an app see your photos. The web will work the same way.

URLs

URLs are the power of web. The browser address bar will die, but the URLs will not. They uniquely identify (ok, locate) the resource. This makes linking, the main navigation tool, possible. The links could be open in tabs, saved to bookmarks, found by robots, sent to friends. Native apps can’t do anything like this unless specifically programmed to.

When developers of native apps start to develop for the web, they have hard time figuring out how to manage all the application states in a consistent manner. The user can open any URLs in any order regardless of the developers plan. “How do I pass a variable from a page to the next one?”, a web novice would ask. The very question shows that the person has no idea what they are doing. And then we get the stupid websites where you can’t just press Back or Reload: the browser asks you if you want to resend the forms data. It takes years of experience to appreciate and embrace the beauty of the web technologies and start developing with full understanding of them.

Native apps try to support deep linking, but this is very inflexible in comparison to the web.

Tabs

Tabs are a great invention of human interface. They let you use the app the way you like. You can open multiple states at once or group related things together in a free way.

The developers of native apps often can’t even make their app capable of running multiple copies. Some online banking sites, too, suffer from dumb limitations like an inability to open a link in a new tab. This is probably due to the fact that they were developed by the developers from the native world.

Apple has added tabs to the Finder, but I can’t even open a folder in a new tab in a reliable way. And it’s crazy that the Finder has to explicitly ”support tabs”. Facebook and Wikipedia also support tabs, no big deal! Only for the clumsy native apps tabs are an accomplishment. The web just uses URLs and gets tabs for free.

I very much miss tabs in Lightroom, iTunes, Mail and Evernote. It may well be that these apps will learn to support tabs some day, but each one will have its own unnecessary limitations. Tabs must be a responsibility of the OS. Also, if iTunes and Evernote do eventually support tabs, I still won’t be able to group them in one window, like I do with Facebook and Wikipedia without them even noticing.

Bookmarks and history

Bookmarks, as well as tabs, are just an effect of having URLs. Every UI window is identifiable, and thus we can save the identifier for quick access. I don’t understand why I can save a Google Docs document on a bookmarks panel, but can’t do the same with iTunes search results. Actually, I do understand why: it’s because iTunes is a stupid native app. It works only in a limited set of pre-defined ways.

The same thing with history. I can always find what I’ve been doing yesterday or a week ago, and websites don’t have to “support” it. The best we can get from the native apps in this regard is a list of recently open files (very short, not searchable). You can only dream about the ability to search for an obscure Photoshop checkbox that you’ve enabled last week. For this to work, Photoshop has to implement search and history in preferences, which is obviously an overkill. I’m not sure any of Facebook developers have even thought about such a feature for their product, but Facebook does have it anyway.

Installing

Installation is an example of UI evil, as website registration is. I just want to buy a book, why do I need to register in an online store? I just want to edit a photo, why do I need to install Photoshop? Today, this question may sound strange to some, but in the future people will not understand this ritual of “installing an app”. It’s just a meaningless waste of time.

I hate the need to keep hundreds of icons in iPhone folders. Why would I need an app of my preferred airline? Can’t I just buy a ticket by typing “air” into the search box? In the world of native apps, no, I can’t.

Meanwhile on the web: thanks to history sync, I can easily open on my laptop something I’ve been doing on my iMac three days ago without even thinking about what’s “installed”.

Accessibility

On the web, you can copy any text or save any image by just dragging it to desktop. Again, a website doesn’t need to do anything to enable this, it is just how it works. A native apps would not care when you try to select a text in a dialog box, unless this is specifically programmed.

On the web, you can zoom. On the web, you have full text search on any screen.

On the web, you can do automatisation: any service can go to any other one and do something with it.

Offline

For web apps to work, you need to be online. While native apps don’t require that, they become less and less useful when used offline. If a native app can’t sync with the server, the fact that it launches may not be particularly useful. But it’s important that a native app starts and shows at least something when offline. You see your calendar as it was when you were online the last time. You cannot send or receive mail, but you can read and reply. This is much more useful than seeing the “You’re offline” message in the browser.

Web apps are now almost capable of working offline as well as the native apps. See Jake Archibald’s talk on ServiceWorker (it can even do push notifications). Google supports this in Chrome.

Browsers

The biggest problem the web apps face are the browsers. Seriously. When you use a web app, you feel its webbiness (?) every single moment. It’s not real. You almost see the tags and scripts behind the pixels.

The browsers are bad. It’s 2015, and they still cannot fight the white screen of wait. This screen is particularly effective at saying “hey, it’s the crappy web, and if your Internet connection is down, well, tough luck!”

I want any app to have a Dock icon, so that switching to Facebook would look like switching to Photoshop.

The future of the OS

In the future operating systems, there will windows capable of displaying web content and merging into one with tabs. The same way as nobody is thinking about the WindowServer process on the Mac today, nobody will think about “the browser”. That’s why a browser vendor would never make an ideal browser. Only an OS vendor would.

Under Windows, Chrome can save web pages as “standalone apps”, but this feature didn’t get much traction. That’s because the web apps are not designed to make use of it. They assume there is a browser around them. It’s unclear what a “standalone” Gmail app should do when I follow a link in a mail. Also, these app wrappers usually hide the pages’ URLs, which is a shame. You can no longer do any of the stuff the web is good for.

While the term “browser” will gradually die, the Back and Forward buttons will become a part of any window in an OS, as the close and minimize buttons. All windows will learn tabs. The address bar will not be constantly displayed on the screen, but there will be a way to copy or edit the address of any window.

That will be cool.

2015   browsers   future

A proposal for custom website loaders: loading.html

In a browser, when you enter a website address and press Enter, the first thing you see is white screen — no matter how fast your internet connection is. When you launch an app on an iPhone, you see the app immediately — no matter how old your phone is and how slow the app is. The trick is that every iPhone app includes a screenshot of its own initial state. Usually it is the app’s first screen without any content.

The browsers could copy the iPhone’s behavior to improve the perceived speed of the web. In addition to the real page, a web server could serve an HTML file with a temporary content to show while the real page is loading. We’ll call it loading.html, but it could be anything pointed to by a link tag.

When the user goes to a site for the first time, the browser loads it in a regular manner. But if it figures out loading.html is available, it downloads the file and saves it locally. When the site is open again, the browser renders loading.html immediately and then replaces it with the real content when it becomes available.

This is not caching: browser shows loading.html while, not instead of loading the real page. And it will reload this file when it changes, like any other resource.

The difference between nothing and something is huge: immediate feedback, even approximate, is one of the main things that make user interface great. Enter:

A proposal for custom site loaders: loading.html

The following aspects of loading.html should be considered:

  • External resources. It seems sensible to disallow usage of any external resources for the file. They defeat the purpose of the file: the browser should not spend any time loading images or fonts for this temporary screen (which, hopefully, will be visible for only a second). The browser could cache those, but this may become a debugging nightmare. Embed all the styles, scripts and images — or make do without them.
  • File size. Since a browser should store this file for every site you’ve visited, the file should be small. Also, its loading should not tax the visitors who open your site only once.
  • Interaction and continuity. Interaction with a page that can vanish and get replaced with another one any moment seems strange. At first I though that it should be completely prohibited: no links, no listening to JavaScript events. But then I thought, what if I put a site’s menu in loading.html? If a user clicks a link, the browser could switch to loading it (it, by the way, could have its own loading.html, see also Scope). But badly implemented this could be frustrating. Say, a user is typing a search query into an input of loading.html when it gets replaced with a real page. The browser must make sure the typed letters are not dropped and the caret position is maintained.
  • Progress information. It would make sense for loading.html to want to display a spinner or a progress bar itself instead of relying on the browser. For this to work, the progress information should be available to it. A way to implement this would be with an event sent to the page, i.e. onLoadingProgress (in which case disallowing all events is not an option).
  • Location. From the point of view of the scripts on the loading.html page, its location should probably be the same as for the real page it’s temporarily replacing (even though in reality, obviously, loading.html was loaded from another URL).
  • Cookies and localStorage. These should probably be available to loading.html as for the real page also. A use case would be showing the name of the signed-in user right on the loading.html page.
  • Scope. A loading.html page might want to specify the scope of real pages it works as a loader to: only the one it is linked to, a range of pages, all pages on the given domain name.
  • Expiry. A loading.html page might want to specify its expiry date.
  • The switch. When should loading.html be replaced by the real page? Waiting for the full page to load is surely not optimal. Perhaps, a browser should use the same heuristics it uses now to start displaying a page when following a link. But I would consider giving a loading.html-aware pages some additional control over it.

I don’t have experience with Offline Web Applications APIs, but going by the description, I assume at least some of the described behavior could be implemented with them. It would, however, be too complicated for anyone to bother.

This feature will probably be abused by some designers to show splash screens and ads. That’s not a problem. On the iPhone, some apps also show splash screens, and though this sucks, in no way is it a reason to remove the feature (actually, if we remove every feature that has a capacity of being abused, we’ll remain with nothing).

I’ve long been concerned with how web pages look and behave during loading, as you may have guessed looking at Emerge.js (just updated, by the way). There is a lot we can do as front-end developers. But to make things significantly better, help from the browser vendors would be required.

2014   browsers   Emerge   web