3 ms·

Not a bad little article, although the fact that it is 8 years old should make anyone who would find it useful question how much of this is still completely acc

Not a bad little article, although the fact that it is 8 years old should make anyone who would find it useful question how much of this is still completely accurate. On an somewhat related note, I really hate it when programming articles don't have a date on them. You start reading just to find out it was written so long ago that the version of code it was written for no longer exists and everything is deprecated.

city41 17y ago
I hate it when any page on the web doesn't have a date. I wish having created on and modified on dates was a standard somehow.
- jacquesm 17y ago
  It is a standard, somehow. After all, most if not all webservers will include that information in the headers. Browsers could easily display it if their designers wanted to implement that. It would be a fairly simple addition to put that in to the statusbar on the right. I'm not sure if greasemonkey scripts have access to header information but if they do that might be one way to solve this for you.
  - city41 17y ago
    Yeah but that might not be good enough. Like if the user switches web servers, they restore from a back up, the data is dynamically served, etc, the dates might not be accurate. What I've always dreamed of is truly accurate dates on when the article was written, and when it was consciously updated.
    - jacquesm 17y ago
      I'm fairly sure that that is exactly how those dates are meant to be used. If people misbehave then that is not really the fault of the standard. Just for a little check I just looked at a page by a well-known news service, today it is the 13th, here is the last-modified header from one of their articles: Last-Modified: Fri, 11 Dec 2009 11:14:26 GMT So it looks like those headers are actually being used the way they are intended. Restoring from a backup should definitely preserve the file dates, dynamic serving could still serve up the right last modified date (such as in the example above). Dates not being accurate is more likely to happen when people can enter them manually! The only thing remaining then would be a header that registers when the document was first created, but for that we have the META name='date' tag.
      - city41 17y ago
        I totally agree with everything you are saying. It's just that in practice it often doesn't work out. I can create a website that pulls its content out of a database and the web server has no clue what the dates should be for the headers. I think the only real solution is for web developers to be more conscious of this and ensure their frameworks play nice. The up side to that being the more conscious websites are more likely to be the sites with quality information anyway.
        prodigal_erik 17y ago
        If the database has no timestamp for the content, the web site shouldn't be using Last-Modified without a meaningful value. When your code doesn't know what's going on but still wants caching, that's what ETag is for.
      - mcav 17y ago
        Last-Modified isn't intended to preserve the date of the content. It represents the modification time of the HTML document, which is used for caching. It may or may not -- probably not -- represent the date the article was modified. To try to do so would conflate the purpose of the Last-Modified header.
        jacquesm 17y ago
        From http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html: "14.29 Last-Modified The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified. Last-Modified = "Last-Modified" ":" HTTP-date An example of its use is Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT The exact meaning of this header field depends on the implementation of the origin server and the nature of the original resource. For files, it may be just the file system last-modified time. For entities with dynamically included parts, it may be the most recent of the set of last-modify times for its component parts. For database gateways, it may be the last-update time stamp of the record. For virtual objects, it may be the last time the internal state changed. An origin server MUST NOT send a Last-Modified date which is later than the server's time of message origination. In such cases, where the resource's last modification would indicate some time in the future, the server MUST replace that date with the message origination date. An origin server SHOULD obtain the Last-Modified value of the entity as close as possible to the time that it generates the Date value of its response. This allows a recipient to make an accurate assessment of the entity's modification time, especially if the entity changes near the time that the response is generated. " The word 'caching' is not mentioned in there at all, those are completely different headers, see the 'cache control' headers in that same document.
  - gasull 17y ago
    I'm not sure if greasemonkey scripts have access to header information but if they do that might be one way to solve this for you. http://userscripts.org/scripts/show/34231 http://userscripts.org/scripts/show/34231
- jonny_noog 17y ago
  This is actually one of my (few) pet peeves with the 37Signals crowd. I remember reading somewhere (possibly in their Getting Real book) the reasoning behind such design decisions as not including the year on the dates displayed in their web applications. The general reasoning as I remember it was "It doesn't matter." It doesn't matter until it's 3-4 years later and I'm reading a post on Rails that may or may not actually still be relevant and trying to figure out what Rails version it pertains to. Sure the date doesn't matter so much when the content is new, but particularly when it comes to technical documentation, the date starts to matter more and more as the content ages.
warfangle 17y ago
It's still fairly accurate. A cursory read through it (I read it once several years ago) and I don't see anything that needs updating, except maybe the books section. Of course, I haven't read much dead tree documentation for JavaScript, so I can't really comment on that aspect. Since the article was written, a few things were added that are handy, but not expounded upon in the article: we've gone from 1.4 to 1.8.1, and added some helpful things like array helpers, iterators, and so forth. Not much else has changed, though - for instance, you can and probably always will be able to accidentally save a variable to the global stack if you assign a value to it without declaring it.
- TNO 17y ago
  ES5 strict mode won't allow you to define an undeclared variable.

