Just over a year ago, I was tasked with developing a new website for one of my college’s R&D groups. Their old website was built on top of a jQuery template and generally hard to maintain. Having built user interfaces for about a year up to that point, I thought I had what it took to engineer a better website… I was wrong!

The projects I had worked on prior to that all used React.js, some with and some without Next.js. As they say, “if all you have is a hammer, everything looks like a nail.” And so I chose these technologies to build a simple static website.

In hindsight, from the get-go it was obvious this could not end well. React.js is kinda awesome, actually, if you want to build highly interactive, dynamic user interfaces with data-driven content. Next.js is a fine accompanying framework that offers server-side rendering, routing and helps optimize performance (among many other things). However, the website I built was static, meaning it wouldn’t benefit from most of these features. Sure, it could be built with React.js and Next.js — and it was —, but at what cost?

The aforementioned tools are rather complex. To build websites with them, you need to know their ins and outs. You can’t just write markup and styles and call it a day, as those need to be written inside React’s paradigm of functional components and hooks, adhering to a component-based architecture and handling data flow through props and contexts… That’s all to say you’ll be writing more lines of code.

That’s not a problem by itself, of course. Your project’s requirements might be impossible to meet with just markup and styles, and you might waste time reinventing the wheel writing your own JavaScript code instead of using an off-the-shelf solution. But if the requirements can be met without this additional complexity, it’s wise to do so. Otherwise, you’ll overengineer and end up with a project that is much harder (and costly) to maintain than it should be.

This is how we’ve come full circle with the website. The old one had to be replaced because it was difficult to maintain. The new one now finds itself in the same — actually, in a worse ?— situation thanks to the brilliance of a young software engineer with limited repertoire. I guess we need a new new website now! I plan on throwing the current codebase away and rebuilding it with as little as possible aside from HTML and CSS. Perhaps I’ll consider a static website generator.

The above is the detailed content of How to (Over)Engineer a Simple Static Website. For more information, please follow other related articles on the PHP Chinese website!