Please, tell me this is Adobe trying to mock IE. It has to be, right?
I mean, they've always sort of not valued source code, but this is beyond torturing it.
Indeed. The inefficiency here is astounding, especially considering the relatively straightforward page layout involved.
Original: 1496 lines, 77.9kB
Your version: 104 lines, 4.75kB
I'd thought we'd progressed beyond the state of a decade ago where Dreamweaver or what-have-you would build you a cumbersome and baroque html splooge to match whatever you had done in the designer, but I guess we haven't advanced that far. Just goes to show you that front-end devs are still as necessary as ever I suppose.
Dreamweaver required you to know quite a bit about HTML. Muse is like InDesign/Photoshop, which people use to do mockups of designs (not UIs/wireframes) today. It cuts translation to code from the workflow. That's a meaningful shortening of the feedback loop for a designer.
As for the rest of us, we don't have to be concerned till Muse starts learning the quirks and features of CSS faster than ourselves.
The original does have at least one advantage: preloaded hover images. It's nice for them to improve usability a tiny bit, along with all the bloat. I can't imagine a complete newcomer to HTML and CSS hacking together a page and having it come out nearly as bad. Any designer who can learn design can easily learn to code better than Muse, in my opinion.
Thanks for that. I know a little about ancient-style table-layout web dev, but didn't know what the "proper way" of laying out that site would have been.
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.
> 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.
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.
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.
Hi Arnorhs,
I am Alexandru working for Adobe, and I recently took over Business Catalyst.
We did read your review and took it at heart - it wasn't easy as you were very direct. However, there is a lot of truth in your review and there's a lot for us to improve. And believe me, that's our goal - to improve the product until customers love it and we have folks like you give us much better reviews :) - because you would actually like the product.
I'd love to chat with you and try to show you where we're going and get your perspective on what should we do differently. Your feedback would be very important for us.
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?
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?
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.
Regarding constructive criticism, I posted elsewhere in this thread that Muse generated a div to preload hover images. It's a nice bit of usability optimization, but the code could certainly benefit from a dose of minimalism. Even if Muse initially generates the page with this much bloat, I'm thinking it would be trivial [for Adobe] to run the page through an optimizer that rips out anything without style assigned to it. Then it could refactor the stylesheets, getting rid of redundancies, i.e. styles targeting p.paragraph and the like, and run a second round of optimization. Maybe I'm thinking about it wrong, but it would be worth the effort if they could cut the page into even a tenth the original size, which is a gross under-expectation.
I have some scripts i use to generate my html. i don't have a framework for generating HTML in as broad a scope as muse because that is a bad idea. Beyond a certain level of complexity, you actually need to stop and think about things.
The right way to do a GUI HTML editor is to provide some templates and some customizations.
Well, at least they're using it. It hurts adoption if people perceive Microsoft to be tepid about WPF or Google with regards to Go. But Adobe is clearly dogfooding.
Since everyone is saying look at the source, might I suggest taking a look at the CSS that is produced for that specific page ... yes, I said page. Each page has its own CSS file that is REALLY big.
The sense I am getting is that GUI generation of markup code is as inevitable as was the first compiler back in the old days. Whether that point is now or not remains to be seen. Back then we had a combination of increase in RAM sizes/processor speed and democratization of Computers beyond advanced research laboratories, that prompted this change. It no longer was necessary to worry about that extra 10 KB or so of cruft that the compiler added.
I see similar concerns about file sizes here, whether the point of not caring for bandwidth is here remains to be seen. And could this be the second wave of web democratization? I'd love to see my mum design her website with this.
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.
As Deestan said, there's a massive difference between how low level assembly code is, and how high level HTML is. But even more than that is the fact that they're fundamentally different. Decomposing a sequential list of instructions down into machine code is something that a is fairly simple to do algorithmically. But HTML is not a programming language - it is a descriptive instead of declarative or imperative.
In the end, humans are a lot better at describing things than algorithms, and I think that's the biggest problem with WYSIWYG HTML editors.
Has anyone seen the video? They're trying desperately to map print paradigms to the web. It's a major fallacy which many developers (and product managers) fall into.
On a casual inspection this is just bloated ineptness, exactly what I have come to expect from Adobe.
One passage consisted of a string of empty divs of the form <div class="wrap"></div> which a decent 'code generator' would simply have omitted. In fact the bulk of the bloat appears to be divs which add nothing to the page.
I strongly suspect one previous version of this code generated tables, then they got the "tables used for layout are bad" memo and did a simplistic translation to nested divs.
Perhaps, to be charitable, they have debugging turned on.
This is a great product, insofar as 10-year-olds will steal it from BitTorrent and use it to get their first taste of web design, then stop using it once they get serious, then reminisce about how terrible their first projects were. Just like lots of us did with FrontPage.
<div id="yo-dawg">
<div id="i-put-div-in-your-div">
<div id="so-you-can-div-while-you-div">This site built in Muse (code name) by Adobe®</div>
</div>
</div>
[+] [-] pierreminik|14 years ago|reply
This is so inspirationally horrible someone spent hours remaking it, like it should've been: http://studentweb.infotech.monash.edu/~wlay/FIT1012/muse-dem....
[+] [-] InclinedPlane|14 years ago|reply
Original: 1496 lines, 77.9kB
Your version: 104 lines, 4.75kB
I'd thought we'd progressed beyond the state of a decade ago where Dreamweaver or what-have-you would build you a cumbersome and baroque html splooge to match whatever you had done in the designer, but I guess we haven't advanced that far. Just goes to show you that front-end devs are still as necessary as ever I suppose.
[+] [-] godsped|14 years ago|reply
http://i.imgur.com/otaOc.png
[+] [-] doublesprout|14 years ago|reply
As for the rest of us, we don't have to be concerned till Muse starts learning the quirks and features of CSS faster than ourselves.
[+] [-] tiddchristopher|14 years ago|reply
[+] [-] chadgeidel|14 years ago|reply
[+] [-] AlexCP|14 years ago|reply
[+] [-] armandososa|14 years ago|reply
[+] [-] potatolicious|14 years ago|reply
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.
[+] [-] loup-vaillant|14 years ago|reply
> 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).
[+] [-] snorkel|14 years ago|reply
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.
[+] [-] bad_user|14 years ago|reply
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.
[+] [-] Sniffnoy|14 years ago|reply
[+] [-] Zak|14 years ago|reply
[+] [-] protomyth|14 years ago|reply
This was with a single vendor spec that was fairly comprehensive. The web is a loose spec with multiple vendors.
[+] [-] arnorhs|14 years ago|reply
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...
[+] [-] acostin|14 years ago|reply
We did read your review and took it at heart - it wasn't easy as you were very direct. However, there is a lot of truth in your review and there's a lot for us to improve. And believe me, that's our goal - to improve the product until customers love it and we have folks like you give us much better reviews :) - because you would actually like the product.
I'd love to chat with you and try to show you where we're going and get your perspective on what should we do differently. Your feedback would be very important for us.
If you're interested, please contact me at [email protected]
Sincerely,
Alexandru
[+] [-] rb2k_|14 years ago|reply
[+] [-] phsr|14 years ago|reply
[+] [-] jeffreymcmanus|14 years ago|reply
[+] [-] lean|14 years ago|reply
[+] [-] cloudwalking|14 years ago|reply
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?
[+] [-] sunchild|14 years ago|reply
[+] [-] tiddchristopher|14 years ago|reply
[+] [-] mun2mun|14 years ago|reply
[+] [-] notatoad|14 years ago|reply
The right way to do a GUI HTML editor is to provide some templates and some customizations.
[+] [-] libria|14 years ago|reply
[+] [-] tomelders|14 years ago|reply
Until then, deal with it.
[+] [-] X-Istence|14 years ago|reply
[+] [-] rrrazdan|14 years ago|reply
[+] [-] mattmanser|14 years ago|reply
We've already trod this path and it lead us to dark places.
[+] [-] nfm|14 years ago|reply
Almost the entire page is duplicated within a `<!--[if lt IE 9]>` block...
[+] [-] antimora|14 years ago|reply
[+] [-] olalonde|14 years ago|reply
[+] [-] Deestan|14 years ago|reply
HTML is high-level and designed for humans to read and write. It maps directly to the concepts it conveys.
[+] [-] perlgeek|14 years ago|reply
[+] [-] stephen_g|14 years ago|reply
In the end, humans are a lot better at describing things than algorithms, and I think that's the biggest problem with WYSIWYG HTML editors.
[+] [-] josscrowcroft|14 years ago|reply
I think compounding all this inefficiency is how they have "<!-- group -->" on EVERY SINGLE DIV.
Someone should use the Tilt extension to visualise this page in 3D (http://hacks.mozilla.org/2011/07/tilt-visualize-your-web-pag...) and screen cap it.
[+] [-] alfiejohn_|14 years ago|reply
[+] [-] M1573RMU74710N|14 years ago|reply
[+] [-] jjm|14 years ago|reply
[+] [-] mambodog|14 years ago|reply
[+] [-] zacharyvoase|14 years ago|reply
[+] [-] azulum|14 years ago|reply
[+] [-] epo|14 years ago|reply
One passage consisted of a string of empty divs of the form <div class="wrap"></div> which a decent 'code generator' would simply have omitted. In fact the bulk of the bloat appears to be divs which add nothing to the page.
I strongly suspect one previous version of this code generated tables, then they got the "tables used for layout are bad" memo and did a simplistic translation to nested divs.
Perhaps, to be charitable, they have debugging turned on.
[+] [-] QuantumDoja|14 years ago|reply
Q. How many times do you inspect the compiled assembly to see what it generated?
One day these tools will be perfect, it's just a shame for me that Adobe have copied what I've done for the second time: http://blog.gameweaver.com/2011/08/16/has-adobe-copied-anoth...
[+] [-] RobLach|14 years ago|reply
http://i.imgur.com/c7tBl.png http://i.imgur.com/6DUW0.png http://i.imgur.com/sfGmv.png
[+] [-] beatpanda|14 years ago|reply
[+] [-] kysol|14 years ago|reply
<div id="yo-dawg"> <div id="i-put-div-in-your-div"> <div id="so-you-can-div-while-you-div">This site built in Muse (code name) by Adobe®</div> </div> </div>
[+] [-] jmitcheson|14 years ago|reply
http://www.medialab.com/
I don't know what the output is like, though.