Copia

Strange spate of discussion recently about XML vs. JSON. On M. David Peterson's Weblog he states what I think is the obvious: there is no serious battle between XML and JSON. They're entirely complementary. Mike Champion responds:

The same quite rational response could be given about the "war" between WS-* and REST, but that has caused quintillions of electrons to change state in vain for the last 5 years or so. The fact remains that some people with a strong attachment to a given technology howl when it is declared to be less than universal. I completely agree that the metaphor of "keep a healthy tool chest and use the right one for the job at hand" is the appropriate response to all these "wars", but such boring pragmatism doesn't get Diggs or Pagerank.

If I may be so bold as to assume that "pragmatism" includes in some aspect of its definition "that which works", I see a bit of a "one of these things is not like the other" game (sing along, Sesame Street kids) in Mike's comparison.

• XML - works
• JSON - works
• REST - works
• WS-Kaleidoscope - are you kidding me?

Some people claim that the last entry works, but I've never seen any evidence beyond the "it happened to my sister's boyfriend's roomate's cousin" variety. On the other hand, by the time you click through any ten Web sites you probably have hard evidence that the other three work, and in the case of REST you have that evidence by the time you get to your first site.

For my part, I'm a big XML cheerleader, but JSON is great because it gives people a place to go when XML isn't really right. There are many such places, as I've often said ("Should Python and XML Coexist?", "Alternatives to XML", etc.) Folks tried from the beginning to make XML right for data as well as documents, and even though I think the effort made XML more useful than its predecessors, I think it's clear folks never entirely succeeded. XML is much better suited to documents and text than records and data. The effort to make it more suitable for data leads to the unfortunate likes of WXS (good thing there's RELAX NG) and RDF/XML (good thing there's Turtle). Just think about it: XQuery for JSON. Wouldn't it be so much simpler and cleaner than our XQuery for XML? Heck, wouldn't it be pretty much...SQL?

That having been said there is one area where I see some benefit to XQuery. Mixed-mode data/document storage is inevitable given XML's impressive penetration. XQuery could be a thin layer for extracting data feeds from these mixed-mode stores, which can then be processed using JSON. If the XQuery layer could be kept thin enough, and I think a good architect can ensure this, the result could be a very neat integration. If I had ab initio control over such a system my preference would be schema annotations and super-simple RDF for data/document integration. After all, that's a space I've been working in for years now, and it is what I expect to focus on at Kadomo. But I don't expect to always be so lucky. Then again, DITA is close enough to that vision that I can be hopeful people are starting to get it, just as I'm grateful that the development of GRDDL means that people in the Semantic Web community are also starting to get it.

On the running code front I've been working on practical ways of working nicely with XML and JSON in tandem. The topic has pervaded several aspects of my professional work all at once in the past few months, and I expect to have a lot of code examples and tools to discuss here on Copia soon.

[Uche Ogbuji]

“Real Web 2.0: Bookmarks? Tagging? Delicious!”

Subtitle: Learn how real-world developers and users gain value from a classic Web 2.0 site
Synopsis: In this article, you'll learn how to work with del.icio.us, one of the classic Web 2.0 sites, using Web XML feeds and JSON, in Python and ECMAScript. When you think of Web 2.0 technology, you might think of the latest Ajax tricks, but that is just a small part of the picture. More fundamental concerns are open data, simple APIs, and features that encourage users to form social networks. These are also what make Web 2.0 a compelling problem for Web architects. This column will look more than skin deep at important real-world Web 2.0 sites and demonstrate how Web architects can incorporate the best from the Web into their own Web sites.

This is the first installment of a new column, Real Web 2.0. Of course "Web 2.0" is a hype term, and as has been argued to sheer tedium, it doesn't offer anything but the most incremental advances, but in keeping with my tendency of mildness towards buzzwords I think that anything that helps focus Web developers on collaborative features of Web sites is a good thing. And that's what this column is about. It's not about the Miss AJAX pageant, but rather about open data for users and developers. From the article:

The substance of an effective Web 2.0 site, and the points of interest for Web architects (as opposed to, say, Web designers), lie in how readily real developers and users can take advantage of open data features. From widgets that users can use to customize their bits of territory on a social site to mashups that developers can use to create offspring from Web 2.0 parents, there are ways to understand what leads to success for such sites, and how you can emulate such success in your own work. This column, Real Web 2.0, will cut through the hype to focus on the most valuable features of actual sites from the perspective of the Web architect. In this first installment, I'll begin with one of the ancestors of the genre, del.icio.us.

