Parse’s going down…

I was a bit shocked reading the following article.

Just choose to use Parse. Built an extension on it. Blogged about it. Loved it with all it’s problems.

It will be shut down not tomorrow of course but January of 2017 will be here soon. 😦

That’s how life works. Heads up! I will choose an other solution and of course will blog about migration from Parse and about the new solution I will use. 🙂


Browse Wisely – The Extension

bw (1)

Through the previous posts I wrote about my experiences developing an extension. Browse Wisely is the extension I wrote about.

Browse Wisely is published now!

You just need to visit the Chrome Web Store, download it and you can get the experience of smart browsing.


Browse Wisely have the purpose to help controlling your browsing habits. You can set rules not to spend too much time on selected pages.

Set block rule with a time frame and the extension will not let you visit the selected site. It will automatically redirect you to a random Wikipedia site. You can read the article and learn new things.

Set a warning rule with defining the site you want to monitor and the time (in minutes) to warn you after. If you spent the given time on the page you will be warned. You can navigate to TED videos. Sneeze the warning for 5 minutes. Restart the timer or dismiss the whole warning panel.


It could be a pleasure to see you between my users!

If you try it feel free to write me a comment or send me an email. I’m happy for all the feedback. If you find a bug or have thoughts about features I could build in write to me.


Links to know more about the extension

To try it out

visit the store and download Browse Wisely.

To know more about the extension

visit the marketing site of Browse Wisely.

To follow the development phases read the posts

about the extensions in theory and in practice,

about React tricks with TypeScript,

about the React development,

and about the Parse and login flows.

It will be open-source soon. The skeleton of it already available.

Parse + Login with Facebook

If you create an application you probably will need to handle users somehow. If your application is front-end heavy and didn’t require big, complex database or complex server side login, you don’t want to spend too much time developing it. That was my situation with my extension as well. I wanted only store some user data and the user’s rules. Rules to control their browsing habits. So I searched for an easy to use, fast to setup and a cheap solution. That’s when Parse come into picture.


Parse is a platform. A cloud-based platform that provides a complete backend solution for your application. Parse’s goal is to totally eliminate the need for writing server code or maintaining servers.

The Parse team is using striped 1000 Provisioned IOPS volumes for MongoDB clusters running on Amazon Elastic Compute Cloud (Amazon EC2) instances. What is very impressive to hear. You can read more about it.

But let’s see what it offers to you, to the developer:

Easy to use. It is just some click to create your first application. Creating some tables is easy as well.

TIPP : Adding data and creating some extra relations between tables are more than the Launchpad is capable for. You need to use your code to do that. Sometimes it is not just the easiest way you can find it is recommended by the developers of Parse as well.

Really well documented. The basics are all in the documentation. They have FAQ section with really good answers.

TIPP : Only thing what I couldn’t get from them is a really useful documentation about authentication with Facebook if it isn’t the basic way and third party authentications. But more about it later in the second part of this blog post.

Easy to observe. You can monitor all of your data on the Launchpad. It is easy to check, update and delete the existing data.

TIPP : If you open your app on the Launchpad, choose the Data section and see nothing don’t panic. It shows you always the Analytics tab first. Change to Core and you will get your data you wanted to see.

Easy to use in code. It provides a lot of SDKs and a REST API as well to handle data from any platform.

More. It can do so much more than I used it for. It can send push notifications, show you analytics about everything and more.

Handle growth. If your app grows bigger and require more logic on back-end you have the first option to write some cloud code. There are hooks to handle the incoming and outgoing data.

After getting bigger than this you have one more step not to leave Parse just extend it. The Parse Hooks API that makes it possible to use your own Node.js server in conjunction with Parse.

But if nothing is enough you can easily export your data into JSON. Build your own server side and fill your data into your database with parsing data from the JSON files. Each table with the containing data will be one file.

And not to mention it is free. Free for commercial use until your app will be so big that it isn’t a problem paying for the services.75689840-7165-4c58-a2af-eb8a06a27c20

It is in hands of Facebook. It can build trust and give some kind of guarantee if such a big company is behind it. Like in case of React. It is used and tested in such a big user visited site like Facebook. It is part of the Facebook Open Source Program.

TIPP : Parse’s Javascrip SDK is open-source. Checking the code could help so much if you can’t find or understand something.

Developing with Parse

Parse gives you a really cool REST API to handle data in the universal mode. But if you want to have something platform specific you have options too. It provides a  lot of SDKs. It has Android, iOS, PHP, .NET an so much more. Of course it provides a JavaScript SDK as well. But working with Parse in TypeScript isn’t a problem neither because it has typings available too. You can use a direct link or install it with TSD.

Not to mention if you develop a React application using Parse you get an extra customized SDK to React.

It supports everything we need to start developing our extension.

It is one line only to initialize:


Building blocks of it are the Objects.

