What Went Wrong with Web Design?

And what can we do to stop it? Standby.

First off, I’d like to start with the fact of what a website is. A website is nothing but some HTML passed in from some server. That’s it. The code that comes back from the server is static. Believe it or not, what ends up on your browser, is static HTML. The browser interprets the text that comes back from the server, and spits it out on the screen after it interprets it.

CSS and JS

If you see bells and whistles, without the page reloading, re-requesting more from the server, hover overs, text changing on the front end, that’s all controlled by some DOM manipulation. JavaScript and CSS are good at doing that. :hover and getElementById('id').innerHtml('newtext') are the secret. The good thing is that this code is available right away to use, and you can usually pipe it in additional .css and .js files loaded in the header, and/or footer.

Add Some AJAX

A great thing that JavaScript does is that is has the ability to send a request to a server, without having the browser reload the entire page, its header, rebuild its DOM, etc. That way you can really make your pages dynamic with fresh content and make it so much faster.

Here’s where it went right

The advancement of CSS2 and CSS3 has been a great release of burden on the JS engine for many of the bells and whistles. Transitions can control animation, canvas and video embedding has become a great solution for making things look pretty. jQuery, along with other JS libraries, have come along and have made the JS work easier for developers. No longer does an ajax call take 12 lines of code. I can be done in as simple as 3-4 lines. jQuery did not come along to complicate things. Let’s get this part straight.

There was MooTools, Prototype, YUI, Dojo, and many other. Why did jQuery survive? Intuitiveness to developers. It was easy to use. It was not confusing. It had decent documentation, even though it was mostly used for quick reference until you got the hang of things. But it wasn’t rocket science. With “frameworks” coming out for JavaScript these days, it just sounds like a lot of complexity for programmers who already know what they’re doing to tailor to those who have no clue how to program the proper way, and need a complex and restricting hand to hold them so they don’t color out of bounds. Yes, I’m talking about angular.js. What a bloated monster. I wonder how websites were build using just jQuery up to recently… Hm…

Here’s where it went all wrong

So, some graduating engineer students decided that a webpage was not a webpage after all, and that they needed to mess with code in order to make themselves feel better and feel more at home writing complex and overly engineered code. Then, they got lazy too. Let’s throw an out of the box framework. The boss will be impressed how quickly we can get a prototype going. And with that, the backend became constrained. No longer could you do whatever you wanted with a webpage. Now it had to follow certain paths and load every single file, even though you didn’t need to load it. This slowed down websites everywhere, because, well, autoloading does that. So what to do? Throw caching at it. So instead of realizing the problem that you’re using a framework that does not need to be used, you’re going to take what was once an exception, and make it a necessity. Besides, doesn’t caching make static files and data? How is the website dynamic anymore? Well, we’ll just delete the cache when a change is detected. So, more complexity in order to deal with the original issue of leaving the freaking webpage be a webpage.

Now you have two additional layers of maintenance to handle. Framework (which needs to be learned and experienced), and caching, which I personally know to have caused a significant number of errors throughout my development years.

But that wasn’t enough… What if we plan to change our database in the future? How are we ever going to be able to do that? Go through all of the lines of code with MySQL in them? No… why do all that work when we can throw another layer of abstraction on top? ORM Database Management. As if your website wasn’t slow as it was, let’s throw this bloated level of complexity on top of everything else that will make sure to have you spend thousands of hours re-learning how to write MySQL queries, or whatever it is that it uses. Let’s take Propel for example. Every single part of a SQL query has now become a PHP function. Talk about a waste of CPU Cycles. How often is it that you change databases? If you change your database once a year, there’s something very wrong with the architecture of your site.

Lack of documentation

Tell me you haven’t heard this a million times: “The code should comment itself”. What kind of absurd, lazy, half assed remark is that? I remember in the good ol’ days of designing a system. You should spend 1/3 of your time designing the system. 1/3 of the time implementing it, and 1/3 testing it. It seems like these days, we’d rather spend NO time on the system design, 150% of the time development, and the rest of your life QA and maintenance. There’s something very wrong with that concept. My grandfather had told me something that holds true even today. “Haste makes waste”. If you rush to get your project in front of your boss and impress him or her, you’re going to have to do a half assed job. And of course, they’re going to love it so much that instead of starting fresh to do it right, you’re just going to build on top of the prototype. And then we wonder how things got so bad. All in the name of pleasing someone else, at the risk of creating something that will break.

