Tracking change and innovation in the enterprise software development community
Tools to get
Visual Studio
2008 Projects
Under Control
Testing Tools to
Support Agile
Software Delivery
Whitepaper
TargetProcess:
Plan, Track
Succeed with
Agile PM tool.
Free Download!
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
Posted by Ian Roughley on Nov 26, 2007 10:50 AM
In the keynote presentation of The Ajax Experience in Boston, Alex Russell and Joe Walker posed the question "What's needed to take development in the browser to the next level?"
The current level of Ajax toolkits are a result of IE winning the browser race, and all browsers vendors entering a period of stability. Stagnation in browsers features meant that to provide new application features, libraries needed to be developed. And the libraries today have provided good solutions to the holes in browser functionality, as well as providing a browser compatibility layer for developers.
To progress past the plateau, Alex and Joe provided thoughts in the categories of features, reliability, trust and momentum that need to be addressed.
Although new features are needed to advance the user experience, they need to be added with care. It will be important that any new features do not break existing ones, and that features are added ubiquitous by al vendors.
In fact, new features are not being introduced by browsers, instead they are provided by Ajax libraries. Therefore, the important question that needs to be answered is "how far can the libraries go?"
Libraries are pushing the limits with features such as Comet, 3D (VML/SVG/Canvas), and storage and downloads.It is only by using a lot of hacks that the Ajax libraries are able to provide the current level of web technologies.
Another issue that will continue to plague the use of new browser features is the depreciation of the browser itself. Even if new features are introduced into a new generation of web browsers, the browsers currently in circulation may take 5 or more years to be removed. This will increase the responsibility of the Ajax toolkits, to assist in the transparent transition between generations of browsers.
Reliability is going to be an important characteristic of new web browsers, as broken content is the rule rather than the exception. This is not a new problem, and web browsers will need to continue with the precedent that they have already set in being able to handle incorrectly formatted content. Similarly, there will continue to be more than one technology. As well as the currently support different versions of HTML, CSS and JavaScript, there will be new versions and new technologies to deal with.
We need to be learning from biology and provide browsers that can cope with failure, and at the same time evolve.
So what can go wrong? There are many concerns that developer have today, these include:
New generations of browsers should be able to assist developers in building secure and trustable applications. In order to do this, reliable patterns need to be developed, and these patterns will need to:
There are a lot of ways to break user trust - we need to turn this around. The suggestions Joe and Alex made for features to assist developers are:
Fortunately the web has already gained huge momentum, being the preferred delivery mechanism of todays applications. And for the web, developers are providing mass and the number of deployed browsers providing velocity.
As developers, we can participate and influence standards bodies to continue momentum, and continually improve the technologies we are using.
We need to reinvigorate standards bodies, with the resulting process being transparent as well as available and driven by user and the community.
Momentum is also being provided by the browser vendors, who are moving forward without specifications. They are taking risks and we should encourage them. In particular, plug-ins are providing a way to break the non-native world, and a question all web developers should be asking themselves is "will the next version of development be via browsers or something that piggybacks on a browser?"
In conclusion, Alex and Joe asked another question, this time rhetorical:
With Ajax toolkits and plug-ins, have we provided a solution so that web browsers don't need to evolve?
The Agile Business Analyst: Skills and Techniques needed for Agile
High Performance Messaging: Tuning and Scalability How-to Guide?
Evolutionary Design through Agile Development Podcast
Lean Software Development Governance, a whitepaper by Per Kroll and Scott Ambler
"With Ajax toolkits and plug-ins, have we provided a solution so that web browsers don't need to evolve?" Clearly, yes! In my opinion we're all willingly running down the rabbit hole of browser application development (BAD)! . I'm amazed we tolerate the status quo of Ajax style development. Being familiar with other client application frameworks over the years I'm astonished at the willingness of teams to do DHTML/Javascript/AJAX at all. To me it is the cruftiest approach to development I've ever seen - by far. I can see the slipery slope that starts with enhancing your typical web app. But, you can get around the deployment win of browser apps. Why hasn't Java Web Start or .NET Winforms taken off? I wish they would.
Why hasn't Java Web Start or .NET Winforms taken off?
Well, I guess the answer for the latter is clear. As regards Java Web Start, and in a smaller measure Flash, I think they aren't ruling the web due to some psychological factors: we got used to think of web in a "close-to-text-format". For me, this is quite similar to our psychology related to paper: we still love the paper, and even if e-paper has been around for a while, almost nobody is using it.
Last, but not least you cannot create Flash/Java Web Start apps using PHP :-).
./alex
--
.w( the_mindstorm )p.
Alexandru Popescu
Senior Software Eng.
InfoQ Techlead/Co-founder
Thanks for a good summary of the talk itself. This was a good talk at an interesting conference. I think there was a general feeling that the libraries have a great deal of overlap and some of that functionality should be brought into the browsers. And if the browsers did include at least a portion of it, we could reduce some of the bloat we're seeing at present. That'd be nice.
Michael Mah analyzes the development process in 5 companies: 2 Agile (one of them BMC) and 3 classic. He presents the factors which contributed to the success of BMC's Agile adoption.
In this interview filmed at RubyFringe 2008, Tom Preston-Werner talks about how both Powerset and GitHub use Ruby and Erlang, as well as tools like Fuzed, god, and more.
David Laribee discusses the purpose of ALT.NET, its mission and future.
Ruby on Rails has become a popular Ruby framework for creating web applications in recent years. An aspect of creating a web application is the need to repeatedly create the same base functionality.
Steven Haines talks about tackling web application performance tuning by proposing a method called wait-based tuning.
Shaw and Fowler talk about the need for a new relationship between the business department and the IT department. Studies have shown that projects mostly fail due to miscommunication between the two.
In this article, Jim Webber, Savas Parastatidis and Ian Robinson show how to drive an application's flow through the use of hypermedia in a RESTful application.
Eccentric artist turned overnight anti-celebrity, Giles Bowkett captures the heart and soul of RubyFringe as he demonstrates his revolutionary Archaeopteryx MIDI drum pattern generator.
3 comments
Reply