One of the speakers at our YC session had a great quote: "It just doesn't matter." The site delivers interesting stories and commentary on a topic I care about - who cares what HTML it uses?
HTML is object code only because you don't have a dedicated designer who wants to make design decisions and changes without requiring the programmer's time. For news.yc that's fine, but for many business sites, having HTML automatically generated in a designer-opaque manner is inconvenient. Eventually you want to hand off the design to someone who is good at design, and having to find someone good at design and good at the programming language you use limits the pool of designers.
The usual alternative to html-as-object-code is to use a template system, but template systems seem to move as a group (and individually during development) toward being a way to write your usual language, but surrounded by HTML, which has the same problems I outline above, since the designer still has to mess with what's really application code. I suppose this is because template systems are usually designed by programmers, for programmers.
You may notice if you look around that much of the time when someone replies to someone else (in any context, not specifically news.yc) they are saying something they wanted to say or like saying, rather than expecting to change someone's mind.
In fact, there are many, many exceptions to my general rule that you'd want to eventually turn over HTML/CSS/design stuff to a designer, and news.yc is one, probably. But the vast majority of my projects are no exception, and I'm fortunate to be married to a designer with strong opinions on the matter, so I get good feedback. :)
Heh. Actually, for most things I've been involved with, UI has been more difficult than any of the rest of it.
One of the promises of the web was that interface could be cleanly separated from the application itself, and it seems to me that most approaches being used today throw away that promise because the programmers assume that UI and design aren't important, or aren't hard.
So yeah, HTML is object code to PG because it can be. Sure, separating programming from web design may be necessary, but it's not better. Having the two concerns properly considered together is better, though more difficult to pull off.
One might also wonder why the vote URL contains the username? The cookie identifies the user so the url can either match that, in which case the vote is recorded, or not, in which case it returns "user error."
But I do note the board does work well: is always up, does what it's supposed to, is easy to use, seems secure, and thus it just doesn't matter.
Voting and deletion are both idempotent, they just aren't side-effect free. The weaker condition of idempotence is all you need for GET, because it's sufficient for guaranteeing that caching won't break things. The solution to the problem with Google is to not let anonymous users delete pages irrevocably.
That's a good distinction. I had to look up the HTTP 1.1 RFC, 2616 and read section 9.1.1 "Safe Methods" to note that while what you're saying is correct, the RFC does strongly discourage... well, here:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of
taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent
other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a
possibly unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
Using some form of "web accelerator" is asking for trouble. I consider Paul's method better than requiring Javascript to vote or making the voting links some wacky kind of button element.
If HTML had a method="post" option on <a>'s then it would be no problem to always use the proper HTTP verb, but we have to satisfice with what we've got.
I, too, have often wished for the method attribute you describe.
That said, if you're already using javascript (as news.YC is), I really don't see why you wouldn't make use of xhr. In which case you could submit the request as a post.
Note: I haven't poked around enough to see if news.YC works without javascript. If they degrade gracefully, more power to them, and I can almost understand the decision to do it the way they have.
I take the BOFH outlook on this: that problem is isomorphic to the problem of a user leaking his account credentials to a malicious third party and should be dealt with in the same manner.
You can just add rel="nofollow" to those links, by the way.
Edit: Or so I thought. I'm wrong.
It turns out there's no standard for this, so who knows what you can do today. But practically, Google Web Accelerator doesn't prefetch links with a query string, at least currently. So Paul's voting links are A-OK with GWA. And that's the only one that you need to worry about, at least today.
Thanks for asking, I double-checked and there are of course not even any informal standards for web accelerators, apart from their common appeal to the HTTP 1.1 standard when the issue of link following safety comes up:
CSS is ugly. For anyone who's used it throughout the years, it was consistently poorly-documented and incompatible across different browsers. Standards compliance? What's that?
A lot of deprecated methods are still used because they work reliably, whereas the replacement often didn't, until much, much later. People remember the pain and bugginess and so you lose the early adopters even if the problems eventually get fixed. Cf. Apple III, g++, MySQL.
It's hard to comment in this one i think.
Yes, it's lame to use spacer GIFs as a design standpoint, with all web community try to separate meaningless technique's (tables, spacers, etc...) from documents.
However for this web site, Yes it just doesn't matter.The functionality become more important.There is news link and comment section with a clean interface. Not much black ink.
If you are in this situation, it doesn't matter but with your new startup's i think its better stick with the notion of separating mark-up with design.
I can't keep silent to those anti-css comments but don't know where to start...i think web started as a way of exchanging "documents" between computers. So in basic terms what you see in your screen is "a document" so it should be seen as " a document". without css in html code what you see is...well some kind of hectic ASCII art.
"It is a valuable thing if your page seen as a document"
i sometimes think that, under the supervision of PG, a small design team (designer, info. arch. & UI person) "may" help founded startups to achieve better in their goals.
While we're on the issue of the news.yc user interface, here's something that pisses me off every time I view comments: the comment author's name is buried in a sentence-long thing of text, and hard to pick out. Make it more noticeable, please.
Paul basically said he doesn't give a shit, which is pretty stupid considering how many people visit the site regularly, and how poor the user interface is. Just because spacer gifs don't directly affect the content, those kinds of poor design techniques influence the user interface and make it crappy, which it has become. Paul, you know good designers-- get them to make it look good.
Thank you for bringing the fact that Paul Graham's unreleased programming language does not yet have a mature web development framework to our attention.
No shit... I deal with programmers like this on a daily basis. These discussions are always kicked off in the name of "good design", or some such, but the view from where I'm sitting is that of a bunch o' corporate IT geeks that like nothing better than burning big piles of cash while providing little to no value.
I've wondered about that, too. One guess: it makes the design harder to steal (but not harder to copy). With CSS, you can just reuse someone else's format -- not so with spacer .gifs.
The last time pg had to do design work or perish (figuratively speaking) was ten years ago. It'll take him a while to get up to speed on all this new-fangled technology.
Besides, it works in all browsers, is reasonably accessible, and if it doesn't make him uncomfortable to work with it...why does anyone care?
Call me a fanboy, but I consider "works in <b>all</b> browsers" a misfeature. "works in all reasonably standards-compliant browsers" is a much better goal, I say. If people didn't support obsolete and/or mediocre software like that, we would all have had almost fully standards-compliant browsers 4 years ago.
I think there's some fairly clever stuff going on. The page source is pretty simple (yes, I'm sure we've ALL looked at it at one point). Take this function for instance:
function byId(id) {
return document.getElementById(id);
}
My guess is that the function body is rendered differently for different browsers. If that's true, it's a clever way of doing cross browser Javascript.
document.getElementById is generally pretty portable across browsers.
And another clever way of doing cross-browser JavaScript is just to use a mature JS library like Prototype or JQuery. They all give you byId for free, in the form of the $ function.
I'm with you there - prototype is first class stuff. I wasn't sure if getElementById was supported by Opera or Safari. If it is, it looks like byId() is good way to save some typing.
