Where's the social engineering part? Trying to convince people you aren't a scumbag so they become your friend long enough for you to swipe their password?
Actually, they don't use Slack because Slack would be the most expensive piece of software they license. The enterprise model from Slack is so prohibitively expensive it's like they're intentionally trying to drive away large customers.
I had an extension a while ago that I was attempting to publish to the Firefox app store and it was rejected on grounds of using eval. I don't remember why I needed to use eval, but basically this is something they do already. I'm guessing that previously they were allowing for an Angular exception.
These things aren't pain points in the browser the way they are in Node. I have never felt the need for an ORM in the browser. I have never dealt with client-side code that was using so many libraries I had to worry about whether exceptions would be handled via exceptions, or the first argument of the callback, or rejected promises. No one (at least, no one I know) is installing node modules like isArray to use in the browser.
Yes, these things _could_ technically apply to the browser, but it's not commonplace. In the node world, these are all things you deal with consistently.
At a previous company, we initially set everything up at Heroku. As things got cost prohibitive, we moved them one by one to AWS. Since Heroku is setup on AWS, it was easy enough to connect to our Heroku postgres instance from AWS web servers and it doesn't add any extra latency vs. running direct on Heroku. Over time, we slowly migrated everything off to our own infrastructure on AWS, but we were able to leverage Heroku to avoid all of that development effort until it was cost effective to do so. You'll need to deal with your own SSL endpoint if you run your web servers on AWS, but it's pretty trivial to do so with ELB.
It depends. I tried to switch to Simple, but at the time I was working as an independent contractor. The maximum size of a check you can deposit without mailing it to them is $3k. Having to mail in every check I received was a hassle that outweighed any benefits Simple provided over a regular bank account.
I'm guessing MySQL doesn't support this (hence the need for a cron job), but postgres lets you set a statement_timeout on the connection. It will force kill queries that go beyond that timeout. I worked on an app not too long enough that occasionally would have some queries go off the rails and start blocking everything. We set up postgres to just kill off anything taking 30s automatically, and then were able to root out the issues without worrying about everything blocking on these broken queries and taking down our systems.