Take your time, and do it right.

A Custom Framework

The framework should be something that your code naturally evolves into, not something out of the box with instructions on how to do everything. How did the original creator of the framework know exactly what I was looking for? They didn’t. They made the framework to be a quick out of the box solution for themselves, and thought, hey, others might like this. And BAM, one after another, junior developers and lazy developers alike downloaded it, installed it, and now we have something that we can’t customize without breaking the barriers of the framework itself. You don’t believe me? Try setting a cookie and a session variable in Symfony2 at the start of a page. Oh, you can’t? Hm… That sucks. Well, time to whip out the good ol PHP code on its own.

How to do it right

Build an index.php file. Done. Build a header file and a footer file. Done. Build a css and js global file. Load them in your header / footer. Done. I would prefer to load JS in the header because it makes for better DOM handling within your rendering code. A rendered page would be aware of the $ jQuery object if you load your jQuery in the head.

Now that you have a one page site, make another site, and load the header and footer in that one too. Done, you have two pages. Now you can make even more pages.

Next, let’s make those URLs friendly. Modify your .htaccess file a bit and make all .html calls point to respective .php files. SEO and friendly looking, done.

So you have a very simple custom framework that doesn’t require loading hundreds of modules, models, views, helpers and God knows what other crap.

Need a global function file? Make it! Store it in a /extra folder, call it reasonably well, functions.php and start writing some functions in it. Load this file on every page before your header file. Call it a pre-header. this is before any markup is rendered. Use common sense. Store functions in here that are globally necessary. Things like database connections, input validation for emails, random password generators, number formatting (to add a 0 before a number if it’s less than 10), etc. You will need these globally, and when you need them, you don’t have to hunt for them. They are in ONE file. This file should never grow over 1000 lines of code.

If it’s too complex, it’s probably wrong

My last argument is this. NO SITE should be considered too complex to navigate, or construct. If it is, it’s probably too complex and needs to be re-thought and re-done. If your code is spaghetti, please, please, please, re-write it so anyone coming on board can easily understand what’s happening and they could trace the code easily just by starting at the index file and the htaccess file.

Growing your site to application level

Need a profile management page for your users? And admin section? A module that’s a one page app? Notice. I’ve mentioned three different things here. An admin section is not a module and it’s not a profile page to be managed. A profile page could easily be a one page form that the end user can submit. A one page app module can be a series of php, js, css files in one folder, routed through your .htaccess file. An admin section could simply be a collection of files and modules that serve the purpose to look through data on the site. Unfortunately, lately, all frameworks treat those three sections as sections of the same type. They’re all modules. That’s such prejudice. How can you say you care about your site and treat all its components the same? Not fair.

Conclusion

I just have to say that sometimes it’s good to go back to the basics and realize that even a house needs blueprints for a reason. Taken straight from the Wikipedia:

“Occam’s razor (also written as Ockham’s razor and in Latin lex parsimoniae) is a principle of parsimony, economy, or succinctness used in problem-solving devised by William of Ockham (c. 1287–1347). It states that among competing hypotheses, the one with the fewest assumptions should be selected. Other, more complicated solutions may ultimately prove correct, but—in the absence of certainty—the fewer assumptions that are made, the better.”

After all, aren’t we all essentially problem solvers?

In the end, the only thing that will matter will be the HTTP requests done by a page, and how fast your content loads in a browser. I think this is the goal that google has in mind. That’s why they try to make people develop pages that run smoother without the complicated bloated code.

On the backend, the simpler the better. Understand that it shouldn’t be rocket science. Programming should be as simple as loops and conditionals. That’s it. If it gets more complex than that, it’s wrong. If it needs to repeat, loop it. If there’s business logic, condition it (pun intended). The rest is as simple as getting data from a database (data files), and rendering them as HTML for the browser.

