Needed Features in HTML5 history.state

Though history.pushState is a much better implementation than hash-tags to mimic the behavior of an HTTP request, it still has some ways to go.

A URL Change Event

When a hashfragement is changed, only javascript and scrolling is triggered. This needs to be extended to all of a URL to be supported. The best implementation is to trigger the popstate event which can be called with the code:

window.addEventListener('popstate', function(event) {

            // Code goes here

}

If the popstate event listener does NOT contain an anonymous function or the anonymous function does not contain:

event.preventDefault();

or whatever you named the event object, then the HTTP-GET request should be triggered as usual.

REST Support

It is a shame that what with the web's frameworks now implementing MVC or MVVM that history.pushState lacks REST support. It should pursue a more simplistic approach since javascript obviously isn't REST, but still same idea. Routes should be defined as:

history.state.addRoute(name, urlMap).

urlMap should be a string in the format:

history.state.addRoute("TestRoute", "/conditionalSegment1/cd2/{history.state.variable1}/{history.state.variable2}/{history.state.variable3}")

That would make HTML5 soooooo attractive.

Read more awesomeness from Ari Falkner >

PHP Should Die

Adapted from Science Adventures
http://sciventures.theroguenews.com/PHP_Dead.html

PHP is old and clunky. It's like that old hag that lives next door -- you know she's wrong, boring, and agitating, utterly useless, but she won't just die. PHP stands for Hypertext Preprocessing. When it first emerged, it was one of the first server-side scripts to be embedded in HTML (hypertext markup language). However, because it is interpreted line-by-line, it’s slow. It also is not very object oriented. While other technologies are constantly being developed and improved at light speed (also compiled to run that fast), PHP has lingered behind, and no longer suits the general needs of the web. It’s time for PHP to die.

First, before we continue, let’s discuss a few of the terms. HTML is the common language of the web. It uses tags to display elements, and the tags define whether the element is merely text, a hyperlink, or an image. HTML is a client-side language, meaning is rendered by the web browser. PHP is a server-side script. It is interpreted (read line-by-line) by the server, and rendered as HTML before being returned to the browser. The browser nor the end user never sees the PHP code; just the HTML. Therefore, it may seem that PHP is necessary for dynamic web content. It is not, and the alternatives far surpass it.

For the remainder of this article, I will discuss some of the more prominent advantages ASP.NET MVC and RoR have to PHP.

REST

REST stands for RepresentationalState Transfer. This is a unique routing system to access certain functions and methods. It drops using URIs as URLs and opts instead to translate routing to specific functions. For example, the first level would be a controller, and the second level would be a function. The third functional would be an ID, often the ID (primary key) used to identify the item in a database.

Example

Controller

Function

ID (as int, but it could also be a string, Boolean, etc.)

Additional parameters

http://localhost:53129/Movies/Details/23?clearData=YES&sendEmail=NO

This is uniquely better because it beats PHP’s routing $_GET function because it makes more intuitive URIs.

DRY

Don’t Repeat Yourself

This is another principal that drives RoR and ASP.NET MVC is that it ensures that by loosely coupling data, one can only change a property in one place and all functions and objects inherit the values defined once in the appropriate place. For example, if one wanted to add validation, I could simply define the parameters of an object in the model (data) part of the application. Using smooth client-side JS validation, ASP.NET will not allow the form to even be submitted without using appropriate values. If the end-user as Javascript disabled, in the controller function, one can simply check with the logic gate:

if(ModelState.IsValid)

, which returns a boolean. All validation is conducted through the model properties. This means no change is needed to the view or the controller. It also allows client-side validation to be effortless.

MISC

If one wanted to delete a method, in PHP, one would need to call it via URI or some advanced function. With the controller, one can simply call methods via a HTTP-POST signature. This maintains that GET is 100% secure, mitigating hackers.

Where to start

To get started learning an MVC-architectural web platform, simply head over to http://asp.net/mvc or http://rubyonrails.org

Good luck!

Read more awesomeness from Ari Falkner >

Hash-Bangs are for Javascript Hacks

Javascript has a place in web development. Unfortunately, many have assumed that the script has such extensive support that it can be used for all dynamic web development. This is simply a hack and should be condemned as such. It ruins security since everything is rendered via the client-side. And it alienates users that are not fond of javascript (I am only referring to client-side javascript, not server-side libraries, such as Node.js). Server-side page rendering should be performed to initially render the page and AJAX deployed only for page changes. All links must create a page refresh if the user doesn't support javascript and the page be rendered server-side. This is good, backwards-compatible web-developing. The server should always be a fall-back resource, not simply a hard drive to serve up the files.

There is one specific method of providing an "optimal" user experience that violates all of these protocols. This is the hash-bang part of the URL. The hash-bang part is the part after the hash-exclamation-point. Hash-fragments have been around for a while. The hash fragment is in green. www.example.com/users#arithehun. This has typically been used to refer to the name attribute of an anchor (this would push the page down to the HTML semantic: <a name="arithehun"></a>. However, since AJAX has come about (asynchronous javascript and xml), a programming language greatly supported by jQuery that retrieves server-side requests in through javascript and retrieves them in HTTP GET and POST requests through XML coding, this hash-fragment has assumed a more sinister role. It is often used as a key-value system to change variables in AJAX, triggering asynchronous server-side requests. Exclamation points are illegal in HTML, so this is often done in hash-bangs instead of just a hash to make sure it does not refer to an anchor. Now it would be just www.example.com/users/!#/arithehun.

"So", you may ask (innocently), "what is the problem with this nifty HTTP-GET-like interface? Doesn't it allow websites to merge javascript and the address bar?" The answer is that it promotes hacking, not software engineering, a quandary I hope does not take the next generation of programmers. Let me elaborate. We all know about the passing in GET/Request values in a web page. example.com/users.aspx?name=arithehun. Now that the MVC architectural pattern has emerged, we are (thank G-d) beginning to see more implementation of REST (representational state transfer), particularly in ASP.NET and Ruby on Rails. This allows more of an arbitrary URI paradise which allows us to build URIs conceptually instead of being bound to URLs. People can define custom routes too, so for a user query, "User/{name}". Instead this URL becomes example.com/Users/arithehun. This will probably call a method which selects the name of all users for username arithehun (or the .Single(n => n.username == "arithehun") connotation). This is all great and well, signaling the great strides that could be lost due to hash-bang fragments.

The problem with hash-bang fragments is that they use the !, so they cannot be rendered by HTML, and the # excludes them from using the HTTP protocol. This means that to function, they must be decoded by AJAX and AJAX alone. This may make web developers build the functionality of their applications into the AJAX states. All the nice RESTfullness is lost and so is all DRYness.

Now you may now dismiss me as an HTML4 crony dismissing a new, fun, and interactive web. However, precisely the opposite is true. My alternative is in fact an HTML5 answer to hash-fragments. It uses the history.pushState. Basically, you simply, when the button is pressed, issue a listener that interrupts the HTTP request and performs a javascript function instead that basically queries a similar function that returns a partial view which can be retrieved via a XML and inserted into the page. Then push the would-be URI into the address bar. If someone refreshes the page, the inherent URI is simply processed via server-side and rendered like the pre-javascript days. Back-requests can even be handled with a listener. And what if the user doesn't have javascript? Then the links are just links just like the good old days. If you are feeling really cocky and don't want a user with javascript to ever re-render the page when the URI is changed (like a hash fragment), then simply add a listener for a URI change and perform the same request: 

window.addEventListener("popstate", function(e) { // do something }); .

 It's quick, easy, and automatically backwards-compatible.

This HTML5 solution may not be as simple and intuitive as the hash-fragment, but is loosely-coupling your classes and patterns more simple than not? The answer is "no", but they make your site much more modifiable, stable, and legacy-supported.

To get started with this HTML5 history.pushState solution, follow this simple getting-started tutorial: http://diveintohtml5.info/history.html

Read more awesomeness from Ari Falkner >