
Single Page Application Is Not a Silver Bullet - bloomca
http://blog.bloomca.me/2018/02/04/spa-is-not-silver-bullet.html
======
vincentriemer
As an avid developer of SPAs (currently working on one for my own blog
frontend) I'd say a lot if this stems from people being convinced SPAs 1)
provide a faster development cycle, 2) they believe that they've offloaded all
need for optimization on the framework they use and 3) "serious" development
teams build SPAs.

Anecdotally I find SPAs, while I'm more comfortable developing them, will take
longer to build. You need to pay more attention to the quirks the author
mentions and you need to spend more time explicitly optimizing your code. I
like this paradigm because if there is inconsistent logic, poor performance,
or other issues, it's my fault and I have the opportunity to fix it.

As a counter example to the ones mentioned in the above article, around 2
years ago I build a drum machine webapp entirely in JavaScript/React
([https://io808.com](https://io808.com)). This has ~17 JS library dependencies
and ~6000 lines of source code but the gzipped bundle size comes out to ~97
KB.

Just because you're building an SPA doesn't mean you need to spend less time
optimizing your code, in fact it likely means the opposite.

~~~
jamra
I’ve used React in the past and I believe what you’re mentioning is very React
specific.

Angular has lazy and eager loading, which reduces bundle sizes. It also
doesn’t require so many frameworks to manage manually. They are still there,
but they are sort of imported automatically by angular cli so it doesn’t take
a lot of mental overhead.

Some issues I had, though, were with bugs in newer versions. Some of those
issues stopped development outright.

Another issue I have on one team is the fallacious notion that the front end
programmer will take over the front end so no one else will need to think
about it. Business specific logic seems to be out of reach for my particular
developers, which prolongs the development cycle.

The benefit of state management and inter component communication have to be
balanced the the practicality of who is doing the work and if those people can
take ownership of all associated areas touched by the SPA.

~~~
swyx
is there a way for React to do eager loading? i asked around on twitter but
got told "thats not React's job".

~~~
connorelsea
I think the react dev team is currently working on an official async loading
pattern for a future update. But currently webpack, rollup, etc. offer dynamic
import, code-splitting, tree-shaking

~~~
shados
Not sure if that's what you mean, but when Andrew Clark keeps mentioning the
"async" word, he means async rendering, not async loading.

~~~
connorelsea
What is an unsolved async loading problem in React you are experiencing?

~~~
shados
I don't have any issues with async loading. I'm just saying that I believe
what you are referring to when you say the React team is working on an
official async pattern is not actually async loading, but async rendering.

At least every time one of their members said the word async in the last
couple of weeks/months, it's what they referred to, and it's a completely
different (and unrelated) thing. I can't read your mind though, so I'm just
guessing.

------
andrenotgiant
I always thought the decision was:

\- Content site = NOT single-page-app

\- Application = single-page-app

Maybe there's more of a gray area between content sites and applications these
days, but I think it's still pretty obvious: If most of the user's time is
spent reading content, it's a content site.

~~~
thinkloop
The problem is even content is becoming functional with interactive charts,
infographics and figures, videos, media, filtering, sorting - then the site
will eventually need comments, ads, subscribing, favoriting, upvoting, login,
lazy load next article, infinite scroll, etc. Yes, a pure content site
shouldn't be an spa, but how long can you survive running a pure content site?
Information is complex and the web allows us to communicate it more richly
than the static 2d representations of old.

~~~
debaserab2
What are static 2d representations?

You can do everything you mentioned without an spa just fine. Plenty of
content sites (the majority, actually) survive just fine.

~~~
nojvek
Well he’s taking about a hybrid. Each of your pages are essentially little
applications on their own.

------
burlesona
One of the ways that I prefer to judge a JavaScript framework is (1) what is
the minimum payload to use it, and (2) how nicely does it play with a hybrid
app?

In practice I’ve found VueJS does pretty well in this regard. Rather than
build a full SPA I can sprinkle a few components here and there on pages that
are highly interactive. The rest of the mostly static screens on my app are
perfectly happy to be rendered from the server.

It can be hard to strike the right balance between developer friendliness (ie
maintainability and extensibility) versus user experience (ie speed and
backwards compatibility) these days, but as always it’s important work to
deliver the best user experience we can, and I agree with the author that SPA
are not always the right choice in this regard.

~~~
unclebucknasty
> _Rather than build a full SPA I can sprinkle a few components here and there
> on pages that are highly interactive_

In practice, I've found "hybrid" apps hard to pull-off. In my experience, the
question becomes, where do you draw the line?

Take the simple/common case of presenting a list view. From the list, you want
to allow the user to click to view details, which you then present dynamically
--maybe in an overlay. It's a great user-experience. Everything pops, the user
can easily return to the list view without a full page-load, etc.

But, you now have a details view that is not reachable directly via its own
URL. So, you use the framework's routing capability to assign one. Now, things
are getting weird, because you're routing a dynamic view on top of a server-
rendered one. You'll likely end up finding that you'll have to route the
server-view as well for general navigability. And, you also have to account
for people hitting the details URL directly (i.e. render the proper underlying
server view, then let the client route to the dynamic URL).

Not to mention the back-button.

All manageable, of course. But, it gets messy to maintain such a hybrid
approach. By the time you've integrated the routing, etc. the question becomes
why hybrid? Why not full SPA?

If your app is _super-simple_ wherein you're just doing the tiniest bits of
dynamic stuff _and_ you don't need things like first class URLs, navigability
among dynamic content, etc. then, yeah, maybe. But, that's not really a
hybrid-SPA solution because there's no SPA there.

In fact, I'm not sure there is a such thing as "hybrid-SPA". By definition,
seems it's either a SPA or it's not.

~~~
Can_Not
> In fact, I'm not sure there is a such thing as "hybrid-SPA". By definition,
> seems it's either a SPA or it's not.

I'm open to hybrid being defined as two possible things: a regular SPA with
server side rendering (SSR on manual refresh and first visit). Nextjs for
react, Nuxtjs for VueJS, angular universal. I think OP was talking about the
other definition of hybrid.

The second definition is for when your team prefers or is only trained in or
is maintaining codebases in the legacy MPA style, typically similar to
Rails+jQuery. When you need a specific div element to have advanced UI
components and a jQuery plugin didn't fit the needs, the answer was "not
happening". VueJS showed up and changed this to "can budget finite dev hours
and willing to maintain", as it had good tutorials for assuming you wanted a
small widget instead of a full rewrite to SPA. Do this enough times, and you
have a hybrid. Now you have enough SPA-ness that you can be satisfied or you
can plan a multi-sprint "convert the rest to SPA" project.

------
baddox
> broken “open in a new tab” behaviour – people like to handle links in
> onClick handler, and browser can’t recognize it as a link (even if the
> majority of the links are valid, sooner or later you’ll encounter a non-link
> “link”)

This one annoys me the most, but I will say an analogous problem is fairly
common on non-SPA web sites, where reloading a URL doesn’t work as expected.

~~~
wavefunction
That's usually just a lack of basic engineering practices common to well-
implemented SPAs.

All requests below the SPA's root should be forwarded to the SPA root, which
appropriately then routes the request to the proper views and controllers.

Proper usage of resource IDs in these URLs allows a newly initialized
application model to populate and serve the appropriate content for the
appropriate views.

~~~
userbinator
The point is that browsers _already_ have built-in code to interact with links
and such in a predictable and straightforward manner, and your suggestion that
"a lack of basic engineering practices", implying all SPAs need to reimplement
that functionality, shows just how absurd the situation is.

~~~
manigandham
There's nothing to reimplement. Browsers navigate based on URLs, so if the URL
for a page in an SPA isn't enough to load the full state on a fresh pageview,
then it won't work.

So it's absolutely about proper engineering to make sure pages have working
direct URLs rather than just relying on other navigation while the app is
already open.

~~~
ninkendo
Sure there’s something to reimplement. Ensuring that changes to the view state
are represented in the URL bar isn’t trivial. Should a popup dialog be
reflected in the URL state? Should a confirmation prompt? What about browsing
a hierarchy of menus?

With web pages as documents that only use JavaScript to “decorate” things, you
get this for free. And it’s likely aligned with what users expect.

~~~
bfrydl
I really don't understand where you're coming from. SPA routing is a solved
problem. There are countless modern solutions that are not only trivial to use
but offer bonus functionality over traditional approaches, such as isomorphic
routing or controlling the state of individual components and elements with
routes instead of entire pages.

> Should a popup dialog be reflected in the URL state? Should a confirmation
> prompt? What about browsing a hierarchy of menus?

These aren't examples of problems with SPAs, they are examples of things that
do not cleanly map to URL routing in general. You could ask all of these same
questions of a normal web page and they would have the same answers.

~~~
nitrogen
Terms like "solved problem" and "modern solutions" set off my BS detector.
Doesn't the existence of countless solutions, rather than relying on built-in
browser behavior, imply that it's not a solved problem?

No doubt single-page apps have their benefits, but there's an _awful lot_ of
new hotness kool-aid being passed around. The JS ecosystem is still suffering
heavily from the inner platform effect.

~~~
manigandham
This is a strange comment thread as it seems everyone is talking past each
other.

Browsers can only navigate via URLs. Traditionally these pages are rendered
completely on the server but SPA's can just as easily load the appropriate
page based on the URL, it's just done on the client and requires routing to be
setup.

 _Whether_ it's actually setup like that is up to the developers to do, as
many don't use routing for all inner pages. If they don't put in that effort
then there are no URLs to navigate directly and thus there is nothing for a
browser to do to open a new window/tab. Routing _is_ a solved problem and is
purely about implementation.

------
JohnnyCrazy
TBH most of the cons stated in this article are just because of bad
programming, not because it's a SPA

> broken “back” button (sometimes it works properly, but in general people
> don’t trust it)

If your UX is good, the user will notice data is refreshed when going back.
All current top tier SPA Frameworks have support for correct HTML5 routing.

> broken “open in a new tab” behaviour – people like to handle links in
> onClick handler, and browser can’t recognize it as a link (even if the
> majority of the links are valid, sooner or later you’ll encounter a non-link
> “link”)

Again, most up-to-date frameworks have a fallback by adding a normal href so
you can still CTRL-Click it.

> sometimes broken “refresh” button – after refreshing you end up in a
> different UI (usually slightly, but still different)

I don't see a real disadvantage here, since you can simply store your state by
manipulating the URL or even localstorage. So you even have the possibility to
not store your state...But again, application design, not SPA

I do agree with TTI (at least on the first load) and bad performance on low
end devices.

~~~
jordache
No. Because it is an SPA, it means there is more work to restore the default
behavior of the back button. That's the way he should have articulated his
point.

You also mention HTML5 routing.. Ok now you have to configure your web server
to properly parse the URL and understand what it's conveying.

~~~
Can_Not
And all of that work is already done for you in all modern major SPA
frameworks.

~~~
jordache
Server side too?

Client side routing? Have you seen the huge chapter dedicated to routing for
angular? You make it sound like it's no work

~~~
Can_Not
> Server side too?

Yes

> Client side routing? Have you seen the huge chapter dedicated to routing for
> angular? You make it sound like it's no work

Haven't seen angular's, they were late to the SSR party.

------
userbinator
Half-expecting this article to itself be SPA, and was pleasantly surprised
that it isn't.

I agree completely with the author; there's some things (games and such come
to mind) which certainly deserve to be SPAs, but the majority of the time it's
a horrific waste for every single visitor to have to process MBs of data just
to display a few KB of text and hundreds of KB of images (at most). Why? Just
so developers can show off that feeling of how awesome they are for using some
incredibly complex framework. That, and the ridiculous rate of churn, are
probably what most irks me the most about the whole web development community
(and why sites like HN appeal to me so much.)

I'm not sure what's responsible for this "love of bloat", but IMHO we should
be teaching developers how to do more with less, and not the complete opposite
as seemingly happening today.

~~~
Can_Not
> Why? Just so developers can show off that feeling of how awesome they are
> for using some incredibly complex framework. ... I'm not sure what's
> responsible for this "love of bloat", but IMHO we should be teaching
> developers how to do more with less, and not the complete opposite as
> seemingly happening today.

I think you're misplacing the cause into developers. Developer's want to use
the SPA framework because certain magnitudes of "application like UI" become
maintainence nightmares for teams who stick with jQuery or use
youmightnotneedjQuery.

The reason they end up bloated or with random framework-supported elements
broken (back button, etc.) is from what I call MVP culture. AIM and IRC were
perfectly fine in the early 2000s, but instead of upgrading them for 2010+
they were abandoned or stripmined of value (Skype). Now we have slack,
discord, flock etc.. releasing MVPs. Except apparently, they are perpetual
MVPs.

Many industries are encountering this. Developers at large are not permitted
to rewrite in native languages, optimize any non-blocking performance issue,
fix bugs that don't affect the bottom line. Everyone's trying to disrupt an
industry so they can vendor lock in high profit rents. When we finish
switching from typescript to reasonML and decide to switch from reasonML to
Nim/kotlin-native, MVP culture will still be there to tell developers not to
fix the broken back button.

------
photonios
Some of the arguments the author mentions are not really good arguments.
Basically it boils down to how much you care about the user experience. I
designed and developed a SPA for a large real-estate portal in <6 months. I
think we've nailed all of the points the author mentioned:

\- Initial request is rendered server-side, so TTI is extremely low. Even if
the JS hasn't kicked in, the website is already usable.

\- Back button works perfectly fine. We use the HTML5 `history.pushState`
method to add new entries to the history stack.

\- Links are always rendered as anchor tags. So even if the onClick handler
fails or the JS crashed, the link will still work.

\- Compress the hell out of the bundle. Clocking in at 190KB compressed.
(Edit: should do something about this, should be <100KB)

Basically, we have most of the advantages of rendering "static" pages, yet
also get all of the advantages of an SPA. We can do pre-loading in search
results for example. If you click a link in search results, we immediately
render the page and use the data from the search result to show a basic page
and then slowly enhance it.

This powers a large real-estate website that receives hundreds of thousands of
visits a week. For this kind of business, a lot of stuff is important to get
right. SEO related optimisations are extremely important. Hence, we server-
side render everything to make sure the GoogleBot can read it all. The same
applies to links. We keep our bundle size as small as possible to keep things
speedy.

Oh, and I personally got a kick out of spending a weekend to make the website
function perfectly well without JS.

~~~
JohnnyCrazy
Do you mind telling which stack you're using?

~~~
photonios
React 16, Redux, Webpack, a custom router. All transpiled using Babel. On the
back-end we also use Python/Django. Nothing out of the ordinary :)

