Pagehop – Your Terminal for the Web

PageHop logo

Developers are weird creatures. We always want to optimize everything and make sure that we lose as little time as possible while doing our job. Our thought usually goes faster than a computer, so we get irritated when we need to wait or spend clicks and keystrokes to do simple things like browsing the web, or opening applications. This is the reason text editors like Vim are extremely popular. They are a mess by modern UX standards, and using them feels like going back in time, but because they save so much time and make automation possible, people still love them.

Today, I stumbled upon another automation tool, which tries to trim more seconds from a developer’s precious time – it’s called Pagehop. Pagehop lets you navigate the web without opening your web browser. It lets you type commands and take action on the results in a simple text box. Any user of Alfred or Vim will feel right at home. I’ve been a user of Alfred for a long time now, and I’ve grown to love it. It’s the start of everything I do on my Mac, weather that would be opening an application or searching Google. But although Alfred has multiple extensions – it only goes so far. Most of the stuff it can do is limited to offline applications. Searching Google seems to be all that falls into its scope when doing things online.

Pagehop is Alfred for the web. Not only can you open web pages with it, but it also lets you navigate multiple links, or search the content of each result. Let’s see how that works.

Once installed, Pagehop can be invoked by pressing Ctrl-Option-Space on your Mac. A textbox appears. You can do a simple Google search by typing “g <your search term>”. Let’s try it by searching for the React javascript framework.

Google Search for React in PageHop

The results of the search are shown immediately below the text box. Pressing Enter would take you to the selected result, but you can also go through them, or type further to filter more. Let’s say that we actually want the React documentation rather than the homepage. We can extend our search by typing “:l docs”.

Search React Links and go directly to documentation

The “:l” tells Pagehop that we want to go through all Links in the result, and search for the string “docs”. Pressing Enter takes us directly to the documentation page. This is where Pagehop feels much more advanced than Alfred. While in Alfred you can tab through the different results, Pagehop lets you use issue custom commands. Apart from selecting links, it also lets you do fuzzy search, regex search or search through the URLs rather than text. It’s like having a terminal for the web. You can call commands, and pass them options and arguments.

Of course googling isn’t the only thing Pagehop can do. It has a number of built-in recipes. A recipe is just a different source of information that Pagehop can pull data from. There are built-in recipes for Google, Bing, DuckDuckGo, Wikipedia, MDN, HackerNews, StackOverflow, and others. You can list all recipes by typing “allr”. Pagehop lets you search documentation or read developer news just by typing, instead of opening your browser. Of course once you are done with your search, Pagehop opens the result in your default browser so you can read at peace.

I already mentioned Vim, and developer’s love for it has caused the creation of tools like Vimium – a browser plugin which lets you navigate Chrome using the Vim shortcuts. Pagehop lets you do something similar without even opening your browser. It provides the simplicity of Alfred combined with the power of Vim to navigate anything with a keyboard.

But the best news of all is that Pagehop lets you extend it with third-party recipes and tools. If recipes are the sources of information, tools are the commands that you can pass to each recipe. If you know JavaScript, and you have an idea for a new recipe that may fit your personal development workflow, you can go through the developer documentation to learn how new recipes are created.

I’ve only been playing with Pagehop for an evening, but it feels wonderful and I suspect that any automation geek will feel at home. Go play around with it.

The End of “var that = this” – Arrow Functions in ECMAScript 6 Are Awesome

JavaScript has taken off. If you are a web developer, you have probably noticed the trend. In the last couple of years the language has seen a tremendous growth in adoption and tools. The community has created some awesome things, among which are client MV* frameworks like Backbone and AngularJS, and also server tools like node.js. The future seems bright for JavaScript and if you are just starting to learn web development, make sure that you pay attention.

I was looking through the new stuff introduced in the latest specification for ECMAScript 6, which is the official standardized name for JavaScript. This new specification is still in development and there’s no browser support yet, but it introduces some very interesting changes. Today I want to focus on only one of them, namely – arrow functions. Arrow functions is a new syntax for declaring functions in JavaScript, but not only that. It also redefines the meaning of this . We will see why this is so good in a moment, but first let’s talk about the syntax.

Arrow Function Syntax

A normal JS function is declared like this:

In arrow function syntax, the same code can be translated as follows:

As you have already guessed from the above example, arrow functions start with the list of parameters in brackets, followed by a double arrow (=>), and then an expression which returns the value of the function. In the above case the function multiplies the two parameters passed to it. However, you are not limited to only using a single statement. You can also write a function which executes multiple statements, as long as it returns only one value. In that case, we need to enclose the multiple statements in brackets.

You may be thinking that this is not much different from the regular function syntax and it doesn’t help you a lot. Well, if you have very simple functions with only 1 parameter and a single return statement, things look much simpler.

As you can see, we have omitted the braces which enclose the parameter list, as well as the curly brackets enclosing the statements. When there’s just one function parameter and one return statement, they are optional. This saves a lot of writing. But the biggest advantage it gives over regular function syntax is how it redefines the meaning of the  this keyword.

The meaning of “this”

When you use the this keyword inside a JavaScript function, its value depends on how the function was called, unlike other object-oriented languages where this always points to the current object instance. In a global function, this refers to the window object:

When your function is a member of an object, then this points to the object itself.

