JavaScript in a modern web application

If someone asks you what is the javascript in modern web developer, probably you should answer it’s almost the half of the traffic of your site and it’s almost everything when dealing with user experience.

Today’s big web apps are useless without it AJAX/JS part. Think about Facebook, Google products, Twitter, Yahoo!, Youtube.

Actually they made this a standart. The times when you used to use JavaScript as a helper language just to figure out how a drop down menu will work are far way in the past. Now JavaScript is everything in a rich web sites. With no JS they will be no rich at all! Then it comes the question how to improve sites with lots of javascript. Actually one of the main problems in the web now is that JavaScript is blocking content.

Blocked by the JavaScript

What that means at all is that until the browser receives and parses the JavaScript file/s it doesn’t process anything else, it even doesn’t load any other resources. Now you can imagine how big the problem is. When it comes to large files more than 100K the user experience will be very bad!

Optimize the web? What about optimizing JavaScript!

If the problem is so big as I described above why should we doubt about where to start with the optimization process? But of course with the JavaScript and the natural question that rises is how this can be optimized at all?

Three steps

Like me, many of you may heart of some techniques that improve javascript performance. Here are some I was able to select as important:

1. minify/compress

That’s rule number one. If everything that is a JavaScript file is processed once it arrives to the client than make it smaller and make it go faster trough the wire. Actually one technique to speed up things more is to concatenated all the files you have into one single big file. Although this will not spend you some space will reduce the HTTP requests and therefore speed up the loading process. Good tools that you can use to minify javascript files are the Yahoo’s YUI Compressor, that beside that compresses CSS and Google Closure Compiler. Both are extremely useful and by the last measurements the Google’s Compiler is even better, but it’s up to you to decide which one to pick up.

2 .write fast and smart code

You can minify everything that’s JavaScript and the code may remain slow. But why is that? That’s because the JavaScript is written in a bad way. You know there are many resources in the web describing what is a bad and what is a good practice when writing JS. Even more you can measure it by yourself if you’d like to use the Firebug’s profiler. That’s a good start to avoid bad practices.

3. improve loading – lazy loading

That’s a bit more complicated. If there’s a really big javascript file after compressing and concatenating all the JS functionality remains big. How to avoid that? Simply let’s the user to see the most important functionality and than load the entire app. Some good tutorials about lazy loading again can be found online. Don’t hesitate to search about.

Beside this really basic advices I’ll continue to write in my blog about specific techniques how to improve the JavaScript as this is one of the most interesting parts of web development by me.

In the spirit of the optimization wave this post is about CSS optimization. There are some simple rules that you can apply. I’m pretty sure most of us have already been familiar with that list, but you never know.

1. Minify

As the JavaScript the CSS also can be minified. This only strips every character that makes the traffic bigger. As you know a well constructed and pretty looking CSS file consists of many new lines, tabs and spaces. Almost every software minifies the CSS by simply removing them. Some of the programs go even further with replacements of different parts of the code considered to be not efficient.

2. Use effective selectors

Some CSS selectors aren’t really efficient. Imagine something like: body div a just to describe only one specific link. That’s really bad. Better practice is to replace that line with something like a.my-class and to replace the a tag into the DOM with that class name. That will be far more effective. Actually if you’re wondering how to find such bad selectors, there’s a tool by Google called Page Speed that’s a Firebug’s plugin and can extract a list of all bad selectors.

3. Inheritance

CSS is really powerful when dealing with inheritance. That’s something that is not some clear but however really powerful. This technique is in the basics of the next rule.

4. Sprites

I’ve written already about CSS sprites. This is nothing new, but be careful when making a new site’s layout. CSS sprites spend you HTTP request and that’s rule number one according to Steve Souders’ list of optimization.

5. Separate logic

Sometimes developers put the site logic in only one file that become to large. Be aware of that. This is hard to maintain and you load things that you don’t need.

That’s a really short list of what you can do with CSS to speed the site up. I hope that can help someone when dealing with cascading style sheets.

Every part of Zend Framework is indeed very profesional and useful. But as it happens often some modules are less used than others. Don’t know why but my feeling is that Zend_Paginator, a wonderful tool for pagination is really misunderstood. And in fact it does one of the most common web development tasks. It builds the abstraction for a component that everybody uses in a web project – pagination.

