Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

muse.adobe.com

Post reply on HN
Print view View original

121–130 of 151 posts

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

#121

Post by coliveira »

InclinedPlane wrote: post #53
skrebbel wrote: post #26

Earlier quoted context omitted.

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 design…

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

Well, compilers may be good for languages such as C++. But for most languages such as Python and Ruby, the code executed is just plain terrible compared to ASM. I don't see anyone writing Ruby code and complaining about that waste, though...

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

#122

Post by william42 »

bherms wrote: post #20
josscrowcroft wrote: post #9

"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

Now do it for the remake posted up in this thread.

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

#124

Post by stephen_g »

olalonde wrote: post #36

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?

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.

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

#125

Post by mkopinsky »

pierreminik wrote: post #49
barnaby wrote: post #38

Earlier quoted context omitted.

You're forgetting that when several thousand people access a site per second, even a 1kb difference means thousands of dollars of bandwidth cost and fractions of a second of download speed.... let alone 70KB of difference which would bankrupt your company and turn all of your users away. We don't write HTML/JS/CSS by hand because it's fun, that's for sure. We focus on code-reuse and delayed loading plus AJAX (plus gz…

This . And, not to mention no business owner want to get locked into a solution, they want their "data" transferable and standardized to at least some extend. The code this produces is so horrible you've lost all the time spent with it. Muse dies out, and your time spent in it dies with it.

If I had to bet, I'd say most companies using a product like this are not looking to build a site that'll be around for years on end. Most of these sites probably have a shelf-life of two years at most.

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

#127

Post by protomyth »

armandososa wrote: post #47

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

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.

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

#128

Post by SoftwareMaven »

tomlin wrote: post #120
potatolicious wrote: post #56

Earlier quoted context omitted.

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 t…

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…

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.

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

#129

Post by SoftwareMaven »

coliveira wrote: post #116
InclinedPlane wrote: post #51

Earlier quoted context omitted.

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…

I think you are not considering the many websites for which this inefficiency doesn't matter. Sure, if you're write Google's main web page, every extra byte counts. But there are not many web sites where this is even close to be true. For example, there is no big difference in functionality if the Adobe web site takes a few extra milliseconds to load. Customers just want to buy a product and get out of the way. And A…

We aren't talking milliseconds, we are talking seconds to 10s of seconds. At that point, you are risking bounces, which any business-oriented site should fear, even Uncle Bob's Burger Bar.

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

#130

Post by Rantenki »

waterhouse wrote: post #58
InclinedPlane wrote: post #7

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…

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 ri…

Keep in mind that those connections are all going to be stuck in TCP slow start (gradually improving) for the duration of their communications, meaning that the smaller version gets loaded in 2*RTT, as it will probably fit, in it's entirety, in 2 packets. The larger one is going to take 8 or so packets, meaning a lot more RTTs (probably at least 4, assuming aggressive TCP tuning, and possibly 6. Since RTT can easily be 120ms, these can be substantially larger load times, and that can make a huge impact to user impression:

   Even small changes in response times can have significant effects. Google found that moving from a 10-result page loading in 0.4 seconds to a 30-result page loading in 0.9 seconds decreased traffic and ad revenues by 20% (Linden 2006).
edit: It has been pointed out below that rfc2581 is going to mitigate this somewhat, and they are absolutely right, although I don't know what the implementation levels on this are in the real world, so my observations above may be obsolete for newer OSs.
Post reply on HN