Ask HN: Is it over-engineering if I implement a blog site as a single-page app? - SimeVidas
======
shrthnd
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.)

------
PaulHoule
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.

~~~
SimeVidas
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?

~~~
PaulHoule
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.

------
simplecomplex
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.

------
detaro
Very likely yes.

~~~
SimeVidas
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?

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

~~~
SimeVidas
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.

~~~
stargrazer
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.

