61–70 of 124 posts
Rather than changing express's syntax, I would much rather have a better express boilerplate generator with an opinionated stack with good documentation/justification. I recently started learning express/node and wasted weeks googling for blog posts for each dependency to figure out how to configure them. I guess this is somewhat valuable for end-to-end understanding but not for productivity. There are a bunch depend…
maybe time to make a "node on rails"!
Earlier quoted context omitted.
Totally a tangent but, don’t use moment.js! It inherits some of the parsing and other quirks from the awfulness that is the JS Date object, the mutability almost certainly will lead to being bit by a couple of bugs before you actually internalize it, and the time zone support is kind of tacked on as an afterthought. I highly recommend js-joda, particularly if you’ll ever be computing/showing things to your users in d…
I've always been of the opinion that timestamps should be stored UTC datetime or unix timestamp on the server side and then displayed to the proper locale by the client's device. Is this not a good method?
As an aside, moment-timezone it a godsend for dealing with timezone discrepancies. I would pay money for it.
Earlier quoted context omitted.
Totally a tangent but, don’t use moment.js! It inherits some of the parsing and other quirks from the awfulness that is the JS Date object, the mutability almost certainly will lead to being bit by a couple of bugs before you actually internalize it, and the time zone support is kind of tacked on as an afterthought. I highly recommend js-joda, particularly if you’ll ever be computing/showing things to your users in d…
I've always been of the opinion that timestamps should be stored UTC datetime or unix timestamp on the server side and then displayed to the proper locale by the client's device. Is this not a good method?
In short, the ES5 specs [1] say that
The implementation of ECMAScript should not try to determine whether the
exact time was subject to daylight saving time, but just whether daylight
saving time would have been in effect if the current daylight saving time
algorithm had been used at the time. This avoids complications such as
taking into account the years that the locale observed daylight saving time year round.
The spec has been improved starting with ES6 [2], but to my knowledge no browser has fixed the issue:
An implementation dependent algorithm using best available information on
time zones to determine the local daylight saving time adjustment
DaylightSavingTA(t), measured in milliseconds. An implementation of
ECMAScript is expected to make its best effort to determine the local
daylight saving time adjustment.
NOTE It is recommended that implementations use the
time zone information of the IANA Time Zone Database
http://www.iana.org/time-zones/.
[1] http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.8 [2] http://www.ecma-international.org/ecma-262/6.0/#sec-daylight...
Earlier quoted context omitted.
I've always been of the opinion that timestamps should be stored UTC datetime or unix timestamp on the server side and then displayed to the proper locale by the client's device. Is this not a good method?
It is not good enough. All the major browsers that I tried do not properly handle the timezone offset, as I discovered a few days ago (I put a more complete answer about this in a stackoverflow answer, but I don't know if putting the link would count as self-promotion so I will leave it out) In short, the ES5 specs [1] say that The implementation of ECMAScript should not try to determine whether the exact time was su…
Unix timestamp refers unambiguously to single point in time. Interpretation of this point in time in different timezones is complicated but it's outside of it.
Rather than changing express's syntax, I would much rather have a better express boilerplate generator with an opinionated stack with good documentation/justification. I recently started learning express/node and wasted weeks googling for blog posts for each dependency to figure out how to configure them. I guess this is somewhat valuable for end-to-end understanding but not for productivity. There are a bunch depend…
maybe time to make a "node on rails"!
Rather than changing express's syntax, I would much rather have a better express boilerplate generator with an opinionated stack with good documentation/justification. I recently started learning express/node and wasted weeks googling for blog posts for each dependency to figure out how to configure them. I guess this is somewhat valuable for end-to-end understanding but not for productivity. There are a bunch depend…
This might be somewhat negative, but I don't quite see what problem the library is solving. It looks like as if Express wanted to become more like Koa (obvious from the context object). Frankly, it has missed out - koa's simplicity and elegance is unmatched. The routing and middleware syntax is particularly clunky. Documentation seems really nice though.
No problem, didn't sound negative. The main difference with Koa would be having a starting point with default middleware, security and websockets. I do agree with your points, Koa is probably the most elegant library out there, probably followed closely only by express. But that is not why I created server. It is not about library elegance and simplicity, it's all about making it easy to use. Both of Express and Koa…
Earlier quoted context omitted.
It is not good enough. All the major browsers that I tried do not properly handle the timezone offset, as I discovered a few days ago (I put a more complete answer about this in a stackoverflow answer, but I don't know if putting the link would count as self-promotion so I will leave it out) In short, the ES5 specs [1] say that The implementation of ECMAScript should not try to determine whether the exact time was su…
It's good enough (and correct) to store unix timestamps. For displaying the date - your comment applies... Unix timestamp refers unambiguously to single point in time. Interpretation of this point in time in different timezones is complicated but it's outside of it.
My issue was with "then displayed to the proper locale by the client's device." I mean, by itself it is ok, but in the case of a web client one cannot unfortunately just use the Date object and convert the timestamp to a human readable string.
Earlier quoted context omitted.
rate-limiting -> nginx || iptables Never ask PHP/Node/Ruby/Python to do low-level network routing. Your throwing megabytes of memory at a simple connection decision. If you need advanced logic for rate-limiting (not just access counting) then using nginx + memcached/redis as the marker. Have your app mark the ip in memcached/redis so nginx knows not to bother Node/PHP/Ruby/Python next time.
What you propose is only a performance optimization at the expense of operational complexity. Like caching. "Never" doesn't make sense.
Rather than changing express's syntax, I would much rather have a better express boilerplate generator with an opinionated stack with good documentation/justification. I recently started learning express/node and wasted weeks googling for blog posts for each dependency to figure out how to configure them. I guess this is somewhat valuable for end-to-end understanding but not for productivity. There are a bunch depend…
https://github.com/konstructorjs/konstructor It is still in it's very early stages. Thoughts welcome!