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.
My point is that my example is complex because some client-side code is necessary. The snippet you shared is nice pseudo-code but a real implementation would be comparable in complexity. Either way you need to learn some stuff, and then it’s a few lines of code.
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.
> 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.
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.