
You probably don't need a single page app - AlchemistCamp
https://plausible.io/blog/you-probably-dont-need-a-single-page-app
======
Spivak
The contention between these two schools of thought seems to elude to a bigger
problem that right now both options kinda suck.

The old old school mode of serving static HTML pages is totally fine. I have
basically no issue with it. You can't do very much but if your site is a
series of interlinked but self-contained documents then it's the gold
standard. Once you start having a lot of dynamic content there's a lot of
waste since each page is it's own little application.

The 'classic' model of multi-page web design which boils down to templating
HTML pages is _awful_. Truly ungodly awful. I don't care how many layers of
DSL you pile on top of it to make it feel less like you're building an
application with C preprocessor macros it doesn't make it any better or less
brittle.

The SPA model is "more correct" way to do dynamic content since we're back to
serving static pages but still ends up terrible since now every single page
has emulate browser semantics poorly and deal with the nightmare that is using
the browser as a rendering target.

There's got to be some middle ground. I want the browser to be my application
router. Give be a site-global place to stick my JS send me an event with what
page I need to render.

~~~
majewsky
> The SPA model is "more correct" way to do dynamic content since we're back
> to serving static pages

The contention is that we cannot even agree on basic words. An SPA is anything
but "static", it's as dynamic as a website can ever be with all the untrusted
JavaScript code that my browser has to execute (hence why browsers are as
complex as they are today). A server-side application serving static HTML and
CSS ("static" as in "no JS") is much easier to trust.

~~~
Spivak
When I say static I mean that your web server distributes a fixed artifact
without any server-side templating.

Your usage of 'static' conflicts with the usage of 'static site generator'
where fixed payloads are generated that can be uploaded to any web server.
Such sites can have no JS, be full blown SPAs, or anywhere in between.

Some people use "static content" for this but often sites serving static
content are still enhanced by JS in some form. Just that the main page content
doesn't have any interactivity.

------
shaunpersad
One of these "You probably don't need [popular technology x]" articles comes
out pretty often now. I understand what the message is (don't use tech just
because it's popular, but pick the right tool for the job). But I always
wondered why these types of articles are titled to be dismissive ("you
probably don't need x") rather than representative of their actual content
("here's when to use x").

~~~
paxys
Because the standard "everything is bad nowadays" headlines always get clicks
and upvotes

------
s_y_n_t_a_x
You need to ask yourself if you need a website or a web app. Sometimes your
project can be split into both. The homepage, login, billing, privacy policy,
and other static pages can be a traditional server-side rendered website. More
complex sections, like a file browser or text messenger, can be apps.

~~~
vorpalhex
Why do you need server-side rendering for static pages? They are static pages
- let them be static html and send the file. Pages like that get millions of
times more reads than writes.

~~~
ape4
Often "static" pages aren't 100% static. It might display the user's login
name, etc.

------
wilsocr88
If you need an "app," then yes, you should probably do a SPA. In the same way
that an app on your phone is a chunk of pre-loaded client-side code that
accesses a server's API in a minimal way, with mostly metadata being
exchanged, I'm of the mind an "app" ought to minimize server load in this way.

If, on the other hand, you need a "site" (which will be relatively static),
and you can handle a few extra processor cycles on your webserver, server-side
rendering is probably fine. Still, I retain a distaste for it that I can't
fully explain.

------
vikramkr
Does anyone have a good example of something that's made as a single page app
that shouldn't be one? The reasons described for choosing a single page app,
real time functionality and rich ui interactions etcetera, seem like core
parts of just about every new startup's web service offering as all these
formerly offline desktop programs become online SAAS subscriptions and so on.
What wouldn't need a single page app?

~~~
thekyle
I believe that the new TechCrunch website is a SPA.

~~~
egfx
Your right! Now there is a good example of a site that doesn’t need to be a
SPA!

------
egfx
Good luck building my application [https://gif.com.ai](https://gif.com.ai) as
a non SPA. This is an app as much as photoshop is an app so this is a good
case for a SPA as the author suggests. If over 85 percent of your app logic is
on the front end then you might need a SPA.

------
neves
No, unfortunately you need. If you want to build a Progressive Web App (PWA)
and have just one source for your site and your mobile app, you need a SPA.
The mobile ecosystem is nowadays more important than the web.

~~~
aldoushuxley001
You can of course just use the website on mobile too though, apps aren’t
needed and often they’re just annoying marketing ploys designed to keep you in
a walled garden. I much prefer accessing the website of services than their
apps while using mobile

------
RocketSyntax
In the hybrid approach, would you implement a full framework like Vue or would
you just use jQuery?