It make sense if there where more tutorials like the following one describing its usage! Many thanks to Joey Rivera for a great tutorial about Zend_Paginator.

Even more this tutorials goes behind the pure usage of the paginator but it helps you understand the integration with one of the most used web apps today – Twitter and another Zend Framework component – Zend_Cache.

In most of the tutorials about Zend Framework the simple theory is described how all these MVC things may work together. However beyond that the things become more and more tricky and not everything is done by the MVC pattern itself.

What I mean is that reading most of the tutorials about ZF I found describing the simple relationship between controllers and views just by setting up a view member variable in the controller and than simply call that variable in the view of that particular controller action.

Setup controller’s view variable. In this example I used the default ZF IndexController – indexAction:

public IndexController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $this->view->greeting = ‘Hello World!’;
    }
}

where afterwards you can call this member variable in the index.phtml view in the index view scripts.

Note: In a typical Zend Framework installation all this is setup into the application folder (either web visible or not), where the IndexController.php file containing the code above is placed into the application/controllers and its indexAction stores its view in the application/views/scripts/index/index.phtml

In that situation the view file, the previously mentioned index.phtml should access this “greeting” variable in something like:

<div><?php echo $this->greeting ?></div>

Note that here you miss the ->view-> part of the chain. That’s because the view’s parsed and now this contains everything that the controller’s view member object contains.

All that is pretty cool and it works great until you start accessing and working with different type of data escaped or not, coming from various sources.

Natively comes the problem of escaping bad strings and the single question is why should I do that? To give you a simple example I’ll describe the above code in a different manner.

Imagine you should setup a browser specific title depending of the controller/action you call. To do that is simple but there comes the tricky part. In the example above we can just change the code a bit.

In the controller you can setup the browserTitle variable:

<?php
class IndexController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $this->view->browserTitle = “Welcome”;
    }
}

Than normally in the view you may have something like that:

<html>
<head>
<title><?php echo $this->browserTitle ?></title>
...

Everything until that looks normal and you don’t need to escape whatever as it appears. Even if the browserTitle contains something with quotes:

...
$this->view->browserTitle = ‘Hello ”World”’;
...

This will result in the browser’s source view as:

...
<title>Hello “World”</title>
...

see the image below:

But what if you setup a meta title tag:

<meta name=”title” content=”Hello “World”” />

for the browser that’s an error as shown on the image:

There’s why you simply should be careful when dumping variables all over the page and to use the native ZF escape function.

$this->escape()

In the example above you simply can call the escape function into the view:

<html>
<head>
<title><?php echo $this->browserTitle ?></title>
<meta name=”title” content=”<?php echo $this->escape($this->browserTitle) ?>” />

That will prevent the browser to “crash” and of course and more important will improve the site’s SEO.

Why you should do that?

First of all what’s a link shortener? Such online software exists and it’s widely used by the customers. Sites like bit.ly became extremely popular because of the growth of web apps like Facebook and especially Twitter. The simple goal that they achieve is to convert a long website uri into a short unique one. Beside that they give more information about who clicked that link and some useful stats along with that.

The question is why to make your own link shortener? One of the main reasons why is to paste links containing in plaintext your domain. In the case of http://stoimen.com instead of using http://bit.ly/xxxxx it will be great if the link was something like http://stoimen.com/xxxx than pasting it into Twitter or wherever I get the primary impression of my domain.

How to …

It should be no mystery how to make your own. In fact you’ll need only one more table into the database, as this is the most common way to achieve it. Of course you can do that with no database using the file system to store the hash table in whatever format you’d like.

In the case of the DB solution you can simply make a table with three columns containing the unique id of the row, the short and the full link. Thus requesting some short link the db will return the “real” full uri. You can simply drop the short column if you’d like more efficient solution. Thus the unique identifier may become short link. That may be really fast if you’ve an index on the full link column.

See the example below:

id | short_link | full_link
1  | qwrt 	| /blog/2010/01/27/theory-of-caching-zend_cache-zend-optimizer