~~~
OffTheRails
This is great to see.

I've been developing in Rails for the last 5 years, and am about to build my
own products, and am opting for this kind of setup.. though have decided to
hop over to Elixir on Phoenix, and will swap out Redux for Mobx. The
application is mostly a dashboard (SaaS). Could easily be an MPA, but I want
to move into more responsive UX, and wouldn't mind leveraging the portability
for when I develop mobile or desktop apps.

It seems majority of these responses against SPAs are, as you said, all based
on bad design, not because the architecture itself is fundamentally flawed --
though it is obviously going against the grain by breaking a lot of this
functionality in the first place.

Having said that, the fact that browsers are providing native features to
support SPAs, while bridging mobile-native features, is a massive sign of
things to come. They're not going away, and support will only get better, and
they will only become easier to develop.

Anyway, I'd be interested to hear about your custom router! Any particular
reason you rolled your own? I was planning to just use react-router, but if
there are headaches down the road in terms of managing a hybrid SPA with SSR,
I'd appreciate the heads-up.

------
thehardsphere
The problem with SPAs in the sort of cases that the author is talking about is
that people don't think clearly about what requirements they are satisfying
when writing a new one. If your app actually needs to switch between various
screens without a refresh so your users can most efficiently get their work
done, then yes, by all means, make an SPA. That requires knowing clearly who
your users are, what they want to do, and what constraints they are under
(e.g. if they all work on desktops with good internet access, maybe it doesn't
matter that your app is bloated and slow on mobile). I think most people don't
do that thinking step first. They want to play with the new shiny, either as a
sort of fun or so they can add it to their resume.