And I still don't want that that monkey-ass Web 1.0. Anyway, as usual, there's lots of code here. Python, Amara, ECMAScript, JSON, and more. That will be the recipe (mixing up the ingredients a bit each time) as I journey along the poster child sites for open data.

[Uche Ogbuji]

...simple - just don't use script in XSLT unless you really really really have to. Especially on the server side - XSLT script and ASP.NET should never meet. Use XSLT extension objects instead. As simple as it is.

—Oleg Tkachenko—"XSLT scripting (msxsl:script) in .NET - pure evil"""

Amen, f'real. When XSLT 1.1 first emerged the first thing that jumped out from the spec and punched me in the face was the embedded script facility. I made a fuss about it:

In general, I think the re-introduction of xml:script is execrable. XSLT 1.0 had perhaps the most elegant extension model possible, and xsl:script ruins this by destroying the opacity of extensions to XSLT processors. Language bindings may make sense in the realm of CORBA or DOM, where the actual expression of the program is done in the bound language, but XSLT is XSLT, and introducing the need for language bindings only reduces general interoperability while giving a small boost to interoperability between small axes of implementations.

I even worked with some like-minded folk to put together a petition. I have no idea whether that was instrumental in any way, but soon enough XSL 1.1 was dead and replaced with XSLT 2.0, which was built on XPath 2.0 and thus had other big problems, but at least no xsl:script.

xsl:script does live on in some implementations, and notably MSXML, as you can see from Oleg's post. You can also see some of the problems. XSLT and many more general-purpose languages make for uncomfortable fit and it can be hard for platform developers and users make things work smoothly and reliably. More important than memory leaks, script-in-xsl is a huge leak of XSLT's neat abstraction, and I think this makes XSLT much less effective. For one thing users are tempted to take XSLT to places where it does not fit. XSLT is not a general-purpose language. At the same time users tend not to learn good XSLT design and techniques because they scripting becomes an escape hatch. So an script user in XSLT generally cripples the language at the same time he is over-using it. An unfortunate combination indeed.

Oleg advocates XSLT extensions rather than scripting, which is correct, but I do want to mention that once you get used to writing extensions, it can be easy to slip into habits as bad as scripting. I've never been tempted to implement a Python scripting extension in 4XSLT, which would be easy, but that didn't stop me from going through a phase of overusing extensions. I think I've fully recovered, and the usage pattern I definitely recommend is to write the general-purpose code in a general-purpose language (Python, C#, whatever) and then call XSLT for the special and narrow purpose of transforming XML, usually for the last mile of presentation. It seems obvious, and yet it's a lesson that seems to require constant repetition.

[Uche Ogbuji]

Bruce D'Arcus commented on my entry "Creating JSON from XML using XSLT 1.0 + EXSLT", and following up on his reply put me on a bit of a journey. Enough so that the twists merit an entry of their own.

Bruce pointed out that libxslt2 does not support the str:replace function. This recently came up in the EXSLT mailing list, but I'd forgotten. I went through this thread. Using Jim's suggestion for listing libxslt2 supported extensions (we should implement something like that in 4XSLT) I discovered that it doesn't support regex:replace either. This is a serious pain, and I hope the libxslt guys can be persuaded to add implementations of these two very useful functions (and others I noticed missing).

That same thread led me to a workaround, though. EXSLT provides a bootstrap implementation of str:replace, as it does for many functions. Since libxslt2 does support the EXSLT functions module, it's pretty easy to alter the EXSLT bootstrap implementation to take advantage of this, and I did so, creating an updated replace.xsl for processors that support the Functions module and exsl:node-set. Therefore a version of the JSON converter that does work in libxslt2 (I checked) is:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
    xmlns:func="http://exslt.org/functions"
    xmlns:str="http://exslt.org/strings"
    xmlns:js="http://muttmansion.com"
    extension-element-prefixes="func">

  <xsl:import href="http://copia.ogbuji.net/files/code/replace.xsl"/>
  <xsl:output method="text"/>

  <func:function name="js:escape">
    <xsl:param name="text"/>
    <func:result select='str:replace($text, "&apos;", "\&apos;")'/>
  </func:function>

  <xsl:template match="/">
