top | item 7136373

Hand Coding A Personal Website

50 points| petewailes | 12 years ago |seogadget.com | reply

52 comments

order
[+] nmc|12 years ago|reply
Nice tutorial, I just disagree on two small points.

First, there are very sound arguments for not using CSS preprocessors [1].

Second, for a website that you own, using ".htaccess" is discouraged for performances reasons. The Apache 2.4 docs [2] say:

"You should avoid using .htaccess files completely if you have access to httpd main server config file. Using .htaccess files slows down your Apache http server. Any directive that you can include in a .htaccess file is better set in a Directory block, as it will have the same effect with better performance."

[1] http://blog.millermedeiros.com/the-problem-with-css-pre-proc... [2] http://httpd.apache.org/docs/2.4/howto/htaccess.html

[+] petewailes|12 years ago|reply
I can't agree with the first. Most of the arguments from the quoted post are the result of bad practice with preprocessing, not preprocessing itself. For example, the "Dumb code duplication is dumb" example is just someone writing things badly. It should have been written as:

  .error-default, .error-special { @include error; }
  .error-special { background-color: #fcc; }
Similar arguments can be made for most of the other points. The nesting part for example seems to imply that you'd write in LESS/SASS etc, then maintain the post-processed CSS - whereas obviously you'd be maintaining the pre-processed files.

Not convinced, personally.

Disclosure: I actively develop a CSS framework built explicitly around the functionality of preprocessors.

[+] pyalot2|12 years ago|reply
The benefit of having some (any) facility to be able to write non vendor prefix/semantic infested CSS and to have nesting take care of an otherwise entirely unmaintainable flat CSS selector soup so far outweights any drawback that whatever argument you'll contrieve to construct against CSS preprocessors is essentially null, nill and invalid.
[+] onion2k|12 years ago|reply
The reasons not to use preprocessors set out in that article are generally arguments against using one without understanding what it's actually doing. A little knowledge is a dangerous thing - poorly written SASS code can build a nightmare forest of styles that get out of hand quickly, slow the client down, and cascade in strange and wonderful ways - but that isn't a reason not to use it. It's a reason to learn it.
[+] prottmann|12 years ago|reply
How many Billions of visitors you need, until a local .htaccess slows down your Website significant ?
[+] laumars|12 years ago|reply
> Second, for a website that you own, using ".htaccess" is discouraged for performances reasons.

Agreed, and not just for performance reasons but security as well.

While a correct set up wouldn't allow write access to the docs root nor developers to copy up hidden files, sometimes a sysadmin drops the ball. So disabling the use of .htaccess files prevents an attacker from changing your Apache configuration without gaining root access (and if that happens, then it's already game over).

[+] iamchrisle|12 years ago|reply
The .htaccess file is important for SEO. For the context of the blog (seogadget.com), it's worth noting that SEO is more important than performance.

The .htaccess is used to 301 redirect www.bennet.org to bennet.org. Important for SEO so that Google only indexes one domain instead of the domain and the subdomain. Only indexing one domain gives it a better chance of ranking higher.

Also.. do you really think the traffic and 453k of bandwidth is really going to put any strain on performance?

[+] normloman|12 years ago|reply
He said hand coding. Not hand hosting. He's on a shared host, so good luck changing the main server config.
[+] dlwiest|12 years ago|reply
I was about to link this to a friend, who has been using Wordpress and expressed interest in learning more about how websites work, and then OP got into installing a local Apache server and using LESS to compile CSS, and I'm afraid it might intimidate her, since she's already hesitant about her capacity for learning this sort of thing. I'm not sure why either was brought up though. If OP is comfortable with these tools and wanted to write about his own experience, I could understand, but for the sake of a tutorial, what benefit does adding these complications, which present a risk of alienating some segment of the tutorial's audience, provide? Unless you need a back end language, you don't need to install a local Apache server; you can run html files directly from whatever folder they're stored in, and if you link with relative paths, you can transfer the whole directory to a live server and it will still work fine, and for the amount of rules a beginner will probably write for a small, personal website, using LESS is probably overkill. Furthermore, anyone who's comfortable with either of these practices would have no problem adapting them to a basic "building a website with a grid framework" tutorial, and everyone else can pick them up later, when their value becomes more apparent.

It reminds me a little of the way every Javascript tutorial I find lately seems to assume that you're running a Node.js server. Outside of maybe the HN crowd, are most people running Node servers? I doubt it. And it's almost never necessary; you don't need Node to configure routing or build some custom directives in Angular, for example, so why insist that people use it?

[+] Bahamut|12 years ago|reply
Node provides some very handy tools for working locally. For example, usage of Bower, the client-side dependency, uses Node. Node also adds the ability to do nifty stuff like utilizing Livereload for automatically refreshing a page when you make an edit to a file.

I will admit, using all these tools was initially intimidating for me, but getting comfortable with them was extremely rewarding.

[+] robmclarty|12 years ago|reply
I agree this is a bit of overkill for a "my first hand-coded website" project. I've been hand-writing websites for over 15 years (back when all I had was Notepad on a Windoze box). I think I'd approach this sort of learning adventure more along these lines:

