This article is meant for folks who already have a static React site, and want to dip their toes into doing some backend stuff. It isn’t really meant to be the simplest way to build a hit counter.

That said, I challenge the assumption that this way is _that_ much more complicated. I’ve built similar things with PHP, a long long time ago, and it was a lot of the same pieces. The only part that feels truly more complex is the re-render necessary in React, since the data comes in async, but this is hugely beneficial since it means the page doesn’t need to be server-rendered / the user isn’t staring at a white page waiting for the RPC to the database.

Edit: realizing that there are ways to do this in PHP that aren’t blocking, like if you use an image tag that resolves to the right image, but honestly that way seems wayyy more complex to me, especially when factoring in accessibility / screen-reader-friendliness.

> ... it means the page doesn’t need to be server-rendered / the user isn’t staring at a white page waiting for the RPC to the database.

React-based frontend didn't invent XHR. In the old days you just do

  <script>$("#hit-count").load("/path/to/hit/count");</script>

Edit: Not saying old hit counters are implemented using XHR.

The old way was really just a image or iframe. It would update on the fly since it was just some perl code in a CGI-BIN writing to a text file

I meant the old way to achieve exactly what the React version does.

The code snippet is working code (as long as you substitute the correct endpoint), not pseudo code. Unless you meant I didn't add a trivial error handling callback.

Ah, I thought “load” was a jQuery plug-in. In that case it’s real code, but it’s only handling the data-fetching; I don’t need React to do that either, but I’d need to generate the hit counter itself (for it to be exactly equivalent, it would need to generate the numbers with SVG as well as add aria labels for screen readers).

The only React-specific thing is the useEffect call, which is essentially comparable to window.onLoad.

these examples of the simplicity of the "old days" are certainly leaving out a lot of stuff that would still need to be done to make the hit counter work and as such they are really not comparable.

It is starting to remind me of a guy in 2006 approximately that said all you needed to parse display an rss feed in your webpage was a call to rss.parse(my rss url); ignoring all the other stuff that needed to be done (using third party script with all rss parsing built in, having the correct css from the third party library to make the output html look good, make sure not to have any conflicting classes in your page because this third party script from the old days didn't take that kind of thing into account , having a div in your page that had the right id for the rss.parse method to append its output to etc. etc)

it's jquery[0], so this is only the "old days" if 2006 was the "old days" for you (which obviously for many it was).

Before 2006 you'd probably use XMLHttpRequest directly- but of course that was only widely available in 2004 or 2005. Before that you would have used a hidden frame- or more likely you would use CGI to either replace a directive with the counter, or generate an image with the correct numbers. That's what I would call the "Old days": a dynamically generated gif with bold white-on-black numbers displaying the visit count.

[0]: https://api.jquery.com/load/

> it's jquery[0], so this is only the "old days" if 2006 was the "old days" for you

People don't remember so well. Even backdating it that far is too generous. Just as a reference point, on New Year's Day 2006, jQuery didn't even exist yet. There was a time post-2010 when the scourge of jQuery showing up for trivial use cases was considered a real problem and a huge source of bloat on the web. (Side note: it's more than a little annoying, for this reason, to see people when trying to talk about changes in Web developer trends to lump jQuery and vanilla JS together.) To give another reference point, Firefox's then-new Tab Groups feature demanded the creation of a jQuery-like library for handling the tab canvas. John Resig was a longtime friend of the project and one-time Mozilla Corporation employee, but jQuery itself was out of the question because of bloat/performance. That was for Firefox 4, which would have been 2011, since it was released at the end of Q1 that year...

There's a lot more concentrated change in the 2010―2015 timeframe than is often accounted for when people think or talk about the Web.

I understand where you're coming from, but I'm going to play devil's advocate and think through everything that needs to be considered for a simple, "back in the day" solution that involves apache, php, and a mysql database:

1. Provisioning the server, either via VPS or setting it up on your local machine and exposing port 443.

2. Installing Apache on your operating system

3. Installing a cert, getting it signed by an authority

4. Installing php, enabling it in apache

5. Installing mysql

At this point you'll have to write your php from scratch or use something like wordpress. Assuming we want to keep it as simple as possible and write php from scratch, you'll want to consider file permissions so your database credentials aren't accidentally leaked.

6. Creating the schema and tables on your database

7. Distributing your site's static content through a CDN

And this doesn't even involve automated deployments, which these services give out of the box.

My point is that a "traditional" approach can appear just as overengineered and convoluted if we want to replicate the scalability, stability and security of solid PaaS services like Vercel and Fauna.

I get that a hit counter is very simple, but I assume the point of this article is to provide a simple "hello world" example that uses these PaaS services, which again, provide a lot of benefits over manually configuring infrastructure.

Your point is valid, but only in cases where you don’t already have everything you listed set up.

I think the OP’s comment was coming from a perspective of someone adding a hit counter to an app that already has app servers, etc, already in place.

if that's the case then the OP's comment should take into consideration the perspective of someone who already has most of the things listed in those steps setup.

In which case - as an example - you don't need to set up a serverless account and have several hundred loc for that because you've got that in your app already, and probably only need 1 loc to call what you need.

Now I'm arguing on the side of serverless, sheesh.

The one you've linked to doesn't seem to actually store the count anywhere, which seems to be the hard part.

Agree with a lot of what you wrote, but the example is weird. It's a client side counter with no persistence.

Yeah, i realize that, it was just something quick I found after about a 30 second search. I wasn't trying to complain about the original article itself, it's obviously a production ready example whereas my linked one not so much.

It's just the general idea that, such things are required even for something so simple just seems over the top when you look at something like a hit counter alone.

It's just overall, if we tried to simplify, the simple things, would all the rest of the frameworks and apps end up being so convoluted and overengineered?

Yes, I imagine there's some example that uses Redis or similar with a proper increment and locking somewhere, perhaps in an eventually consistent way that doesn't block the page load.

yeah, but what you link to isn't a real hit counter? It makes something that looks like a hit counter without any of the backend stuff you need for a real hit counter.

As far as how simple it was back in the day https://news.ycombinator.com/item?id=24618580 already said.