If the function handles some DOM event in the web page, then this points to the DOM element which triggered the event.

For more info on the different behavior of  this , you can read this great article on MDN: this

Of course today most developers are not writing event handlers and global functions like the above examples. People have started using the module pattern to introduce better structure to their applications. They are using immediately invoked function expressions and use the concept of closures to emulate encapsulation in JavaScript objects and block access to some of the members. If you are not using these, you should be.

Note: If you are not familiar with the module pattern and closures, please go ahead and read about those first. These articles are a good starting point:

In order to illustrate how arrow functions change the meaning of this, let’s take a simple module as an example.

The above code snippet defines a single module. Note the difference between writing public and private methods. Private methods are normal functions inside our module and can only be accessed by other functions inside the same scope. Public methods are members of a custom object. We return that custom object as the result of our immediately executed function. So anyone outside our module will only see the members of this object.

When we log the value of this in a private method, it points to the object which called the function. Why is this so?

The reason is that privateMethod is not a member, it is a normal function defined in our module’s scope. Inside that function, this points to the caller, in this case window  (see the examples above).

For object-oriented development, it is very weird for this to point to an external caller. That’s why JS developers have tried to escape from this oddity using different techniques. One such technique was to declare an internal variable, which holds a reference to this even after the closure exits. You can declare such a variable right next to our private method.

This practice is very common and widespread. Once we have an internal variable, we use that variable in all our methods instead of  this . We guarantee that it will point to the object it is declared in. Although this solves the problem, it is not very straightforward and may still confuse developers who are new to the concept.

Other techniques to solve the same problem are to use bind(), call() or apply() to change the value of this when you invoke each function. However, this moves the responsibility of supplying the scope to the caller and is not very good for encapsulation.

Arrow functions to the rescue

Designers of the JavaScript language and members of the committee working on the ECMAScript specification have noticed this problem, and they have provided a solution in the form of arrow functions. Arrow functions capture the value of this  from the enclosing context, no matter the caller. This changes everything (no pun intended). If we use arrow functions, we can just use this everywhere and our code will work.

No matter who calls the method, it will always log the Module object return value to the console. You can see that this feels much more intuitive than introducing variables to hold our context. Arrow functions can change the way we currently write JavaScript modules. The specification is not finalized yet, and currently there is no official support in any browser, but very soon you will be able to play with the new ECMAScript 6 features and take advantage of the new syntax.

You can follow how browser support for the different features of ES6 rolls out at this excellent comparison table:

Project Hosting Solutions: Another Comparison of Options

Ages ago, when this blog was still hosted on, I had written a post, comparing several project hosting solutions. Well, things have changed since then, and I have found a couple more that I want to share.

At the time I was working on a student project and all I needed was some source control. A project hosting service would provide much more than that, which I didn’t take into account at all. Now when comparing similar services, issues like integrated bugtracking, the type of source control system used and availability of private repositories are much more important to me than they were in my previous review.

Here’s a list of what I want no matter what:

  • Private repository (at least one).
  • Support for a distributed version control system (Git or Mercurial).
  • Integration with a bugtracker.

So the the following are four more project hosting services for anyone who needs an integrated solution with private source control hosting:


This is my personal favorite. Lately I’ve been reading about distributed version control systems (DVCS), like Mercurial and Git, and growing fond of them. I can say that I switched to using Mercurial for all my personal projects. Bitbucket is a service that gives you unlimited private and public source repositories based on Mercurial, with an integrated bugtracker for free up to 5 users. They also have other pricing plans for larger projects, but this is the best free offer you will find on the market. I’ve been using Bitbucket for a while now and these terms are new, after today they announced they’ve been acquired by Atlassian. Definitively a good bet.


A work of FogCreek software, which you’ve probably heard of (Joel Spolsky). Kiln is a system implemented on top of Mercurial, which adds some advanced features (not listed because they are irrelevant in the comparison). One good thing is that it integrates very nicely with FogBugz, a top-notch bugtracking tool. Please note that what I’ve used is the so-called “Student and Startup Edition”, which allows for unlimited space and number of repositories for 2 users. They provide a standalone Kiln client, but any Mercurial client should work (if you want tighter integration with your IDE for example).

Project Locker

Up to 3 projects, 500MB, 5 users – free. That’s their offering. The difference here would be that they offer Subversion and Git hosting, rather than Mercurial. If that’s the type of source control you’d rather use, maybe this is a better option for you. Github might actually be better known, but as of now they don’t offer a private repository for free, and that’s one of my primary concerns. The con I find about Project Locker is their speed and the clumsy and unfriendly web interface. They also only provide TRAC for bugtracking, and put ads on those pages when you browse, which is probably understandable, but still a downside.


This is what I used before I switched to Project Locker. The two are probably comparable, Beanstalk have a free account for 3 users, 1 private repository and 100MB of space. Subversion and Git are supported, but space is definitely a limiting factor here. The web interface is wonderful compared to Project Locker, but I wouldn’t use this for anything else than a test project simply because of the 100 MB limitation. Please note that they also don’t provide integration with a bugtracking service.

I’ve been researching services similar to the ones above for more than a year or two now, and the ones I mentioned are what I consider the best at the moment. Please share your comments if you’ve used some of them and have any particular impressions or know about another one I probably haven’t heard of. Until the next edition of such a comparison, happy coding.