Parse.Object contains key-value pairs of JSON-compatible data. This data is schemaless, which means that you don’t need to specify ahead of time what keys exist on each Parse.Object.


You can use your Objects through Querys.


ruleParseObjects is the container list of all the original Parse.Objects.

Objects have the save and destroy methods on itself. So if you cast your data to something else like me you need to handle the linking between the new objects and the Parse objects. I created an IRule object from the Obejcts given by Parse, passing only the data for my React components. So I saved in my parseService class the original Obejcts as well. Linked them with the object ids to the IRule objects.


TIPP : It is important to be careful with naming convention because Parse can’t handle it. It will create new columns in your data table if you misspell something.


It is so easy to use. The goals of this post was only to show you how easy to use Parse for simple problems. After knowing the basics of Parse let’s see the bigger problem that I used it for Parse as the solution. It was the login. It has three parts to get things work. Setting up Facebook, setting up Parse and hacking the crazy things of an extension.

Login with Facebook

Using Facebook logic didn’t come so obvious for me. If you are someone like me you neither like to give access to your profile for unknown applications. But I thought about it and something I more dislike is to register myself again for something new. Problems with giving a unique nickname or finding out a new password – sometimes with too strong requirements – and of course remembering all of that is more frustrating for me. So I decided to save this procedure for my users. Made their life with that easier I think. It is just few click to register and to login. Think about it. It requires only your email – for custom registrations it is also required – your name and sometimes some public data. Only public. Data, what is already available for everyone on the internet. Actually it isn’t so strange to do that from this perspective.

It could be of course not just the Facebook to login. It could be Google+, Twitter or whatever third-party login as well. But Parse gives you the Facebook login out of the box. I decided to lunch my application with it and after some user feedbacks or after a hundred of users I will work on adding other login providers to my app. Doing so isn’t so obvious with Parse.

But let’s see how I built Facebook login into my extension in. It wasn’t as easy as I first thought.

Creating a Facebook app is easy. It is really well documented. (As I mentioned it previously by React and Parse too – Facebook does this documentations thing good, makes developer’s life easier)

Register your Facebook app.

After having the Facebook account registered as a developer the next step is to register the url of your website for getting things done. The url of your extension is chrome-extension://iccdneeippnmcmbaekeoonkckkjhojfi/UI/Popups/index.html. It runs in the local environment of users installed your extension. It isn’t the url you could use. So you can’t register your extension as a web app / website.

Here comes the trick. You need to host a site with the scripts of the Facebook init and login. After that you need to add this site to your extension as a content of an iframe. You didn’t need to create a whole login site and change your extension’s login site to it. I created only a button for this purpose. An iframe with a size of a button and the site hosted somewhere only containing a button.

OK, I can login with Facebook now but how does the extension know about it? – could be a right question. Here comes the messaging system of the extensions into the picture. But let’s see the Parse part of the login first.

Parse part

Parse gives you Facebook login out of the box. After checking the tutorial on the Parse site you could reach an incorrect conclusion as I did. I thought first that I need to use the two together as it is in the examples.



After I logged in the user that way I checked what happened. I had the logged-in user on my site, not in the extension. I thought I can post the required credentials to the extension. I checked what are stored into local storage after the login process because I saw that the Parse.User.current() method operates with the data in the storage. So I passed the local storage data to the extension saved into the local storage of the extension. After reloading the extension it could link the session on Parse side with the local storage data in the extension. Sounds terrible I know and it worked only deterministic way. Sometimes not. I needed to find something better. A real solution.

This was the first time when the documentation of Parse couldn’t help at all. So I searched for similar problems and I could find something. There is an option to give credentials for the FacebookUtils.login method of Parse. It means you can handle the two login separated. Login your user first with Facebook and after that logging your user with the Facebook’s credentials into Parse.


This was the original code of Facebook to handle login and get some user data. This site and this code will be embedded into an iframe – into an iframe of the extension. So the easiest way to send message to the extension’s background page is getting the top window and sending the message from it. The receiver code which will use Parse’s login with passing the credentials is on the following picture.


So this is the way the user can log in with using only one button. With the button loaded into an iframe hosted on a separated site which handles in the background everything else. Logs the user with Facebook in, send the login data to the extension and login user from the extension into Parse leading to the authorized user using your extension. That’s the way you can succeed all the login from the extension. It was not so easy to find out but it’s simple and clean as the result.

Summary of Extension tricks

1, Extension itself doesn’t enough if you want Facebook or Google+ login. Both – and almost all other – requires an address of your site. So you need to have a somewhere hosted site. After having the Facebook website configuration you can’t trick with calling it from your extension. It only works with the origin site built into the extension with an iframe.

2, Login with two separated steps. Login with Facebook on the hosted site and send credentials to the extension through the messaging system of the browser. After that login with this credentials to Parse. That’s how you get an authenticated user in your extension on an easy and fast way.

React – The journey begins

