The OP isn't talking about Ajax calls and Dom transformations. He's talking about using semantically correct markup (c'mon, it is literally an ordered list) and a style sheet. Things that would make the site faster, easier to maintain, and easier to parse.
If this were anyone other than pg, you'd all be excoriating the developer for living in the 90s.
The big benefit is to accessibility through screenreaders or other alternate clients.
Google's HTML is also all generated. They switched to CSS-based markup in 2007. It is a bit easier to maintain, but only a little, and mostly because of obscure things like bold tags needing to be red and normal-weight in Chinese because bolded Chinese characters look like shit.
Size and rendering speed wise, it's basically a wash. The HTML is significantly smaller, but the CSS is significantly larger, and CSS is a massive pain to refactor and can easily lead to bugs.
It's much easier to manipulate with JavaScript, because the DOM structure of the page is much simpler. Tables also have weird implicit element insertion rules, eg. the first direct child of the <table> on this page is a <tbody> tag, not the <tr> tag that you outputted as source. That alone is a big reason why Google would never go back, though I don't know how much it applies to a mostly static site like this.
Why are you generating styling at all? It's not dynamic information. It's a static asset that can be cached.
Semantically correct markup uses fewer tags, so the output is smaller (also, there'd be no online styling, which would also make the page smaller). Even a small difference on a popular site could matter. But only you can answer that for HN.
Look, do what you want. You want to write bullshit markup, be my guest. But there isn't a single web dev in this community who would code output like this for their own site. They're just too chickenshit to tell you.
Generating and caching are orthogonal questions. You can generate stuff, and then cache it. And in fact HN does do a lot of caching.
I wasn't asking how much faster "semantically correct markup" would make HN pages render as a rhetorical question. I'm genuinely curious. If you want to make claims that x is faster than y, you should be prepared to back them up with numbers, not merely with more heated language.
Generating and caching can be intertwined. For example, HN seems to generate an inline script at the top of every page. The script doesn't change nearly as often as the posts do, so that script is sent redundantly at the top of every page. If that script were located at separate URL, set to expire never, every visitor would load it once and never again. If you need to change the script, you can change the linked URL. Doing that can avoid an expensive calculation for the server, but also a network request for the client which could be very, very expensive.
To me, it sounds like the caching you're talking about is on the server side. I think you mean something similar to memoization, so you can avoid doing some expensive query or calculation. That is worth doing, but it's still possible to organize the output of those caches in an inefficient manner, and incur unnecessary network overhead. The "semantically correct" part of the markup being advocated here isn't that interesting, if you ask me. What is interesting is the claim is that you can generate less markup per page, and get the same display.
The balance between the repeat visitor cache behavior and the initial number of HTTP requests and latency for a first-time visitor can get hard to judge. Without lots of time to measure the various alternatives and mitigation tactics, it's best to try and generates as little markup as possible. That's where so-called "semantic markup" comes in. Usually it's just less markup, and does better.
Another thing to take into account is the layout behavior triggered in various browsers by the markup you're generating. HN is pretty simple and should render instantly, but it doesn't in anything I've tested (Firefox, Chrome, Safari). Each of them redraw the scrollbar one or more times. That could be due to the tables.
I am trying to dig up the old benchmarks that created the tables are slow mantra but like all things their is a grain of truth to it. Before IE 5 and the addition of the table-layout CSS property tables where considerably slower and more resource intensive on the browser to render. That being said, the point is mostly moot in modern browsers. While their are differences in performance metrics between CSS and table layout, the reality is, it is insignificant enough to not be cause for concern. Unless you are specifically targeting browsers before IE 5.
I personally believe that it would, because you can then generate the site and allow what the site looks like to be external from that generation. Managing what the site looks like, independent from what the site says, is good clean separation of concerns and does in fact promote maintainability.
By all means, try to raise your rates. The first step toward being paid a lot of money is asking for it.
But if these templates sound like a good idea to you, you need to focus on something else first. The only way you could change your rate via email is if you're doing your freelance work without a formal contract, which is a colossal mistake.
So, forget these email templates. First, get all your clients to sign a services agreement. The time to negotiate your rate is when you and your client draft and sign the statements of work appended to that agreement.
In my experience, parenthood is often challenging because we are given so little good information in advance concerning what is actually challenging about parenting.
When we talk about the difficulties of parenthood, we normally talk about sleepless nights and tantrums and expense. We do this, I think, because these are safe topics. They allow us to have ritualized conversations about parenthood. We know what we are supposed to say and we say those things, even though we often don't think they're true or important.
But the real crisis isn't something we talk about. Raising children requires a huge commitment of time and energy--time and energy we can no longer give to ourselves or our spouse. And while almost all new parents try to keep their pre-baby lives intact for some period of time, eventually the futility becomes so obvious that they relent and cull many activities out of their lives to make space for the baby. The real crisis is one of identity. We fear that by cutting so many of the things we care(d) about out of our lives, we risk not being ourselves anymore. Am I the same person now? Is my wife the same? We don't talk about these questions because many of us don't like the answers.
For me personally, any such fears were unwarranted. I love my new life. Having children improved an already wonderful marriage--my wife and I are now an unstoppable team. My toddler has become one of my best friends. The infant just looks like a new buddy in waiting. But I'm a fundamentally happy person. I suspect it's like winning the lottery. If you're happy beforehand, you'll be happy afterward; if you're unhappy beforehand, you'll be unhappy afterward.
These are all valid points, but I think you're overstating the case a bit. Certainly, IP creation should not be routinely outsourced, but it can be outsourced in limited cases to the benefit of the organization.
I think there's a common misperception that outsourcing firms charge higher rates because their resources are (supposedly) more technically proficient. But, at least at my company, this is rarely what's going on. Most of my clients have excellent technical staffs. Our clients hire us in part, of course, because we are talented technologists, but the larger part, I believe, is because of our ability to acquire domain knowledge rapidly and our ability to retain that knowledge over long stretches of time when we aren't actively involved in the development process. Finding a comparable resource to hire or contract is so onerous that it doesn't make sense when what the company really needs is to achieve a goal now.
In other words, any product development company worth a damn hires as much for business acumen as it does for technical acumen. Otherwise, what would be the point?
I'm sure that's true for many, many firms. But, in my experience running a domestic product development firm, the single best way to acquire repeat business is to exit completely and gracefully. Doing so builds a trusted relationship not only with the business managers who authorize our work but also with the technical resources who have to live with our code. When we give both groups reasons to trust our integrity, I find that I'm able to negotiate better, longer-term maintenance agreements (when those make sense) AND that I'm presented with opportunities to bid on future projects.
Clearly, many HNers have had poor experiences with outsourcing (whether domestic or overseas). But there are good guys out there, I promise.
>But, in my experience running a domestic product development firm, the single best way to acquire repeat business is to exit completely and gracefully.
Very much so the truth. Additionally, giving great business advice to go with your software works well too. The business of software is unfamiliar to most of the people hiring software developers.
I had the same initial reaction. On further thought, I think the author understands the difference. The problem is that he's not a very good writer.
When he writes "one single space", he means what we all think of as padding in one direction or margin in one direction. I think all he's really saying is "don't create extra padding by adding margin" and "don't create extra margin by adding padding."
The argument is valid: it's just kind of obvious and poorly worded.
The other reason not to use margin and padding together is that you'll have less inconsistencies between browsers (i.e., IE6 vs every other browser — these properties are a source of a lot of annoying IE6 bugs).
If you do have trademark problems with HootSuite, you could also consider using an elephant with a couple small birds on it.
Elephants have a symbiotic relationship with a kind of bird that rides around on their backs and provides a valuable service (in this case, eating ticks--feel free to leave that part out!).
I think this would serve as a good metaphor for using tweets to facilitate the long-term retention of information.
My own experience in this area suggested another, more fundamental problem.
In the commercial world, we expect any idea to fail many, many times before we figure out how to make it work for the market. We embrace, rather than stigmatize, failure. Academics are conditioned to view failure as, at best, deeply embarrassing and, at worst, career-ending.
My experience is, of course, anecdotal, so take it for what it's worth. The researchers I met cared more about science than money, and because they perceived the commercialization process as potentially damaging to their academic careers, they threw a huge fit when technology transfer was broached. In the end, the university backed off (which warrants another discussion altogether).
Hi, there. I'm Kenny Dialoggins. If you're a Rails developer who wants to use scriptaculous dialogs but doesn't want to mess around with JavaScript, maybe we should hang out.
If this were anyone other than pg, you'd all be excoriating the developer for living in the 90s.