ENTRIES TAGGED "ajax"

Transforming the Web (through transformation)

Decorating content may no longer be enough

Photo: http://commons.wikimedia.org/wiki/File:Metamorphosis_frog_Meyers.pngThousands of people invented it independently. Millions use it without thinking about a broader context. It’s time to name it so we can talk about it.

Transformation is changing the way we look at the balance between clients and servers, our approach to formatting and layout, and our expectations of what’s possible on the Web. As applications shift from transformation on the server toward transformation on arrival on the client, transformation’s central role becomes more visible.

“Templating” doesn’t quite capture what’s happening here. While templates are often a key tool, describing that tool doesn’t explain the shift from server to client. Templating also misses the many cases where developers are using plain JavaScript to insert, delete, and modify the document tree in response to incoming data.

These practices have been emerging for a long time, in many different guises:

  • In the Dynamic HTML days, scripts might tinker with the DOM tree as well as modify CSS presentation.
  • Transformation was supposed to be a regular and constant thing in the early XSLT plans. Stylesheets on the client would generate presentation from clean blocks of XML content.
  • Ajax opened the door to shell pages, apps that set up a UI, but get most of their content elsewhere, using JavaScript to put it in place.
  • New data format options evolved at about the same time that Ajax emerged. JSON offered a more concise set of programmer-friendly content tools. Many apps include a ‘bind JSON to HTML before showing it to the user’ step.
  • Template systems now run on the client as well as the server. In many systems, templates on the server feed data to the client, which applies other templates to that data before presenting it to users.
  • The HTTP powering Ajax still created a long slow cycle of interaction. WebSockets and WebRTC now offer additional approaches for collecting content with less overhead, making it easier to create many more small transformations.
  • Some developers and designers have long thought of the document tree as a malleable collection of layout boxes rather than a deliberately coherent base layer. Separation of concerns? A dead horse, apparently. Recent debates over CSS Regions highlighted these issues again.

Read more…

Comment |

A concrete approach to learning how to program

A solid foundation on which more meaningful learning can happen

578px-Perspectiva-1.svgAs someone who has previously taught computer programming for nearly a decade, I’m often asked questions that involve “what’s the best way to go about learning to program computers,” or “what’s the best way to get a software engineering job,” or “how can I learn to build mobile or web apps?”

Most of the readers of this blog have probably faced the same question at some point in their career. How did you answer it? I’ve seen many different responses: “come up with an idea for an app and build it,” or “get a computer science degree,” or “go read The Little Schemer,” or “join an open-source project that excites you,” or “learn Ruby on Rails.”

The interesting thing about these responses is that, for the most part, they can be classified into one of two categories: top-down approaches or bottom-up approaches. Top-down approaches are informed by the opinion that it’s better to be thrown in the middle of an application or a framework which encourages the learner to piece together knowledge in that context. Many books and online tutorials use an explicit top-down approach, often starting with the basics of a popular methodology, framework or technology. The most visible example of this are books on Ruby on Rails — they almost always inevitably begin with a description of the Model-View-Controller design pattern, but defer the incredible number of non-obvious ideas that make it up (Object-Oriented Programming, for instance).

On the other hand, a bottom-up approach starts with the basics/fundamentals of programming and then slowly builds your knowledge over time. In contrast to top-down approaches, bottom-up approaches try to minimize the number of these non-obvious ideas that the learner has to take for granted. Khan Academy and Code Academy are two examples of online sites that use a bottom-up approach to teaching programming. For the most part, they completely leave out any specific framework and focus on fundamentals of programming.

Read more…

Comments: 5 |

Squeaky Clean Ajax and Comet with Lift

Focus on application development, not the plumbing

Lift is a web framework for Scala, and is probably best known for having great Comet and Ajax support.

I’ve been touring the features of Lift that I find appealing. Initially I looked at designer-friendly templates and REST services. Recently, I highlighted the great features for organising and controlling access to content.

Let’s now take a look at the Ajax and Comet features of Lift.

Ajax

When I think of Ajax, I think of interacting with a web server, but avoiding page reloads.

An example: suppose we had a site that allowed you to write poems, and a feature on that site might be a button you could click to get an associated word from a thesaurus. The thesaurus we have is large, we don’t want it loaded in the browser, so we need to call the server to use it.

The HTML template would be a field and a button:

