Tag Archives: Web development

More on hash-bang links
3

More on hash-bang links

| By | 3 comments

Tim Bray offers a good high level explanation of why hash-bang links are a horrible idea and fundamentally break the web. I like this question:

So, my question is: what is the next great Web app that nobody’s built yet that depends on the simple link-identifies-a-resource paradigm, but that now we won’t be seeing?

I got a few responses to my question yesterday, which was, why are people doing this, and the one that I found most convincing is that it’s a resource issue. Let’s say you’re building a Web application and you want the ability to load items onto the page dynamically using AJAX. You have to pay engineers to build the JavaScript code that does so, and also pay someone to build the services on the servers that respond to the AJAX requests. Paying people to build the equivalent functionality that serves static pages costs even more money. So people who don’t really understand the Web cut costs in that fashion.

That probably explains the Twitter case, since Twitter is an application that rightly has many dynamic elements. But that doesn’t make sense for Gawker, a Web publisher in the business of publishing static blog posts on the Web. Why are they loading that content dynamically? My best guess there is that they hired a developer or manager who had done it that way somewhere else, probably for more sensible reasons. They came to Gawker and decided to just build things in the way that they already understood. That person should probably be fired.

The state of the Internet operating system
1

The state of the Internet operating system

| By | One comment

Tim O’Reilly offers a definition of the Internet operating system:

This is the crux of my argument about the internet operating system. We are once again approaching the point at which the Faustian bargain will be made: simply use our facilities, and the complexity will go away. And much as happened during the 1980s, there is more than one company making that promise. We’re entering a modern version of “the Great Game”, the rivalry to control the narrow passes to the promised future of computing. (John Battelle calls them “points of control”.) This rivalry is seen most acutely in mobile applications that rely on internet services as back-ends.

This is a great and important article, an explanation of where we are right now as an industry.

The two questions that I’m interested in trying to answer, or seeing other people try to answer, are:

  1. What are the keys to preserving the freedom and openness of the Internet given the trends in the article?
  2. How should people developing applications using the Internet operating system be investing their time right now?
Defending view source
1

Defending view source

| By | One comment

Dojo developer Alex Russell continues to look out for view source:

If HTML is just another bytecode container and rendering runtime, we’ll have lost part of what made the web special, and I’m afraid HTML will lose to other formats by willingly giving up its differentiators and playing on their turf. Who knows, it might turn out well, but it’s not a vision of the web that holds my interest.

I linked to his previous warning on this subject back in January.

The risky aspect of HTML5
0

The risky aspect of HTML5

| By | No comments yet

The theory is that if all the User-Agent providers implement all these algorithms exactly as specified, complete interoperability will be achieved and people who build Web applications need no longer concern themselves with the differences between User Agents. Which would of course be wonderful.

Will it work? Nobody knows; it’s a science experiment. Just because nobody has ever succeeded in specifying a workable networked object model doesn’t mean this project will likewise fail. But it does mean that when considering the future of HTML5, we should recognize that this is a very hard problem, and there’s no guarantee that that part of it will come off.

From a blog post on HTML5 by Tim Bray.

Assessing Apple’s revamped checkout process
0

Assessing Apple’s revamped checkout process

| By | No comments yet

Form expert Luke Wroblewski compares Apple’s revamped checkout process to their old checkout process. If you do any work designing HTML forms at all, you’ll want to check this case study out. I’m particularly interested in the pros and cons of requiring users to enter their city, state, and zip versus entering just the zip and looking up the city and state. Luke has looked at this issue before.

Storing data for Google Maps
7

Storing data for Google Maps

| By | 7 comments

I hinted at this in my link post, but I thought I’d write up the whole thing in hopes of discussing it. I have a page that will include a Google Map with markers for a number of locations (potentially a large number of markers). For an explanation of how to add markers to a Google Map, check out this page.

So the question is: how do you get the address data from my database to Google Maps?

The process is to geocode the address and then apply the marker to the map. There’s a simple example at that link.

Here are some possible approaches:

  1. Write some code (PHP in this case) that emits the JavaScript used to geocode the addresses and put the markers on the map. Unfortunately then you have a mixture of JavaScript and PHP code that looks a lot like JavaScript on your page.
  2. Print out a JavaScript data structure that contains all the information for the markers and then iterate over that data structure in JavaScript.
  3. Put the map data in hidden elements on the page where it can be extracted using JavaScript. The downside is you have hidden elements on your page. The upside is that your PHP is completely separated from your JavaScript.
  4. Create a service that returns a JSON data structure of the marker information that can be called using XmlHttpRequest and call that from the page. That offers a clean separation of the JavaScript from the PHP but unfortunately could add latency to the page.

I’ve done some searching to find out how people handle this problem, but haven’t seen any good answers yet. Any ideas?

HTML 5/XHTML 2 link roundup
0

HTML 5/XHTML 2 link roundup

| By | No comments yet

This is a special link roundup related to the W3C killing off XHTML 2 and putting all its eggs in the HTML 5 basket. I’ve posted about this myself here.

Links from July 9th
0

Links from July 9th

| By | No comments yet
Determining whether to hide a report filter
1

Determining whether to hide a report filter

| By | One comment

Let’s say you have a report that has some filter controls on top that let you narrow the scope of the report. When the report loads, the filter is collapsed. The user opens the filter, changes some of the settings, and submits the form. What is the preferred method for determining whether the filter should be displayed? A related question is whether you should detect the filter’s visibility status in JavaScript or you should check on the server side and use the style attribute to control visibility.

Here are some options:

  • Always leave the filter collapsed initially. I hate this option, though, because it hides important information from the user. If the report is in some non-default state, the user should be able see when it loads what that state is.
  • Check to see whether any form parameters were submitted. If there were, add the appropriate style attribute to the form on the server side.
  • Assuming the GET method was used, check for a query string in JavaScript and hide the form using JavaScript if no query string is present. (Indicating that the filter is in its default state.)
  • Using JavaScript, check the values of all of the fields on the form to see whether they are in their default state. If not, display the form.
  • Use a hidden form field set on the server side to indicate that the filter should be displayed. In JavaScript, check that field to determine whether or not the filter should be displayed.

There are probably other options as well, and all of them will work. Choosing from among them is a matter of ease of maintenance, mostly. Ideas?

Links from June 3rd
5

Links from June 3rd

| By | 5 comments