The video was very good but in the beginning Misko Hevery struggled a bit to describe it and at the end admitted the biggest problem was explaining to people what <angular/> is. To me it is clearly a language, and an extensible one at that. It is (or at least contains) as he describes an HTML compiler. Doesn’t a compiler imply some language to compile. The source is clearly more than just HTML so it must be more than just an HTML compiler. I wonder if there is some reason he avoids calling it a language. The fact that it can be extended to handle new behaviors, widgets, etc. just makes it a better language. Is there some fear that calling it a language would put people off? It doesn’t bother me since I previously said that higher level languages will provide the biggest productivity gains.

The parallels I was talking about are:

• Its a declarative language
• The language is designed to be extended
• It has two way data binding

Two way data binding is a very important aspect in simplifying the creation of web apps. The first time I ever saw data binding was back in the the late ’80s. I was visiting a friend that was working on a maser, which is cool (literally) in its own right, but what caught my eye, as he showed me around his lab, was some software running on an old Mac. That software was LabView. The fact that a line drawn between a sensor and a gauge meant that any time the senor value changed the gauge was updated really impressed me. More recently I noticed that data binding is built in to the JavaFX language. I haven’t written any programs in LabView or JavaFX so I’m not sure if the bindings can be bidirectional but I’m pretty sure at least in JavaFX that bidirectional changes can be accomplished.

It is the two way data bindings that most notably distinguish <angular/> from template languages. I used to be a big fan of template languages, and StringTemplate was my favorite. Lately I have found them to be less useful. One reason is that in my recent work I have found that procedural logic far outweighs the amount of template text. The bigger reason is that most template languages don’t automatically protect you from script injection (XSS). There are many JavaScript template languages available now and I don’t have a need for any of them. But <angular/> is different — it is not a template language and it looks like it protects against script injection by default.

<angular/> is new but it looks very promising.

• Performance. One of the performance recommendations made by Yahoo’s performance team is to reduce HTTP requests. One way to do this is using the CSS Sprite technique — combining many images into a single background image.
• Skin-ability. With the img tag the image URL is in HTML markup where it is hard to change. With CSS Sprites the image URL is in a CSS file making it more convenient to change. Sure you can change the contents of the original file but there are reasons for changing the URL. It is not as easy to move the images to a different server or group them in different image files when the URL is not in CSS.

However there are drawbacks. The biggest is accessibility, specifically high contrast mode. In high contrast mode all background images and colors are ignored — replaced with high contrast colors such as white on black or black on white. The other issue is that background images are not always printed.

The prevailing accessibility advice is to not use background images for functional images. The underlying problem is that there is no way in HTML/CSS to identify a background image as being functional. They are all considered decorative. It is also true that not all img tag images are functional but again there is no way to distinguish them for the purpose of high contrast mode. So high contrast mode makes a reasonable assumption that background images are decoration to be removed and img images are functional and must be shown. From here on I’ll call functional images icons. They either convey important information or are interactive (like a toolbar button for example).

I have seen recommendations that functional background images should be replaced with text when high contrast mode is detected. This does not seem right to me at all. A desktop app does not change its toolbar button icons to text in high contrast mode. The assumption is that icons are already designed to have reasonable contrast.

It also just feels right to me that the icon URLs should come from CSS.

Since I care about performance and accessibility I’m not happy with this conflict. I want a solution that puts the icon URL in CSS, works in high contrast mode and allows me to combine icons into a single image file. Here is what I came up with.

My typical markup for an icon is something like this:

    <button><span class="icon edit"></span></button>
    <button><span class="icon delete"></span></button>

The basic style is:

span.icon {
    display: -moz-inline-box;
    display: inline-block;
    width: 16px;
    height: 16px;
}
button span.icon.edit {
    background: transparent url(images/toolbar.png) no-repeat 0px -32px;
}
button span.icon.delete {
    background: transparent url(images/toolbar.png) no-repeat 0px -16px;
}

This creates a button with an edit icon assuming that toolbar.png is a sprite image with the edit icon at offset 0, 32 etc. I left out extras like a title tooltip and hover and active states for the button icon to keep things simple. This works nicely until high contrast mode is turned on.

