Making Development Less Difficult: Interceding with the Browser Gods

A developer’s tools control how he builds applications. Sure, anyone can hand-code software to do something precisely, starting with assembly language if necessary. But good development tools make some features easier to implement, integrate debugging and other process-related tools into the environment, and generally make the developer’s life easier. One word summarizes all of this: wizard.

ARTICLES IN THIS SERIES: THE FUTURE OF WEB DEVELOPMENT

Beyond Ajax: Software Development, Two Years from Now

Convergence of Desktop, Web and Mobile Clients

The Immersive, Cinematic Application: Improving the User Experience

>>Making Development Less Difficult, or Interceding with the Browser Gods<<

Are Web Browsers Ready for the Next Generation of Internet Applications?

Web Browsers of Tomorrow

But with so many technologies, languages and frameworks, the situation can often become more complex rather than get simpler. Jochen Krause, CEO of Innoopract (the company behind Eclipse RAP), says, “The Java tool stack and runtime stack—this is incredibly complicated. There are at least 50 acronyms. Even with the best tooling, if you have such a complicated technology or stack of technology, it will always remain very difficult to build apps.” Krause and others expect changes to occur in the development tools space, particularly in the languages and frameworks adopted: “That’s why languages like Ruby, PHP, etc., are so helpful,” he says.

While Ajax is clever and useful, it isn’t easy and it has limitations. Scott Guthrie, Microsoft general manager, .Net development platform, says, “Ajax itself is built on top of an innocuous HTML feature; the programming model wasn’t built to scale for that.” JavaScript performance is an issue as applications get bigger and need to be maintained. Plus, he points out, these applications are “weirdly stitched together.”

As a result, says Bob Brewin, Sun’s software CTO, doing Ajax is really painful, “like building an aircraft carrier by hand.” Hand-coded Ajax development today requires a large skill set, so several interesting technologies have materialized to simplify it.

That trend—to develop a new capability and then find ways to simplify development—mirrors what happened in desktop computing. But Brewin believes the improvements will happen faster, because techniques can be borrowed from desktop development. “We invented it and now just have to copy it,” he says.

It’s up to the tools to make the task easier. As Alex Russell, project lead for the open-source Dojo Toolkit, says, “My job is to intercede on developers’ behalf to the browser gods.” Because the Web cut everyone off in visual design and user design, he says, “We’ve all, on every front, been rebuilding the tool chains, and how we think about those problems.”

You Can Create Apps Faster. Can’t You?

Developers have always been under pressure to create software faster, but Tim Bray, director of Web technologies at Sun Microsystems, feels that increasing focus on time to market will require developers to choose tools that streamline the process. He expects the advent of new frameworks like Rails to enable projects to be done in days rather than months, in months rather than years.

For more about Rails, see “Why Ruby on Rails Succeeded.”

The experts also expect more adoption of software methodologies such as Agile. “A quick time to market is good at meeting business objectives, and better for developing software,” says Bray. “Get a few features right away; get feedback; get continuous improvement.”

Brian Goldfarb, Microsoft group product manager, UX platform and tools strategy, also expects test-driven development to become more common, and built into the tools. “The embers are there to begin the fire,” he says. In two or three years, Goldfarb expects, after a lot of businesses are burned by difficult-to-maintain systems, they’ll decide, “The next wave of technology is the ability to maintain a project.” According to Goldfarb, companies need to ask, “How do we build software by building tests first?”

Today, building a rich Internet app is “like building a ship in a bottle,” says David Temkin, Laszlo Systems CTO. “You spend a lot of time optimizing, because it’s a memory pig.” We need a faster virtual machine environment, he believes, to address application speed.

Important things for toolmakers to address, Temkin feels, are programming languages and the (related) execution speed of the client. It used to be that the key application bottleneck was bandwidth: the connection between the Web application and the server (remember dial-up?). But now, Temkin points out, “It’s the limits of execution speed on the client. These languages aren’t designed to produce full-out GUIs.” Existing programming languages may not generate code that’s fast enough to run on the eventual client. If you’re writing browser apps, Temkin says, you’re living in a virtual 1990. Previous generation languages like C and C++ are appropriate for lower-level software, according to Temkin, but not for UIs, because “they require too much detail knowledge.”

