To me it's sad how meta Node.js community is, even worse is with five minutes browsing on the tablet I can't even find out exactly what this nasty person said or did. I suspect this is another hypersensitive SJW act. It started with the legend Crockford being banned from NodeConf for saying dog-balls. Grow up ffs!

In what ways has Trump done anything similar to Hitler?

I've recently launched https://pryin.io, an application performance monitoring tool made for Elixir and Phoenix. It hooks into Phoenix and gives you insights into how long your request / channels take and what Ecto queries are run / how long those take. You can also manually augment pretty much anything else (background jobs, API calls, ...). Plus it keeps track of some important BEAM metrics like memory consumption.

It's very sad that our industry is so hype driven.

Nothing really changed, you could write Android apps on Kotlin before, as well as on any other JVM language. But now "Kotlin is the hero".

I suspect that Google's adoption of Kotlin is just politics: JetBrains develops Android Studio for Google, so they pushed Kotlin as part of the deal. Google could acknowledge Scala years ago, but didn't, because Scala authors spend less time on bullshit politics and more time on actually improving the language.

Also, I don't understand the point of Kotlin. Clojure, Groovy and Scala are all very distinctive from each other and have their own niche. Kotlin is just a subset of Scala. Same thing, but less features. I guess it's NIH principle applied to JetBrains.

The criticisms of JWT seem to fall into two categories:

(1) Criticizing vulnerabilities in particular JWT libraries, as in this article.

(2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc.

The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternatives.

I could care less about JWT per se. I'm happy to implement a similar pattern with something else (e.g. store a secure cookie post-auth, skip all the refresh business and just let it expire when it expires, and employ an ugly revocation strategy only if absolutely necessary). I don't need JWT for this.

If I'm providing a REST API, then I'd prefer a token string that I could pass as a header value rather than forcing the use of cookies. Although I suppose you could argue that a cookie is just another header value.

Either way, if you're serving up a REST API to a JavaScript UI... what's NOT a good option is server-side session state (e.g. Java servlet sessions). That requires you to either: configure your load balancer for sticky-sessions, or employ a solution to share session state across all your server-side instances (which never works very reliably). Moreover, relying on a session isn't a very RESTful auth strategy in the first place.

So if I'm writing a SPA in 2017, then I'm definitely taking a client-side approach and running afoul of the #2 critics. And since JWT is so widely implemented (e.g. if I use a "Login with Google" option then I'm using JWT), I'm probably running afoul of the #1 critics too.

These criticism are fine, I guess. There's no faster route to blog clicks, book sales, speaker invites, and consulting dollars than: (1) telling everyone to jump on this year's hype train, or (2) telling everyone that last year's hype train sucks. What the world really needs is a bit more actual prescriptive recommendations of what to do instead.