You can use the same sprite image in an img element and position it relative to a fixed size parent that has overflow:hidden to achieve similar functionality to a background image.

For example:

    <button><span class="icon edit"><img alt="" src="images/toolbar.png"></span></button>
    ...

The style to make this work is:

span.icon {
    display: -moz-inline-box;
    display: inline-block;
    width: 16px;
    height: 16px;
    overflow: hidden;
    position: relative;
}
button span.icon.edit img {
    position: relative;
    left: 0px;
    top: -32px;
}
...

This works in high contrast mode (as well as normal mode) and has multiple icons in a single image but the image URL is in the markup not in the stylesheet. What I want to do is use JavaScript to take the image URL from CSS and dynamically add the img element as a child of the icon span. The html mark up and stylesheet will be the same as the first example above except that the stylesheet will have these additional styles:

span.icon.edit img {
    top: -32px;
    left: 0px;
}
span.icon.delete img {
    top: -16px;
    left: 0px;
}

These additional rules are not too much extra work considering you will usually have additional rules to adjust the position on hover and active states anyway.

My first attempt tried to get the URL from the current styles using jQuery like so: $(…).css(“background-image”). The trouble is that in high contrast mode the effective current background image is “none” even though the CSS file does have a background image. This makes sense — the program should “see” what the user sees. The solution is to get the actual background image directly from the CSS rules. This takes a little fiddling to get it to work cross browser. Some browsers return the full URL and some return exactly what is in the CSS file. Some times its wrapped in quotes.

This test page shows an example of the traditional CSS Sprite technique as well as my jQuery enhanced high contrast mode compatible version. All the styles and JavaScript are in the html file to make it easy to see how it works. It also contains code to detect high contrast mode. One option is to only make the dynamic change if high contrast mode is detected but that is not the approach I took in the test page.

View the page with high contrast mode turned on and off to see the difference. Note: not all browsers or operating systems support high contrast mode. Firefox and IE on Windows do. It is also important that the dynamic changes work even in browsers that don’t support it (by work I mean that the icons look right and are functional, not that high contrast mode magically starts working in browsers that don’t support it). I tested on Windows with IE8, FF3.5, Safari 3.2 and 4.0, Opera 10 and Chrome and found that they all worked. I also tested on Linux with FF3 and found no problems. I don’t have a Mac to test with. I tested with IE6 and found that it did not work. More investigation is needed but IE6 is not a high priority for me right now. I need to test with IE7 but don’t have it handy right now.

Feedback on how it works in other browsers and operating systems would be very helpful.

I did not do any performance testing. The assumption is that moving the image from the background to an img tag will not cause the image to be requested from the server. The Firebug Net tab indicates that it is fetched just once. The page seems to render fast enough with no flashing. More testing is needed but I think the principal is sound. The script could use some improvement to be more robust especially for much older browsers so they at least fall back to using the CSS sprites as is. I bet there are other cases of relative URLs to test for as well.

Keep in mind that the test page is meant to demonstrate just this technique. It has a bunch of other accessibility no-nos such as the disclose icons are not focusable, keyboard accessible, and have no screen reader accessible label text.

When you use the focus method to set focus to a focusable element the expectation is that, in the absence of css rules to the contrary, the browser will show a focus outline around the element using its default style. This is what happens in Firefox, Chrome, and Safari. (Opera has its own set of focus problems which I didn’t investigate fully.)

There are a number of elements that are naturally focusable, such as inputs and anchors. In addition any element with a tabindex attribute equal to -1 is focusable. If the tabindex is non-negative then it is focusable and in the tab order. My test case uses list elements with tabindex of -1 or 0. I suspect that the same is true of other elements using tabindex.

Older versions of IE (I tested IE6 and I believe IE7 works the same in this regard) had some strange additional requirements beyond just calling focus. The outline would not be shown if the focus method was used to give focus to an element with a tabindex of -1. So before setting focus you would have to set the tabIndex to zero (or a positive number).

elem.tabIndex = 0;
elem.focus();


Also if you click on an element with tabindex of -1 no outline is shown unless the className is updated (even if the value doesn’t change). Perhaps other style changes would work as well.