1. HTML/CSS (This is the end-result a browser needs, and you can write it all by hand yourself; by not using any grid/layout frameworks you'll learn all the fun things that CSS can do for you and you can focus on making clean semantic markup without any other dynamic distractions.)

2. Do some simple backend stuff that now dynamically generates the above HTML/CSS based on some simple logic (I'm thinking PHP to start because it's on almost every server already so you don't need to worry about installing anything... just get used to the idea of generating the above static HTML with some programming logic.)

3. Add a database (probably going to want to go with MySQL for the same reason as PHP; learn how to store data in the cloud and retrieve it to show in your dynamic pages)

4. Maybe learn some server config (probably Apache) but don't get too carried away because you can do a lot before you need to be installing Apache modules and tweaking environment variables... I'd just start by playing with redirects and error pages)

5. Now that you can build a full-stack website, I'd probably beef up my graphic design skills to make that shit sparkle (Usability, information hierarchy, and clear communication are the names of the game here. Design skills can make up for many technical difficulties if you think about the business problem you're trying to solve, not just how fancy you can make your sorting algorithm)

6. With the fundamentals under your belt, now I'd start looking into frameworks and libraries and helper tools that can make all of the above easier and faster. Now you'll understand what those tools are really doing for you and where they're appropriate to pull out. Get your CSS grid, your LESS compiler, your deployment tool, your database inspector, your autocompleting IDE (if that's what you're into) and make the computer do the grunt work, but now with the understanding of how it's helping you so that you can bend it to your will.

7. Move on to more advanced stuff like front-end MVC, non-blocking backend, websockets, streaming, ssl, localstorage, scaling optimizations, etc. But now that you can do the foundation yourself, you can add-on any of these advanced techniques as needed (no one in particular is absolutely necessary as they are specialized to particular tasks).

To me, this is the sort of DIY path that should be taken, step by step, to really understand how to construct a web property. IMHO the OP jumped into the deep-end a little too early. Learn to walk before you run ;)

[+] ozh|12 years ago|reply
I've rarely seen such an off topic introductory image, but I'm more surprised to see that kind of very beginner info land on HN front page. Nicely written and everything, but... HN?
[+] krapp|12 years ago|reply
Everything old is new again.
[+] pyalot2|12 years ago|reply
Having written pages, by hand, for ages now (like 15 years or so), I recently took this to a new level. I'm now hosting my site on my own hand coded webserver and no other server in front (please don't make me explain).
[+] imdsm|12 years ago|reply
Please DO explain. I'm going to guess at a PHP based site?

I couldn't imagine trying to run my personal website (https://github.com/Imdsm/PersonalWebsite/) on a hand-written web server and database server, though if I did that would be an achievement.

[+] lemonberry|12 years ago|reply
That's cool. I tried setting up a linode server to host my own sites and FAIL. I'll tackle it again when I've got more time. I'd like to do this using erlang or elixir.
[+] profil|12 years ago|reply
Please explain! And if you dont want to explain, please show some code? This sounds really interesting.
[+] sdegutis|12 years ago|reply
The title made me think this was gonna be minimalistic, something like <html><head><title>My Great Website</title></head><body><h1>Hello world!</h1><p>Find ye great content yonder.</p></body></html> so I was surprised to see it using LESS and delving into .htaccess
[+] walshemj|12 years ago|reply
So your hand coding but using in OpenDAWS doesn't that defeat the purpose of doing it all yourself from first principals?
[+] mox1|12 years ago|reply
I came to the same conclusion as the author recently, which spurred me to write a simple, no frills lightweight CMS. For those interested you can see it at https://github.com/mox1/webpy-bootstrap-blog

Personally, I think there's a middle ground somewhere between writing everything yourself and using hosted Wordpress. I want to control the HTML / CSS of the pages on my site, but I don't want to end up in a WYSIWYG environment where all the details are hidden.

[+] binarymax|12 years ago|reply
Good for you - keep learning! Knowing how things are built from scratch will give you a level of understanding that will help in all sorts of situations.

However, I am at the opposite end of the spectrum. I have never used a template or boilerplate or anything. Every time I've tried to use a prefab site I end up spending hours tearing it apart and feel like I am going backwards.

That being said, I cannot really recommend my approach - find a happy middle, and your productivity will soar.

[+] mailarchis|12 years ago|reply
I did something similar few months. I've been developing webapps using django for a while now. But my frontend skills (html/css) had always been very rusty. I decided to improve it by building a personal website without using any frontend framework or doing any server side development.

It was an interesting exercise. The output is here - http://archisman.com/

[+] adav|12 years ago|reply
I haven't developed for the front-end web in a while, but is it considered hand-coding if a boilerplate this-or-that is used at every stage?
[+] rickr|12 years ago|reply
That was my first thought. I'm also kind of confused at who this is for...the author is a designer and assumes a firm knowledge of HTML/CSS.

How do you obtain that knowledge without doing anything outside of a CMS?

[+] footpath|12 years ago|reply
Just like to add that if you're using FileZilla as your FTP client, make sure to not let it save your passwords, as FileZilla stores them in plaintext on the computer.

https://forum.filezilla-project.org/viewtopic.php?t=30765

[+] krapp|12 years ago|reply
One way I found around this is to run filezilla from a script which copies the password file out of an encrypted drive then nulls the file when you're done: https://gist.github.com/kennethrapp/7e58f10e149786baf06c

(I can't find the site I got this from though - and just not saving passwords probably would be better)