4 ms·

> 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 technolo

by mapgrep 12y 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.)

benatkin 12y 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 12y 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.
  - benatkin 12y ago
    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  <p>Hello</p> </body> </html> 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/ http://www.w3.org/TR/html401/ Edit: I didn't quite remember it right. It's 
    - seabee 12y ago
      Server side includes amount to a preprocessor, no? A lot of code is written that way without major incident.
      - benatkin 12y ago
        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.
        mapgrep 12y ago
        You're wrong, the extension by default is unique, shtml. You can order your webserver to parse all HTML files as SSI but it's not recommended. Searching for server side includes on google works fine. And the comment-formatted "#include" directive seems pretty clear to me.
        benatkin 12y ago
        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.
    - deleted 12y ago
      [deleted]
burnte 12y 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 12y 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.

by mapgrep 12y ago

benatkin 12y 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 12y 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.
- benatkin 12y ago
  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  <p>Hello</p> </body> </html> 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/ http://www.w3.org/TR/html401/ Edit: I didn't quite remember it right. It's 
  - seabee 12y ago
    Server side includes amount to a preprocessor, no? A lot of code is written that way without major incident.
    - benatkin 12y ago
      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.
      - mapgrep 12y ago
        You're wrong, the extension by default is unique, shtml. You can order your webserver to parse all HTML files as SSI but it's not recommended. Searching for server side includes on google works fine. And the comment-formatted "#include" directive seems pretty clear to me.
        benatkin 12y ago
        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.
  - deleted 12y ago
    [deleted]

burnte 12y 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 12y 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.