IE8 adds some new bizarre behavior. First if css is used to set an explicit outline style on the elements (either directly or inherited) then the old IE quirks mentioned above go away as well as the new IE8 problem described below. Setting your own outline style for focus isn’t a good idea unless you are giving your whole web app a focus style makeover. I think it is best to stick with the default styles since it is what the user is probably used to. There is also the problem of old browser like IE6 not supporting the outline style.

If the className of the element receiving focus is updated in the onfocus handler while the tabIndex is -1 then no focus outline is shown. Assuming that the tabIndex is -1 and addClass is a function that adds a class to the className, one would expect the following two lines of code could be executed in either order.

addClass(elem, "myfocus");
elem.tabIndex = 0;


In IE8 setting the tabIndex to zero must be done first or the outline is not shown. This is exactly what tripped me up. If I just happened to write the statements in the opposite order I would never have discovered these oddities.

Note that in all cases focus is actually set correctly it is just the visual indication of focus that is wrong – but thats the important part of focus.

I created a test page that allows playing around with these rules. It is also an example of how focus can be managed with a roving tabindex. If you play with this page in different browsers you will notice that in Firefox (versions 2 – 3.5) , Chrome, and Safari 4 (I tested on Windows) it doesn’t matter what options are checked, the behavior is correct. In IE you can play with the options to see which combinations work.

I wonder if this is intentional in IE8 or is something that will get fixed in a point release.

Sometimes you see the term REST API and sometime REST Service (or RESTful Web Service). I don’t like the REST Service term because I think it gets confused with the SOAP and RPC styles. REST API is also a strange term. When we think of APIs the most familiar is the local call to a function, method, subroutine or procedure. The remote procedure call tries the best it can to preserve the same semantics when the caller and callee are not on the same machine. When we think of a remote API it is easy to assume RPC. With REST the focus is on the resources. Other aspects of the interface such as the set of method are fixed and uniform. I use REST API to mean a RESTful application data layer that can be consumed by another program.

REST is an architectural style for hypermedia systems with the World Wide Web being the primary example, and the only instance of immediate concern. For all the talk of APIs the web is still mainly about UI. Its a hypermedia system for humans.

REST doesn’t care if it is a human or a program that is the client of your resources. So why all the focus on APIs? Other than general information about REST I have not found practical specific advice for implementing RESTful web applications. The best I have found is this slide deck — I wish I saw the talk.

An information only web site (one with static HTML and no forms) is likely to be RESTful even if only by accident. As web sites allow richer interaction between the user and the site and among users of the site it gets easier to stray from the principals of REST. Some of the issues that come up are:

• The HTML form element doesn’t support PUT and DELETE
• You need somewhere to put conversational (i.e. session) state and REST says no cookies
• You need to authenticate users but can’t accept the limitations of HTTP authentication

Is it these issues that caused REST to retreat to the realm of APIs?

Now ajax can help solve these problems so its reasonable to think about making your web app UI RESTful. XHR does support PUT and DELETE (as well as GET and POST). There are a few options for maintaining state on the client:

• A single page app can keep state in JavaScript objects
• Gears or HTML 5 client storage can store session state and more
• HTML 5 session history can handle specific issues with the back button

Authentication is still an issue and the solution to CSRF requires server side session state. I need to think more about these.

Lets assume all the issues with your web app UI being fully RESTful are solved. Now you want to also provide your application’s functionality/data to other arbitrary clients. Do you do this as a completely independent effort? It makes sense to me that the UI should be using the same RESTful data layer API that other clients would use.

Now you have two related but separate planes of URLs; UI URLs and data URLs. You will find yourself in the same situation by following the principals of SOFEA if you try to make the UI and data layer RESTful.

While looking at a list or table of accounts the UI URL might be something like myapp.com/ui#accounts (the hash is used because I’m assuming a single page app) and the URL for the resource supplying the account collection might be myapp.com/api/accounts. The names of accounts in the list include links to details about each account. Clearly, for bookmarking, the UI URL needs to include the account identifier. The UI URL for an account detail view might be myapp.com/ui#accountdetails;083249. The data URL could be myapp.com/api/accounts/083249.

If your RESTful data layer follows the principal of “hypermedia as the engine of application state” then the /api/accounts representation should have (in some form or another) the URLs to each account in the collection. The accounts list UI also needs to know the the UI URL for account details.