var g_books = [
<xsl:apply-templates/>
];
  </xsl:template>

  <xsl:template match="book">
<xsl:if test="position() > 1">,</xsl:if> {
id: <xsl:value-of select="@id" />,
name: '<xsl:value-of select="js:escape(title)"/>',
first: '<xsl:value-of select="js:escape(author/first)"/>',
last: '<xsl:value-of select="js:escape(author/last)"/>',
publisher: '<xsl:value-of select="js:escape(publisher)"/>'
}
  </xsl:template>

</xsl:transform>

One more thing I wanted to mention is that there was actually a bug in 4XSLT's str:replace implementation. I missed that fact because I had actually tested a variation of the posted code that uses regex:replace. Just before I posted the entry I decided that the Regex module was overkill since the String module version would do the trick just fine. I just neglected to test that final version. I have since fixed the bug in 4Suite CVS, and you can now use either str:replace or regex:replace just fine. Just for completeness, the following is a version of the code using the latter function:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
    xmlns:func="http://exslt.org/functions"
    xmlns:regex="http://exslt.org/regular-expressions"
    xmlns:js="http://muttmansion.com"
    extension-element-prefixes="func">

  <xsl:output method="text"/>

  <func:function name="js:escape">
    <xsl:param name="text"/>
    <func:result select='regex:replace($text, "&apos;", "g", "\&apos;")'/>
  </func:function>

  <xsl:template match="/">
var g_books = [
<xsl:apply-templates/>
];
  </xsl:template>

  <xsl:template match="book">
<xsl:if test="position() > 1">,</xsl:if> {
id: <xsl:value-of select="@id" />,
name: '<xsl:value-of select="js:escape(title)"/>',
first: '<xsl:value-of select="js:escape(author/first)"/>',
last: '<xsl:value-of select="js:escape(author/last)"/>',
publisher: '<xsl:value-of select="js:escape(publisher)"/>'
}
  </xsl:template>

</xsl:transform>

[Uche Ogbuji]

The article “Generate JSON from XML to use with Ajax”, by Jack D Herrington, is a useful guide to managing data in XML on the server side, and yet using JSON for AJAX transport for better performance, and other reasons. The main problem with the article is that it uses XSLT 2.0. Like most cases I've seen where people are using XSLT 2.0, there is no reason why XSLT 1.0 plus EXSLT doesn't do the trick just fine. One practical reason to prefer the EXSLT approach is that you get the support of many more XSLT processors than Saxon.

Anyway, it took me all of 10 minutes to cook up an EXSLT version of the code in the article. The following is listing 3, but the same technique works for all the XSLT examples.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
    xmlns:func="http://exslt.org/functions"
    xmlns:str="http://exslt.org/strings"
    xmlns:js="http://muttmansion.com"
    extension-element-prefixes="func">

  <xsl:output method="text" />

  <func:function name="js:escape">
    <xsl:param name="text"/>
    <func:result select='str:replace($text, "&apos;", "\&apos;")'/>
  </func:function>

  <xsl:template match="/">
var g_books = [
<xsl:apply-templates/>
];
  </xsl:template>

  <xsl:template match="book">
<xsl:if test="position() > 1">,</xsl:if> {
id: <xsl:value-of select="@id" />,
name: '<xsl:value-of select="js:escape(title)"/>',
first: '<xsl:value-of select="js:escape(author/first)"/>',
last: '<xsl:value-of select="js:escape(author/last)"/>',
publisher: '<xsl:value-of select="js:escape(publisher)"/>'
}
  </xsl:template>

</xsl:transform>

I also converted the code to a cleaner, push style from what's in the article.

[Uche Ogbuji]

“Dynamic SVG features for browsers”