This I think is made worse by the unparalleled decadence in which the modern,
first-world developer now lives. It is absolutely excessive to have to
download 2.6 MB just to show a blog or some simple textual information, but
thanks to broadband everywhere and terabyte hard drives, nobody under the age
of 30 who isn't working in embedded systems thinks about this anymore.

------
nikkwong
From a development perspective, in my humble opinion the single biggest hurdle
with developing SPAs vs traditional server side applications are problems
dealing with state consistency. The state model in non-spa apps is simple:
when a pageload is requested, pull the latest state from the server. In SPAs
the state has to be held on the client and server, and has to be able to react
to state changes from the other side of the wire.

Also I think that large bundle size being a mark against all SPAs is
misleading. Yeah, angular is 1mb+, but vue is ~20kb, so the potential for the
bundle to be small exists.

~~~
Udik
> The state model in non-spa apps is simple: when a pageload is requested,
> pull the latest state from the server. In SPAs the state has to be held on
> the client and server, and has to be able to react to state changes from the
> other side of the wire

My view is the exact opposite. Whenever you go through a page reload you lose
the state on the client. And that _has_ to be there, as it's what the user
interacts with. You then need to send to the server a state which is not,
strictly, an application state (it's a UI state) and that state needs to be
taken in account by the server, and possibly merged with the application
state, when generating the new page. A mess.

On the other hand, a spa never loses its UI state, so you never need to
recreate it. The server is also usually stateless, and simply satisfies the
requests of the client. Basically you go from developing two separate
applications with partly overlapping concerns to developing a single one,
running on the client and relying on a service layer to query and persist its
data.

------
buzz27
I was thinking about this recently watching a major web app throw a bunch of
errors and slowdownsall to do with its SPA features. If it was just a normal
web app it would be so much faster and more usable. It seems crazy to me that
we have faster and faster computers and internet connections, and yet we've
added all this new latency to the software we use.

I find the list of pros somewhat unconvincing.

For a lot of applications, a reload is no hardship, and is faster than most
SPA interactions I see.

For a lot of granualar actions, jquery, while not sexy, is not harder to
maintain than a full SPA would be.

The alleged development efficiency of decoupling front from back really needs
context and argument.

As I see things, there are a lot of web projects where a normal app with a
little progressive enhancement is a good solution.

------
sebringj
I thought gatsbyjs was a nice medium ground. You have the familiarity of a
single-page app in terms of stack and yet have the quick loading times and
back button, SEO all of that since it produces a static site. I thought it was
genius but I'm biased because I like react.

~~~
_sdegutis
Funny you mention it, I just started looking into rewriting my portfolio
website ([http://sdegutis.com](http://sdegutis.com)) from a custom node-based
static site generator to use Gatsby.js, in order to get more practice with
React.js. Really curious to hear what other HN regulars who've used Gatsby
think of it...

~~~
sebringj
I used it actually because I love react but needed to work with a great
designer who already knew sass and I needed to include react components but
also wanted to hook it up with a cms too. Check check check... keeps going and
produces a static site. Wow. Even the designer could use this and modify
things for simple components, not knowing react. I'm pretty happy so far.

------
eadmund
I recently started blogging again, and I chose to go with a static site
generator. It's _fast_ , really fast. Loading a whole page with each click is
so much faster than visiting most of the sites I visit each day.

I'll never get why we collectively decided that it's reasonable to grant every
random website in the world execute permissions on our machines.

------
buchanaf
Not the most compelling list of pros/cons that I have ever seen.

In terms of raw performance for content sites, I found hybrid implementations
like Gatsby.js to beat most things. Most of the cons of SPAs can be
significantly diminished with SSR, proper chunking, and a variety of other
modern techniques -- it just gets complicated in a hurry.

~~~
piranha
What's chunking in this context?

~~~
ryanworl
Breaking down your JavaScript bundles into smaller files that contain the code
necessary for the route you’re actually going to be viewing once the page is
loaded. For other routes, you fetch the necessary code on-demand.

This lessens the CPU power and bandwidth needed to initially load the page.

------
tzakrajs
"Stop writing only SPAs" is advice in the same way as "stop making only left-
hand turns". This article stops short of convincing me to stop biasing towards
SPAs because it appears only to reiterate known challenges about SPAs and
calls out bad practices (tons of unused javascript libraries). SPA frameworks
are pretty damned good and they really can and ought to be used wherever you
feel the need because some SPA frameworks are very quick to get started with
and can be customized to significantly reduce bloat.

------
scarface74
I have mixed feelings about SPAs. I'm mostly a back end developer but do have
some front end experience. On one hand, I think life is a lot simpler with
server side rendering. On the other hand, I like the purity of REST APIs and
front end rendering.

For technical reasons not worth getting into, on my current project, a SPA
would be overkill and hard to implement. But I did take the lessons I learned
from my time with Angular to create a poor man's model view framework with a
combination of HandlebarsJS+JQuery.

After my experience doing it, I understand why a framework would be better.
I'm reinventing the wheel (out of necessity), it wouldn't scale to multiple
developers without becoming an ungodly mess without a framework to keep people
on the rails and it would be harder to ramp people up. When I got thrust into
my first Angular project it was easy just to read a few articles and watch
some PluralSight videos.

As the dev lead, I will definitely choose a SPA framework when my next front
end project comes up. For all of the reasons above and because it's easier to
recruit and retain people when you're doing the new and shiny that can add to
someone's resume - including mine.

It doesn't matter how I feel about the most popular frameworks, if I want to
be employable, I need to keep up to date.

------
seawlf
I've worked on a number of SPA's over the years and I always run into the
problem of getting my team to give a shit about performance. "We're not
Google," they protest. Frankly for a lot of people it's the trade-off of slow
client performance for development velocity. It's much easier to just throw on
another state for new functionality than it is to consider what parts of the
page can be static and how they can be rendered.

~~~
andybak
Surely if you can't produce an SPA with equivalent or better performance than
a more traditional architecture then - don't build an SPA.

Or even better use a simpler solution that gives me 80% of the benefits of an
SPA: Turbolinks, PJAX, intercooler.js or even a light sprinkling of good old
AJAX.

Does anyone remember "progressive enhancement"?

~~~
tacone
Perhaps the most simple and trasparent solution to seamless navigation:
[http://instantclick.io/](http://instantclick.io/)

As long as your backend is fast enough, it feels like navigating a SPA.

------
mwcampbell
For the problem of bundle size, it saddens me that Google's Closure Compiler
(specifically the advanced mode) hasn't gained much traction. This provides
fine-grained tree-shaking to minimize the bundle size. But this requires
static analysis of the whole program, which is at odds with the dynamism of
JavaScript. Maybe now that static typing is coming back into fashion, the
Closure Compiler or something like it will gain widespread adoption.

~~~
bpicolo
There's a number of projects out there working to reuse closure compiler bits
on top of typescript. e.g.
[https://github.com/angular/tsickle](https://github.com/angular/tsickle)

------
adamnemecek
One thing that doesn’t get mentioned is that writing an SPA feels more like
programming.

Writing jquery feels like idk...not quite like programming.

~~~
mythrwy
I'd about say the opposite.

Organizing all your jQuery into meaningful classes and keeping the whole thing
organized and orchestrated is very much the essence of programming. It's a
rare skill (as a trip through many large jQuery code bases reveals).

Filling in some templates causing magic to happen behind the scenes on the
other hand, not so much.

That being said, 1) are we interested in feeling like programmers or in
pumping product? 2) if "pumping" is the answer, best tools depends on what is
being done. All in favor or SPAs (when needed), but no, they aren't cooler
than jQuery and are often big fat pigs that just shouldn't be used in that
situation.

~~~
unclebucknasty
> _I 'd about say the opposite._

> _Organizing...into meaningful classes and keeping the whole
> thing...orchestrated is very much the essence of programming_

> _Filling in some templates causing magic to happen behind the scenes on the
> other hand, not so much._

I'd agree and add that the different perspectives might be in large part due
to the shift in programming away from procedural/code to declarative over the
last decade or so. That is, if you started in coding over the last ten--and
especially five years--you're much more likely to think of programming as
declarative as much as code-oriented.

And, the shift towards frameworks is probably the biggest driver of the
declarative trend itself.

~~~
mythrwy
lol you caught me, I'm old.

I'm all in favor of what's fast and easy. So many jQuery messes have almost
given me PTSD. So not knocking frameworks in any way. It's just weird to me
someone would suggest using them is "more like real programming". No, it's
more like one of those paint by number kits rather than a blank canvas and
some paint. Of course many people are going to get better results with the
paint by number kit, but it isn't more like "real" painting. It's less like
"real" painting. And, if you reach for a paint by number kit when all that's
needed is a few red dots you are messing up and ought to learn the craft naked
a bit for such situations. jQuery isn't a paint by number kit. More a set of
stencils and brushes you are free to make as big of a mess as you like with.

~~~
unclebucknasty
> _lol you caught me, I 'm old_

Ha! Only because I can totally relate my friend. Been in the game a while
myself. That really is how I can identify with what you're saying.

And, you know what? We're right! Adding an attribute to an HTML-like component
tag is _not_ programming, no matter who insists it to be so. That's not to say
there's no value to such approaches, but it still doesn't make it coding.

Was talking to another coder friend a while back and we agreed the game has
changed: it's more about integrating pieces into a whole than writing swaths
of logic. In other words, "coding" is now more assembling than construction.

It's possibly (but not categorically) more productive and it may represent
"progress" by some measures, but it is still ironic to hear that referred to
as programming over actual programming.

------
mnm1
Over 90% of my web browsing is done with JavaScript turned off. When I hit an
spa blog I sometimes read it, sometimes not. Clearly if the owner of the blog
is so insensitive as to make it an spa, they don't care about the content and
especially don't care about their readers. That's fine. There's plenty of
other content on the web to read. I don't understand why it's normal to let
strangers run code on my computer. Yes, the masses are ignorant of the
consequences, but I think that's slowly going away as me generations grow up
with the internet. Anyway, the upside is that over 90% of web pages I visit
load under a second. Imo, people who make their blog, marketing site, etc. an
spa blindly don't care about their content, presentation, or the reader. Why
would the reader care about them?

------
est
been a victim of shit corporate SPAs

1\. tons of widgets/slides/inputs in one single page

2\. click submit -> error -> go back -> all filled info gone

3\. cant open links in new tabs

4\. cant copy shit off the inputs because text was in some kind of fake div
with v-data attribute with disabled cursor movements. Had to use devtools to
copy shit

5\. Naturally, cant paste shit. Had to manually type MD5 checksums.

6\. Always got redirect to home page after login

7\. Broken links everywhere. Cant restore page state via link. IDK if this
page is broken or still ajax in-progress. Had to open devtools to see if
there's any js errors

8\. If page is broken, refresh, boom, all your typed contents and procedures
are gone.

I think if people cant make a proper "multi" page form based web application,
they should not be allowed to engage SPA at all.

------
sago
> [SPA Pro:] frontend is decoupled from backend

I was very surprised to read that.

Very often validation and context-sensitive behaviour needs to be performed on
the client _and_ (since you can't trust the client) on the server. You can
certainly argue this is better user experience: you don't have to wait for a
server round-trip before finding out an action is invalid, but it's hardly
decoupled.

Isn't this a part of why node is so popular as a server platform? The stack is
now so deeply coupled, it is very beneficial to reuse code.

~~~
Udik
Repeated validations, while not DRY, aren't a case of coupling. They seem more
a case of de-coupling, as they're needed for the application and the service
layer to work independently from each other. While in non-spas your server
receives from the client an extremely specific blob of page state plus user
input and has to rebuild a specific new page with state updates and/or error
messages.

------
throwaway0255
One thing I'm noticing about SPAs is that they're often slower to load, but
the slowness and loading animations gives me a higher perception of the
quality of the application.

The same application loading and doing things instantly as server-side
templates feels comparatively cheap and un-modern.

What is wrong with me?

~~~
pugworthy
Maybe to this day, Zombo.com is just an SPA that nobody every gave enough time
to totally load. I mean after all, it was written in the late 90's and SPA
technology wasn't that sophisticated back then.

------
jconley
Many of these pitfalls can be avoided with intelligent server side rendering,
which includes the router on the server, so no using client-only “#” URLs.
But, that adds another significant layer of complexity to application
development.

------
oaiey
Just a reminder: [https://varvy.com/pagespeed/wicked-
fast.html](https://varvy.com/pagespeed/wicked-fast.html)

------
osrec
We built one of our products as an SPA
([https://usebx.com/app](https://usebx.com/app)). I have to say it was a
fairly enjoyable experience, and our users like it too (they often add it to
their home screen and comment that it feels totally native). The only annoying
thing was ios Safari, which has it's own little quirks in certain areas (but
those are not limited to just SPAs but any kind of website).

~~~
chrisper
Your app is breaking the back button on Firefox beta. That's in the demo. I
wasn't able to get back to HN.

~~~
osrec
Yes, that's something we're looking to fix. I know it's annoying, but it's
because of the somewhat unpredictable nature of onpopstate in a number of
browsers (at least at the time of development). We'll probably do a full clean
up of any related hacks in a couple of weeks and the issue should disappear!

------
maligree
Is anything ever?

Why is there such a strong tendency towards treating things as a this-is-
it(-this-time-for-real) thing? This only confuses people and muddles up
expectations.

------
geraldbauer
Great to see the article posted on a "classic" (static) website built w/
jekyll. Find more open source (ready-to-fork) themes @
[https://drjekyllthemes.github.io](https://drjekyllthemes.github.io) Build
your own "classic" websites / blogs :-).

------
smnrchrds
Tangential question: what is the best practice for handling authentication on
a SPA? I have seen JWT being heavily criticized on HN and elsewhere. What is
the alternative that still maintains the separation between front- and back-
end?

~~~
navd
Like anything else it depends. JWTs are still great. Just don’t treat it like
a classical session and dump important information in it.

You could also use session like you always have if the SPA is being served by
the same server.

~~~
snuxoll
JWT is at the heart of OpenID connect, I agree they’re still perfectly
reasonable.

The big issue I have with JWT is they are hard to invalidate for security
reasons, but if you lower the validity and refresh the token more often you
can mitigate (not eliminate) the risk.

------
fictionfuture
Hold up, most these problems are directly related to the problems of using
React+redux (JSX) and likely some complicated backend stuff.

We use Vue + Firebase and even have SSR working w no complaints. (So it's
actually more than just a SPA)

------
Illniyar
This might not be a popular opinion here, but yes, SPAs are indeed a silver
bullet.

Or at least, no you shouldn't make a site that isn't SPA. With universal
rendering, light frameworks like Preact/Inferno.js and things like microjs.com
, you can make a site that loads faster, renders faster and navigates faster
then a multi-page application. You can make SPAs behave like a regular site -
with links that work and all.

It's simply that many developers/managers don't care for or know how to make
fast websites with SPAs, but then again even Multi-page applications are
usually bloated with dozens of marketing, analytics and third-party libraries
which makes them just as slow.

I don't think reloading the entire page on every request is acceptable in
2018, even if it's a blog.

------
jaxn
What about applications that are used day-in and day-out? Applications that
average dozens of "page views" per session. It seems that an initial load is
worth a better UI.

------
jaunkst
When you need an SPA it’s great. JQuery noodles are a past time and I’m not
going back. If you need a blog or something just render it all sever-side and
sprinkle some JS.

~~~
meesterdude
> JQuery noodles are a past time and I’m not going back

I love me some jQuery noodles! For some sites it becomes unwieldy i'll agree,
but when sprinkled it provides a lot of enhancement.

------
digi_owl
Frankly SPAs should be served up via a whole different channel, they are
effectively an abuse of web tech to NIHing the likes of VNC.

------
tatersolid
A lot of misinformation here.

SQL Server has had check constraints since at least the year 1996.

------
rhizome
Can we start a movement to teach tech bloggers what "begging the question" is?

