Hacker News Reader

Comment by hluska | Hacker News Reader

I'm not trying to troll, though I have a response to your question.

There is a large percentage of decision makers who want to be able to update their own sites, despite barely being confident enough to use Microsoft Word. In actual practice, the odds that these decision makers will ever actually update their site is nearly 0%. However, despite this, they still want the capability. If I were to show them static HTML/CSS, I'd starve.

For me, Wordpress gives me an interface that I can show these people before they decide to hire a quack who uses Wordpress for everything.

I've sometimes thought of a business model where I'd do content updates within 24 hours, but that just seems insane.

View on HN

I think this is it, it's easier to justify your fee if you offer lots of features and extras.

You could spend a lot of time thinking and examining requirements and come to the conclusion that a static site with very minimal but carefully designed styling would be an effective solution.

But it's hard to ask for thousands of $ for that with a straight face when the competing bidders are offering CMSs , iphone apps and facebook integration for the same price.

I edit my own site by hand. I ssh into linux vps, navigate to folder, launch nano, edit, save, exit.

Then I go to my browser, hit F5, and presto, my change is displayed.

Ahhh, and I don't even use CSS! Only html5.

I use the following tags: h1, h2, h3, h4, p, ul, ol, li, br, strong, and i.

I use © and &

And I let the browser render as it wishes.

That's great, but that's not something that is realistic for a majority of the content owners on the Internet. I could do what you're proposing (although I'd use emacs instead of nano because I've been using it forever), but so what? My takeaway from the article was that we don't need a full blow $new_tech app for every site, but I also don't think that's an excuse not to use one that makes your life simpler.

Editing code, live on the production server... what could possibly go wrong?

for the use case mentioned above. if it goes wrong, its a easy fix.

>its a easy fix.

Famous last words. The day when it's not an easy fix, you're stuck with bad code live in production affecting all users until someone can fix the bug. Worse, the only way to verify that the fix works is to check your assumptions against the live system aka a nightmare. Of course, none of this matters if your site is a personal blog or something that doesn't affect anybody's business, but nothing really matters in that case.

Exactly. It's not Amazon.com.

(1997)

(1993!)

(You're not improving your case!)

Reply on news.ycombinator.com