To click a link and get from the accounts list to an account detail vew there are two things that must be done. First the accounts list UI must know how to take the account id number and add it to the account details UI URL. There is nothing in the uniform REST interface that tells the UI how to do this. In fact programs should not pick apart URLs (there seems to be some debate about if it is OK for programs to assemble URLs) .

Second the account details UI needs to know the data URL to use for the specific account. Here are some ways it could happen:

1. The details page could know how to create data URLs taking the account number from its own URL and sticking it in the right place. I think the article “Describing RESTful Applications” is saying this isn’t OK.
2. The accounts list page could put the data URL somewhere in memory (or other client storage if it isn’t a single page app) so that the account details page can retrieve and use it. But this wouldn’t work for bookmarking.
3. The UI URL could have the full data layer URL encoded in it like so: myapp.com/ui#accountdetails;/api/accounts/083249. This solves the bookmarking problem but something just doesn’t feel right about this URL. If nothing else its long and repetitive.

Articles on RESTful APIs (including the above linked “Describing RESTful Applications”), put a lot of emphasis on loose coupling between servers — the things providing the API — and clients. There seems to be an underlying assumption that generic or arbitrary clients exist.

In my past experience of building desktop applications the UI has detailed knowledge of the underlying data. In traditional MVC architecture (if there is such a thing) the views know about the model (the views can call methods of the model to get or set data) but the model has no direct access to the views. Some sort of publish subscribe event notification is used by the model to let the views know about changes. The main motivation is to allow multiple different views for the same data. What does this have to do with web apps? Most web apps don’t need change notifications in the form of server push. The point here is that the UI is tightly coupled to the model but the model has no direct dependency on the UI. The model is there to serve the needs of the UI but is not impacted by its implementation. The UI can change independent of the model. If the UI needs some particular new data then it will be added to a resource or if appropriate a new type of resource will be created. If a resource changes, it’s URL renamed or is removed it will likely break existing UI. To me this is the nature of applications. This is why the first option above (the details page knowing how to create the data URL) seems OK to me.