Respect the browser!

PHP Frameworks Suck

It’s kind of funny. After trying to understand Zend 2, I decided that I was happier with Core PHP. I noticed that anyone can pick up any framework and learn it in a few days, or even a few weeks, but to master it, you really need to spend a lot of time with it. I’ve spent 11+ years with PHP at the time of this writing. I know PHP.

Why have any framework? For most do it yourself type projects, just build a website from the ground up. You already have 4 great layers (Apache or server, MySQL or Database, PHP or backend language, and HTML, CSS, JS all in one). This looks like a LAMP stack to me. Why do I like keeping it this simple? Well, you don’t “need” anything else. Really. This is all you need to build anything. And I do mean, ANYTHING! You name your project, and i can build it.

My only caveat is jQuery. I’ve gotten used to it over the years, and in a way I wish I could go back to plain JS. I mean, for the most part, I still use JS, I just use jQuery for selectors / DOM manipulation, events, and the ever so simple to use ajax function. The main reason I use jQuery is because, otherwise, I would just write my own functions to do all these things. jQuery just makes sense to use.

My next task is to convert all my jQuery into JS at some point. Why? Because that’s what the browsers understand. The browsers don’t understand jQuery, or angular, or LESS or SASS on their own. They need pre-processors and libraries to convert all that.

This brings me to my other point. The backend should be no different. PHP is what is already installed on the server. Running PHP code in your files speaks directly to the PHP installation on Apache. You don’t need additional overhead to make things work better. Write PHP, done. You can structure your PHP in logical functions to make it work for you, such as getMeSomeData(), or renderThisHtmlBlock(). But that’s it. At its core, PHP is a great and most opened and powerful framework of all. Why add so many layers of abstraction on top of it?

My next good practice is to write MySQL directly into my php code. Why not? That’s the fastest processing you’re ever going to get without involving overhead. Use propell? Why? Just so you can stack php functions that eventually build out what you meant to say with MySQL anyway? Again, more layers of abstraction? What’s the point? Because it doesn’t “LOOK” like SQL? Is that really a valid excuse? Learn some damn MySQL like a good programmer, and remove all those PHP overhead functions to keep your site optimal.

It’s not what you use, it’s how you use it. Developers have become so lazy over the years, and no one cares about code itself. They treat it like they’re bored of it and just need to add layers of complexity.

The only thing that matters is how the client side performs. All of my projects’ pages load faster than 2 seconds, out of which most load under 1 second. In the end, that’s what matters. And, the turnaround time for most of my development is minutes, not days like most projects dependent on builds.

And I simply don’t want to discuss things like memcached, composer, ruby (for SASS), or any other dependency that’s simply not necessary. Are your websites fast? Then, that’s what matters. I worked at this one company where they would be concerned with micro optimizations such as to use array brackets instead of array_push function. At the same time, they were using propel that would run through dozens of php functions to get data, and their pages were loading in over 4 seconds, with unoptimized images, and over a hundred http requests. I just don’t understand this sort of mentality. These things should matter no matter if you are running an SEO site, or a private LAN intranet. Users will complain when your site loads in over 2 seconds. That’s a rule.

I’ve built many systems over and over and over only to come to the same conclusion. Simplicity just works better. Ask Steve Jobs.

Zend 2 For Beginners Step 2

All right, guys. In response to the Zend 2 For Beginners post, I thought I’d carry on and show more on how not to be afraid of Zend 2.

If you find yourself frustrated with frameworks as I was a couple of years ago, don’t lose hope. A lot of the frameworks out there have evolved to the point where they’re very manageable. If you’re like me though, and want to do pure PHP on your own projects, no one is forcing you to do Zend. And no, using Zend doesn’t guarantee that everyone who will use it will be a better coder, or that your code will be cleaner, or faster. In fact, it takes 10 times more of the processing power to render out a zend call than a pure php call.

But, if you’re involved in working with others on Zend, I’m writing this to show you that anyone with a bit of programming knowledge can pick up Zend 2 and go with it. Simple.

Let’s start!

Here’s the structure you will need for the basic module. The bare essentials to just render out some text.