Every few years, programming languages ascend to a new level, he believes. “We’re going to move up a new level in that stack.” Will that stack be fixed? Sure. “All that stuff is going to get cleaned up one way or another, but probably not by way of the W3C,” he says.

Greater Reliance on Components and Mashups

One defining characteristic of Web 2.0 applications is the use of mashups, combining content from multiple sources (usually by means of an API or Web service) into an integrated experience. One current example pulls together Google maps and rental property listings on Craigslist.

Mashups are only the beginning, say these development experts. Jean-François Abramatic, chief product officer of ILOG, believes that mashups will become even more significant in application development: “We ain’t seen anything yet,” he says.

Using mashups, says Abramatic, means that developers have to do less and less from scratch, and they can leverage existing applications. “This will become mainstream in the next few years,” he says.

Mashups are still primarily a consumer tool. According to Abramatic, “The concepts are good, but you need a more robust platform in the enterprise.” To use mashups, corporate IT developers will need to watch for service availability. What happens if one data source is offline?

However, the security questions about mashups are plentiful. “There’s lots of ways to test the water on the current architecture,” says Russell. The industry needs to determine how to consider security, at what level of granularity, but it can’t be so complex that it doesn’t get done. Plus, he points out, the applications have to ship this info down the wire; that gets really expensive.

Mashups are “new” in the sense of using publicly provided data (or, less commonly, a company-internal data stream), but experienced object-oriented developers are familiar with the concept: separating both data and functionality into components and containers.

David Intersimone, CodeGear vice president of developer relations, suggests that instead of thinking about tooling for the browser, developers realize, “We don’t have to care about the browser.” The important lesson—which applies today, not just two years from now—is to separate the user interface from the object. Objects are all about abstraction layers. “In the browser we have the document model and Java objects, etc.—but how do all these objects work together?” he asks.

Objects let you hook into the event mechanisms, but toolmakers need to make the development process simpler. “We’re making it so that you don’t have to think about Ajax, JavaScript, browsers or desktop applications, containers,” Intersimone says. “You’re dragging and dropping components visually. The components do the right thing to make sure that they can run where they need to.”

Microsoft’s Guthrie expects software development to “just naturally gravitate” to using more software services (whether called mashups or something else) in a wider range of categories, “whether they’re PayPal or commerce transactions or social networking.” This won’t necessarily be complex, he says; after all, RSS turns out to be a useful way to transfer information. “It’s the simple stuff that usually works the best,” says Guthrie.

The goal of developing modular apps has been around for 20 years, says Krause, and it’s part of the philosophy behind Eclipse. “Now you can develop really modular Web apps, and the components can be really reused,” he says. In a few years’ time, chat components will be common across applications, Krause says, and it will be the same functionality whether it’s a Web app or a desktop app.

The Micro-ISV

One side effect of the increase in mashups and service/component-based development: It will become cheaper to launch a new application. It already has. “Seven years ago,” says Guthrie, “You’d have to invest hundreds of thousands of dollars to launch a mapping app. Now anybody can do it for free or super-low cost.” It’s not just the cost of writing an app from scratch; what used to require huge data centers no longer does, and it’s possible to start up a business relying entirely on online ads for income.

The startup costs will continue to drop, according to Guthrie. “We’re seeing that right now with the consumer space; we will also see it in the enterprise space in the next couple of years.”

Another side effect from more component-based applications: how we deploy, evaluate and consider enterprise software could return to the days when we chose single-use applications that each did one thing well. The computer industry pendulum may swing back to the era of “small tiny shrink-wraps”—some of which are open source—that IT manages and installs, Temkin says. You can buy components within the enterprise today, Temkin points out, such as the collaboration tool Basecamp, which is cheap enough to be included on an expense report without prior approval. “All these possibilities are now open,” Temkin claims.

Sounds great. But what about the platform the applications will run on, the Web browser? Can it take the load? That’s our next subject, in Are Web Browsers Ready for the Next Generation of Internet Applications?.