It may be better if the data resource described how to create the URL. It could provide the full URL for the benefit of the assumed generic clients and in addition provide a pattern plus the identifying parts. For example: rel = details, url = /api/accounts/083249, pattern = /api/accounts/*, id = 083249. The trouble is that the description is most efficiently given in the data resource providing the link (/api/accounts) but it is needed by the UI account details page.

It is pointless to have an API, RESTful or otherwise, without some client but is the arbitrary client a myth? I think it depends on the generality of the API. Clearly the Amazon S3 service is very general and can be used by many different kinds of clients. If the data resources come about as part of building a specific web application then they are probably very specific to that UI. While other clients are possible they would probably end up being similar to the original web app or require changes to the data resources. This is a case of different UIs having different needs of its data model.

Is there a general client — one that can consume in a useful way my REST API as well as yours? For this to work the client and services would have to have a shared understanding of some content type. For the client to provide a UI the content type would need to declare the UI. There is such a client and content type. Its the web browser and HTML. Now we have come full circle and can see the problems. HTML has not kept up with the demands of rich efficient user interactions and does not allow separation of the view and model. HTML 5 and XForms may be addressing these issues. (I have only read parts of the HTML 5 Draft and its been a long time since I read XForms.) Should HTML be providing a rich set of built in functionality or a minimal set that can be composed with scripting to accomplish the desired rich interaction? Going back to my HTML is the assembly language of the web analogy, do we want a CISC or RISC architecture?

How are you creating RESTful web apps today?

I agree with the overall reasoning and the conclusion.

So one obvious way to correct the thin client architecture is to implement a true MVC framework on the client side… That means that all “Presentation Flows” must occur within the currently ­loaded web page… So one workable model is the Single Page Application (SPA).

First let me get some minor complaints out of the way.

The paper tries to be fair to REST but it gets some things wrong. The mapping of CRUD verbs on to HTTP methods is as follows:

• Create is done with PUT or POST depending on the relation between the entity to create and the URI.
• Retrieve as well as search and find is done with GET. Search should not be done with POST.
• Update is done with PUT
• Delete is done with DELETE

It has a definite bias against JSON based on it not having a schema. But there is a proposed JSON Schema and the author seems to have updated his view on this matter. It seems contradictory to me to say REST is valid but XML is the only representation that is acceptable. What would be wrong with microformats in HTML or CSV for example? Any well defined format should be OK — thats the whole point of constrained content types. Using the X in AJAX as justification for using XML shows outdated thinking. Current usage of ajax is not as an acronym but a term referring to an architectural style for web apps leveraging a wide range of technologies.

The description of the POST-Redirect-GET pattern is very good but I don’t agree with the conclusion: “Although ingenious, the POSTRedirectGET pattern is mere bandaid over the fractured web architecture.” I consider the POST-Redirect-GET pattern (I call it redirect after post) to be the way the web is intended to work and I’m still baffled that its use is not wide spread.

The superficial differences between thin and rich clients should be updated. The offline distinction of rich clients starts to go away thanks to Gears and related features of HTML5. The footprint of thin clients is going up as they use more and more JavaScript libraries.

I think the claim that Front Controller is an anti-pattern should be backed up. Give more background on what Front Controller and MVC patterns are and justify why Front Controller is an anti-pattern. Not having this rigor makes it harder to believe the conclusions. The Design Patterns book does not list MVC as a pattern but does note that it is made up of other patterns including Observer, Composite, and Strategy. I think the most important part of MVC is the decoupling of the model and view. The main pattern involved in this separation is Observer. But the Observer pattern, where views get notifications when the data changes, doesn’t work well across the web. So there must be some other benefit to the separation of model and view. This paper describes the benefits in terms of Presentation Flow and Data Interchange separation. Laying the blame on Front Controller doesn’t seem fair. As far as I know Front Controller doesn’t say anything about the combination or separation of model and view. It is simply about combining common precessing in one place and dispatching to command processors for specific processing. It made sense given the state of web app architecture at the time. Perhaps Front Control means Model 2 in the context of this paper. I never did understand how server side framework’s, such as Struts, can claim to be an MVC architecture or more generally I don’t agree that Model 2 is MVC.

The two more fundamental issues I have with the paper are:

• The insistence on a schema for the model.
• Too many implementation issues left unanswered.

I’ll discuss these in order.

My background and experience is in creating web applications. Functionality, usability and performance are the most important factors (along with time to market) driving the design. I have not had any direct experience with SOA. One aspect of SOA is loose coupling between systems. The loose coupling motivates a strong contract. In my experience the presentation layer (a.k.a UI) of an application has tight coupling with its model. For this reason I don’t have a problem with the data that flows between the UI and model not having a schema. At some point the underlying data will likely have a schema or some formal description, for example a database schema. Way back when I worked on desktop apps there was the notion of an intermediate model between the view and the underlying data store. Now this intermediate model is delivered as a REST resource and it is in direct support of the presentation layer. It satisfies the needs of the presentation layer — not the other way around. A simple change to the UI can result in a need to rewrite the contract with the data model. The overhead in maintaining the contract must be considered.

So I could be all wrong about this. My experience could be too limited and there are cases where you want a firm contract between the presentation and the data. If so then SOA makes a lot of sense. I’m not trying to say anything negative about SOA. It seems to me that the insistence on schema is more a motivation for SOA than anything else. Without it I would still draw the same conclusion, as others have done, that a single page app (i.e. move the controller to the client) is a good idea. Is the principal of statelessness from REST enough motivation in itself to draw the conclusion that the controller needs to move to the browser?

The paper ends with a list of principals for the SOFEA model and an example but a number of tough issues and details are left out. Some of these issues apply to ajax techniques in general. In the traditional web app architecture you can always choose not to use a particular ajax technique if it causes a problem but when your application architecture requires ajax at a fundamental level these issues must be addressed.

The first two issues are about accessibility. A single page app (SPA) relies on JavaScript. What about users who disable JavaScript or browsers that don’t provide JavaScript. Is it reasonable in this day and age for web apps to require JavaScript or should you try to make your app accessible to as many user agents as possible? What about the principals of unobtrusive JavaScript (UJS), is it easier to apply when the app uses multiple pages (traditional server controlled presentation flow) rather than a single page.

A SPA also makes dynamic changes to the DOM which causes trouble for assistive technologies. Is it a matter of assistive technologies needing to catch up? Do we wait for WAI-ARIA to come to the rescue? If you are designing for the future or your users are on the cutting edge (or you don’t have users with disabilities) then this may be a non issue. If your app has strong accessibility requirements including legacy software support then a SPA is out of the question.

Is this architecture appropriate for all kinds of web apps or not? In which cases does it apply? For example does it apply to web sites. This brings up the old debate about the distinction between web apps and web sites.

Does putting a controller inside a web page break the way the web is supposed to work. There are issues with bookmarking, and the back button that must be addressed.

What if the app is too big to fit in a single page? Sure you can grab bits of the HTML structure as needed but how will this impact search engine spiders?

There are many implementation details to solve in creating a MVC framework in the browser. The paper bemoans the proliferation of web frameworks but this architecture and ajax in general have enough challenges to ensure that there will be an equal or greater number of client side frameworks. How do we keep from making the same mistakes that were made server side? For example some client side libraries for templating are sprouting up and they seem to be making the same lack of model view separation mistake that server side template engines made. In a previous post I asked “Is there a need for a JavaScript implementation of StringTemplate?” I think the answer is a clear yes. However, templating is just one way to get the data back into the view. Another option is directly injecting each data value into the DOM. What are the pros and cons of each method?

Is SPA the only way to move the controller and state to the client? The paper also mentions frames as a potential solution. Would local storage such as Gears work with multiple pages each making a separate request for its data satisfy the principals of SOFEA? The conversational state is kept in local storage. Separating the data from the view and having multiple pages has the disadvantage of increasing the number of requests at least until the view pages get cached. This means it is even more important to give the static view pages a far future expiration date.

Another issue is localization of text strings. In traditional web apps this was done as part of the same templating that merged the data in with the markup. This seemed reasonable at the time but text translation is very different from data access. The application data is likely to change frequently whereas the text translations rarely ever change. Would the principals of SOFEA recommend that text localization be done on the client side as well? As far as I can tell it makes no recommendation in this area. As long as the data and view are separate it shouldn’t care if the translation is done on the server. But running the otherwise static view markup through a template engine just to do text localization seems silly. Why not pre-translate the view and store it on the server?

I’ll stop now before I ware out my question mark key. Wait, one more: How are you solving these issues?

JavaScript has suffered some prejudice but that is starting to change. It really is a likable language once you get to know it. Back when JavaScript was used for simple things like validating fields developers wrote quick and dirty JavaScript or copied from others that had done the same. Rather than write in a JavaScript style they carried over the style of whatever language they were using.

The realization that doing web apps means doing JavaScript made it clear to me that I need to learn JavaScript well and that JavaScript code deserves the same engineering practices used for server side code – use coding conventions, document it, check it, test it, and “build” it.

Even if you plan on using drop in widgets at some point you will need to do some debugging or glue different things together. You’ll need to learn the new style of JavaScript programming in order to read the source for the libraries you are using.

I’m in the process of relearning JavaScript. To this end I have found Douglas Crockford’s site and the Mozilla developer site very useful.

I agree with these coding conventions except I add the type attribute to the script element because it is a simple thing to do to appease the HTML validators. Adjust the indent and bracket style to your taste – just be consistent.

There is a JavaDoc equivalent for JavaScript called JSDoc (there are other implementations). I have only started to try it out. Getting this formal is more important if you are making a reusable library. But isn’t it the hope of all code to be reused?

Using JSLint can help catch errors and should be used. In the next post I’ll describe how I got it integrated with Ant.

There is a testing framework called (no surprise) jsunit. So far I have only used its core for asserts. If not this then build your own test framework.

JavaScript source should be organized into meaningful modules (files) and have plenty of comments and whitespace. The browser doesn’t need the comments so it is a waste of bandwidth to send them. It also doesn’t care if your variable name is 1 character or 20. There are a few minifiers that will make the JavaScript files smaller. It is also more efficient for the browser to get one file rather than many. JavaScript files should be aggregated into just a few files and then minified. This is what I meant by “build” it.

How are you treating JavaScript seriously?