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.
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.)
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!
* 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.
Whoops, I wasn't clear - I mean that using a static site generator has no downsides relative to writing HTML/CSS directly. Your downsides are both relative to using more tooling.
In terms of those downsides, I agree with you for larger sites, but not for the kind of really small sites the OP was talking about.
Surely that's not a static site? I think the author was trying to say that people rely to heavily on tools to achieve simple goals; using a tool or framework for your own amusement can sway you away from the actual goal, in his case making a static website for an animal shelter.
You can still have a web UI and produce a static website.
I've written blogging software that did just that. Every time the author edited/added something in the web UI (which saved to a db), it just re-'compiled' the particular pages.
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.
> 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.)
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.
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.
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.
That misses the point of this article though, it isn't about easy to learn tools, it's about not having to learn something at all.
I've used SSI and I don't wish to use it again. It isn't the same as a static page, and is too underpowered for me to want to use it for a dynamic page.
It reminds me of files that don't contain a well-formed html fragment. Stuff like
Oops, did I just remember the proper syntax for SSI? Guess I might not have forgotten it like I intended to. :P
Also server side includes are using a second language inside a first language without any introduction to the second language. No mention of them here: http://www.w3.org/TR/html401/
Edit: I didn't quite remember it right. It's <!--#include virtual="header.html"-->
The trouble is that the preprocessor isn't referenced anywhere, and it's going to confuse many web developers.
It isn't in the file extension, the extension is just .html.
"include" by itself is the tenth result on google. "include virtual" and "include file" (without quotes) have SSI in the top results. But not everyone is going to google that.
With C most knows there's a preprocessor. That could be true with HTML and Server Side Includes, but it isn't.
That's right, files might be named shtml. Hadn't thought about that. But if the file isn't an index, that detail makes it to the client side, confusing users, doesn't it?
The phrase "server side includes" doesn't appear anywhere in the "#include" directive. I'm talking about what could be gleaned from the code alone. And again, if they put file or virtual in their search term, they get the result. I just don't expect all web developers to do that.
To address your last point: the #include language seems simple but it doesn't explain why it's happening. It would seem like black magic to someone who thought their host was just sending files to the client and didn't know about SSI.
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.
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.
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.
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.
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.
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.
> "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.
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.
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.
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.
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.
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.
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.
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.
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.
The thing of it is, the next person that looks at the site might not know PHP... then what? You must know HTML to be able to work with a webpage. Anything else is just a further restriction on who can edit the site. Most small businesses get their websites managed by whoever happens to come along with a tiny bit of knowledge. The tiny bit of copy and paste you might need to do to avoid non-HTML is a perfectly good tradeoff to keep the barrier of entry as low as possible for the next poor schmuck who has to go in there and twiddle with things.
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.
Right, you have a header, a collection of body docs, and a footer. A markdown converter if you'd like. make and then scp transfer or commit to vcs, etc.
As these are common tools there's no cognitive overhead for developers and it can still be automated for users.
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!)
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):
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.
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...
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.
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.
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.
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?
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?
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.
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.
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.
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.
I mean in relation to what this article is talking about. A simple page eg hours.html or something. I think most folks could manage it. But you're right it would entirely depend on the design and the willingness of the user to take a moment to learn the ftp software and the crash course in HTML it would require. I still think that's simpler than running and operating a full wordpress installation in some cases.
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.
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.
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.