1
2
3
4
5
6
7
8
9
10
11
12
13
modules
|-- Articles
    |-- config
    |   |-- module.congif.php
    |-- src
    |   |-- Articles
    |       |-- Controller
    |           |-- IndexController.php
    |-- view
    |   |-- articles
    |       |-- index
    |           |-- index.phtml
    |-- Module.php

Don’t be scared. this is only 4 files if you look at it carefully. Yes, it’s a lot of folders, but it’s not a lot of code. Yes, clean PHP could do it in one file, but there is a lot more to worry about as far as keeping track of all of the including, etc.

So, now, let’s look at the first file: The Module.php off of the module root folder:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// /module/Articles/Module.php
// This line defines our namespace. The place where our module resides. Keep this the same name as our module.
namespace Articles;

// Name our class, obviously.
class Module
{
    // this is to load our configurations for routes, etc.
    public function getConfig()
    {
        return include __DIR__ . '/config/module.config.php';
    }
   
    // this it to load our source files (namely, our controllers).
    public function getAutoloaderConfig()
    {
        return array(
            'Zend\Loader\StandardAutoloader' => array(
                'namespaces' => array(
                    __NAMESPACE__ => __DIR__ . '/src/' . __NAMESPACE__,
                ),
            ),
        );
    }
   
}

And that’s it. Basically, this file tells us to load our module configuration and autoload any controller files we may have.

The next step is to look at our config file.:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// /module/Articles/config/module.config.php
return array(
    'router' => array(
        'routes' => array(
            // this is going to be what we call our route. It's a good idea to keep it the same name as our "link"
            'articles' => array(
                // Yes, this time, were passing in an exact match for the route. No parameters, no trailing slashes, done.
                'type' => 'Literal',
                'options' => array(
                    // Finally, this is what the URL should say to access this route.
                    'route' => '/articles',
                    'defaults' => array(
                        // And of course, we define our default controller and action.
                        'controller' => 'Articles\Controller\Index',
                        'action' => 'index'
                    )
                )
            )
        )
    ),
    // Specify our controller shortcuts (from the controller above)
    'controllers' => array(
        'invokables' => array(
            'Articles\Controller\Index' => 'Articles\Controller\IndexController'
        )
    ),
    // and, finally, where to look for our main file when the /articles link is hit.
    'view_manager' => array(
        'template_map' => array(
            'articles/index/index' => __DIR__ . '/../view/articles/index/index.phtml'
        )
    )
   
);

Simply put, this code above will direct any calls that come in to the right logic in the code and the right template file to use when rendering.

Next, our Controller file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// /module/Articles/src/Articles/Controller/IndexController.php
// Our namespace to define module and usage
namespace Articles\Controller;

// load this for basic controller functionality
use Zend\Mvc\Controller\AbstractActionController;

// define our class for this Controller
class IndexController extends AbstractActionController
{
    // And... define our main action.
    public function indexAction()
    {
       
    }
}

And that’s it with this one. Basically, the route points to this controller to do any sort of logic, or business logic, and calculations before sending stuff to the template for rendering.

And last, but not least, our view file!!! Yay!

1
2
<!-- /module/Articles/view/articles/index/index.phtml -->
This is my Articles Index file.

That’s it. There really isn’t much to it. This view file will produce a comment of the location and some text that mentions that this is my article index file.

If you could resist through this tutorial and the previous one, you can pretty much build your own Zend 2 modules. Yes, there’s a lot more to learn about Zend, which I’ll slowly be covering in other posts, but for now, to get you started to understand how everything is pulled into Zend to render out some simple pages, this is all you need.

I’m also going to teach you how to load scripts and css files into the header. That’s going to be fun. And later than that, I will be covering AJAX calls and partials.

Don’t forget to remove the /articles route from your Application module. 😉

See you next time!

Angular JS Kinda Sucks

UPDATE: 7/11/2015

It’s apparent to me that there needs to be more of a focus on architecture and not as much frameworks. Learn how to do it and why you should do it before you can just assume that throwing a framework will just magically fix anything ahead of time.

UPDATE: 4/3/2015

