New Programming Paradigm

[Delifisek]

Hello there,

For a while I'm trying to combine some methods for programming web pages. I believe it was very promising.

And I want to share it.

When (maybe 2 years before) we arguing future of the web programming with our local programmers in local board, my prediction is server side evolve to json pushers and all rendering done by clients.

In my programming environment, procedure something like this.

Find the statement (calling plugin etc). Generate template data, include template and produce output. This model fairly simple and I use extensively in our German Tourism Portal projects and it was so successful.

Anyway,

After losing my job, I want to pursue this idea. After some inspection  I came up with a question. What if I convert template data to json and send to client with a javascript template file. And after some research I found http://www.embeddedjs.com/ esj javascript template system was very good candidate for my tests.

So ?

Results was amazing.

Lets think about it. You are sending all, sector, maze, map data into client.

And generate output from this data. For example, walking in the maze, searching start sectors etc.

In my case, I send, entire star sector data (2.5 mb (after 5mb browser had crash)), which has 100 star systems and every star system and planet was different.

Players can sweep entire sector without generating any server requests (except images).

Then I use same concept in my CMS/Framework project.

I'm so happy with results.

You may asking what so different than ajax. In this model, we use ajax too and difference is we move entire html rendering job to browser via javascript. In beginning dealing javascript may tricky and handling json very similar to handling php arrays.

After some, especially with growing javascript knowledge, you realize you can do more thing in browser side and your thinking starting to change.

Here basic model.

javascript.

Code: [Select]

function parse_template(url,rData) {
$.ajax({
type: 'POST',
url: url,
data : rData,
success: function(response) {
if(typeof(response) != 'object') {
response = "("+response+")";
}
cObj = eval(response);
if(cObj.view != false) {
cEjs = new EJS({url: cObj.view}).render(cObj.vars);
$("#"+cObj.destination).html(cEjs);
cEjs = '';
}
}
});
}

on php side

Code: [Select]


$r['view'] = '/path/to/your/ejs/file.ejs';
$r['destination'] = 'id of your html element';
$r['data'] = $your_php_data_array;

echo json_encode($r);


and here some ejs example

Code: [Select]

<ul>
<% for(var i=0; i<supplies.length; i++) {%>
   <li><%= supplies[i] %></li>
<% } %>
</ul>

And you can put any kind js code in this template.  EJS, has own caching mechanism. So each request just gets json data. And all other computation was done by client.

I believe this model will give an edge.

Hope it helps

Regards.

Sancar 'Delifisek' Saran

[lolninja]

Ah cool yeah, your going a bit further than my experimentation and its sounding promising. When I was working on http://demo.httpmmo.com/mappy/ I offloaded all the map data, and stored it in json files, then the browser builds the blocks of tile data and draws everything using canvas, so you'll need FF/Webkit/Opera for it to work.

The only issue I can see with building your html on the client is that SEO will be tricky, users with poor JS performance will have a worse experience on your site.

* To get that demo working you may need to wait for the image to download, then refresh, as its using a pretty big image, with no preloading.

[Marek]

I've explored something similar and I reached a similar conclusion: the results are pretty awesome. My idea involves using the fragment hash (the portion of the url that follows the hash # sign). I had left the idea sitting in limbo for a few months, so it's funny that I stumbled upon your thread today, because just yesterday I had started working on the idea again

Here is the thread from a while back where I initially discussed the topic: http://community.bbgamezone.net/index.php/topic,2711.0.html

I've since learned some new things. One: there are many JS templating systems available. They vary a lot in approach and in complexity. I've been giving jQuery.tmpl a try; it's a small plugin from John Resig. Mustache.js and Underscore.js templates also do the trick. And there are many others.

Two: Google is able to index sites by fragment hash. The identifier that signals that a page is using a state-keeping hash is "#!". So when google finds a link to somepage.php#!blah it will crawl that page with a JS engine enabled (it normally ignores hash fragments, since they are intra-page links). Google will see your JS-rendered page exactly as the browser. Pretty amazing. Nevertheless, I think the power of this approach lies in interactive apps (not static documents), but it's great that Google is already ahead of the game in this respect.

[lolninja]

Oh awesome, I wasn't aware you could use #! to signify a bit of static content, might look into this once Thorny is out of the way.

[dsheroh]

Lets think about it. You are sending all, sector, maze, map data into client.

And generate output from this data. For example, walking in the maze, searching start sectors etc.

In my case, I send, entire star sector data (2.5 mb (after 5mb browser had crash)), which has 100 star systems and every star system and planet was different.

Players can sweep entire sector without generating any server requests (except images).

Yes, let's think about it indeed.

As a player, I now have all the game data in my hands.  I don't have to explore the sector through the game interface, I can dump the data to disk and write a trivial script to rummage through the data directly and, within a matter of milliseconds, tell me exactly where the richest/least-defended/whatever locations are so I can head there directly.

Assuming we're talking about a multi-player game, any player who doesn't have access to a similar capability for analyzing the sector data has no chance against me because he knows only the tiny slice of information about the sector which the game interface presents to him and he has to spend time/turns/resources to collect additional data, while I know everything and can access it instantly, at no cost.  This holds even if the game's intended interface is designed to present all information without any limitations because he'll only be able to scan/summarize the data in ways that the game provides, while I'll be able to slice-and-dice the numbers any way I can dream up.

The first rule of networked application development is "never trust the client."  Don't send players any data they shouldn't have access to because they will get access to all data you send to them.  With a well-known, standard protocol like HTTP and a well-known, standard data encoding format like JSON, this is trivial to do, but even using custom protocols and formats doesn't give any real protection against this form of cheating.  (See http://en.wikipedia.org/wiki/Cheating_in_online_games for examples, most notably the sections on "Aimbotting and Triggerbot", " Wallhacking", " Removals", "ESP"... oh, I give up.  Most of them are, to some extent, based on making use of information which the game client is intended to receive, but not share with the player.)

This can be an interesting way to boost performance in single-player games, just be aware that, by giving all game data to the client, you're also handing the player the ultimate cheat code.

[aerosuidae]

Yes, let's think about it indeed.

As a player, I now have all the game data in my hands.  I don't have to explore the sector through the game interface, I can dump the data to disk and write a trivial script to rummage through the data directly and, within a matter of milliseconds, tell me exactly where the richest/least-defended/whatever locations are so I can head there directly.

Yes!  I tried this general method in a game recently, and found so many ways it was dangerous.  I ended up creating a User::dump_restricted_view() type method that only exported the subset of data currently visible to the player, based on their location at the time and a few other metrics.

Treat it like a firewall.  You (hopefully) start with all ports blocked and stealthed, then open ports on a strict need-to-know basis.