51–60 of 124 posts
I'm super-interested, but I'd like to know at a deeper level what this gets us over plain Express.
This pulls in over 200 dependencies, with a total weight of 37MB. I'll pass.
Long-term I would like to reduce this and have some ideas in mind, but right now this is not an issue.
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…
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…
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…
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…
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 haven't tried it, but https://date-fns.org/ looks nice. For example, immutable API and just uses native Date objects.
In general I see the appeal of using a small shim around a standard library thing rather than re-implementing something totally new, but JS Date is bad enough that you're better off staying away altogether. It's just hard to use correctly since there's no "timezone unaware" object available and it always assumes the local timezone, so users' browsers in different timezones treat them differently. Lots of seemingly simple things (e.g. a time + timezone input picker) are easy to mess up because you end up accidentally implicitly converting things to the local time.
Earlier quoted context omitted.
What you propose is only a performance optimization at the expense of operational complexity. Like caching. "Never" doesn't make sense.
I guess you could simply rate-limit your login/signup if your not worried about a DoS and just want to keep people from brute-forcing a password. On the other hand, it's not simply "a performance optimization" as there is no way for node to handle a DDoS without crazy amounts of hardware relative to what iptables|nginx can handle.
Notice how "rate-limiting" is a much more generic concept.
For example, Hacker News rate-limits the amount of posts you can make in a window of time. That's not because they think you're trying to DoS them.
https://github.com/ChALkeR/notes/blob/master/Do-not-underest...