Hacker News new | ask | show | jobs
by mtomczak 6011 days ago
I believe that I see your point, and I would agree that the verbosity of HTML leads to sharability, and that is a strength.

But the verbosity is also one of its weaknesses for large projects; it adds a great deal of overhead in terms of keeping track of the tags, especially if the HTML needs to be re-arranged. And with no language-supplied rules for how much whitespace to use or where (beyond "all adjacent whitespace is compressed"), there is too much flexibility for a large team to work smoothly. My usage case doesn't mesh with your example, because I'm working in an environment with version control and multiple developers. The guy using Notepad will be told to get a tab-aware text editor, because his changes will mangle the whitespace in the file and lead to unnecessary noise when he commits.

When structure in your whitespace is already desired (to avoid making your version control noisy), you can leverage the fact that you are structuring the whitespace to make it a semantic element. This greatly decreases typing, makes the code easier to eye-scan, and allows details such as proper closing bracing to be left to the compilation tool and not to the developer. I agree with commenters who have noted that HAML has been proven useful for some developers.

I would categorize both SHPAML and HAML as tools that let you be more productive with HTML.

1 comments

It's not the verbosity or lack of it that makes it shareable, it's the fact that it's a standard.

Some of these inventions are a bit nicer than the original thing, but not so much that I'd give up being able to share the code with pretty much anyone and everyone.

I can do HTML pretty quickly with Emacs' psgml mode, and I'm sure there are other people who specialize in it who can do it even faster with other tools. I think that's the place to look for improvements, rather than generating it like machine code.

When you run SHPAML through the preprocessor, it produces HTML that you can share with other people. So it's not that big an issue. Your greater point is well taken, though--using SHPAML is particularly suited to small teams.
Things can get messy if people sending you patches for something generated, rather than patches for the original source, though. Most such transformations aren't trivially reversible.
I understand the use case, and if people are frequently sending you patches for your HTML, you probably want to make HTML the authoritative source. Do people frequently send you patches for HTML that you author? SHPAML does not allow you to trivially reverse HTML patches, but it does allow you to manually apply them without too much pain, as it lets most HTML pass through unmolested. I actually source control my HTML output to be able to see diffs on the HTML, for what it's worth.