> ...a few MB of bandwidth and a few seconds of CPU time

Many people are on cell phones with low data limits. A "few MB", let's say 3MB == a few, represents 0.1% of someone's data limit. Sure, it's not that much on its own, but it adds up.

Likewise, a few seconds of CPU time is fine if you're on the latest iPhone, but if you're in a developing country on an inexpensive Android phone that few seconds of CPU time is going to turn into a world of hurt.

This cavalier attitude towards bandwidth and CPU time is outright hostile to certain classes of users.

The article mentions 100k page views being ~24MB extra a month, which means we are talking about a token of ~240 bytes. So for a single user you are talking about several kilobytes if they are multiple views to the server, which is now several orders of magnitude less than your original estimate.

For this single thing, this is not a big deal at all.

I was objecting to the "It's 2018 and you're complaining about a few MB of bandwidth and a few seconds of CPU time?" statement, not the technical detail of JWT adding an extra ~240 bytes.

I've seen statements similar to this applied to everything from big JavaScript libraries to large "Hero Images" to 2MB GIFs embedded in pages. It's a poor argument and it's representative of an attitude that's hostile to users.

The problem is you are talking about a different problem than the OP. The OP was talking about a few MB and CPU _from the server's perspective_, while you are talking about a few MB and CPU _from the client's perspective_. Yes it would be bad to willy-nilly force clients to take on a few MB per request, but that's not the issue being talked about.

This. Often I've had discussions about APIs that take 100ms or more to return a result where the person writing the API and even the product manager do not understand that this response time is likely too long. Going back to the 1960's and the PLATO system, engineers recognized that humans need a response in 500ms or less whether visual, audio, or haptic, to inform them that the system received the input. Therefore, to give a user that same 500ms response time today across the Internet, not just across the room to the mainframe, requires understand the entire latency chain. One approach is to consider that any interaction has a 500ms budget which cannot be exceeded and then start subtracting out the various latency components. Round trip time across the USA, 150ms. DNS, Connect, HTTPS negotiation, TCP setup, etc.. 25ms. Suddenly your down to to 300ms of remaining budget. Lets assume that 5 service API calls need to be made internally to provide the response, 300 / 5 = 60ms avg budget per API call. I'm going to tell you that with today's CPU/RAM/SSD speeds, 60ms is a huge amount of computing time for a reasonable request.

tl;dr, remember the 500ms overall budget for the humans at the end of the pipeline. No one anywhere said I want my response time slower.

1/3rd a kilobyte to the user per page request. The MB and CPU time are to your server. Over the entire month. I'll pay that penny.

> It's 2018 and you're complaining about a few MB of bandwidth

Ah, yes, 2018, the Year Where Everything On The Internet Is Connected To A Cable.

It's 298 bytes per page request given the example he gives (your token can be smaller or larger depending on the data in it).

It's 24 MB of bandwidth to the -server-. Your server -better- be behind a decent broadband connection, or what are you even doing?

1/3rd a kilobyte per page request to the -client-. 1/3rd a kb is a blink of an eye even on modern dialup.

Why do you think it has to go skyrocket forever?! I am already really disgusted by how big applications are nowadays, how bloated, slow, memory-hungry and inefficient they are. Every saved MB counts.

In this case the article is talking about 24 MB of additional bandwidth used by the server to serve 100k pageviews using JWTS

A few extra MB of traffic is fine in a datacenter. Not so much for a mobile client somewhere with a weak signal.