People on HN love ripping on Adobe. I agree that the code is gross, but can we get some constructive criticism? What's a better way to programmatically write good HTML? I'm willing to bet everybody on this thread writes their HTML by hand. How many of you have a framework for programmatically writing HTML? How many have a framework for writing HTML as broadly as Muse can?
Adobe will get my constructive criticism when they build something worthy of it, and not a second sooner.
I recommend reading this post by Zeldman from last year: http://www.zeldman.com/2010/07/05/an-indesign-for-html-and-c... 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.”
Good article, except for this minor point: > 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 current…
Didn't someone write an algorithm for music generation that produced pieces styled after classical composers that actually did have their style?
I can't find the page right now, but it had samples and they sounded quite good.
So they use tables. Big deal. I don't get that CSS snobbery. Tables do work on even older browsers. That's something you want for a tool that generates code for people who don't want/can't put up with writing HTML themselves. For them the product has to work and look good in most of the browsers.
So they use tables. Big deal. I don't get that CSS snobbery. Tables do work on even older browsers. That's something you want for a tool that generates code for people who don't want/can't put up with writing HTML themselves. For them the product has to work and look good in most of the browsers.
It's not CSS snobbery. It's HTML snobbery, which to some people still matters, for the usual accessibility reasons as well as wanting to write the correct code for the job.
Sure, but if you're hired to write HTML code then I guess you won't be using tools like this. You know how to work around browser perks. But Joe who just wants a website made probably doesn't - and he doesn't care.
This software, Muse, was not used to build that website.
The software used is Business Catalyst (http://businesscatalyst.com/), an enterprise CMS (all-in-one solution urgh) Adobe bought 2-3 years ago. And yes, the semantics are very bad.
How about we've progressed to the state where HTML is the bytecode you don't want to see anyway, and designers can use modern tools to manipulate it? If the generated markup works, cross-browser and cross-platform (I don't know to what extent it does, but let's assume so), then what's the problem? For many purposes, optimizing the HTML nerd out of the process is a much bigger win than a 20k download (don't forget gzi…
In this case it's a 78k download, of just text. That adds up over enough users. It adds to page load times, it adds to page rendering times, it adds to bandwidth costs. And then there are the higher level issues. What happens when you get a bug report about how the page is rendered in a specific browser/OS? Do you want to wade through 1500 lines of html or 100 lines? Which do you think will be easier and faster to fi…
Quite. It all adds up and it's unnecessary. It's not green. It's wasteful. It's not elegant. But I fear it is the way things are going, because I've seen this before -- I used to write games in lovely, pure, beautiful assembly language, then folks started using C etc because it was easier and, hey, hardware like the Amiga could still run the games fast anyway. And then the hardware got to a point where it was all so complicated only a madman would contemplate assembly language...
I'm definitely playing the devil's advocate here, but didn't assembly programmers have the same kind of reaction regarding compiler generated assembly not so long ago?
Assembly is low level; practically machine code. It is hard for humans to read, and writing a program concept in assembly must go through a lot of layers.
HTML is high-level and designed for humans to read and write. It maps directly to the concepts it conveys.
This software, Muse, was not used to build that website. The software used is Business Catalyst ( http://businesscatalyst.com/ ), an enterprise CMS (all-in-one solution urgh ) Adobe bought 2-3 years ago. And yes, the semantics are very bad. In fact, I disliked this piece of software so much, I wrote a post about it a few months ago: http://arnorhs.com/2011/01/19/11-reasons-why-business-cataly...
The only thing I see is that the jquery is served from a CDN address that has catalyst in the name. Where else do you see something pointing at Business Catalyst?
WYSIWYG for HTML is just never a good thing. You spend more time learning the idiosyncrasies of a crippled GUI when you could just get busy in a text file.
I agree! I also think compilers are ridiculous. You spend much more time tuning their output and learning their arcane options and switches and pragmas than you would need just writing ASM by hand.
People make the same mistake again and again with code generation and this goes back as far as CASE tools and Microsoft wizards. The key thing is that you should never use anything where you cannot "debug at the level of the abstraction" as Dave Thomas puts it (Smalltalk Dave, not the pragprog guy). That's why the analogy with a compiler breaks down: You never have to debug the assembly or look at it for any reason except if you are doing real embedded stuff and even there if you end up having to look at or debug the generated assembly frequently then it would be better to work exclusively in assembly. i.e. Its hard enough to map a program into your head, doing it at two levels is impossible to do without making a mess.
People (including me) like to delude themselves though. "I'm not a web/database/embedded developer. Here's a tool that will give me a quick win". But in the end because you find yourself debugging the mess that it generates you have to rewrite by hand anyway meaning that in the long run a quick win turned out to be twice as long as just sitting down and learning how to do it. BTW I think that DSL's could be the next thing that leads people down this path. A great idea but...