in reply to RE: Something I wanted to share with the group.
in thread Something I wanted to share with the group.

Anyone who relies on code generation (look at any HTML editor) is clearly not capable of evaluating the code it generates.

Russ, I have to take issue with this. This is just *wrong*. I have some 300 HTML pages in the system I've implemented for the system at the office. Each one is not hand-coded and tuned, because it just doesn't matter. If you want to take the time in your favorite editor, and hand-type each and every HTML tag, and make sure it's perfectly optimized, then you clearly have more time than I do.

The code the HotMetalPro produces is not perfect. I know this. And I don't care. It doesn't matter. And I can crank out a page, especially with a few interleaved tables, a lot faster than I can with 'vi'. And, furthermore, I can see the results as I edit. And no, I can't use CGI.pm, because it's a template type system, and also because someone behind may have to make changes to the pages, and they don't need to be mucking around in Perl code just to change a header.

Hand tuned highly optimized HTML has a place, don't get me wrong. It's more important to be *aware* of the code that your tools generate. Use them when you can, avoid them when you can't. This same rule apples to Perl, 'C', and any other langauge you choose to pick. Perl doesn't produce perfect internal code. Neither does a 'C' compiler. It takes it best shot at it, and the majority of the time it's accurate. The only reason people are quick to judge the output of HTML, XML, and other editors is because the code is clearly much more visible than the assembly or byte code produced by a compiler. I imagine if your browser didn't have a view source button, you'd be a *lot* less aware of good vs. bad HTML.

And besides, even if you do hand tune the HTML, the next bozo who comes along behind you may use FrontPage anyway, and all that nice work is shot. And on a 100mpbs (or even a 10mpbs) network, who cares if the line is broken in the middle, or has an extra "colspan" tag, as long as the HTML is valid, and produces the output required?

I'm not advocating writing bad code, or bad HTML. I'm advocating being aware of the output you and your tools produce, be it the compiler, HTML editor, or whatever.

By the way, it's my opinion that most HTML editing tools are designed to make web pages accessible to people who don't want to or shouldn't have to learn the intricacies of HTML. If it weren't for these people, even with their "Hello, World" web page, the web would be a much smaller, and less popular place.

--Chris

e-mail jcwren
  • Comment on (jcwren) RE: RE: Something I wanted to share with the group.

Replies are listed 'Best First'.
(crazyinsomniac:coming from a web designer) Re: (jcwren) RE: RE: Something I wanted to share with the group
by crazyinsomniac (Prior) on Aug 18, 2000 at 00:23 UTC
    If you're not a 'professional' web designer, i see no point in you learning HTML, and if you are you should only use WYSIWYG editors when the boss says, "I need a new webpage in 5 min."

    In my opinion, handcoding is meant for 'template driven' sites. You just design your template, optimize your code, and populate the template with content in its reserved spot.

    Anyway most WYSIWYG editors have the option to edit the actual html source, and control any and all comment that get automatically generated.

    The real power of WYSiWYG editors is automation. For example, if you have a 'template driven' site with some 500 odd pages, DREAMWEAVER or FRONTPAGE will let you change the TEMPLATE and update every page accordingly and automatically.
     

    "cRaZy is co01, but sometimes cRaZy is cRaZy".
                                                          - crazyinsomniac

[reply]
RE (tilly) 3: Something I wanted to share with the group.
by tilly (Archbishop) on Aug 17, 2000 at 21:28 UTC
    While I sympathize with russ, I simply have to agree with you. Automatic code generation off of a data structure is a very powerful idea. In fact one of the nice things about Perl is how easy it makes this to do.

    Anyone who disagrees should simply stop and think about the process of pulling data out of a database and spitting out formatted HTML...

    EDIT
    I thought about it and an even better example would be something like Parse::RecDescent. Pass it a string description of a grammar. It generates a parser for you. An example of automatic code generation of Perl in Perl which has been recommended several times by the likes of merlyn.

    So while I absolutely think that a lot of code generation tools are abysmal, code generation (even generation of Perl) is a concept that should not be categorically thrown away.

[reply]
RE:(3) Something I wanted to share with the group.
by Russ (Deacon) on Aug 18, 2000 at 01:51 UTC
    Each one is not hand-coded and tuned, because it just doesn't matter. If you want to take the time in your favorite editor, and hand-type each and every HTML tag, and make sure it's perfectly optimized, then you clearly have more time than I do.
    In my experience, I can hand-code HTML far easier than I can deal with an "editor." The HTML will come out clean and nicely indented, allowing much more efficient changes and extensions later. It might be different if I were tasked with 300 plain HTML files with no code, no functionality.

    However, I think you may have missed my point. I am addressing the "people who don't want to or shouldn't have to learn the intricacies of HTML." This may be acceptable for something simple, like HTML creation. But, do you really want people using "automatic" Perl code generators on your servers? Those people who don't want to learn the intricacies of Perl are the very people who should be forced to do so, or ask for professional assistance.

    Concerning the "extra colspan," I am referring to HTML that is a few K when hand-coded, but 40-50K from some editor. They tend to put gratuitous font tags around every element, create nested tables for no reason, duplicate style information and colors repeatedly and redundantly, over and over. This mess is far from maintainable, except in another editor, where the junk may be compounded even further.

    On a 10Mbps network, 50K files will download quickly. Are we willing to inflict that kind of wastefulness on an unsuspecting world (who likely do not have OC3 connections to the internet)? How long do you like to wait while Netscrape renders a pile of highly inefficient HTML? Bad HTML is a more serious problem than simple download times.

    Russ
    Brainbench 'Most Valuable Professional' for Perl

[reply]
      Well, I'm not the guy telling others what to do, but I will say it anyway.

      Here in the office dreamweaver is used. This is mainly because of there are people updating the content who know no HTML. But this is changed with a content-managment tool.
      But The most web-developers here also use DreamWeaver and accuse me of being stupid using a plain text-editor. But hey I'm a fast coder. I code my pages faster then them I know what I'm doing and most of the time I see what I get in my browser. Who said I type each tag? Not me I know how to use Copy&paste effective and fast.
      I got no real probelm solving HTML problems, I just have to look at my code to see the problem and most of the time the DW guys come to me to solve HTML problems and I see yuckie code. One of the things I learned early is to format my code. Well, I do this with all my languages even HTML. This makes debugging often simpler.

      So my point is that when you've got code-generators they should at least format the code nicely.

      --
      My opinions may have changed,
      but not the fact that I am right

[reply]
      I personally use Cold Fusion Studio and handwrite my code, but by the same token, I work with developers who use Macromedia because they can tell the developer to create the page for x.x browser and to use x.0 version of HTML and x.x version of Javascript, and it puts out pretty good code.
      The editors have their place in development, as long as it does not substitute thinking out your code and your goals (or thinking in general for that matter), which should be optimization and maintainability, etc.
[reply]

        >they can tell the developer to create the page for x.x browser

        That so goes against the whole idea of the web in the first place. HTML should never cater itself to a particular browser. To a particular ([psuedo|meta]\-)?language perhaps, but never to a browser.

        </soapbox> :)
[reply]
Re (jcwren) 3:Something I wanted to share with the group.
by nuance (Hermit) on Aug 17, 2000 at 21:25 UTC
    If it weren't for these people, even with their "Hello, World" web page, the web would be a much smaller, and less popular place.

    Ok, now I'm confused, your english seems to imply that this would be a bad thing somehow ;-)

    Nuance Who doesn't have a web page because it would only say something banal like "hello world"

[reply]

In Section Perl Monks Discussion