Subtitle: Build on SVG basics to create attractive, dynamic effects in your Web projects
Synopsis: Learn how to use dynamic features of Scalable Vector Graphics (SVG) to provide useful and attractive effects in your Web applications. SVG 1.1, an XML language for describing two-dimensional vector graphics, provides a practical and flexible graphics format in XML. Many SVG features provide for dynamic effects, including features for integration into a Web browser. Build on basic SVG techniques introduced in a previous tutorial.
Lead-in: SVG is a technology positioned for many uses in the Web space. You can use it to present simple graphics (as with JPEG) or complex applications (as with Macromedia Flash). An earlier tutorial from June 2006 introduced the basic features of the format. This tutorial continues to focus on SVG for Web development, as it demonstrates dynamic effects that open up new means of enhancing Web pages. The lessons are built around examples that you can view and experiment with in your favorite browser.
Developed by the W3C, SVG has the remarkable ambition of providing a practical and flexible graphics format in XML, despite the notorious verbosity of XML. It can be developed, processed, and deployed in many different environments -- from mobile systems such as phones and PDAs to print environments. SVG's feature set includes nested transformations, clipping paths, alpha masks, raster filter effects, template objects, and, of course, extensibility. SVG also supports animation, zooming and panning views, a wide variety of graphic primitives, grouping, scripting, hyperlinks, structured metadata, CSS, a specialized DOM superset, and easy embedding in other XML documents. Many of these features allow for dynamic effects in images. Overall, SVG is one of the most widely and warmly embraced XML applications.
Dynamic SVG is a hot topic, and several tutorials and articles are available that include fairly complicated examples of dynamic SVG techniques. This tutorial is different because it focuses on a breadth of very simple examples. You will be able to put together the many techniques you learn in this tutorial to create effects of whatever sophistication you like, but each example in this tutorial is simple, clear, and reasonably self-contained. The tutorial rarely deals with any SVG objects more complex than the circle shape, and it keeps embellishments in scripting and XML to a minimum. The combination of simple, step-by-step development and a focus on real-world browser environment makes this tutorial unique.

Pay attention to that last paragraph. There are many SVG script/animation tutorials out there, including several by IBM developerWorks, but I found most of them don't really suit my learning style, and i set out to write a tutorial that would have been ideal for me when I was first learning dynamic SVG techniques. The tutorial covers CSS animation, other scripting techniques and SMIL declarative animations. It builds on the earlier tutorial “Create vector graphics in the browser with SVG”.

See also:

• Copia announcement of the first SVG tutorial
• Copia announcement of “XML in Firefox 1.5, Part 2: Basic XML processing”
• Copia announcement of “XML in Firefox 1.5, Part 3: JavaScript meets XML in Firefox”

[Uche Ogbuji]

“XML in Firefox 1.5, Part 3: JavaScript meets XML in Firefox”

Subtitle: Learn how to manipulate XML in the Firefox browser using JavaScript features
Synopsis: In this third article of the XML in Firefox 1.5 series, you learn to manipulate XML with the JavaScript implementation in Mozilla Firefox. In the first two articles, XML in Firefox 1.5, Part 1: Overview of XML features and XML in Firefox 1.5, Part 2: Basic XML processing, you learned about the different XML-related facilities in Mozilla Firefox, and the basics of XML parsing, Cascading Style Sheets (CSS), and XSLT stylesheet invocation.

Continuing with the series this article provides examples for loading an XML file into Firefox using script, for applying XSLT to XML, and for loading XML with references to scripts. In particular the latter trick is used to display XML files with rendered hyperlinks, which is unfortunately still a bitt of a tricky corner of the XML/Web story. I elaborate more on this trick in my tutorial “Use Cascading Stylesheets to display XML, Part 2”.

See also:

• Copia announcement of the first article
• Copia announcement of the second article
• More on the XML+CSS tutorial series

[Uche Ogbuji]

Sylvain and I have discussed recently his discomfort with Web browser state of the art in the age of AJAX (to use a grand term, even though I strongly believe that AJAX is nothing but an incremental gathering of conventions rather than anything new and special). He has gathered his thoughts in a blog posting "The chicken and egg problem". I posted a comment, but I thought I might copy the comment here as well.

[Let me summarize] in brief my reasons for thinking that the current system is not broken, and that we do not need to change anything fundamental about browsers.

First of all the basic semantic of "link history" in a Web browser has not changed since the Mosaic days for a very good reason: it is empirical to HTTP, REST and all that. At each point a browser is at a particular resource, and it moves from one resource to another according to actuation of simple REST verbs. Within each resource the browser can do all sorts of complex things, including showing animations (Shockwave, SVG, etc.), providing mini-applications to the user (Java applets, Flash, AJAX, etc.) and more, but the resource has not changed. The boundary of resource is defined by the service provider, and the browser simply reflects that in the history, URL bar and other features. I don't think the back and forward buttons should be overloaded for any operation within a resource. They should not be used as hot buttons in Flash apps or in AJAX apps. This violates the layering that is so important to the success of the Web.

