cultural reviewer and dabbler in stylistic premonitions

  • 145 Posts
  • 186 Comments
Joined 4 years ago
cake
Cake day: January 17th, 2022

help-circle






















  • Idk it works for me.

    I don’t think there is any possible value for the sign variable which would make that if statement do anything other than raise a TypeError.

    Also "8:00:00" > "10:00:00"

    but "08:00:00" < "10:00:00". comparing timestamps as strings is weird but actually works, as long as the hour is zero-padded :)

    the problem with this code is that & (bitwise AND) has higher operator precedence than > and == do, so it is first trying to bitwise AND "10:00:00" with sign (which i’m assuming would also be a string) and that will always raise a TypeError.

    to do what the author appears to have intended to do, they would either need use parenthesis around both comparisons to actually bitwise AND their results, or (better) to use the boolean AND operator (and) instead of &.

    The boolean and operator is the right tool for the job, and since it is lower precedence it also wouldn’t require that any parenthesis be added here.







  • I don’t think anyone called those “web apps” though. I sure didn’t.

    As I recall, the phrase didn’t enter common usage until the advent of AJAX, which allowed for dynamically loading data without loading or re-loading a whole page. Early webmail sites simply loaded a new page every time you clicked a link. They didn’t even need JavaScript.

    The term “web app” hadn’t been coined yet but, even without AJAX I think in retrospect it’s reasonable to call things like the early versions of Hotmail and RocketMail applications - they were functional replacements for a native application, on the web, even though they did require a new page load for every click (or at least every click that required network interaction).

    At some point, though, I’m pretty sure that some clicks didn’t require server connections, and those didn’t require another page load (at least if js was enabled): this is what “DHTML” originally meant: using JavaScript to modify the DOM client-side, in the era before sans-page-reload network connections were technically possible.

    The term DHTML definitely predates AJAX and the existence of XMLHTTP (later XMLHttpRequest), so it’s also odd that this article writes a lot about the former while not mentioning the latter. (The article actually incorrectly defines DHTML as making possible “websites that could refresh interactive data without the need for a page reload” - that was AJAX, not DHTML.)