There's a reason why C compilers aren't implemented as editor macros that convert what you type into assembly, as you type it. It's because a high-level programmer never wants to work at that low level; he should never see the lower level. Ideally, he shouldn't even know that the lower level exists. (When was the last time you debugged your CPU microcode?)
If something is so cumbersome that it needs to be abstracted away, do it right. It's really fun to press a few keys and watch a bunch of code show up, but it's even more fun to not watch it show up. Because then you have something that's not a write-once operation.
I'm not sure I understand your point: Zen Coding just makes it easier to write HTML (like autocompletion in an IDE) instead of translating it into some other language (like your Assembly example).
The point is that, while Zen Coding is easy to manipulate (C), it's being converted to something hard to manipulate (Assembly) as you go, making it challenging to go back and rearrange things.
I see HTML as very easy to read but bothersome to type.
You really can't compare the level of complexity of HTML vs. assembler or microcode, especially as HTML has no control structures like a for, a while or a setjmp.
Now, if HTML were not so easy to parse-at-a-glance, then you could had a point.
If you want to optimize for other people's productivity, that's fine. But that's not what's best for you.
Also, there is a simple solution to this problem -- a program that converts $foo into HTML and a program that converts HTML into $foo. pandoc is an example.
Which me? Me the business owner that hires both web designers and programmers? Me the team leader that needs to manage a heterogeneous group of people, each with a different skill-set? Me the one-man-shop (and programmer) who outsources the design work?
If I have both web designers and programmers on my team having them communicate can most certainly be my problem (or at the very least a problem I am gravely effected by).
You can say that about any new tech, but truth of the matter is that there are certain advantages to using well know & widely used tech.
I'm not talking about zen-coding or pandoc or any tool specifically, you can make the same argument for e.g. clojure vs java: as much as you'd like to use the shiny new tech, you must at least consider the fact that it's a hell of a lot easier to find x new programmers that can use java proficiently than even x/10 that can use clojure proficiently.
It doesn't mean it should be the overriding deciding factor, but the cost of retraining/learning should at least be taken into account when making that decision.
Zen Coding seems like the Haml philosophy implemented as code completion rather than as a run time compiler. The upside is that the markup you generate is plain old HTML that any web framework can serve. The downside is that it has the readability of plain old HTML.
For me, its never been the initial coding of HTML that was the problem; there's always been plenty of text-editor solutions like auto-close and find-matching tags. Instead, the PITA of HTML is refactoring it and moving bits around, which is what Haml alleviates, but this does not.
And that upside would go away, because you could just configure your deployment tool to do the 'rendering' upon deployment, generating HTML that could be served by any framework.
The thing I don't like about all these ways to "improve" HTML/CSS is that they all seem to assume the rest of the webapp ecosystem doesn't exist.
Take SASS's variables and arithmetic, for instance. I agree that CSS desperately needs some way to abstract out common values. But any decent webapp will already be using some sort of template system, and the template system will have some sort of variable. Why not use it and be consistent with the rest of your UI? If you introduce SASS into the mix, you just have to do things one way in your CSS and another way in your markup.
Same thing with Zen Coding. Instead of using an editor plugin that expands abbreviations (which then have to be maintained), why not use your template system and avoid writing all that code in the first place? If I were writing the example listed here, it'd look something like this:
(That's using google-ctemplates because it's what I work with daily, but substitute in Django, Cheetah, Mako, or erb as necessary.)
Yes, there's still room for improvement, and yes, I wish my editor were more aware of available template variables. But I also don't have to maintain the 5 separate <td> tags once I've typed them out, I can change one and have its updates be reflected across all the generated code. I can avoid those pesky closing tags by simply not typing them; the HTML spec doesn't require them, all browsers handle it fine, and it saves end-user latency as well. And I don't need to learn a new tool, I just have to use my existing tools better.
The upside of having a system like SASS is that it can be a lot smarter about the underlying system it's generating content for, which you don't get if you use a general-purpose template system. Selector nesting in SASS is a good example of this. It makes both the styling and page structure a lot easier to understand, which is a bigger win in my book than the typing it saves.
I see a system like Zen Coding not for tackling the same tasks as a template system, where the bulk of your work effort might be spent. It's for the irritating little bits around the edges where, instead of taking 5 minutes per page bashing out boilerplate, it now takes 30 seconds. Not a huge win, but a win nonetheless.
You could do CSS in a templating system, sure. First off, you'd want to cache it, but that's a solved problem. And you'd be well served to cook up some subtemplates/helpers/whatever that automated away some of the drudgery. Pretty soon you'd have more ideas on how to keep your CSS more maintainable, your subtemplates would become more general, etc.
At this point you have implemented most of Sass/Less/etc but you have a bunch of templating gunk, less documentation, and hundreds fewer eyeballs looking at the code. Or, you have not implemented most of Sass/Less/etc and you are still writing CSS like a chump.
But it would be the same templating gunk that is used by the rest of your webapp, which most likely has more documentation and thousands more eyeballs looking at the code than Sass. Most people don't roll their own templating systems. They use an established library that's been battle-tested on websites before. These libraries have been around a lot longer than Sass/Haml has.
I feel similarly about all these HTML improvements (although i would love some CSS variable action like in SASS).
Almost any homepage I create that's not a one-shot throwaway for a client is going to running on top of some sort of framework. That means that for any table like this, I'm only going write a single row (at most), and then have my framework iterate over it and turn it into pretty code.
I love any time-saving or code-saving functions and features in my code as much as the next guy, but this seems like an unnecessary complication to already rather streamlined coding.
Also the fact that any IDE with decent auto-complete will be able to do the same thing with just three strokes instead of all that. (For example, in Eclipse if I type "<tab" then press enter, I get a fully formed pretty table in 5 key strokes.
I think there's a market for this in people who develop small brochure sites or for whipping up HTML comps. You have to start the template from something, no?
I find this odd. It's been awhile since I have done dedicated front-end work, maybe 5 years or so, but it was never writing this kind of code that was the real time suck, it was always making sure it worked in every browser that was the real problem.
Is writing TONS of HTML really a problem that needs solving? Are people writing Bible-Tome sized pieces of markup? This feels like a solution in need of a problem.
When i want to code HTML i use HTML.vim (for vim of course). Of course, you have to memorize some keystrokes such as ";bo" for bold. or ;fo for font or ";fc" for font color etc, but these are really easy.
I'd be interested in knowing if this is available for some OS X editor (pref a free one) and whether they have vim support. (Cant recall if TextWrangler is free)
Towards the bottom is a pretty long list of what it's available for.
There are several OS X apps it supports, but Aptana is the only free one I believe. It's quite good if you can deal with how big of a program it is - you should check it out if you haven't already.
I've seen it implemented as a binary, so VIM can call it (I think someone wrote a plugin already). There's a version for textmate that works quite well.
This plugin really shines in conjunction with your editor's power features. I use Zen Coding with the SublimeText editor's multiple and reflective selections.
If something is so cumbersome that it needs to be abstracted away, do it right. It's really fun to press a few keys and watch a bunch of code show up, but it's even more fun to not watch it show up. Because then you have something that's not a write-once operation.