If service providers want to provide navigation within a particular resource, they should do so within the application, and not at the REST level. I want my Front office app to have an "Undo" button (which makes much more sense than "Back"). [Why do I need chameleon browser chrome when I can just do <xforms:button id="undo"><xforms:caption>Undo</xforms:caption>...</xforms:button>?] When I click browser "Back" I want that to exit the application and go to the previous resource.

IMO People think they have trouble with the back button and Ajax because they do not appreciate protocol layering very well, and because the AJAX tools do not yet help in this understanding. I think a better understanding of this layering and better tools are what's needed, not a major redesign of the browser idiom.

[Uche Ogbuji]

Sylvain's question about Javascript-without-tears certainly kicked off a chain of interesting dialogue, for me. It also happens to dovetail with some interesting dialog elsewhere that started independently.

Kurt had an interesting take in his follow-up "Javascript and Python"

To be blunt, I would prefer to see a Python interpreter being standard issue in all browsers in addition to a Javascript one, as I believe the language to be much more expressive, more object oriented, more secure, easier to write, and in general better suited to contemporary needs. Unfortunately, browsers in particular are informed as much by business and political decisions, some, perhaps even most, based less upon the best technology for a problem and more based upon what will provide the best backward compatibility to insure that existing websites do not break or that download sizes remain under some critical value.

I like Python as well, but boy do I shudder to imagine the political conflagration that would ensue if Python were elevated in Web programming over peers such as Perl and Ruby. Javascript appears to have carved out a niche as the Switzerland of dynamic languages.

I would like to see diversity in Web scripting languages, so that others have choices besides Javascript, and as Kurt says, Mozilla does seem to be taking the lead in this. It's really cool to see the Mozilla Wiki entry "Breaking the grip JS has on the DOM". And you gotta love the opening lines:

We want to change the grip JS has on the DOM and on XUL. We will do this in 2 steps:

• Change the framework to be language neutral - https://bugzilla.mozilla.org/show_bug.cgi?id=255942
• Create a Python implementation.

Ideally, the first step could be done without consideration for the second, in the assumption at the implementation should be truly language neutral.

But regardless of scripting language, there is the fact that XForms is out there looking to take on the very need for scripting in many of the browser use cases. Kurt says:

I am a major advocate of XML, precisely because it is much more difficult to isolate a language when a mapping is essentially an XSLT transformation away. For this reason, XForms is a very attractive model to be moving towards, certainly, and I look forward to the day that I can build XForms applications that work in all browsers equally. However, XForms is not even remotely widely implemented yet nor are there standard forms of declarative binding languages along the lines of XBL (sXBL is getting there, but so far there are perhaps two still very much test implementations in existence).

Chime predictably takes exception to this (in a response to Kurt). He's been a very involved early adopter of XForms, and I've been amazed to see how productive XForms has made him, so I take his point very seriously when he says:

I beg to differ. Though it may be true that it doesn't quite have the traction that Flash has at the moment, I wouldn't go as far as saying it isn't remotely, widely implemented. There are several very mature implementations...
[...] [re:eliminating the need for an imperative language] Once again, I have yet find myself in a situation where I needed javascript for UI-related capabilities that weren't covered by XForms event processing, instance binding, and other such [programmatic] components. The only time I did was when I had to encode XML content as base64 encoded binary (see: http://copia.ogbuji.net/blog/2005-08-19/BinaryEncodingAndXMLRPCs) and had little to do with XForms but more with the means of remote communication (SOAP). I'm not suggesting that frameworks such as XForms will eliminate the need for an imperative language, but rather that the need will be more like the reverse of your 80/20 proposition.

To be fair, I think Kurt was saying that script is only needed for the 20% case, and not the 80% case. He just felt that declarative solutions architecture "is hideously inappropriate for the remaining 20%." I do agree with that, but I think that people (not Kurt) tend to exaggerate this fact as an argument against declarative programming.

Chime wraps up:

I must give the disclaimer that I'm not suggesting XForms will be a user interface / browser-based application building [panacea], but rather that the potential it has to eliminate the unportable, architecturally unsound code that often drive DHTML web-sites with minimal complexity is very much overlooked.

Based on what I've seen of XForms, I tend to agree. I actually think Chime and Kurt are more in agreement than they sound, except maybe on the matter of the maturity of XForms engines.

At almost the same time another script versus XML exchange was going on in Mark Birbeck's blog, and in particular "On Adobe and XForms via Declarative Programming, Wizards and Aspects". That article is well worth reading in its entirety, but I'll highlight what he says about Wizards:

...in nearly all cases I find the 'wizard approach' is great to get you started, but then very quickly gets complex again. Anyone who uses Microsoft's Visual Studio, for example, will know that getting a C++ application up and running quickly, with support for multiple windows, toolbars, printing and file saving, is a snip. But then when you want to modify that code and move away from the wizard, you are very soon into normal C++ territory.

I tend to put this point even more strongly, as I do in my article "The worry about program wizards", but I'm always happy to have it reinforced.

In some ways I see wizards as the shoddy high street knock-off of declarative systems. Well designed declarative systems fully encapsulate modal aspects of the application in development, and they expose slots for ready extension in imperative implementation, if needed. Wizards, on the other hand, do focus on parameters in a way tantalizingly like declarative systems, but then ruin the entire plot by handing the programmer a hairball of imperative code that they have to hack at arbitrarily in order to complete the application. It's the difference between just plugging a device into a USB port to add capability to your PC, rather than having the motherboard thrust in your face so that you can find the right place to solder in the leads.

Chimezie Ogbuji

Sylvain Hellegouarch wrote in "Client side application frustration"

I don't want to start a flame or whatever so I'll only say that Javascript is far from being THE solution for clientside application IMO. Don't get me wrong, the language itself is interesting and powerful enough for most things you might want to do, but the environment (the browsers) in which it sits is quite not there yet.

It looks like Javascript has never been seen as something browser vendors should pay much attention. So they did implement what the ECMA group had specified but with some variations which doesn't allow the developer to ensure everything will work the same way. For too long Javascript was seen as a toy for doing rollover menus or spamming you with popups all over the place.

He was trying to write a Weblog engine with a lot of the code in the browser and ran into endless portability problems, as well as security concerns and lack of friendly developer tools.

He also tried looking beyond Javascript.

Then I decided to look at SVG, XForm and the WHATWG effort but again I felt frustrated. Those are very well specified but have such a bad support (or none) amongst browsers that they are almost unusable. Should I come back to Java applets? sigh

And he finishes with a question:

So my question now is about the future of client side development, we do have a lot of different choices but there are no clear vision for the average joe like me on which one to focus on neither on how they will cooperate in the future nor what will be the support amongst browsers. Maybe people in the know could clarify things?

Kurt Cagle took up the question in his piece "Is Javascript Dead?", providing some historical perspective and exploring some code patterns as a way to illustrate the language's flexibility.

Javascript has traditionally been considered a lightweight language - useful for web pages, but not something appropriate for larger scale applications. There is some justification for this viewpoint - Javascript is almost invariably interpreted, meaning that it cannot optimize content cleanly prior to running it. While it does have classes (in the sense of functional prototypes), Javascript has no obvious concept of a package, which means that higer order organization can prove complicated and likely to impinge upon namespaces. There are, however, ways around this.

Kurt goes on to show an example of Javascript's elegance by turning what most people write as gruesome forms element processing logic completely inside out, and mapping events quite naturally to classes and functions. He concludes:

I think the final point of all of this is that, far from being too primitive for use with existing technology, Javascript is in point of fact still very relevent, and if anything is finally reaching a point where it can hold its own against just about every other programming language out there, at least within the domain of the manipulation of DOMs (or XML). Given the incipient emergence of E4X, I fully expect Javascript to become one of the predominent languages on the planet.

Kurt doesn't touch on Sylvain's concerns about portability, security and development environment, and those are still matters that need serious discussion (for one thing, they are issues that have always interfered with my productivity in Web development). I see Kurt's post as a bit of advocacy to underscore for developers why some of the pain is worth enduring. I look forward to more posts on the topic.

[Uche Ogbuji]