12 ms·

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 go

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?

sunchild 15y ago
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.
- skrebbel 15y ago
  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.
  - orblivion 15y ago
    Your argument is against haml, not a gui.
    - skrebbel 15y ago
      Oh well I also think vi is ridiculous so there :P
  - fullmoon 15y ago
    Reductio ad absurdum? :(
  - InclinedPlane 15y ago
    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.
    - coliveira 15y ago
      > 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...
  - discreteevent 15y ago
    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...
  - sunchild 15y ago
    Honestly, I don't see how WYSIWYG GUI front-ends for building HTML are at all like compilers for high-level languages. Care to elaborate? I think your analogy will start falling apart pretty quickly.
- schlomie 15y ago
  Yes, I also write all my programs in assembly for the same reason...
- ugh 15y ago
  Why? WYSIWYG works perfectly well in InDesign (which is absolutely awesome, by the way), why can it never work with HTML? I don’t really understand. Current and past implementations are or have been bad, sure, but why can’t it work in principle?
  - intranation 15y ago
    It's hard (not impossible) to make it work in principle because a printing press doesn't need to infer meaning from the post script or whatever you provide it. A browser does need to, so you'd need to layer the extra semantics on top of your WYSIWYG editor. Which means asking questions like "this is 36 pixels high: is it a heading,; or is this just a landing page with big text?" etc. So maybe I lack imagination, but I don't see it being that easy a problem to solve from a UI point of view.
    - ugh 15y ago
      There are plenty of semantics in InDesign documents. InDesign is all about character, paragraph, list and table styles – it’s what you use to make InDesign work. You wouldn’t have to add much to make those styles do all the semantic work. Yeah, you would still be able to just ignore all that – just like you can adjust each headline individually in InDesign – but that would only mean that you are an incompetent user of the software. A good WYSIWYG editor wouldn’t always have to produce great markup but a competent user of the software should be able to easily make it produce great markup. I’m really not that sure why adding a GUI for semantics would be so hard, especially since existing concepts like paragraph or list styles already map very well to HTML concepts.
  - stephen_g 15y ago
    One big part is that when something is designed for print, it is essentially always designed for a fixed size page, so you don't have to deal with resizing. Then there is the fact that web sites have to cope with people not always having the same fonts you do - which makes it almost impossible to do pixel perfect designs involving text rendering. Then there is the fact that something like an Indesign document doesn't really have any concept of separating the style from the actual content. For the time being at least, humans are much better at logically ordering and marking up text, and then adding the style with CSS, unlike programs which add a whole lot of extra markup and CSS to do the same thing. Those are just a few things which make WYSIWIG work a lot better for print than it ever could for web - and there are more... These things will probably be somewhat resolved as time goes on (ie. with wider support for @font-face and so on) but I think that hand written HTML will be better for a long time to come.
- yahelc 15y ago
  WYSINWYG: What You See Is Never What You GEt.
mun2mun 15y ago
But first tell me why designers need html page generator? Is learning HTML and css that much hard in google era?
- tjarratt 15y ago
  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 about how they'd rather be using Adobe Illustrator. The truth is that there will always be a group of people that are able to visualize what they want to create better than they can verbally, or symbolically.
  - josscrowcroft 15y ago
    That's why we have WordPress, Tumblr, etc., even things like launchrock, about.me, shopify, the list goes on.
    - wlievens 15y ago
      You mean things that are (eventually) html page generators?
  - mun2mun 15y ago
    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.
notatoad 15y ago
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.
tiddchristopher 15y ago
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.
libria 15y ago
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.
tomelders 15y ago
Adobe will get my constructive criticism when they build something worthy of it, and not a second sooner. Until then, deal with it.

sunchild 15y ago

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.

skrebbel 15y ago
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.
- orblivion 15y ago
  Your argument is against haml, not a gui.
  - skrebbel 15y ago
    Oh well I also think vi is ridiculous so there :P
- fullmoon 15y ago
  Reductio ad absurdum? :(
- InclinedPlane 15y ago
  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.
  - coliveira 15y ago
    > 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...
- discreteevent 15y ago
  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...
- sunchild 15y ago
  Honestly, I don't see how WYSIWYG GUI front-ends for building HTML are at all like compilers for high-level languages. Care to elaborate? I think your analogy will start falling apart pretty quickly.
schlomie 15y ago
Yes, I also write all my programs in assembly for the same reason...
ugh 15y ago
Why? WYSIWYG works perfectly well in InDesign (which is absolutely awesome, by the way), why can it never work with HTML? I don’t really understand. Current and past implementations are or have been bad, sure, but why can’t it work in principle?
- intranation 15y ago
  It's hard (not impossible) to make it work in principle because a printing press doesn't need to infer meaning from the post script or whatever you provide it. A browser does need to, so you'd need to layer the extra semantics on top of your WYSIWYG editor. Which means asking questions like "this is 36 pixels high: is it a heading,; or is this just a landing page with big text?" etc. So maybe I lack imagination, but I don't see it being that easy a problem to solve from a UI point of view.
  - ugh 15y ago
    There are plenty of semantics in InDesign documents. InDesign is all about character, paragraph, list and table styles – it’s what you use to make InDesign work. You wouldn’t have to add much to make those styles do all the semantic work. Yeah, you would still be able to just ignore all that – just like you can adjust each headline individually in InDesign – but that would only mean that you are an incompetent user of the software. A good WYSIWYG editor wouldn’t always have to produce great markup but a competent user of the software should be able to easily make it produce great markup. I’m really not that sure why adding a GUI for semantics would be so hard, especially since existing concepts like paragraph or list styles already map very well to HTML concepts.
- stephen_g 15y ago
  One big part is that when something is designed for print, it is essentially always designed for a fixed size page, so you don't have to deal with resizing. Then there is the fact that web sites have to cope with people not always having the same fonts you do - which makes it almost impossible to do pixel perfect designs involving text rendering. Then there is the fact that something like an Indesign document doesn't really have any concept of separating the style from the actual content. For the time being at least, humans are much better at logically ordering and marking up text, and then adding the style with CSS, unlike programs which add a whole lot of extra markup and CSS to do the same thing. Those are just a few things which make WYSIWIG work a lot better for print than it ever could for web - and there are more... These things will probably be somewhat resolved as time goes on (ie. with wider support for @font-face and so on) but I think that hand written HTML will be better for a long time to come.
yahelc 15y ago
WYSINWYG: What You See Is Never What You GEt.

mun2mun 15y ago

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

tjarratt 15y ago
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 about how they'd rather be using Adobe Illustrator. The truth is that there will always be a group of people that are able to visualize what they want to create better than they can verbally, or symbolically.
- josscrowcroft 15y ago
  That's why we have WordPress, Tumblr, etc., even things like launchrock, about.me, shopify, the list goes on.
  - wlievens 15y ago
    You mean things that are (eventually) html page generators?
- mun2mun 15y ago
  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.

notatoad 15y ago

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.

tiddchristopher 15y ago

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.

libria 15y ago

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.

tomelders 15y ago

Adobe will get my constructive criticism when they build something worthy of it, and not a second sooner. Until then, deal with it.