It's OK not to use tools

http://signalvnoise.com/posts/3752-its-ok-not-to-use-tools

by refrigerator • 12 years ago

135 96 12 years ago

This is true. But it's less true for tools that degrade gracefully - Wordpress may be damn convenient, but it's a pain to move away from. For some static site generators, you can simply throw away the tool and continue editing the output with no downside over never having used the tool in the first place.

(The same applies in other domains, too - it's fine to rely on gcc's many -W switches, but be careful with its custom C dialect; etc.)

sanderjd3• 12 years ago

Came here to say something very much like this. A good static site generator has no downsides:

- It's easier for you, the savvy developer who groks the toolchain, because it allows structure and reduces repetition.

- It may very well be easier for the next person who wants to add a page or change some copy, because editing Markdown and running a couple (admittedly esoteric) commands is likely still easier than editing HTML directly.

- If the next person doesn't understand or like the toolchain, they can ignore it entirely and edit the HTML directly, which is no worse than if you didn't use a generator at all.

So yeah, you don't have to use tools, and yeah, CMS sites and compile-to-CSS is probably overused in the small-site market, but I think static-site-from-Markdown with vanilla CSS is a pretty sweet spot for this!

cparedes• 12 years ago

Er, sure it does:

* No web UI. This may be a blocker for business folks who want to update a blog. This is a blocker for folks who are using devices like iPad's to update blogs (which is a huge reason why I moved away from things like Octopress and moved toward things like Ghost or Wordpress.) This may be a blocker for folks who don't always have the tools on whatever machine they're using at the time in order to generate the site.

* No imposed structure. It's easier to impose a web UI form that locks folks into certain workflows than it is to just give them a git repository with all sorts of stuff strung about, with no apparent structure other than the FS structure.

deong• 12 years ago

One downside might be that if the next person (person N+1) doesn't know the system and just edits the HTML and CSS by hand for a few months or years, and then person N+k comes along and runs the generate script, he potentially blows away any edits that weren't done with markdown and the site generator.

I suppose you could use the static generator for the initial build and then throw it all away yourself, but that's basically the same as not using it at all.

jarrett3• 12 years ago

Repeating the headers and footers even eight times seems unworkable to me. I'm quite certain I'd mess up at some point, and one page would be different from all the others. Maybe there are some projects where that doesn't matter, but I haven't worked on such a project.

For me, a static site generator is the bare minimum.

toyg• 12 years ago

SSI is usually available out of the box, or at worst an .htaccess away.

X-Istence• 12 years ago

nginx certainly doesn't use .htaccess ...

btgeekboy• 12 years ago

Or, on your basic shared hosting, you'll usually find PHP too. While I'm not advocating a ton of calls to do all sorts of things with databases and who knows what else, a set of PHP includes (and maybe a few additional helper functions) would be similarly useful.

stevekemp2• 12 years ago

The downside there is performance overhead.

If a user requests "/foo/bar/baz" you have to allow your webserver to stat "/foo/bar/baz/.htaccess", "/foo/bar/.htaccess", and "/foo/.htaccess" which can be a significant performance hit.

SSIs have similar issues, parsing all files on the off-chance there is some magic that will be required.

mixmastamyk2• 12 years ago

make (or a simpler alternative) is also an option in such circumstances.

jarrett3• 12 years ago

How so? Would you use basic Unix utils like `cat` to build the final page? I guess you're essentially building a static site generator at that point. Albeit a very simple one with minimal dependencies.

wvenable• 12 years ago

My personal site is static but using minimal PHP to include headers and footers.

I had intended to use a content management system at some point but never got around to it.

NateDad3• 12 years ago

Really? You can't copy and paste 8 times and then visually verify each one? Hell, you could diff them against each other to make sure you're not missing anything in those sections.