You could hear about React in 2015 a lot. It is a new way of creating user interfaces. Fast and easy to use. Developed, supported and used my Facebook. Sounds good! Why don’t have a look on it? That was my thinking too when I decided that I spice my extension development with this new technology.

This post will be about the some basic knowledge and about my experiences with React. I don’t want to teach you with this post how to develop in React. I have no space for that here and there are a lot of good articles about it. I will show you some sites, where to find more about React. However I need to say only the documentation of it is also a really well written source for learning React. But let’s see my thoughts about React first.


Why React?

You can hear about it a lot nowadays. Check what the strengths of it are and what they mean for you.

It follows the functional programming style.

The real benefit of adopting a functional style is that our programs can be broken down into smaller, simpler pieces that are both more reliable and easier to understand. Functional programs should be stateless and immutable.

Immutable means that you should simply create new data structures instead of modifying ones that already exist. It is obvious by simple types but it need to be followed by complex objects and arrays as well.

Stateless, which basically means they should perform every task as if for the first time, with no knowledge of what may or may not have happened earlier in the program’s execution. In more concrete terms, this means that your functions will operate only on data passed in as arguments and will never rely on outside values to perform their calculations.


Virtual DOM

It is extremly fast. Faster then any MVC fremwork rendering method or faster than template engines.

Let’s see why.  The Virtual DOM is an abstraction of the HTML DOM. It is lightweight and detached from the browser-specific implementation details.

React includes a lightweight implementation of the DOM and events system. Manipulation of the in-memory representation of the DOM is faster and more efficient than manipulating the real browser DOM, and our events system implements all events in a cross-browser way, including bubbling.

It describes the actual state of the DOM.

You can think of template languages as a function that defines your data at time=0; with React, you define your UI in a similar way — declaratively — except it specifies how your UI looks at any point in time, not just the initial load.


If you change something it will be differentieted to the actual virtual DOM in memory. It is a fast operation. After that React will change only that part of the real DOM that actually changed. It isn’t a whole rerendering of the DOM.


Data flow

No more to way binding. If you change something you change the state and changing the state will trigger a re-render. A smart rerender as it was described in the previous block about the Virtual DOM.

Two way binding was a big thing of Angular. It was a cool feature but it has a big performance cost. Checking all the changes, the dirty values through an all time running digest circle isn’t a small amount of work in background.

I looks a cool feature but think about it. Is it worth it? Do you realy need that? It is maybe not so neccessary and you could live without it. Creating simplier user interface. Maybe you don’t need inline editable values in big list. Starting an inline editor – changing the show component to edit component – is what you could do instead and that’s the way of React.



JSX could be uncomfortable at first. A new syntax and why is HTML in JS? It’s from the Devil, you could think. But think again. Why is it better and more accepted writing JS in HTML than this? If you use Angular you write expressions and bind data into HTML what could lead to a lot of trouble. Misspelling something is an easy to do but painful to find thing in a programmer’s life.

JSX, writing HTML with JavaScript code together in a .js(x) file in any editor will make you sure not to misspell something.

But if you really are against it, you can write React code without JSX. Just in pure JavaScript. JSX is only a syntax sugar. It will be transformed from an XML-like syntax into native JavaScript.


Development environment

If you are ready to start developing you will find yourself having more options to start. It is up to you how you want to develop your React application.

TypeScript (+ gulp)

TypeScript compiler supports jsx syntax and the module loading of React. TS compiler in console is enough to do all the stuff but Gulp can make your life easier.

JavaScript ES5 or JavaScript ES6

If you are not familliar yet with the new features of ES6 or your project not in that stage yet you can still use React:


You can write your React code with ES6 as well:


Or use TypeScript like:


After decideing the language  and the version. You can use more than one infrastructure to build your application.

Webpack or Gulp

It is only the decision of your taste.

Webpack can handle all your needs using React with ES5 or ES6.

Check a tutorial for setting up your Webpack.

You can download packages for Gulp to handle everything Webpack is capable for.

A small tutorial about configuring Gulp.

It is really good to have more options. What is a little worse that you can find examples on the internet in all different ways. You need to check always what you are looking at. Which language which version.


My way of thinking


Thinking in React is different than in Angular. You need to think in small components. You need to think in as few controller components as you can and as small components as you can.

I was coming from the Angular world. This was my first project with React. So my thinking could be strange a bit but I write it down and hope it will help someone understanding the React development concept easier.

First I wanted to see the end result of my development. It inspires me to see what I want at the end. That’s why I started with the quick build of the html tags and CSS classes. I created my first screen with mock data. So I saw what I will get at the end. Than I ripped the screen into pieces. Into small pieces.

Started with the smallest components and stepped always one up in my component tree:

  • The smallest, simplest element of my site was a list item. Done.
  • It needed a container, the list. Done.
  • And I needed the page itself. Done.
  • On the page with an “add new list item” button. Done.

