Tech Sisyphus

In my last post, I write a little about how driving the site forward takes work, especially if you want to build a good site.

Images are the best example. Images can quickly destroy site performance if they are too large, the wrong format, not cached, or not optimized.

HTML doesn't do the content tech expert any favors as the <img> tag just stuffs an image into the DOM. This was great in 1999 when browser were weird and creating pages was difficult.

Now, we have to use srcset to tell img to do the right thing BUT we also have to have images optimized for each entry in teh srcset.

So. This is more work and points at a larger issue.

The tech keeps changing. Back in 1999, nobody imagined the iPhone 11 when browser viewports were assumed to be 760x480 and sites were hardcoded to a width using tables and pixel-specific values for cell widths and so on.

While images are one example, content tech is continuing to evolve as content needs to be searchable and indexed by services like Algolia or others. It needs to be marked up with schema so that search engines can easily know topics or details about content and show content as rich snippets, in business sidebars, and more.

The tech keeps changing. Thanks Moore's Law!

There's value in becoming a wise old elder, who knows every detail of a specific system or technology.

Well, there's value in that until Moore's Law wipes out that technology. Very few platforms survive more than 5-10 years in IT. With the web, it can be even less as browsers dictate what is useful/current and when the browsers are retired, so is that tech.

Side-note: Have you every screamed "I HATE INTERNET EXPLORER" in your career? I mean, it was a good-enough browser but when people built sites that only ran on IE? Oof.

Anyhow.

While a person who knows MUMPS or IBM Mainframes might have a job forever, folks who work with the web need to keep up or they get left behind.

In general, the only way I found to prevent being left behind is to divide the tech into two parts:

This site and the rebuilding process is a great example of how I approached this stack in order to keep up with the tech.

On one hand, these fundamentals don't change often and when they do they have to be backward compatible. Theoretically, you could keep coding things the same way you did 5 or 10 years ago and browsers would process it and chuck out a page.

But, the fundamentals DO evolve to address new needs. That `img` tag that once took a source property and that was it? It had to be updated so that it kept up with new display options.

JavaScript is especially prone to this. You could still write pages with jQuery and plenty of people do. The problem is that jQuery was written to provide a standard interface to programmers when every browser underneath was different. jQuery solved a problem (weird browsers) that doesn't exist today to the extent that jQuery is needed.

If you don't keep up with the tech, you wind up programming with a library that isn't really the tech and when that library is no longer supported and turns out to have critical security issues, you're in a bad place.

Even with the fundamentals, content tech professionals have to track what's happening.

Of course, if we have to rebuild the same stuff every time we create a new site, life is terrible.

Frameworks provide us with tools that make site creation easier. jQuery let us write code in a way that would execute on any browser at a time when browsers were terrible, weird, and sometimes evil.

As browsers matured, frameworks also had to mature. While browsers are now much more consistent and adhere to universal language standards, other problems emerged like "how do you build a site that takes full advantage of a new phone on fiber WiFI but also works great on a second-hand phone on a 3G network?"

Frameworks attempt to address those problems as the evolve and emerge. React makes it easier to build huge sites. Then NextJS helps turn React sites into more streamlined versions so that performance is better across devices.

What's important, I think, are two things:

And, of course, as new frameworks emerge, pay attention.

Usually, new frameworks are the confusing hairball type that can be tossed because new problems to solve are rare. But sometimes, a solid leader shows up that solves a new problem OR uses a development in the Fundamentals in an important way.

When that happens, people rally around and it's good to watch that leader framework evolve even if you don't need it at first. Seeing how they change (often by scanning the issues in Github every month or so) can help you understand the problems it's solving.

Platforms are the worst because they are owned by a vendor, they play games to make it hard to switch to other platforms, and once you leave the platform all the things you learned about the platform are useless.

But, just like with frameworks, platforms solve problems. There's no way I'm going to build a CDN that can compete with Cloudflare. When I need to think about caching content, I'm going to use services from Cloudflare or Azure or Akamai or some other "A" vendor who shall remain nameless lest I summon them like Beetlejuice.

The thing is to learn enough to build solid sites by relying on the fundamentals and frameworks. Platforms solve problems that are worth paying money to solve. Use them to solve those problems, but, again, know the edges.

Learn enough about the platforms so you don't overpay or miss an opportunity to make some other complexity/cost/risk go away. But then stop. Unless you like being locked-in to a vendor...

The bottom line here is (a) don't become an expert unless you need to be an expert and (b) never forget to keep up on the fundamentals and frameworks.

This is my opinion, but this approach worked pretty well for me. YMMV.

OK. This post is done.

It's time for me to go roll that training boulder back up the hill and find out why NextJS is throwing a wacky error, then review Typescript because something I'm doing there is wrong and I'm using an explicit "any" type which...well, I'm not proud about.