I think our culture has put too much of a taboo on copy and paste. It's not the end of the world if you're careful about it. Ideally, yes, you'd have it defined in a single template which then assures you that all pages are identical.... but what happens when the next guy comes and doesn't understand how the templating system works? It may end up costing your client a lot more money because the guy has to spend time figuring out your specific brand of templating, making sure he has the tools to work with it, etc etc. As opposed to simple copy and paste in plaintext, no tools, just content.

wtetzner• 12 years ago

That's why you use a static site generator. If the next guy wants to just edit the output of the static site generator, he can, and you're no worse off than if you'd just written it by hand in the first place.

ajanuary• 12 years ago

    So what if I have to repeat the navigation markup 8 separate times? It’s not that hard. We used to do it for much larger sites!

I would still be tempted to use a static site generator for it. You can always hand over the compiled output for the next person to maintain.

Other tools like sass/less, I would be less tempted partly because it's slightly harder to get human maintainable output (though the argument of a small site counters that too!)

127001brewer• 12 years ago

Today, a basic HTML/CSS site seems almost passé. But why?

Logically, a small website should be built with static HTML and CSS. So why build an overly complicated infrastructure with a web application front-end and a database back-end (which needs to be regularly maintained) just to display a simple website?

In many cases, WordPress became the hammer looking for anything that resembles a nail.

hluska• 12 years ago

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.

jiggy20113• 12 years ago

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.

chris_mahan3• 12 years ago

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.

latj• 12 years ago

Its been a long time since I've built a basic HTML/CSS site. Is it easy to make it look good across devices? This is one of the original reasons to use a framework.

VLM• 12 years ago

Are you talking about

http://purecss.io/

I've found it effective at abstracting away browser differences.

adamors2• 12 years ago

I agree that when it comes to Wordpress or nothing it's better to pick nothing. But the newest Joomla is pretty nice, comes with Bootstrap and it's responsive out of the box etc.

Updating pages through a CMS is also easier to an end user, than editing text files.

AdrianRossouw• 12 years ago

Jekyll is much simpler still, and is what most of those kind of sites actually need.

http://developmentseed.org/blog/2012/07/27/build-cms-free-we...

see also: http://prose.io

tbergeron• 12 years ago

Logged in just to say, whoever thinks the old or the new Joomla is a great tool says bullshit or never really had to get their hands dirty with it because it plain sucks. I hate Wordpress and I'd rather use it than Joomla. Plain HTML FTW.

adamors2• 12 years ago

Why are you getting your hands dirty with a CMS?? It's a simple tool and should be used as such.

antidaily• 12 years ago

Joomla over WordPress? Huh.

dahart2• 12 years ago

"And for that matter, why even bother with Sass? Regular old CSS can do the job just fine."

I do not think Saas means what you think it means.

Edit: I made a reading mistake

cocoflunchy• 12 years ago

Sass, not Saas.

dahart2• 12 years ago

Ha! My mis-read.

I do not think Sass means what I think it means.

shortstuffsushi• 12 years ago

Do you know what Sass means? http://sass-lang.com/

trjordan• 12 years ago

Sass is a CSS extension language that helps remove redundancy and make CSS easier to work with. http://sass-lang.com/

modarts• 12 years ago

Not sure how that could be misinterpreted as such, given the context

Fizzadar• 12 years ago

Couldn't agree more, perhaps a tiny bit of PHP to handle headers/footers but certainly nothing more.

It seems these days you need a whole Django/Wordpress/etc app for even the simplest, static content.

eddieroger2• 12 years ago

That was exactly what I thought as well. A simple Sinatra router that looks for a filename that matches whatever the user asks for, and I'm off to the races. Quick and dirty header and footer in a layout file and I'm good - my 8 page site is now 9, but it's much more edit-friendly than 8 versions of a nav bar.

bitJericho3• 12 years ago

So true. Show the receptionist how to use the FTP client and she can update the hours and holidays. Imagine teaching her the ins and outs of wordpress and expecting her to be ok with it or training in the next user.

LordIllidan2• 12 years ago

Why would you need to teach her the "ins and outs" of wordpress?