So I collected all the components What I at first sight wanted and wrapped them into an every time bigger container. Added the CSS to the elements. Be careful it can be done with “className” and not with “class”. JSX sytax handles it that way.

After all of this I started to add the logic. This happened in the reverse way by me. I collected what I needed at the top level. The page itself got the logic to fill the list and handle the add new element action. After I have the list of the elements from a service I pushed down necessary info to the lower levels. It comes with so much property passing. There are solutions to handle this passing process but for now I wanted to see how it works in a pure React app. If you want to skip this try out thing that I’ve done you can jump a big and use e.g.: Redux from the start. Redux is a predictable state container for JavaScript apps. You can use it easily with React together. But more about it later.

The main concept what I used was that build your HTML code from the smallest to the biggest and build your logic from top to bottom.

As I created this skeleton of course I saw that it isn’t so simple. One list item have more small components that could be outsourced for a new component with passing some data to them. But the main concept remained the same build your HTML code from the smallest to the biggest and your logic from top to bottom. Create a big controller component at the top level with a fat state and give only the necessary data through properties to smaller components. You not just handle data through this system. Probably you want to handle changes. Changes of element on the lop level but modified at the bottom, in a small editor component. You need to pass handler functions from to to bottom as well.

That was the logic what I used to create my first pure React app. That made me see that I really need something better, a better way to handle all of this passing down work.

TIPP : In JavaScript you can add constraints about the properties you require for your components. In TypeScript you can use interfaces to define this. At first I created my TypeScript components with the state and properties of „any” – no constraints in Javascript. It was easier and quicker. At first. But after I created the first skeleton I started to change „any”-s to predefined interfaces. It helped me handle the growth of my application.


Development components

This components are in TypeScript. You may not need them if you are writing your code in JavaScript (ES5, ES6). But I choose this way and can show only this kind of real life example now. These components are far not all you can use. These are the main components you will run into by developing a small application.


These are the main building blocks of your React application. It is an extended class. You have to handle the state, the props, the render function and all the lifecycle methods are available.

You can have private methods and private properties as well. All of these will give you an element that have a HTML representation and optional some logic.

Here is an example:



You can initialize your actual state in the constructor of your component. After that you can set the state any time in two different ways and all the changes of the state will trigger the call of the component’s render method.

setState({mykey: 'my new value'});

