Live data from Hacker News

Oh, Adobe... read the copy, then view the source.

muse.adobe.com

51–60 of 151 posts

Re: Oh, Adobe... read the copy, then view the source.

#51

Earlier quoted context omitted.

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…

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 fix? Which do you think will be easier to inspect for correctness from the start? What happens when you need to figure out why your page is rendering too slowly? Which is easier to analyze, which is easier to speed up? What happens when you want to change the design? What happens when you want to take the design and use it as a UI for a web-app?

Using a tool that generates such crappy HTML may allow an inexperienced person to create a web page with a decent appearance, and it may even save an experienced designer a few minutes upfront. But over the lifecycle of a project it ends up being an enormous drain. If you're an enthusiastic teen putting up a web page for your mother's knitting circle, it's fantastic! But this is not in any sense a truly professional tool.

Re: Oh, Adobe... read the copy, then view the source.

#52
post #8

Bridge to Engine Room: We need more DIVs

Cap'n, Engine Room here - We've diverted emergency DIVs to sensors, increasing noob sensing range. We'll need more add-ons if yer want mowr DIVs!

I read this in my "Enterprise problem of the week" voice.

Re: Oh, Adobe... read the copy, then view the source.

#53

Earlier quoted context omitted.

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.

If modern compilers were as inefficient and horrid as html design tools were a lot of people would code directly in ASM.

Also, HTML is not ASM, it's a very high level language. The ability to code a scant few hundred lines and nevertheless have that become a full-featured, rich, beautiful, and complete layout for a web page or a web app UI is tremendously powerful, and it's no wonder that high end web devs and designers take advantage of that. Until web design "compilers" approach anywhere within spitting distance (even within a factor of 2) of hand coded designs in terms of maintainability, cross-browser compatability, performance, and code size that's not going to change.

Re: Oh, Adobe... read the copy, then view the source.

#54
post #24

Earlier quoted context omitted.

But first tell me why designers need html page generator? Is learning HTML and css that much hard in google era?

Do you really think everyone has 100+ hours to spend learning the idiosyncrasies of HTML and CSS? That's asking a lot for someone that just wants to put up a landing page for an idea, or to design their portfolio. Everytime my artist friend wants to put their portfolio online, I suggest they start by writing some simple markup and half an hour later I'm explaining the finer points of the box model while they whinge a…

For layman person wanting to create a website with static page it is ok. But I am talking about professional web designers who creates templates for dynamic web page. Why the hell they would prefer generator like this? In the long-term it will turn into maintenance hell.

Re: Oh, Adobe... read the copy, then view the source.

#56

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.”

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.

Re: Oh, Adobe... read the copy, then view the source.

#57
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.

Re: Oh, Adobe... read the copy, then view the source.

#58

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. This is so inspirationally horrible someone spent hours remaking it, like it should've been: http://studentweb.infotech.monash.edu/~wlay/FIT1012/muse-dem... .

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…

And how much is it compressed? Let's see...

  ~ $ curl -s 'http://studentweb.infotech.monash.edu/~wlay/FIT1012/muse-demo/' | gzip | wc -c
    1741
  ~ $ curl -s 'http://muse.adobe.com/index.html' | gzip | wc -c
   11521
Hmm, so 11.5kB vs 1.7kB with gzip, which I believe browsers can usually handle. That's a factor of 6.6, incidentally. I don't know much about this, but might it still be ok?

I thought to check this because of ridiculousfish's old article (note the FAQ at the bottom, "Isn't that a humungous flood of markup?"): http://ridiculousfish.com/blog/archives/2009/06/01/roundy/#f...

Re: Oh, Adobe... read the copy, then view the source.

#59
post #18

Earlier quoted context omitted.

Sprite sheets?

I can't tell whether you're suggesting a solution or taking a guess as to what Muse did. I think it's the latter. Sorry if I interpreted your question incorrectly. :) They're using a hidden div full of elements to load the hover images before they're requested by an actual hover. It's all the way at the bottom of their code code: [Removed for brevity] Sprite sheets are another option (using the sliding doors techniqu…

Or you could inject them into the Dom so they load, but don't exist anywhere on the page..

Re: Oh, Adobe... read the copy, then view the source.

#60
post #20

"You can design and publish original HTML pages to the latest web standards without writing code" - WTF I think compounding all this inefficiency is how they have " " 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.

http://dl.dropbox.com/u/661094/tilt.png

[deleted]
Post reply on HN