As compared to teaching her about FTP, opening files in a text editor, and editing HTML/markdown.

bitJericho3• 12 years ago

You think a wordpress installation is easier to use than ftp/notepad?

jiggy20113• 12 years ago

Don't shelter websites usually have an up to date list of animals to adopt? That seems like something that would need some kind of backend unless he's willing to update the list himself every week or whenever.

tjr• 12 years ago

Some shelters outsource that aspect of the site to something like http://www.petfinder.com

Jonasd• 12 years ago

That's exactly right. We used Petfinder and a simple API call with jQuery.

jiggy20113• 12 years ago

That's kind of an awkward UX though since you have to search, find the shelter website and then search again. Unless they provide some method of deep linking or maybe a javascript API.

pekk• 12 years ago

This is a pretty elementary observation that will only be a revelation to someone who learned things like Wordpress and Sass, let's say, last year. The more sophisticated tools exist to handle cases which are not covered by "just write some HTML and CSS". Maybe a client wants to update his own page in simple ways without writing markup?

chrislomax2• 12 years ago

Although I'm a fan of not over complicating things; generally when you re-build something for someone and they see the potential of their new site then 1 of 2 things happens.

1, They let the site go stagnant again like their previous site. 2, They want to build more on top of their site.

I always build a site like a client is going to come back to me for more work. I never work on the expectation to build and forget.

In most cases, the client ends up coming back to me for more pages. I've generally built this in a CMS so I charge 1 hours work for something that takes me 30 minutes to sort out for them. There is a client service there where I am doing them a service. I make 30 minutes profit per page (at a min charge of 1 hours work at a time) and everyone is happy.

The beauty of this method is that I am not coming back to a site in a year and wondering how I built it. Did I put navigation on every page? Were there differences on some pages?

I say Yes to not over complicating, I say No to not over complicating at the expense of making it complicated again for yourself to modify in the future.

EDIT: Typo

jbooth• 12 years ago

I think the key distinction there is how unique is the site/project. Is it something that fits naturally in a CMS? Then for god's sake use a CMS. If it's something that doesn't fit naturally, it's just as much effort to figure out the hacks you did to make it fit as it is to figure out your from-scratch code.

chrislomax2• 12 years ago

Yes and No. How do you know that something that doesn't fit now won't fit on the next iteration?

Can you honestly say you haven't built a site before that you wish you had built differently? I know I have.

These regrets make us make better decisions in future and to that end I always plan for bigger.

NateDad3• 12 years ago

I did this exact same thing on a friend's small business website. There was some ASP code to put the business's contact info in several different places, but her new hosting didn't support ASP. The answer was to just copy and paste the contact info into the 5 pages that needed it. It's trivial to look at every page on the site and make sure they're all correct, so why bring a whole apparatus into the equation?

zimbatm• 12 years ago

And with HTML5 imports you don't need to repeat the headers and footers anymore ! :)

http://www.html5rocks.com/en/tutorials/webcomponents/imports...

scott_karana• 12 years ago

Cool! Once that's more widely supported, that seems well worth using.

mapgrep2• 12 years ago

So what if I have to repeat the navigation markup 8 separate times?

Server side includes are built into both Apache and nginx, and are a very mature technology, so you don't even have to worry about that. (And lots of ISPs, including Dreamhost, support them. Notable exception: S3.)

benatkin5• 12 years ago

It isn't well known though. A lot of people know of server side includes but don't know how to write them. I'd fail that interview question.

thenomad• 12 years ago

Fortunately, nginx's server-side includes are (or at least appear to be, on a production website) quick, robust and very easy to learn.

I was facing exactly this problem on a static HTML website a few months ago, and was pleased to discover that two Google queries and five minutes' work left me with a functioning SSI.

burnte• 12 years ago

But those are tools, and this argument is that it's better to do things the bad old way than to think ahead and save time and work. I guarantee this guy doesn't remember what it was like creating web sites in 1996.

PavlovsCat• 12 years ago

"think ahead and save time and work"