city41 17y ago

I hate it when any page on the web doesn't have a date. I wish having created on and modified on dates was a standard somehow.

jacquesm 17y ago
It is a standard, somehow. After all, most if not all webservers will include that information in the headers. Browsers could easily display it if their designers wanted to implement that. It would be a fairly simple addition to put that in to the statusbar on the right. I'm not sure if greasemonkey scripts have access to header information but if they do that might be one way to solve this for you.
- city41 17y ago
  Yeah but that might not be good enough. Like if the user switches web servers, they restore from a back up, the data is dynamically served, etc, the dates might not be accurate. What I've always dreamed of is truly accurate dates on when the article was written, and when it was consciously updated.
  - jacquesm 17y ago
    I'm fairly sure that that is exactly how those dates are meant to be used. If people misbehave then that is not really the fault of the standard. Just for a little check I just looked at a page by a well-known news service, today it is the 13th, here is the last-modified header from one of their articles: Last-Modified: Fri, 11 Dec 2009 11:14:26 GMT So it looks like those headers are actually being used the way they are intended. Restoring from a backup should definitely preserve the file dates, dynamic serving could still serve up the right last modified date (such as in the example above). Dates not being accurate is more likely to happen when people can enter them manually! The only thing remaining then would be a header that registers when the document was first created, but for that we have the META name='date' tag.
    - city41 17y ago
      I totally agree with everything you are saying. It's just that in practice it often doesn't work out. I can create a website that pulls its content out of a database and the web server has no clue what the dates should be for the headers. I think the only real solution is for web developers to be more conscious of this and ensure their frameworks play nice. The up side to that being the more conscious websites are more likely to be the sites with quality information anyway.
      - prodigal_erik 17y ago
        If the database has no timestamp for the content, the web site shouldn't be using Last-Modified without a meaningful value. When your code doesn't know what's going on but still wants caching, that's what ETag is for.
    - mcav 17y ago
      Last-Modified isn't intended to preserve the date of the content. It represents the modification time of the HTML document, which is used for caching. It may or may not -- probably not -- represent the date the article was modified. To try to do so would conflate the purpose of the Last-Modified header.
      - jacquesm 17y ago
        From http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html: "14.29 Last-Modified The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified. Last-Modified = "Last-Modified" ":" HTTP-date An example of its use is Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT The exact meaning of this header field depends on the implementation of the origin server and the nature of the original resource. For files, it may be just the file system last-modified time. For entities with dynamically included parts, it may be the most recent of the set of last-modify times for its component parts. For database gateways, it may be the last-update time stamp of the record. For virtual objects, it may be the last time the internal state changed. An origin server MUST NOT send a Last-Modified date which is later than the server's time of message origination. In such cases, where the resource's last modification would indicate some time in the future, the server MUST replace that date with the message origination date. An origin server SHOULD obtain the Last-Modified value of the entity as close as possible to the time that it generates the Date value of its response. This allows a recipient to make an accurate assessment of the entity's modification time, especially if the entity changes near the time that the response is generated. " The word 'caching' is not mentioned in there at all, those are completely different headers, see the 'cache control' headers in that same document.
- gasull 17y ago
  I'm not sure if greasemonkey scripts have access to header information but if they do that might be one way to solve this for you. http://userscripts.org/scripts/show/34231 http://userscripts.org/scripts/show/34231
jonny_noog 17y ago
This is actually one of my (few) pet peeves with the 37Signals crowd. I remember reading somewhere (possibly in their Getting Real book) the reasoning behind such design decisions as not including the year on the dates displayed in their web applications. The general reasoning as I remember it was "It doesn't matter." It doesn't matter until it's 3-4 years later and I'm reading a post on Rails that may or may not actually still be relevant and trying to figure out what Rails version it pertains to. Sure the date doesn't matter so much when the content is new, but particularly when it comes to technical documentation, the date starts to matter more and more as the content ages.

warfangle 17y ago

It's still fairly accurate. A cursory read through it (I read it once several years ago) and I don't see anything that needs updating, except maybe the books section. Of course, I haven't read much dead tree documentation for JavaScript, so I can't really comment on that aspect. Since the article was written, a few things were added that are handy, but not expounded upon in the article: we've gone from 1.4 to 1.8.1, and added some helpful things like array helpers, iterators, and so forth. Not much else has changed, though - for instance, you can and probably always will be able to accidentally save a variable to the global stack if you assign a value to it without declaring it.

TNO 17y ago
ES5 strict mode won't allow you to define an undeclared variable.