I am a "Web-Developer" and have been for quite sometime. Allow me to retort:
RacerX said:
Why would this matter? Web browsers generally display the formatted pages... not the code. Something like that would only matter to people who spend more time viewing the raw pages than how they are displayed in the browser.
There is in fact a real-world reason for favoring shorter code over longer code that accomplishes the same thing. It's called bandwidth usage, and if you can serve one, dare I say, "dreamwoven" page or two optimized pages that are half the size, then you have just cut your bandwidth costs in half. For sites that serve a ton of pages, this can be a significant amount of money... and in the end worth the extra effort.
RacerX said:
If you want something that is not needlessly and hopelessly complicated, type out a plain text document with no code at all.
Your sarcasm/ignorance really helps your case.
RacerX said:
The point of HTML is web layout within a browser. Hand coding HTML is very much like knitting your own clothes, while it is an admirable skill, it is also time consuming.
Sure I can hand code, but why would I want to? I can hand sew too, but I'd rather use a sewing machine. I'm more than fit enough to bike everywhere, but I still use a car (specially in the weather we have here in Minnesota).
I'm not sure as a hobbyist (... based on your comments, I assume you are this...), you are qualified to make this statement. Your analogies are far from accurate. First of all, HTML isn't a "coding language" it is a markup language, and no, HTML's goal is not "web layout within a browser." The "point" of HTML is to breakup pieces of data--whether it be textual, tabular, lists or otherwise--into a well-formed structure. For example, using the <p> tags to encase a paragraph says nothing about how it should be displayed, but only labels the enclosed text as a "paragraph." The same goes for lists... using HTML I (should) only define a list of elements as that... a list using the appropriate list tag. It is then the job of the Stylesheet to apply a style to that list, table or whatever else and render it visually according to whatever styles have been defined therein.
RacerX said:
From what I've seen, the people who are most proud of hand coding are those who invested a lot in learning hand coding. It was the same mentality that users of DOS or non-GUI Unix have. They took all this time to learn to be productive via command line, and then the world moved on. They are struggling to hold onto this skill that they mastered even in the face of newer tools that are easier to learn and help people be more productive.
Again, in this case your analogy is inaccurate, and I doubt you've encountered many professional level web-developers. A hobbyist's view of anything is always different (skewed?) than those who make it their livelihood. Here you insinuate that the skills needed to use a command line are outdated? Useless even? I use an OS X box to do my development primarily because I have the option to use either/or. It is kind of hard to be "more productive" using a GUI when you are required to log in to a remote server via SSH to fix something. The beauty of OS X, for example, is that you have options to choose from, depending on what the job calls for. Having the skill to choose when to use one technology over another is one way that professionals separate themselves from hobbyists, as again, it is our livelihood at stake.
RacerX said:
I mean, even at the beginning of the World Wide Web HTML was being made in a WYSIWYG app (the original browser/editor worldwideweb.app for NEXTSTEP). The need for hand coding came on other platforms as they didn't have anything to do that (they were lucky back then to even have a web browser to view what they had written).
I don't think it'll be too long before hard core hand coders are looked upon the same way we look at the Amish today.
I doubt that DOOM4 will be written in Visual Basic. I have a big problem with people who learn how to use something that they feel is "easier" and interpret that as being "better." In the same token, just because hand-coding something can be "harder," it doesn't mean that it is more optimized.
I originally learned how to write HTML markup with the aid of a WYSIWYG editor. It is a fantastic way to understand how something is translated from a visual tool into textual markup. As you become more proficient, you understand that the editor takes liberties in certain areas and in the end it is more time consuming to fix these than to simply maintain it yourself--this being my prerogative of course.
To their credit Macromedia has done a very decent job from a coding aspect with the new Dreamweaver.
I think your argument that Dreamweaver as a WYSIWYG editor is better/faster than hand-coding is unfounded. You have obviously never tried to tap into BBEdit's more powerful tools. One of the most overlooked tools in BBEdit is the Glossary feature. This allows you to select component templates and have them inserted into the working document. For example, there is an HTML page template that automatically fills in the code for a basic (blank) HTML page. Sound familiar? Yes, this is basically what you get when you open a new Dreamweaver document. The power here lies in the fact that you can customize these templates for any language or any type of component. Say, for example, if you're finding yourself writing a certain set of tags very often, you can create your own glossary entry to insert this code automatically. BBEdit's palette's extend this functionality into clickable buttons that will insert code (for say, tables) automatically, much like Dreamweaver. This is in effect an equivalent to Dreamweaver's snippet code library. BBEdit also has a built in FTP client, like Dreamweaver (although I use Transmit with it's built-in "Edit with BBEdit" command).
So up to this point, from a coder's standpoint, what's the difference right? Well my main point is this: the reason you say that Dreamweaver is easier is because it does most of the underlying work for you--implicitly--and you get the generated code that comes with it, which is usually less than optimized. I am suggesting that taking most of that implicit coding and making it an explicit process allows you more control over the code as a whole--hopefully making it easier to make it clean which in my case, is important. Also, I usually have to test this on multiple browsers anyway, and Opera 6.0 (which drive's Dreamweaver's in-app HTML rendering) is really the least of my worries, as often it renders differently than Mozilla or IE, and in the real world, IE (unfortunately) is the first browser that needs to render correctly, with Mozilla coming in second. I find it easier to test a resulting page in one of these browsers, so the "live" in-app preview doesn't help me in the end (and yes, just as in Dreamweaver, BBEdit has a "Preview in Browser" command).
There are a number of other reasons why using BBEdit has become more natural for me than using a WYSIWYG tool, most of which won't matter or simply won't be understood by the casual user. So, in conclusion, as far as your statements are concerned, I prefer to take a little more time upfront to do something right, rather than correct things after the fact, but again, this comes down to choosing the right tool for the job. To each, his own.
I apologize for the lengthiness of this post.