True, but still: there is still a lot of wilderness to get lost in between certain future needs and possible future needs. Realizing you need to go back and fetch your bat belt to cross a bridge as you come to it costs time; but so does hauling a million tools which you could have needed, but actually didn't end up needing that day. We all have our anecdotes, but none of them invalidate the one of the author.. if he says he's happy with his work, and his client is as well, I will believe it.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." (Antoine de Saint-Exupery)

To read that as "let's go back to before anything existed, and stay there", is missing the point. Likewise, when someone says that sometimes it's okay to bring a walkman, they are not saying orchestras should not be a thing; just that, say, when you are jogging and want to listen to some music, it's more practical to bring a portable audio player and headphones, than have a orchestra/band run beside you. While that is always the coolest option, it is not always the most practical, and it can even seem a bit tacky. Sometimes, just sometimes, less is more.

carsongross• 12 years ago

If you are on a *nix box and have an HTML site with more than one page with a common header/footer, it'd be well worth your while to take the 10 minutes required to learn jekyll. After two or three header/footer updates you'd be money good with respect to time.

buckbova• 12 years ago

We used to do it for much larger sites!

Why is there this group of people fighting against innovation, against experimentation?

For your client you can do whatever you want, but you should strive to make your code manageable at least.

Remember when the web was damn simple? It still can be. It’s up to us to make it that way.

Over a decade ago, I used java servlets, with XML and XLST. It was not simple.

aenario• 12 years ago

So what if I have to repeat the navigation markup 8 separate times?

"Actually, could you remove the facebook link from the header and put it on the footer"

Why do we need a CMS for an 8-page site?

"James might need to make some changes in the future, don't worry only the edito ... HTMWhat ? FTPWhat ?"

Let's add Sass and a grid system ... Regular old CSS can do the job just fine.

"This needs to run on IE8"

They want to get stray animals adopted, not fuss around with website stuff.

Exactly.

vacri• 12 years ago

"Actually, could you remove the facebook link from the header and put it on the footer"

  man diff
  man patch

benatkin5• 12 years ago

"Actually, could you remove the facebook link from the header and put it on the footer"

This assumes the site has a header and a footer. The author just specified navigation. Maybe the facebook link is only on the home page. Is that a real problem?

"James might need to make some changes in the future, don't worry only the edito ... HTMWhat ? FTPWhat ?"

Then someone can help them get it set up, when that happens, and it will be easier for the person helping James to get them set up with whatever tool James is comfortable with. It's hard for people to learn skills they don't need to use right away.

"This needs to run on IE8"

Depends on the tools that are being considered, some new tools like ZURB Foundation (which is one way to use Sass) and Angular don't support old browsers, for reasons that are valid for a web app but not for a simple website.

arb99• 12 years ago

this is hacker news. and this post is questioning if its worth the effort to copy navigation to 8 pages. surely the obvious answer is to just include header/footer files (e.g. simple example in php: <? include('header.php');?>).

this way will just increase cost for his/her client down the road. Use even a super simple templating system (even if it is just including header/footer).

sure, using WP is overkill. but this is just silly to have actual plain .html files...

plus in a url http://example.com/about-us.html doesn't look as nice as http://example.com/about-us

(something like mod_rewrite could fix this, but if he/she is copy/pasting headers/footers i doubt that would be implemented...)

copperx2• 12 years ago

mod_rewrite? you must be kidding. How about an about-us/ folder with an index.html inside?

Tools give some people too much rope ...

carrotleads2• 12 years ago

I don't see this fixation with clean-urls.

One of the saners reasons is to avoid broken links

but I see broken links with with clean urls all the times. So don't think that is a good reason either.

codez• 12 years ago

Header and footers, layouts. Just use something like jade?

aaronbrethorst• 12 years ago

So why not use a service like Squarespace (or their dozens of competitors) to build a new, attractive website with a hosted WYSIWYG editor, and everything else the non-profit might need?

    Even hosted CMSes have a lot of cognitive overhead,
    and the content is trapped away inside someone
    else’s system.

