BrowserStartpage – the SpeedDial for all your Browsers

Do you remember the time when Internet Explorer virtually dominated the web and there was not much choice of browsers? Fortunately, those days are long gone and we have a wide range of good browsers to choose from. Every browser has its own strengths, so it is not always easy to find the right browser for your own surfing habits. I currently use the Mac both professionally and privately, and so four of my favourite browsers have now crystallised out of the masses. Let me say right away that they are the four browsers that everyone knows: Safari, Firefox, Chrome and - perhaps not yet so well known - Vivaldi. Each with its advantages and disadvantages, which I would like to outline briefly here:

Safari #

The browser comes with macOS and offers good speed as well as the practical iCloud Sync, which, among other things, keeps bookmarks in sync between devices. The developer tools are solid but nothing spectacular. Unfortunately, the browser just feels too "fiddly" for me, and I'm in need of better DevTools. The elements of the user interface are extremely small and visually it fits in well with macOS, but Safari just doesn't suit my taste at the moment.

Firefox #

Mozilla's browser had its heyday as the first serious competitor to Internet Explorer and then fell behind over time. In the meantime, however, Mozilla has recognised this and is consistently developing the browser further. It is fast, offers a Firefox sync and has quite good developer tools. Moreover, the browser itself does not pass any data to Google. Actually, it's my browser of choice - if it weren't for Google's Chrome.

Chrome #

Google entered the browser market quite late, but nevertheless very successfully. It is not without reason that Chrome has become the most widely used browser. Chrome is fast, reliable and offers extremely good developer tools that are constantly being developed further. Of course, you have to be aware that Google has an interest in spreading the browser as widely as possible. Google sells advertising. These are optimally tailored to your surfing behaviour in order to achieve the highest possible match of interests and thus higher click rates on the advertisements displayed. The bottom line is that advertising generates more revenue. Is Chrome also available without Google?

Vivaldi #

The company that develops the Vivaldi browser is led by the ex-CEO of Opera, Jon von Tetzchner, and has brought a pretty good browser onto the market with Vivaldi. Like Chrome, Vivaldi is based on the Chromium project and contains many useful functions. Splitscreen of web pages and the web panels are the highlights from my point of view. The developer tools correspond to those of Chrome - but are usually always updated a little later. Unfortunately, Vivaldi reacts a bit sluggish here and there, but this can be fixed with a few adjustments in the configuration. (Here is the link to the corresponding adjustments: https://www.ghacks.net/2017/02/13/how-to-speed-up-the-vivaldi-web-browser/

Browserswitching and Speeddials #

As you can see, every browser has its advantages and disadvantages, and it's not always easy for me to choose my favourite. As already mentioned, I currently use Firefox (in the developer edition). Switching from one browser to the next is usually not a big problem. Bookmarks can usually be imported into the new browser without any problems.

All browsers now have a speed dial. As a rule, the most frequently visited pages are stored in a speed dial and you can usually "pin" your favourite websites here so that they are not replaced by other pages. Unfortunately, speed dials are also the big problem when you change browsers. As a rule, they cannot simply be transferred to the new browser, or they are not synchronised between the devices.

BrowserStartpage - the idea #

This was also the trigger for my BrowserStartpage project. I had reached the point where I hardly used my bookmarks and my really often used links were stored in a speed dial. How could I transfer them to another browser or keep them synchronised between the browsers? Create all the links manually in the new browser? Wait until the new browser had rebuilt the page on its own? No, none of this was a good solution. I began to design and develop my own Speeddial.

The requirements #

The initial requirements for the Speeddial were quickly taken up:

• it should be able to be hosted on its own web server
• it should work on all devices, i.e. also responsively
• it should offer the possibility to divide the content into several areas - keyword "tabs
• the currently opened tab should be saved in the browser, so that the next time I open the page, it will open in the same way I left it.
• the Speeddial should make as few requests as possible to the web server in order to achieve a high speed even on mobile devices
• the maintenance should be quite simple and later also automatable
• later on it should be possible to create your own themes to adapt the site to your own taste
• It should be possible to export the site later, so that the Speeddial also works without its own web server and can be synchronised. For example, as a static page, synchronised via Dropbox.

From the idea to implementation #

I started to create a first, static prototype. A collection of links, decorated with screenshots. That was a pretty good start. I synchronised the result via iCloud and set the page as the start page in all browsers.

The tabs #

Logically, the tabs had to be realised with Javascript. No big problem with jQuery - but since I wanted to generate as few requests and as little traffic as possible, I started to implement the tabs with regular Javascript. This would save me the approx. 80kB of the jQuery library.

The page should also be functional without Javascript, since, for example, Javascript cannot be executed on iCloud on mobile devices. This resulted in the fallback that the tabs would jump to the corresponding areas when clicked instead of switching them. The page would now work without Javascript - this is also called progressive enhancement.

Now it was time to save the last opened tab. I decided to use the localStorage here - a small local storage that can be used by the browser. The ID of the currently clicked tab is stored there and read out the next time it is called up. If this ID is not or no longer available in the Speeddial, the default ID is used. This could also be done with a cookie, but in contrast to the localStorage, they can be deleted quite easily.

Minimising the calls #

As the next step, I wanted to optimise the caching of the files so that the browser only downloads files that have actually been changed. I wanted to transfer as little data as possible over the mobile network on the iPhone. I decided to use the application cache. This is realised via a manifest file in which all files are listed that the browser should store locally. If the web server is not accessible, the page can still be used because the data is saved locally the first time it is called up. Even a forced reload in the browser does not put the page out of operation. Another practical advantage of the implementation is that the Speeddial is also functional if the web server does not respond.

The Javascript and CSS I created are now loaded directly into the page to avoid further requests. Also it is a single page application (well, sort of) so caching doesn't play a big role here.

Data maintenance #

Since I plan to change the speeddial directly on the page at some point, I wanted to outsource the content to be displayed to a file. A configuration file, if you will. Since the later changes in the Speeddial would probably be realised via Javascript, I decided to choose the json format for the configuration of the contents. Currently, the following contents are specified in the json file:

• Tab names and structure
• Link targets of the tiles
• Graphics for the link
• Description of the link
• Background graphic

This content is currently read in via PHP and the Speeddial is created from it. The static HTML is currently no longer used. In addition, the already mentioned application cache is also built up dynamically. The advantage now is that additional tabs and links can be specified in the json file. The application cache is then updated without further intervention and the page can now be expanded relatively easily. Only the graphics for the links still have to be created manually, but this can also be automated later.

CSS and Javascript #

The Javascript, as I already mentioned, is now loaded directly into the page, but exists, like the CSS, as a separate file on the server. Both Javascript and CSS are generated using Gulp. Line breaks and spaces are removed to save data. The CSS is developed using SCSS to facilitate later theming.

Get the Speeddial #

The Speeddial is developed by me in a local PHP environment. I simulate a PHP-capable web server here using Vagrant. If this is all Bohemian woods for you, that's no problem - all the relevant data for using the Speeddial is in one directory. You only need the PHP environment if you want to build on the project.

You can find the Speeddial on Github. There you can download all the files. You can find a demo version of the current version here https://demo.saschadiercks.de/startpage/.

There are only a few links here, but there are enough to test the functionality.

All files and a documentation in English can be found on Github at https://github.com/saschadiercks/browserStartpage.

I hope the Speeddial will be as useful to you as it is to me. Switching between browsers or using different browsers at the same time is no longer a problem - they all use the same Speeddial.

Oh yes, I have also linked the browsers described here in the demo file.

If you are wondering how I created the screenshots in the devices: With Magic Mockup you can insert your screenshots into the corresponding templates.