Ask HN: Is it over-engineering if I implement a blog site as a single-page app? | Hacker News Reader

Ask HN: Is it over-engineering if I implement a blog site as a single-page app?

2 pointsSimeVidas11 comments

There are definite pros and cons of either approach.

Yes, it is over-engineering in a sense that you can start a blog using any number of free hosted platforms, or install an existing blogging platform onto your own host.

BUT! If you already have a data-source, you should check out GatsbyJS or VuePress -- these are static site generators which allow you to create a single-page experience while also providing fallback for browsers with compatibility issues.

(Even without a datasource, both of these frameworks are a great starting point for building out prototypes, landing pages, and simple websites.)

I think it is inappropriate if this is about the content. Why should somebody need JavaScript turned on to read a blog? If there is a real benefit then go ahead but if the goal is to write a spa than that's a bad application of it.

That is a downside, of course, but that by itself doesn’t indicate that the site is over-engineered, I think. Over-engineering means that the site is more complex than necessary. Is it not possible that a singe-page app approach can be less complex than, for example, server-side rendering combined with progressive enhancement via JavaScript?

One way to do it is to write some kind of "viewer" in Javascript and then make the blog posts be JSON documents.

That would fit with the "progressive webapp" approach where you could build a caching framework to support disconnected operation.

You might be able to pursue simplicity in the back end by having it be some kind of fairly generic document store.

Yes. It’s overengineering and most likely what you’re planning on building doesn’t even work. For example, offline support and caching work just fine with HTML, but you’re probably planning on breaking them.

No you don’t need React to publish some words on the web.

Very likely yes.

Could you elaborate? I’m specifically interested in the comparison to alternative approaches. You need a tool to create a blog site anyway, so what makes a JavaScript framework more “over-engineery” than a server-side or build-step approach?

You still need some server-side or build process to feed data to the SPA, and it won't be that simpler that without the SPA.

Blogs typically don't have complex state that's worth keeping and managing on the client.

SPAs have extra complexity to get all the things working properly that work on multiple pages by default. E.g. I have to immediately think of this recent thread about a SPA blogging platform: https://news.ycombinator.com/item?id=20494114 - and I see broken pages like that all the time.

... assuming client side rendering. there are single page server side renders which can provide html-only single page sites.

What if you need some degree of client-side interactivity? Then you need JavaScript logic in the browser. That is in addition to the tools that perform server-side rendering. Isn’t this added complexity prone to over-engineering, more so than having a single JavaScript framework that renders the site and handles interactivity, all in one place?

I get that client-side rendering can be a problem if JavaScript is disabled or fails to load and execute, but that by itself does not mean that singe-page apps are over-engineered. On the contrary, I’d argue that a single-page app is the simplest (least complex) approach to creating a blog site with some interactivity.

For example, Emweb's WT is an example of a server side renderer which inserts pieces of JavaScript on the client side for some UI enhancements.

With the server side rendering, it is able to detect browsers where javascript has been disabled and then render html-only pages.

So whether it means anything or not, server side rendering can service a wider audience than can client side renderers.

Reply on news.ycombinator.com