Says Nack:
As I noted the other day, “Almost no one would look
inside, say, an EPS file and harrumph, ‘Well, that’s not
how I’d write PostScript’–but they absolutely do that
with HTML.”
There's a good reason for that - clean HTML is not just the territory of pedantic/obsessive designers, it has tangible and important benefits to many sites (note: many, not all).
Sure, if you want a personal homepage, or put up an ode to your dog Scruffy on the internet, tools like this may very well work for you. But in those use cases, we've already had capable tools for years, many of which produce cleaner code than this.
For anything bigger/more professional, dirty/bloated HTML/CSS means a few things:
- Bigger downloads for your visitors, wasting their bandwidth. But whatever, you're not paying for that, right?
- More data transfer for you and your host. That you do pay for.
- Increased latency (sometimes massively) and decreased accessibility for people with slower connections. Given the awesomeness of American broadband performance, that means most of your customers/visitors. More latency = more bounces = fewer visitors buying stuff from you, reading your ad copy, etc etc.
- Increased rendering times. See: bounce rate.
And these aren't negligible effects. The difference between a 10KB and 100KB file is very significant, and you don't need millions of uniques a month to find out the difference.
Dirty EPS files are not the same thing - because unclean PostScript suffers from none of these deficiencies except bigger downloads - which for EPS files has little to no consequence in the typical use case.
And then, on top of all these fine points, you'll get into trouble when you want to do something outside of what the tool provides. Then you need to touch the code, which is a horrible mess; with code this bad you'll want to kill yourself.
Just like PNG output from Photoshop, soon HTML+CSS output from design applications will beat most humans, or at least be reasonably close so that this complaint doesn't apply any more. It's not very hard to do a lot better than the source code of this web site.
Will Google design their homepage with Muse? No, they want to hand optimize it. Will people design websites for small businesses that get accessed a handful of times per day with something like Muse, when its output gets better? Yes. It might not make nerd-sense, but for a lot of sites it does make business-sense to have an increased page size in return for saving a lot of design and development time. Think of it this way: of all the things a person designing a website for a small company might spend their time on, is reducing page size the most profit increasing activity?
For me, this is really about code generators in general. No need to center Adobe out here, as I can't think of a single IDE that doesn't generate all kinds of extra code that, to me, is useless 90% of the time.
You also should keep in mind that Muse is a beta and the Muse site itself was actually written with Muse.
In this case, I think Adobe deserves the benefit of the doubt. They're trying to showcase this product with hopes that people like us will come to the table and give constructive feedback rather than point to the past and say, "See, I told you! Damn Adobe!".
If you don't think this is constructive criticism, don't ever build a product in a space largely influenced by engineers. You need thick skin to be a PM and get feedback from engineers.
Adobe could be learning a ton about their product from this response. If they say to themselves, "Those Developers just want to say, 'See, I told you! damn Adobe!'", they will have wasted a major opportunity to better their product.
Their target market is obviously not developers, and there is a lot of feedback here i would just chuck as interesting but meaningless to the product. There is some, though, that will directly impact whether an engineer will laugh when his non-tech friend asks about Muse or shrugs and says "It's not perfect, but if your needs are light, it'll work" (just like I was telling my father-in-law Dreamweaver would work for the genealogy stories cd he wants to make for the family).
Adobe needs to get the product to the second place.
> Certain kinds of human creativity and expertise cannot be reproduced by machines. […] [machine's] music can never be the Eroica or “This Land is Your Land,” because there is no algorithm with the creative and life experience of Beethoven or Woody Guthrie.
Of course, I agree with the practical point where no current machine can do human art. Because of that we can't currently automatically extract the semantics of an image, or even convert a post-script document into clean HTML. So, it doesn't affect the conclusion in the foreseeable future.
But one can't seriously believe there's no algorithm behind an artist's art without believing in some kind of ghost controlling her brain, and that ghost somehow doesn't run an algorithm. As far as I know, there is no such ghost. It very much looks like our cognition (including our art), is entirely the product of physical processes, even though it definitely doesn't feel like it.
Now, I reckon art is not just the product of some internal algorithm, running in isolation from the rest of the world. We're highly interactive beings, and our output mostly depend on our input. But there is some kind of algorithm which does all these interactions, though it is likely incredibly complex.
My point is, I wouldn't loose hope of automating something that currently, only humans can do. Take spam filters, for example. With very little knowledge, they can take out spam with stunning accuracy. But if no-one told me about Bayesian filters, I would likely try to make the computer parse the whole e-mail like a human, then give up, thinking that only humans can understand those e-mails well enough to filter them (note my mistaken assumption that the spam filter somehow must acquire some high-level understanding of the e-mail to do its job).
No, clean HTML semantics still matters a lot! Forget about programmatic efficiencies like crawlers and page load times. Think about the poor web dev who is handed this steaming heap of bad markup like so:
Management: "We need you to change all the buttons on this web site and enlarge the logo."
Web dev: "OK, these pages were puked out of Muse. Do you have the Muse project files and a copy of Muse for me to install?"
Management: "Muse? What's that? No, we don't have the source files. Can't you just edit the page?"
Web dev: "Sure. After I drink this bottle of Scotch and look for other job postings."
So guess what? HTML is still source code not a machine language.
So guess what? HTML is still source code not a machine language.
Your metaphor would be great, if it wasn't for all the times developers (myself included) have been asked to dig into assembly or bytecode to fix something when the higher level source file had been lost to the ages.
Compared to those, editing machine generated html is a treat.
Somebody else mentioned the benefits of semantic HTML for saving bandwidth / crawlers.
I'm going to mention something else: fluidity.
It is very easy to patch together a good looking design in Photoshop. But the Photoshoped-content does not move. The window cannot get resized. The divs are not flowing, they are not resized or shrunken as the user moves the window handles.
Also, while CSS has many flaws, it does provide separation of presentation from content.
Many authors prefer writing entire books in Latex. Do you know why? It's because of the What-I-See-Is-What-I-Mean style of writing, which is far better as from a single Latex source you can generate HTML, PDF files and optimized ePubs, for whatever medium you desire and have it look exactly as you intended it to look.
HTML is also about developing input-interfaces.
I did work with Delphi, also with the editor in Netbeans called Matisse, which does a kick-job at defining Swing interfaces. Also worked with Visual Studio and with Adobe Flex Builder -- nothing comes close to the ease with which I work with HTML.
Heck, I'm working on a desktop client right now that just embeds a webkit view with native-hooks, simply because I don't feel like learning yet another sucky GUI-toolkit that will disappoint me in one way or another.
Also, I started my webdev carrier by using Adobe Dreamweaver. It was one of the dumbest things I ever did.
I find your largely contextless restatement of the quote a bit odd, when the actual post is quoting that from somewhere else, and explaining why this is so (when out of context the quote seems to imply that this shouldn't be so).
Perhaps a bigger problem than maintainability using external tools (since one could continue to use Muse to edit the page) is performance. The page is slow to render from the cache in Chrome on my not-slow laptop, uses 153M (compared to 35M for the alternate code elsewhere in the comments) and requires the transfer of quite a bit of data (still significant on mobile connections).
Back a number of years, people were actually very concerned with what was in the EPS or PS files. Preflight before publishing was critical to make sure the files didn't overload the printer. A screwed up print run was pretty costly.
This was with a single vendor spec that was fairly comprehensive. The web is a loose spec with multiple vendors.