I feel like I have to clarify for the people who keep trying to explain that jQuery is not angular.js. No duh! I’ve learned that over the years. However, what people don’t seem to understand is that I’m not comparing angular.js to jQuery. I’m comparing the difficulty to lean angular.js to jQuery. With difficulty in mind, I read an interesting quote the other day: “More entrepreneurs than ever before will enter this booming market with limited coding ability and they will need something other than [insert preferred framework / language here]”.

And now for the original post…

Ok, so I ran across this angular js framework and looked it over, tried to duplicate some functionality that I already had existing with jQuery, and was not impressed.

First of all, I can do anything in jQuery, and have full control. Full control of the selectors, HTML, the DOM. I like that. I like knowing what I’m doing and what’s happening in my application. Somehow, angular fails to let me know what’s happening behind closed doors, unless I go dig into the code itself. Hm. Never had to do that with jQuery.

+ jQuery

The documentation is just plain horrible. Basically, it comes down to how basics work, not how you can and should build an application, even though they stress that you must first architect your application before you build it. Architect it how? Are there examples? Some nice examples would be of projects that are relevant to the outside world. Data manipulation? Dynamic AJAX driven application? It just seems like a lot of hype because it’s the “cool” thing to do and everyone is doing it. Well, not everyone. About 0.1% of sites out there use Angular, while well over 55% of websites use jQuery. Most of the documentation is just hard to understand without explaining the parts of the application or explaining the magic behind the app, or even explaining why I’m naming certain things the way I name them. Anyway, just confusing.

+ jQuery

Which brings me to my final reason for not liking it. Intuitiveness. It’s not intuitive at all! If you know JS and jQuery, everything is build so you can just figure things out. .show(), .hide(), $.ajax({stuff}), $(‘whatever selector you want full control of here’).doThings(). It’s easy to read, just like OOP. In angular it feels like you’re looking at fog. ng-this, ng-that, and now you have to assume that somehow everything is aware of everything else on the page. WTF?

+ jQuery

Speed of development? Hardly. We had some experience with it at work where some front-end code was handed down to be integrated by back-end guys, and… well… everything broke. Why? The back-end guy knew only jQuery. Now, he has to spend additional time and resources to learn angular, and the learning curve is STEEP!!!! And once he learns it, maybe someone will come up with another stupid framework that will do exactly the same thing jQuery does, only more abstract. Can we get practical with our development, stop being such lazy-ass programmers, learn to code properly, and stop complaining about how working on something feels like work? Beware of lazy programming and short cuts to faster deployment schemes. Sounds a lot like get rich quick schemes. How well have those worked out so far? Is everyone rich yet?

+ jQuery

Just not for me. Might be for you, but for me, I stand by the saying, “If it ain’t broken, don’t fix it!” And jQuery is definitely not broken. It’s by far the most favorable, intuitive, powerful “framework”/library to date. It’s not a hula hoop. It’s a cellphone.

Updated on Feb 27th, 2014:
After attempting to look through documentation and examples on stackoverflow, I’ve come to the conclusion that I’m much happier with jQuery, for the simple reason that I know how to use it and it does everything I’ve ever wanted, because it’s a tool for short-cutting a lot of mundane tasks that JS threw at us. .each() loops, .ajax calls, class selectors, very easy to understand and build on top of. After looking at many examples of angular implementation, I’ve noticed a pattern of jQuery being used on top of angular. Obviously to take care of the many things that angular can’t. It seems to me that performance wise it wouldn’t be smart to use angular, simply because it would be additional bulk on top of your programming. It doesn’t complement JS, it complicates it by changing the rules, and way of thinking. jQuery respects JS and complements it greatly. So…

+ jQuery

If anyone has the solution to how they would take care of the example I’ve created using jQuery with angularjs here, I would love to read it.

Clear floats with overflow: hidden

Lately, I’ve seen a trend of programmers adding on new elements to pages in order to add a class to them to clear all of the floated elements in a container. Why? Simply use overflow hidden on the parent, and like a miracle, bam! The container becomes aware of all of the children elements.

The old way:

1
2
3
4
5
6
7
<ul>
    <li><a href="/">Text</a></li>
    <li><a href="/">Text</a></li>
    <li><a href="/">Text</a></li>
    <li><a href="/">Text</a></li>
    <li class="clearfix"></li>
</ul>
1
2
3
4
5
6
li {
    float: left;
}
.clearfix {
    clear: both;
}

The old way is not as effective, since we have to add additional elements that do not show anything. Their only purpose is to fix a css style. Why not do it in css? This method also adds what seems like an additional line that makes it seem like you have bottom margin, or padding. Too much to maintain and fix. Additionally, I believe at the time of this writing, google looks for empty elements and dings you if you don’t put anything in them. Validate your HTML. Be a good programmer.

The new way:

1
2
3
4
5
6
<ul>
    <li><a href="/">Text</a></li>
    <li><a href="/">Text</a></li>
    <li><a href="/">Text</a></li>
    <li><a href="/">Text</a></li>
</ul>
1
2
3
4
5
6
ul {
    overflow: hidden;
}
li {
    float: left;
}

Who’s JSON?

J. S. O. N. Actually

Not sure where I’m going with this, but here we go. I like JSON (JavaScript Object Notation). What’s that, you say? You mean, who’s that? Oh, wait. No, it’s ‘what’s that’.

What I’d like to start with is something experimental. Let’s focus on the idea that there is a back-end, and a front-end to any development, especially web development, and especially web application development. What if both sides could simply just communicate with itself via JSON. Why JSON? Because JSON is super light weight for transferring data. What kind of data, you ask? Any kinds. Sure, we could render out code via an AJAX call as HTML, but all those little extra tags are overhead. JSON keeps it simple with only one or two additional characters per variable or value. Let me show you what I mean.

1
var myObject = { "person" : { "fname" : "John ", "lname" : "Donson"} };

Notice what happens in the block of code above. I’ve specified an object with enough information to arrive at the conclusion that this data is related to a person, and their name is John Donson.

jQuery can easily do this JSON encoding from arrays, strings, etc. You just need to pass it the variable:

1
var myObject = $.parseJSON( '{ "person" : { "fname" : "John ", "lname" : "Donson"} }' );

Please note that I’m using double quotes inside the object itself. This is proper JSON format. Escape any single quotes with backslashes. This gives us an object that we can easily inspect in the console log of Firefox.

All right, now that we understand who JSON is, let’s have fun with him.

HTML5 Kicks in

Wouldn’t it be great if we could use HTML5 to send some data to JavaScript who can in turn send the data to the backend (PHP), who can then get some data from a database and return back some JSON code that we can use back in JS to manipulate elements in HTML5?

Wow, I mean, why even go down this road? Simple. Large amounts of data to be processed. PHP may be fast at 300 requests per second, but HTML is even faster, with 1000 requests per second. The idea is to develop for online applications. Such as, a game, or management systems.

Let’s start from the top. Here come’s < a >.

1
<a href="javascript:void(0);" class="jsonCall" data-get='{"url":"/ajax/main.php","data":{"var1":1,"var2":2}}'>Click me!</a>

Whoa, why all this? Let me break it down.

– The void call in the JS call is to make sure older browsers don’t show a white page when clicked.
– We’ve added a class because we want to identify any element with an action. Doesn’t have to be an < a > element.
– data-get is our HTML5 way of introducing data that we will need. This is our JSON data that we will send from JS through our AJAX call.

Let’s see where this takes us.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$(document).ready(function(){
    $('.jsonCall').on('click',function() {
        var queryVars = $(this).attr('data-get');
        var qJSON = $.parseJSON(queryVars);
        var qString = "internal=true";
        for (data in qJSON.data) {
            qString += "&"+data+"="+qJSON.data[data];
        }
        $.ajax({
            url: qJSON.url,
            type: 'post',
            data: qString,
            dataType: 'JSON'
        });
    });
});

This is the entire code we need to parse out our data-get attribute value and send it out for processing. Let’s put what we did into practice.

Practice Makes Improvement, Because No One is Perfect

Let’s say we want to load a list o thumbnails with descriptions and links to another page. So, let’s set up the scenario.