So far, that’s probably similar across many web frameworks. What you might now expect is for us to define a REST endpoint, do some jQuery wiring to connect the service to the button.

In Lift, we can do that, but often the Ajax goodness comes via this kind of Scala code:

This Associate snippet is binding the submit button’s click event to a Lift Ajax call. That is, the left side of the replace function (#>) is a CSS selector targeting the “onclick”, and the right side is arranging for the Ajax call to hit the server.

The first parameter to ajaxCall is the value passed from the browser to the server. We’ve asked for the value of the input field with an ID of “word”. The second parameter is the function to run when the button is pressed. Here we’re taking the word we’ve been sent, and updating the field with whatever our Thesaurus.association function gives us back.
Read more…

Comment |

Smuggling Web Practices into the Enterprise

How fast can the enterprise change?

At last year’s Fluent Conference, I kept having the same conversation with attendees from large companies. They had come to the show with a mandate from their bosses to figure out how to bring that fast-moving web work into their slow-moving enterprise systems.

I enjoyed some of that same conversation this year, but also a different note: even with management support, making that transition was difficult. Some parts meshed, others were difficult: changes in one place could reverberate through many others. The whole concept of “rapid prototyping” fit badly with a variety of technologies and approaches meant to minimize unpleasant surprises. Even eight years after the advent of Ajax, a variety of server-centric techniques limit the flexibility of front-end developers.

Someone at lunch said that “the technology helps, but the culture matters.” A few others talked about how everyone wanted better front-end work, but thought it could be grafted easily on existing back-end practice. The shiny parts are easy to talk about, but the plumbing is harder.

I was happy to see Bill Scott (@billwscott) of PayPal take on these challenges in his keynote. Bill wasn’t smuggling anything—that would be difficult under the title “Clash of the Titans: Releasing the Kraken.” He was brought to PayPal to change the company, to bring the lean “build – measure – learn” approach. In a risk-averse world, with “a 20-day class on how to use their version of Spring,” Scott had to change the “culture of a long shelf life” (something publishing folks are starting to do as well).

It’s a hard-hitting talk, calling for major change, skunkworks projects, and shifts in both company culture and technology.

Read more…

Comment |

What Kind of JavaScript Developer Are You?

Fault lines make conversation difficult

“JavaScript developer” is a description that hides tremendous diversity. While every language has a range of user skill levels, JavaScript has a remarkably fragmented community. People come to JavaScript for different reasons from different places, and this can make communication difficult. Sometimes it’s worse than that—not everyone likes everyone else.

“JavaScript developer” used to mean “web developer,” specifically a developer who spends a lot of time working in the browser. Even as JavaScript became a specialty of its own, most JavaScript developers came through a broader web practice first, learning HTML and CSS before tackling the DOM. This was my path, and is still a common one. It was reasonably easy to absorb JavaScript by example, using it as an object manipulation language before pushing into the harder corners.

Many programmers, however, started on the server-side, building code that filled templates. Server-side JavaScript existed, in the Netscape Enterprise Server, for example, but was a tiny fraction in a world dominated by Perl, Java, Python, Ruby, and ASP’s languages. Developers who spent most of their time writing code that ran on the server worked with a different set of tools and expectations, and had to shift gears as JavaScript became a more critical part of web applications. (Some of these developers generate a lot of JavaScript—JSON is, after all, JavaScript—but would prefer to think of JavaScript’s role in that as an accident.)

Another group of developers came from desktop applications, and expected more direct control over the interface. Many of these developers now understand JavaScript because the browser forces them, not because they want to.

Involuntary JavaScript creates a tremendous amount of tension around the language. Normally, the people who dislike a programming language can just work with something else. JavaScript’s browser dominance makes that hard.

Other developers, though, are much much happier and much deeper into JavaScript. The JavaScript revival that became visible with the rise of Ajax in 2005 gave the language greater credibility. Douglas Crockford’s work “Unearthing the Excellence in JavaScript,” JavaScript: The Good Parts demonstrated a powerful language lurking in a toolset many had considered trivial.

Over the past decade, JavaScript’s power and reach have grown thanks largely to a core group of developers whose focus on the language has created best practices and frameworks, while driving browser vendors to improve their implementations. Node.js emerged from this work, giving JavaScript a unique server-side framework that deeply reflects the language.

Read more…

Comment |