The Guilty Carnivore says:

@Luca Candela. Yes I can. I can create websites, with lean chunks of code, that backend developers can easily hook into in order integrate rich application functionality. I can progressively enhance my semantic markup by using the DOM to attach javascript behaviors quite readily. I can return to any project, years later, and instantly understand the underlying structure and easily make updates, swap out content, or bootstrap. If anything seems vague, there are usually comments in markup or javascript that clue me into what was the original intent of any particular chunk of code.

Also, the page is lighter that what would normally otherwise generated from any automated process, allowing for quicker load times, less bandwidth, and thus a better user experience (not to mention lower server bandwidth overages).

All of this is quantifiable from a monetary perspective, as it saves my client money and myself a lot of headaches.

@J David Eisenberg. I don’t disagree with your assertions or analogy, in some respect it’s valid. But currently, there’s nothing for me personally that substitutes my process: take a layered Photoshop document, create semantic markup and structure, then apply CSS and integrating the necessary sliced images (which is becoming less cumbersome process due to CSS3 gaining acceptance). Even with the smallest of projects this is largely a process filled with snap judgement calls at every stage, which at the end of the day no program export or macro currently replicates at any acceptable level. Sometimes you don’t need a jackhammer when a plain ole’ hammer will do the trick just fine.

Jason Santa Maria says:

But while our current tools can certainly stand improvement, no company will ever create “the modern day equivalent of Illustrator and PageMaker for CSS, HTML5 and JavaScript.” The very assumption that a such thing is possible suggests a lack of understanding of the professionalism, wisdom, and experience required to create good HTML, CSS, and JavaScript.

True, though I’m sure people said comparable things about movable type or the assembly line. I agree though, it’s unlikely for someone to make this application. Certainly not Adobe. They’ve long since fallen out of favor as the corporation that understands and inspires their customers. Now they seem to languish in blissful ignorance of modern production processes.

I think, at least in the shorter term, the answer lies not in an application that can do all of these things for someone, but in an application that can assist them better. An application that acknowledges the ways that CSS works with type, or the way a browser and its variant window sizes render a shape (allowing it to grow and shrink, or remain fixed), and all of the other properties unique to interactive media. I’m not a very big proponent of designing in the browser; I think tuning in the browser is a better flow, but that leaves us with little else to use than tools we sorta hack around to make them work for comping.

Luca Candela says:

@Tom: Paintings in that particular age were more often the expression of a pictorial need than works of art. While some of those are incredible works of art, some of them were just filling the need of a world that didn’t know photographic reproduction. After photography became popular, painting became much less popular and reserved to the “pure art” circle.

@Tom: an engineer designing a car has no idea whatsoever about how a screw is forged, or how a tire is vulcanized. They just read the spec sheet and use whatever they need to make it work.

@Guilty Carnivore: this is not sustainable, that’s the point. When you say better results, you mean better for yourself. Who is that better for? How is hand-coding making things better? Can you put a dollar value on that?

J David Eisenberg says:

@Guilty Carnivore: We insist because ultimately it’s more efficient and gives you more power, understanding, and control of the process.

This is, in some way, a repetition of the old (circa 1974) argument of whether to program everything in assembly language (more efficient and gives you more power/control) or to use one of those new-fangled “compilers.” At one conference, I heard this exchange: The assembly guy said, “Compilers produce code that is only 80% as efficient as the best human coders.” The compiler guy responded, “Yes, but how many ‘best human coders’ do you have working for you?” I realize this is not an exact analogy; a tool-generated page only 80% as elegant as one crafted by hand is going to look extremely ugly. But how many “best human designers” are making web pages? [Side issue: "looking good" is not an issue for some sites, e.g., useit.com]

I tend to agree with @David Sleight: “The task requires a fundamentally different form of GUI that we haven’t seen thus far”

Neil says:

Nicely put.

I think a lot of these code-as-images experiments really are just that: explorations of a cool new shiny. Waiting for adoption of these new tools by browser-makers is one thing, but I don’t think we’ll get to the point of these feasibly replacing images until their rendering performance improves.

The Guilty Carnivore says:

Luca Candela,

We insist because ultimately it’s more efficient and gives you more power, understanding, and control of the process.

Thibaut Sailly says:

These CSS3 based illustration have the merit to explore and demonstrate new possibilities, but don’t they more and more look like dick size contests ?