What we need:
– link
– thumb
– text

There’s the classic way and try to render everything out on the backend, and spew out some static html that can be placed inside our “container” whatever that container will be.

Why not make it smarter, and just send a request for the items you need. Let’s say you need 16 thumbs because that’s how many thumbs will be on the page at once. Yes, you can always change this number, but 16 is perfect for a 4×4 display of thumbs.

First, we need to understand what our content might look like. It will probably look something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<ul>
    <li>
        <a href="">
            <img src="" />
            <span></span>
        </a>
    </li>
    <li>
        <a href="">
            <img src="" />
            <span></span>
        </a>
    </li>
    ...
</ul>

Ok, it will be a little more intricate than that, but here’s the reason to load your content with JSON. All of this above is simply overhead. None of our data has been loaded yet. There IS no data! So, with all this effort of rendering out, we got back a big fat nothing.

Why not templat-ize the results? It would make much more sense. Why not load the template HTML content inside our current document so we can just use it? Since it will be used anyway on the page, load it up, but keep it hidden.

1
2
3
4
5
6
7
8
<script id="content-list-item" type="text/x-jquery-tmpl">
    <li>
        <a href="[[url]]">
            <img src="[[thumb]]" />
            <span>[[text]]</span>
        </a>
    </li>
</script>

This would allow us to get the content via the jQuery.html() function, replace the values inside the double brackets, and append this element to the container.

Doesn’t make sense yet? Let’s compare the old way we used to do things. If we had a loop of items on a page, we would render everything at the php level right after we got the data.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
$qty = $_POST['qty'];
$retVal = array();

for ($itemCount = 0; $itemCount < $qty; $itemCount++) {
    ?>
    <li>
        <a href="http://www.motortrend.com/roadtests/oneyear/coupe/1302_2013_scion_fr_s_arrival/">
            <img src="http://i2.squidoocdn.com/resize/squidoo_images/-1/lens10584771_1271704447MARIO_thumbnail.jpg" />
            <span>2013 Scion FR-S Arrival</span>
        </a>
    </li>
    <?php
}
?>

This would be fine, if the data would remain minimal, but where are your alt tags, title tags, what if you use itemprops for SEO results. All that is additional overhead.

Our template contains almost the same amount data returned as JSON. The reason being is that we’re not returning

1
<a href="

as data, but we’re most likely returning