setState(function(previousState, currentProps) {
  return {myInteger: previousState.myInteger + 1};

If you change the state implicitly (eg: data deep within an object changes without changing the object itself) or if your render() method depends on some other data, you can tell React that it needs to re-run render() by calling forceUpdate().This will trigger the normal lifecycle methods and will still only update the DOM if the markup changes.


Properties are coming from the parent component as a constructor parameter of your actual component.


I will show you a small example of it in TypeScript

And here is the description of all the lifecycle events you can use. It is a short and simple description of them. Didn’t wanted to just copy paste it.

The documentation from the official site.


React is for UI handling. It makes rendering easy and fast but not cares about other things. Routing is something that you may need for a smaller app as well. Like for me developing a browser extension.

It comes to React as an additional package. You need to install react-router with npm. Include into your sources.

For TypeScript users there is a React-Router d.ts beside the JavaScript sources.

Using the routing is not so difficult. Just define your routing at first and you get the navigation.


TIPP : There is one typings for Routing if you use tsd install but you can get an extended d.ts for Router from this link.

TIPP : In some examples there is a context.router but instead you can use the context.history in TypeScript.

TIPP : Passing properties through the navigation is not an obvious thing. Look after this two options.

RouteHandler component. It can have properties that will be available for all the components loaded into the place of the handler.

Or something similar to this concept but a custom way. Writing a wrapper component as the route handler component and this wrapper component will contain the data you want to pass and gives access through properties to the contained component.

More info.


Flux – Redux

Flux is the application architecture that Facebook uses for building client-side web applications. It complements React’s composable view components by utilizing a unidirectional data flow. It’s more of a pattern rather than a formal framework, and you can start using Flux immediately without a lot of new code. You can find a lot of implementations of the flux architecture, e.g.: Redux or Reflux.

Redux holds your application state in one place, and defines a minimal but sufficiently powerful way of interacting with that state.

Reflux is a simple library for uni-directional dataflow application architecture with React extensions inspired by Flux. It takes the Flux approach and streamlines it, making it both easier to work with and easier to grasp.

I hope I will have time to refactor my pure React extension and integrate the use of Redux into it. Of course I will blog about it as well. So keep visiting my site and hopefully someday in the near future it will be a blog post about it.

But until then check these cool articles in the theme:

A compare of implementations.

A flux – reflux comparison.

A Redux article.

The official Redux site.



I really liked using React. These were my first steps. Maybe for a veteran React developer there were some funny thing but I will stay on this road and will deepen my knowledge. Hope that someday I will smile on this article too, but that’s how I started that’s the way I could adopt at first this new world and hope it will help you.

If you want something really fast working component I would use React. A component. As a developer it isn’t so fast to use. If you want to write clean and nice code in React you need to do a lot of refactor through your development. So much small iteration. If you find something that you could break for a smaller, dummier component you better do it. If you need a new object or just a property to handle probably you need to pass it down from upper – controller – levels to deeper to dummy components and writing the change handling of it and so on.

As I experienced writing a whole application in React (React + something flux) is complicated. Other usage of React could be that you writing components in React and using them in an Angular project. You get the whole infrastructure that makes your life easy and you can use fast rendering components. I will give a shot to that too, will try to replace a component in our huge Angular project. Seems as an interesting work to do. That will maybe a new theme for a later blog post. Check my site and you may see it published someday. J

These were my thoughts about React but I’m interested in your ideas and opinions. Feel free to leave a comment so we can discuss them.


Some sites I can recommend

React official site.

Functional programming @ SmashingMagazine.

React @ SmashingMagazine.

React getting started @ RisingStack

React best practices @ RisingStack

React goodies 1

React goodies 2

React with TypeScript



If you red my previous posts you probably know that I currently develop an extension in TypeScript.

For implementing the UI part of the extension I chose React. React because it is super hyped nowadays, I was interested and always good to learn something new.

About React itself and about the development details developing with React it will be an other post as it is planed. But I thought this part of my journey with React deserves a separated post.

Let’s see how I get together React and TypeScript for my extension.


Start getting TypeScript together with React


The release of TypeScript 1.6 includes support for React components.

That means you don’t need to use any module dependency handler, like Browserify to handle React modules.

It’s really nice. Let’s try it out!

You install typescript with npm:

npm install –g typescript

You check the version you have installed:

npm view typescript version

It is the newest. 1.6. Cool!

Try to use the tsc compiler with ––jsx or with ––project (including jsx handling as well).


The first problem


Do you have Visual Studio installed to work sometimes with that too?

Yes? – That’s the problem!

I work on Windows with WebStorm 11 but for other projects I have Visual Studio 2015 installed as well.

Visual Studio makes its compiler for windows as default. Command line will try to use it first.




Check your Visual Studio folder:

C:\Program Files (x86)\Microsoft SDKs\TypeScript

Does it contains any TypeScript versions under 1.6?  Yes?

  • Solution 1

Upgrade the Visual Studio’s TypeScript from here.

  • Solution 2

Just delete the older TypeScript versions.

  • Solution 3

Set an explicit system variable pointing to the npm installed version of TypeScript compiler.



Getting TypeScript together with React


After letting this problem behind you can try out the TypeScript compiler.

Install React and ReactDOM with npm.

npm install –save react react-dom

Install typescript definitions for them with tsd.

tsd install — save react react-dom

If you are using modules you should use react.d.ts, react-dom.d.ts and any of the react-addon-*.d.ts definition files.

Use them in modules you need:

import React = __React;

import ReactDOM = __React.__DOM;

If you are using the global React variable, you should use react-global.d.ts.

You need to download the react-global.d.ts file from the DT site and copy it under the typings/react folder.

Include React and ReactDOM in index.html. (From CDN or from your sources.)


Create your UI


Write your demo button .tsx file:

react from extension

If you didn’t handle page load in your code and include your scripts into the head, you probably will face the following error in your inspector console.

Uncaught Error: Invariant Violation: _registerComponent(…): Target container is not a DOM element.

A quick fix could be if you write your script tags at the bottom of the body tag. Handling all of this is better from code I think. I wrote it down just because if you see this error this is the fastest way to move on.

react from extension

Including scripts at this point of your site isn’t from the devil. With React you have the option to do that and you can read a lot of good thoughts about the benefits of including scripts this way.

Having to code is one thing you. You need to create a deploy-able package from your source.


Compile for publish


You can do it from command line manually with tsc. You only need a good configuration json.

tsc –project tsconfig.json

Or you can choose an automated way, using Gulp. Gulp could be good for handling other automatized tasks as well. In this post we will check only the typescript compiler task of it.

You need to require the TypeScript compiler:

var ts = require(‘gulp-typescript’);

And use the “createProject” method of it. It will create a configured project according to the settings in your json file.

The project’s src is defined in the files section of the json config file (if not all files will be included).

react from extension

Let’s see the magical tsconfig.json file that we could use for the command line compiler and for the gulp task as well.

react from extension

For all setting options detailed, visit the following sites.

Schema description. Just the facts.

Github wiki with more explanations.

If you don’t have a lot of options and you don’t want to outsource it to a json file, you can configure the ts compile in the gulp file as well.

react from extension


Run it and it will work fine!

Extensions – Practice

In the previous post you could read about the main parts of an extension. Short and just the definitions. Let’s see them in practice.


I used TypeScript for the development. We decided to choose this instead of the plain JavaScript because a lot of developer worked on the original project. There were a plenty of misspelling errors – figured out only in run-time and we had problems to keep everything in hand. We needed regulations a more structured and controlled environment for developing in JavaScript. That’s why we choose TypeScript to work with. I only get used to developing with it that’s why this project is in TypeScript as well.

Developing this way requires only a few extra thing to do.

  • You need to use typings (type definitions for JavaScript). The definition files of regular JavaScript libraries. But you don’t need to panic, because it is collector portal and you can find here a lot of typings for different libraries. – really a lot, I found typing for so small libraries I couldn’t believe it first. (:
  • You need to compile typescript files. But doing this is supported by gulp. You can easily add automation to do it with a single gulp library, called gulp-typescript.


Here is the structure for my source.


Well separated parts: Background, Content, UI, Manifest like the architectural parts of an extension + Common and Assets. Files in this structure will be explained in the following sections.

Other infrastructural elements of my solution.


  • Gulpfile for automation
  • package.json for libraries installed with npm
  • tsd.json for type defintions installed with tsd
  • gitignore for github
  • and dist for gulp-generated, package-ready files.


We have these parts: Background page, extension’s UI and content script.
What we have in common, they all communicate with each other.
Messaging connects all of them.

So for a good extension skeleton we need a good messaging system.

In my solution I built a base class for all my components that contains the mechanism of messaging. My implementation based on broadcasting.

From content scripts we send a message which one all the background scripts based on my baseClass will get but only the subscribed ones will handle it. One event could be important for more parts of the background components. Same from the extension’s UI.

Background scripts will broadcast their messages to the content scripts and UI scripts as well. UI scripts can’t communicate direct with the content scripts but through the background script they can. Sending the message from UI to the background script and forwarding from the background script to the content script that’s how it could work. 

Every base class have the same functionality.


In the constructor you pass the event handler of your actual component for the browsers event handler. Browser part will be explained in the next section – these are the common, browser independent parts.

You have this base class with two arrays for all your component’s classes. Listeners and pending responses. Storing them and checking them at every action will provide that you didn’t lost any message or reply in the extension’s messaging traffic.

As an example. I created the test file. It defines its event subscriptions in the constructor. Other classes extending the base class will have own arrays for all of that. Every component will know for which events they interested or for which ones not.


The actual ‘on’ subscribing method adds only this subscription to the array. Going through the array and checking which events to handle will happen if the browsers listener will get a message.


Sending a message will be the preparation of a well defined event package and the triggering of the event. Triggering is different in the different browsers that’s why it is only a method here, a method of the browser.

Browser & Component differences of messaging

As I mentioned all the base classes are only duplicates. In the code yes, but in every component we will use a different browser implementations. So we will have browser file for Background scripts, Content Scripts and UI scripts as well. First I will show you these differences. So the different browser implementations of the different components. After that I will show the actual browser differences, that are because of the two different browser, Chrome and Firefox.

Isn’t clear yet? – No problem. I will show everything in practice. I hope it will make things clear.

Background script:browser1

chrome.runtime.onMessage.addListener is the method of the chrome API to handle event subscriptions. If we get a message we will iterate through all of our subscribed class’s callback – remember base class passed in its constructor to the browser implementation – and call them with the actual event data.

Filling this array, the eventListeners array happens through the eventReceived method.


Sending a message from background scripts has two steps. Sending the actual message to the scripts in the UI and sending them to the content scripts. Both have different ways.


UI can communicate directly through the run-time with the background script so we can use it to deliver messages from one to other. But as I mentioned it in my previous post, Content scripts are not part of the extensions technically. They will get the messages through the actual page, into they are actually injected. We can get all the pages opened in the browser in our background script with the chrome.tabs.query and we can send the message to all of them. Only the page containing our injected logic with the event handlers will do something with the message the others will ignore it.

Content script & UI scripts (Popup):

Background need to use other method to send message to Content Scripts and UI scripts but they can get messages through the run-time and can use it to sending the messages as well in the same way.



The type in the sendMessage is for the browser. Extension communication go through  the type, message. In the payload we can define our type as well. Identifying our messages with our types/names.

UI scripts implementation is for popup types, not for panel types. It is differentiated in chrome. More about it you can find in my skeleton implementation.


Messaging in Firefox looks different. In background scripts you have to create a panel as the main component of your extension. It has a port, we can use for sending and getting messages.

In content scripts and UI scripts we have a ‘self‘ or ‘addon‘ object with the port or we can use the window object for sending and listening events. More about it you can find in my skeleton implementation.

Other browser differences

We need to hide more differences not just messaging. So little things like timeouts are different in the browser.

In Chrome:


In Chrome background scripts you can use a fully featured window object, but in Firefox you don’t have the timeout functions on that. You have a timers SDK to use for that.

In Firefox:


In Chrome you can use the chrome.* objects and methods.

In Firefox you need to use the underlying module handler – the built in CommonJs for getting the SDK’s libraries.


More feature that needs different implementations according to the actual browser will come. In the skeleton I needed only these ones. I think in later posts there will be more about this differences. Don’t miss them.

Extension bootstrapping

Bootstrapping the extensions are very different in the two browsers.

Chrome uses the manifest.json for all the things.


It will bind the Ctrl + B key-combo to start our UI. The UI will be the default_popup’s html. We define the background scripts and the content scripts as well. Chrome will know what to do with them.

Firefox have a few details in the package.json file.


It defines only the path of the background script and Firefox will use the background script and the browser’s SDK to create the parts of the extension.


You define here the panel and it properties. The icon (= button) in the browser’s toolbar. It handles the show and hide of the extension’s UI. Injecting the content scripts happens also here with the pageMod SDK library.

In case of content scripts the * defines that we want our script injected into every opened tab, we define the path of the script and we want to load and run the script on document ready event.

In Chrome (previous picture) matches: <all_urls> is the same with the * in Firefox. Js defines the path. Run_at is the same as contentScriptWhen. In Chrome we have an extra option to include our script not just into the page but into all of the iframes the page contains. Firefox uses other option to do that.


All the sources mentioned in this article you can find in my repository in github. You can check it:

If we are ready with the development we need a good automatized infrastructure to build the files and prepare them for packaging and publishing.

Automations with gulp

Developing an extension for both browsers. Chrome and Firefox. Without gulp could be very hard. Gulp task can help us make the right package for both browser with a little configuration and with parameterized tasks. Here I don’t have space to define what gulp is. Please let me speak about it so as if you would know the basics of this technology and if you didn’t, here are some good links to learn more about gulp.

One big difference is that in Chrome we can add more background scripts but in Firefox we can only define one file. So we need to concat all the background scripts into one.


Using TypeScript makes our work easier, but for packaging we need of course the compiled JavaScript. Gulp helps.


We can add our different browser files with the gulp task in our copy task but we need different path settings in html files. (If we don’t want to rename our destination files.) There is an option to do it with gulp as well.

We can define string patterns (with custom prefixes) to replace with value in that place too. In html I will define //@@browserFilePath and gulp will replace it with chrome.js or with firefox.js according to the parameter.

Now we have the already ready files to package them for the browsers. About packaging and and publishing I will write about later. I hope this much content will be enough for this post. But more info in this theme will be coming soon.

To be continued…

Extensions – Theory

Update: I started to write one post about extension basics but it grown too big. So I decided to write two about it. One about the theory and one about the practice. So this one will be more readable. I promise the other one will contain codes and minimal of talk. You can easily skip this one if you are familiar with extension basics and you are interested only in checking my solutions for developing one.


Extensions. Extensions everywhere. This was my previous half year about as I mentioned it in the previous post. It was a good intro to this series I think, so I don’t want to start it with telling stories. Let’s jump into the world of browser extensions.

This post will be about the extension basics, where everything begins:

  • What is an extension exactly?
  • Which browsers are we talking about?
    • Chrome and Firefox
    • IE and Safari
  • What are the extension’s cross browser and reusable parts and what are not?
  • How to start developing extensions for multiple platforms?

What is an extension exactly?

Extensions extend the functionality of the browser and the websites being viewed in it.” – this is the official definition of them.

Extension has little or no UI components. It isn’t their purpose to show a lot of information through visual elements. Their true power is getting and manipulating the tabs and their contents. That is what makes them sexy.

I think you already have some extensions installed. Maybe you didn’t know about them. Let’s check them in your browser.

In Chrome:

In Firefox:

Ok, you checked them. Maybe not so interesting ones (if you didn’t already use extensions). Check this examples:

One really good example is the extension of Evernote. It really uses the actual page’s DOM and makes cool things with it.

Another good one is Meldium. It uses more components of the API. Navigation, new tab opening, text injection and so on.

Now you know what an extension looks like and saw what they can do with your browser. And that was only the tip of the iceberg. But I hope you already started to feel that you need to create one. It is so much potential in one thing like that. Now what? Let’s google it. Let’s start searching for some development help.

Chrome Web app vs. Chrome Extension vs. Firefox Add-on vs. Firefox Extension

These could be the words you will probably find in this context. Which one? What I will create through this articles is something that is called in Chrome as an extension and in Firefox as an add-on. Your eyes work just fine. Chrome extensions are not equal to a Firefox extensions. Chrome extensions are the same as add-ons in Firefox. Firefox extensions are a smaller subset of add-ons with different functionalities. Nice isn’t it?

– If you develop for Firefox as well and search for something on the internet ALWAYS check that it is for extensions or for add-ons generally. Especially on the developer site of Mozilla. The two can use very different SDK-s in different contexts and you can just watch why it isn’t working. –

More about extension vs. app, add-on vs. extension:

Chrome app vs. extension

Firefox add-on vs. extension

I will develop simultaneously a Chrome and a Firefox extension. – I will write ‘extension’, but you know the term differences between the two browsers already.

IE and Safari have different concepts, installation process and have very different APIs to work with. So I skipped working on this platforms. Usage of this browsers is so dawn low.

Now we know what we want to develop. Let’s see what the bricks we can build with are.

Architecture of Extensions

What parts have an extension?

  • Manifest
  • Background page
  • Content script
  • UI pages (Panels and popups)

These are the terms in both cases, Chrome and Firefox. But of course it isn’t so simple. The meanings and implementation details of them are different in the two. This section will be about the definitions with some examples. We will see what are the similarities and differences between the two browsers handling the following components.


First of all we need a manifest file. It will be the entry points of the extension creation.

In case of Firefox it is only a sort description file. General info such as name, author… From development site the permissions and the main part could be interesting but the Background script will make the big thing, what is done in the manifest in the case of Chrome.
We have permission almost everything by default. Private-browsing, cross-domain-content and multiprocess options are the editable through this file. The “main” property defines our background script.

Manifest file of a Chrome extension contains a lot more info about the extension itself. It defines beside the general things the content scripts to inject into pages (what and how to do), same with the background scripts. It defines the starting page, the icon and browser action to show/hide our extensions UI (popup). Permissions here are very different.
We have access to nothing by default and we need to list every item that we would like to use.  “tabs”, “cookies”, “storage”, “activeTab”, “webRequest”, “webRequestBlocking”, “clipboardWrite” and so on.

Background page

The name of this part could be a bit tricky because background page especially didn’t need to have actual view – html part. It is the place for the logic behind the extension. It could be only JavaScript file(s) – so it is in my case as well. It has the access to the extension SDK and here can we do most of the work we want to do in the extension. It connects all the other parts of the extension as well.

Background pages have two kinds. One for long running task. We can use persistent background pages. I will use only them. But there is another type you can use so called event pages. Event pages are loaded only when they are needed. With them you can freeing memory and other resources. You will see in a later post why I need the persistent ones. But to change from one type to the other is only one property change in the extension’s manifest file. (


In the background you can write a reusable code as your business logic for both browser. Differences will come if you want to use the browser itself. There is a different API for the getting the chrome features as getting the Firefox’s one, of course. From setting a timer – setTimeout – to the sending a message to an opened tab in the browser. Background scripts in Chrome own a full featured window object. You can call the window.setTimeout easily. But in Firefox you have a window object with a reduced feature set. For setting a timeout you need to include the SDK’s timer lib. require(“sdk/timers”);

In Chrome you have the chrome object. Chrome.* functionalities are available for you by default. In Firefox you need to use require – Firefox have a built in commonjs infra to handle modules – to get the different SDK parts. More in the implementation details part.

After developing a while and if you start to check your extension in the browser you can check your extensions background page. It will help to debug your extension.

Where can you find your extensions background page?

In Chrome


IN Firefox


UI pages

These are ordinary HTML pages, styled with CSS and powered with some JavaScript. Most of the time these are options pages, which let users customize how the extension works.

We can see UI pages of the extension as small web pages and we could show some staff for the user but they are better used for interacting with the background part.

UI pages have 2 different kinds. One is the so called Popup. This is what the user get if he/she clicks on the icon of our extension in the toolbar and we show the user our standalone mini site.


The other kind of UI windows are the Panels. They will be part of the actual page of our browser. Standalone window elements, over-layers on the actual page. In Chrome the content of the panel will be part of the actual page, it will be loaded into an iframe. In Firefox they are standalone dialogs. Not parts of the actual page’s DOM.

Actually in Firefox panels and popups are the same, just otherwise positioned. Popups under the extension icon in the toolbar. Panels to whatever part of the actual page.

In Chrome, Panels and Popups have different behavior in background. Such as sending a message looks different from the two different kind of UI elements. In Firefox these are the same with the same behavior. Firefox uses officially only the term of Panel.

UI pages can be inspected in Chrome. As usual just click on the opened window of the extension UI and you get the Inspect Element function. In Firefox I couldn’t find the possibility to check it.

Content scripts

Content scripts are JavaScript codes that we can inject into the web pages, the user visits. This codes share the window object with the actual page, can read and change the DOM.


Content scripts are parts of the loaded page, not the part of the extension. But it have the ability to communicate with our background page through messages – it is a two way communication of course. They are our spies behind the enemy lines.

In Chrome you can see and also debug your content script.


In Firefox I couldn’t find this option, even with Firebug.

Documentations with more info

You can use for the first hand info the developer sites of Firefox and Chrome as well. Both are well documented. You can find a lot of examples and good descriptions about anything. Firefox documentation was a little confusing for me. Chrome’s was much better. But during the development I think you will find yourself reading both of the developer sites.


So these were the main parts of our extension. Short and just the definitions. Next post in this topic will be about my implementation details.

Check it too.