Fair point, but I'd much rather explain to someone that I'm helping that they click this button over here, type in a box over there, and then click the big "PUBLISH" button than try to explain HTML or FTP to them.

I've had a few occasions to help friends with the websites for their small businesses, and I've always tried to impress upon them that they need to be self-sufficient for their long-term web content updating strategy. I can't upload files for them every time they need to change some copy.

$10/month should not be a deterrent, especially given that you, as a professional developer should be able to bill out that hosting bill for a year in a single hour of your time. If you're helping out a non-profit, donate an hour or two of your time and $120 to help them build a new website, instead of ten hours of your time today, and then an hour of your time every month in perpetuity.

Xenmen• 12 years ago

People are working on bringing convenience to self-hosting. Don't assume that freedom precludes comfort: https://arkos.io/

edanm• 12 years ago

I agree with the principle, but disagree with most of the specific consequences mentioend in the article.

We shouldn't use newer tools just because we like new, shiny technology. And we definitely shouldn't push them on our non-technical customers.

But! Saying that modern tools are not more convenient is wrong. Copy-pasting the same change to 8 files is not an improvement. It's not an improvement both practically, since you will mess up on the 18th change you're required to make. And it's not an improvement in reality, because in reality the people who don't use something to abstract this problem away don't do it because plain HTML/CSS is better, it's because they don't know how to solve this issue, or even that they need to solve this issue.

The technical world is better because we assume that you won't have to hand-edit and hand-apply changes in the way the article talks about.

And lastly, anyone thinking that WordPress is a problem is simply mistaken. WordPress is one of the most popular systems for getting real-life people to be able to create and post content to the web. The kind of people who don't have a clue what HTML is, and who couldn't care less.

For these people, and arguably for most people who want a quick web site with a nice-looking theme and easy ability to create and edit content, then WordPress is the best option by far. Even knowing many other technologies and being in general a power-user, I still use WordPress extensively. There's no easier way to get a decent looking site online.

wowsig• 12 years ago

I don't see a lot of value in this post. No one is really there to judge you on what you used to get your stuff done. Unless people are just intrinsically pressured to use the latest stuff, which is quite illogical. CMSes exist because they make the maintenance easier. Not because they are the in-thing to do.

mplewis• 12 years ago

That's a bad example. Harp (http://harpjs.com) is easy enough to set up, develop with, and generate sites with that there's no reason anyone who can work with HTML and CSS can't work with EJS and build a site without repeating a nav bar 8 times.

fiatjaf• 12 years ago

I'm building a tool (at the same time I'm building a personal throw-in-every-data-you-have website, so the Github repo is my personal website repo) to edit any kind of data, fetching it directly from the hosted website, build a git tree locally, upload it to Github and let Github host this new version of the website, just uploaded from itself.

It's kinda of a static hosted hierarchical website generator CMS (if you like these pedantic names):

https://github.com/fiatjaf/fiatjaf.github.io

(and you can access the CMS at work here: http://fiatjaf.github.io/edit , just ignore the password thing)

The idea is that you can create `docs`. Each doc you render itself to a page. Each doc is a JSON object including

- `title`, a title to be findable and nice, and to be displayed on the CMS, but not strictly required, as docs also have ids.

- `text` (something that will be displayed as is, or after some markdown rendering)

- `data` (field in which you can put structured data such as JSON, YAML, CSV, suggestions accepted) and do something with it later

- `parents` (a list of ids of the parents of this element, parents are used for generating URLs such as /parent/son/grandson and some other relationships -- like parents can receive its sons as data instead of the data at the `data` field)

- `kind` (a field that will be used to reference a `processor` and a `template` to render that data later)

- any other attribute you want, included using the traditional `yaml-frontmatter`, that can be used later for processing or display

In the rendering process each docs is passed to the processor referenced by its kinds and then to the template referenced by its kind and the HTML is generated.

It's OK not to use tools

Related Stories