1
{"

instead. Less code already.

But, you say, the difference is not that great. We went from 236 bytes to 258 bytes. It’s not a huge difference. It’s about 9%. I’m not impressed.

Ok, what if you do add those additional items, like title, alt, propitem, etc… And what if you have additional wrappers and other overhead HTML that repeats? Your template only includes this once. The rendered version of your code returns this 16 fold. Let’s see the difference between.

235 to 305!!! How’s 30% increase in your data for a significant enough number?

In Conclusion

So, when comparing the two methods, you notice that our template has been increased by a few bytes.

1
2
3
4
5
6
7
8
<script id="content-list-item" type="text/x-jquery-tmpl">
    <li itemprop="stuff">
        <a href="[[url]]" itemprop="url" title="[[text]]">
            <img src="[[thumb]]" itemprop="image" title="[[text]]" alt="[[text]]" />
            <span>[[text]]</span>
        </a>
    </li>
</script>

Our JS has not increased since we’re just reusing the same references for the alt, title, etc tags.

While the oldmain.php rendering file has increased a bit more than the template file, this repeats several times, significantly increasing the size of data transferred back to the client.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
$qty = $_POST['qty'];
$retVal = array();

for ($itemCount = 0; $itemCount < $qty; $itemCount++) {
    ?>
    <li itemprop="stuff">
        <a href="http://www.motortrend.com/roadtests/oneyear/coupe/1302_2013_scion_fr_s_arrival/" itemprop="url" title="2013 Scion FR-S Arrival">
            <img src="http://i2.squidoocdn.com/resize/squidoo_images/-1/lens10584771_1271704447MARIO_thumbnail.jpg" itemprop="image" title="2013 Scion FR-S Arrival" alt="2013 Scion FR-S Arrival" />
            <span>2013 Scion FR-S Arrival</span>
        </a>
    </li>
    <?php
}
?>

Another benefit is that the template can be changed as an individual file. So, if designs change, you never have to bother the back-end developers, unless new data is necessary for the items retrieved, but that’s a data issue, not a design issue.

Updates to the other files:

The call is being made from here

1
2
3
<a href="javascript:void(0);" class="jsonCall" data-template='#content-list-item' data-container='#my-container' data-qty='16' data-action='getmario'>Click Me!</a>

<div id="my-container"></div>

The JavaScript updated file

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
    $('.jsonCall').on('click',function() {
        var template = $(this).attr('data-template');
        var container = $(this).attr('data-container');
        var action = $(this).attr('data-action');
        var qty = $(this).attr('data-qty');
       
        $.ajax({
            url: '/ajax/main.php',
            type: 'post',
            data: 'qty='+qty+'&action='+action,
            dataType: 'JSON',
            success: function(data) {
                $(container).html('');
                var templateCode = $(template).html();
                for (var itemCount = 0; itemCount < qty; itemCount++) {
                    templateCode = templateCode.replace(/\[\[url\]\]/gi, data[itemCount].url);
                    templateCode = templateCode.replace(/\[\[thumb\]\]/gi, data[itemCount].thumb);
                    templateCode = templateCode.replace(/\[\[text\]\]/gi, data[itemCount].text);
                    $(container).append(templateCode);
                }
            }
        });
    });

The ajax called JSON returning php file

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<?php
// a sort of a controller to get the right function to run
if (isset($_REQUEST['action'])) {
    switch ($_REQUEST['action']) {
        case 'getmario':
            getMario();
            break;
    }
}

function getMario() {
    // normally would make a database connection to populate the data,
    // but that's not what we're testing here.
    // We only made one connection per call anyway.
    $qty = $_POST['qty'];
    $retVal = array();

    for ($itemCount = 0; $itemCount < $qty; $itemCount++) {
        array_push ($retVal, array(
            'url' => 'http://www.motortrend.com/roadtests/oneyear/coupe/1302_2013_scion_fr_s_arrival/',
            'thumb' => 'http://i2.squidoocdn.com/resize/squidoo_images/-1/lens10584771_1271704447MARIO_thumbnail.jpg',
            'text' => '2013 Scion FR-S Arrival'
        ));
    }
    $retValJSON = json_encode($retVal);
    echo $retValJSON;
}

?>

Just to show once again that the more complex your html will be, the more data you are returning the old way, whereas the new way, you are barely adding anything at all to the data coming back. In the long run, you will benefit significantly from the template way of doing things.

Changed the oldway file:

1
2
3
4
5
6
7
8
// from
...
<li itemprop="stuff">
...
// to
...
<li itemprop="stuff" id="item_<?php echo $itemCount; ?>">
...

Changed the template file:

1
2
3
4
5
6
7
8
9
10
11
12
// from
...
<li itemprop="stuff">
...
// to
...
<li itemprop="stuff" id="item_[[id]]">
...
// and added this line to our array of data
...
'id' => $itemCount,
...

Minor changes, HUGE difference. The new results are in, and the new way has gone up to 268 bytes, while the old ways have gone up to 353 bytes. Now we’re at 31.7% increase which goes to show you that we went from just under 30% difference to 31.7% (almost a 2% increase in bandwidth, just from a single change). This might be nothing when considering the small size of data, but for multi million user websites this number can be real significant. And it separates your code better.

Yes, you will use up more space initially when loading the templates. About 115 bytes more, but in the long run, there are greater benefits.

It’s-a me, Mario!

Since I absolutely love the Super Mario Brothers, I couldn’t bare the thought of not upgrading an old classic to the power of HTML5. Am I saying that I’ll re-create the entire game here? No… probably not. But, it’s nice to know that with today’s technology, you can come pretty darn close, and sometimes, even surprise yourself.

Taken from the basic Mario where I had a jumping block on a white background, I think you’ll find it refreshing to see Mario re-evolve in the web world, and have this game be playable on any device eventually. That’s my goal.