
Create your own dysfunctional single-page app - semanticist
https://tinnedfruit.com/articles/create-your-own-dysfunctional-single-page-app.html
======
qwerty456127
IMHO the whole advantage of single-page apps is about separating the UI and
the data + using the browser as a cross-platform UI toolkit, runtime and
deployment engine. The reason for SPAs to exist is that browsers are the only
way to deploy an app that runs on every OS, looks pretty, automatically
updates in an instant every time you run it and can be discovered and ran by
everybody in a single click. Just imagine a world where something like WPF was
made a truly free standard with full-featured 100%-compatible open-source
implementations available on all the major OSes (Windows, Mac, Linux, Android,
iOS) from the beginning and packed with efficient support for apps to be ran
straight from a URL.

~~~
ct520
I imagined a world of apps designed with xaml /me shudders

~~~
colde
Interesting, i've had the exact opposite feeling with XAML. I've written a
bunch of Silverlight and WPF, and always felt it to be probably the best UI
framework i have worked with. Certainly beats all the web frameworks, and imho
it was also better than Swift and Interface Builder.

~~~
mrfredward
I mostly like WPF (and use it a lot), but there are a few design issues that
drive me nuts. The most common one is ObservableCollections--if I have a List
in the model that is going to update as something happens, how do I bind that
to something in the view? Does my model throw events that trigger the
Viewmodel to update an ObservableCollection?

In Angular it's trivially easy to bind to an array and have it update. In WPF,
it's hard enough that I architect my applications around that one single
problem.

------
iamleppert
I love when people try to point the finger at a technology when in reality it
is 100% the people who are using and implementing the technology. It's their
fault. 99% of developers I know who create terrible SPA's have a long list of
terrible things they've created. It's a mixture of incompetence, laziness, and
poor management.

~~~
hnzix
It's not that people are writing SPAs badly so much as it's often unnecessary
complexity. Like the "microservice all the things straight away" trope.

Sometimes a CRUD form should just be a CRUD form.

~~~
collyw
This is the problem 90% of the time. I hate the resume driven development
nature that is almost encouraged in our industry.

The last few maintenance programming jobs I have worked on seem to have been
written by people who have used a framework at peak hype cycle, without
actually having a good knowledge of the framework.

Job ads never say "writes elegant code with a simple yet effective design". No
they want "experience with React, Vue, Rails, Docker, etc".....

------
martin_drapeau
I like the hybrid approach - sprinkle SPAs where page reloads should be
avoided. Have many SPAs in your product. Just keep them small and assign each
SPA a distinct use case or area.

Let's take a CMS as an example. The "Edit blog post/page" function can be its
own SPA avoiding page reload when the post is modified. Managing the list of
posts/pages can be another. A page reload in between steps is fine. Nowadays
internet speed is fast and latency is pretty low. Browsers are also very
efficient and vive caching. If you keep your SPAs small, the user won't see
the lag going from one page to another.

Multiple SPAs also allows you to keep things modular. Different teams can own
different parts.

Do not however bundle the entire CMS into a single SPA. It will most likely
contain a lot of code and resources to load. That will kill performance and
slow down development over time.

~~~
0x445442
I like what you've described but how different is that from just including
jQuery to add some dynamicism to your page? Which, BTW, is what I think JS
should really be used for.

~~~
martin_drapeau
Its no different. React/Vue are modern evolution of jQuery. They allow you to
organize front-end code with strict conventions and best practices. You can
achieve the same result with jQuery and Backbone for example. But you'll need
to discipline yourself a lot and good luck hiring developers (they all want to
work on React and Vue).

~~~
blauditore
> React/Vue are modern evolution of jQuery.

I disagree. They are whole frameworks taking a completely different approach
than jQuery, which is basically just a helper library.

jQuery is useful as a tool for operating within an externally organized
application (or otherwise mostly static DOM tree). It simplifies low-level
operations like DOM element manipulation.

Frameworks like React or Vue take a top-down, more declarative approach on how
the DOM is built and updated. It's in many regards more powerful and more
productive, but comes at a certain cost (setup complexity, total page size,
certain aspects of performance).

So, which tool is best for your project really depends on the individual use
case.

~~~
martin_drapeau
jQuery plugins are extremely powerful. Look at fullcalendar.io as great
example. Web 2.0 was entirely built upon that. I hate to see people dismissing
jQuery and its legacy as just a library. There is a huge community built
around jQuery and thousands of plugins.

It ain't new and shiny but you can build anything with it. In fact, today
jQuery is used on 97% of websites* while React and Vue are around 0.2%. I
imagine that will change over time.

* Top 10M Alexa ranked: [https://w3techs.com/technologies/overview/javascript_library...](https://w3techs.com/technologies/overview/javascript_library/all)

~~~
0x445442
Yeah, the minute you start reaching back to the server for a significant
update to the client data model in order to support a view transition I think
the benefits of SPA are lost.

Granted I've only deployed one SPA to prod and that was an Ember application
but I'm not feeling the love based on that project.

------
itronitron
I think SPAs fail because a lot of teams just don't know what they need to do.
It looks like a web page but needs to handle complex interactions/workflows
and probably maintain state as well. The people with web dev expertise are
used to dealing with pages and forms, and the people with experience
developing sophisticated UIs (either complex or elegant) are used to working
with UI frameworks that are knowable and predictable.

~~~
jbergens
He mentions this in the article. I agree that building a SPA can be a bit hard
and it is not very wise to use in-experienced develpers (without
mentoring/lead) to do it all.

I have started to think about frontend development as at least two different
types and sometimes business people and organizations mixes the two with bad
results. I see some devs coming from html+css with a little js background and
then a need for devs with more experience of data structures, state
management, async code, good architecture etc. Some devs has this but comies
from the backend and might instead lack experience in js and js
frameworks/ecosystems. I think more organizations need to look where they are,
which devs they have and how they can help getting everybody getting better at
advanced frontend programming.

------
tracker1
While I appreciate the commentary, I do disagree on a few points.

Starting towards the end. The comments about JS Framwork cadence doesn't
nearly apply today as much as a few years ago. I mean Backbone was released in
2010 (8 years ago) and was probably the first JS SPA "framework" to gain
significant traction. There have been many since then. Angular and Ember were
also in 2010. React was first released in 2013 (over 5 years ago) and Vue was
2014.

Those have been the heavy hitters imho. All of which are pretty mature at this
point. There are many others, of course, but that's been true of even desktop
platforms. Yeah, Angular 2 was a big shift, but React, Vue and Angular are
really the main players in this space. Most others take some queues from those
three. Given that, it's a poor argument, and the language is more dated than
the frameworks in question at this point.

Personally, I find SPAs are great for Line of business apps that need more
complexity than a typical CRUD app can offer. Also, front end development _IS_
DEVELOPMENT. Many snobby backend developers turn up their noses and feel it
doesn't deserve the same level of consideration as backend development. They
don't follow the same practices, consider use or lean on application designs
already established in a number of toolkits.

Personally, I currently lean on React + material-ui. For the most part it has
me covered, and I can find third party controls that at least match the
styling. Read the Material Design guidelines. It isn't that hard and just try
to follow the rules. Think about other applications you've used and push back
on all features, punting as much as you can for as long as you can.

Avoid complexity at all costs. Break stuff apart into smaller pieces, and
write code that's easy to replace.

Everything said and done, I think I'm just cranky at these types of articles
that just indicate to me a point of view of someone unwilling to learn new
things, or try new tools. I keep an eye on so much, and have for over two
decades in dealing with web-based applications. I'm surprised how much the
attitudes of some haven't changed in two decades.

~~~
expertentipp
> Many snobby backend developers

They are still "web". Try working with C++ hard-heads. Everything from
Jenkins, cloud services, application release over the web, to SPA visualising
3D point cloud is a "stupid HTML website". All they want to know is WHY IS IT
TAKING SO LONG?! At least that was the case in one of my workplaces.

~~~
andybak
> WHY IS IT TAKING SO LONG?!

Kind of how I feel waiting for C++ to compile

~~~
expertentipp
It's the linker.

------
temporallobe
Great read! There’s a lot of truth to this, but in my 18 years of being a dev,
the major reason _anything_ fails usually comes down to poor understanding and
miscommunication from the higher-ups. Customers either don’t know what they
want or are too lazy to articulate it. Management is usually technology-
clueless and, as the article points out, has no idea how much time, money, and
effort is truly required to build a high-quality maintainable app. Add to that
the sea of frameworks, libraries, “tech stacks”, standards, and trends, and
you have a recipe for disaster.

Technology is also becoming increasingly layered and interdependent on brittle
infrastructure. Abandoned projects can be a huge time waster as well,
especially when they break. For example I’ve been working on trying to fix an
abandoned web application written in an odd combination of languages and
frameworks with a testing suite filled with old libraries and test scenarios
that no longer make sense.. This thing is not broken, it’s shattered. It’s
taken our team two entire sprints to get it somewhat working again. That’s the
reality of modern software engineering.

------
nobody271
My go to point on this subject is even if you have the perfect front end it
won't save you from a slow DAL. I'm not sure why we aren't allowed to be full
stack developers anymore because having a say in both the front and back end
is a great way to prevent frivilous work from being done.

~~~
DaiPlusPlus
All we need now is a MySQL client written entirely in JavaScript.

~~~
nobody271
Then it will be everyone's fault.

------
hardwaresofton
I'm convinced SPA are the future -- they're more than about fitting all your
stuff on to a "single page", the concept of a page doesn't go away in SPAs,
it's just the implementations and strategies for loading and state management
that are different. A better way to think about them is as "client side
rendered" applications. The reason I think SPAs are the future, the premises
are simple:

\- Processing power of client devices will only grow, compute will cheapen but
communication costs (speed of light/fiber/etc) are cheapening at a much slower
rate.

\- Repeatedly sending layout is wasteful, given site architectures that render
the same page repeatedly

\- Separation of UI and data is generally a good idea

\- Sufficiently advanced SPAs offer Server Side Rendering (SSR), which makes
them almost equivalent and yet more reusable than the alternatives (Java's JSP
stuff, ASP.NET's ASPX mess, Ruby's ERB + layouts + partials stuff, Django's
Jinja + layouts + partials stuff)

Mark my words, when wasm is widely accepted and lots of languages start
compiling to it, people are going to start porting the SSR alternatives (JSP,
ASPX, etc) to run on the frontend to achieve this same exact goal. I can't
wait to see someone post on HN about "JSP in the browser".

There are of course a few things to keep track of, If sophistication in
quantum communications grows faster than everyone expects, the landscape
changes drastically. As a complete layman it seems possible to me to imagine
arrays of entangled atoms being used at ISPs (possibly forced to be closer
together) to reduce RTT to effectively near zero which fallback to regular
over-the-wire communication for error correction or whatever else.

Almost 100% of the problems I've seen expressed with SPAs is from tooling or
developers doing it wrong. Maybe that's it's biggest weakness, along with
being an approach prone to accidental complexity.

------
tylerjwilk00
For the most part all you need to ask yourself is this:

Must full page reloads be eliminated?

(That's the real defining characteristics of SPAs)

For 95% of businesses a PWA with occasional full page reloads will be fine.

But for 5% of (mostly large) businesses, a kick ass SPA will be necessary.

~~~
platz
That's a great technique that I prefer - full page reload for links that have
large screen changes i.e. page navigation - spa for page-specific
interactivity i.e. filters, edits, updates

Not having a client-side router strips out so much spa complexity.

maybe for apps where you really need persistent state i will use a
router/full-spa, but a lot of apps don't need full persistent state across all
page navigations.

~~~
jbergens
In a way you are just moving the complexity back to the server code. I am not
sure that helps in any way.

The server will now have to have state or reload state on every request and
that state could include many things that are not obvious like

\- what page are you on \- which links should be shown in the menu \- are
there other things on the page that needs to be shown that has little to do
with the current request-path

~~~
collyw
A lot of that complexity belongs on the back end.

Every front end page is likely to have a separate number of REST endpoints, so
the code is effectively duplicated.

In my experience keeping as much of the code on the back end eliminates a lot
of complexity, though I am far more competent with backend technologies, but I
have yet to see a SPA app that reduced complexity.

------
tobyhinloopen
Summary: inexperienced developers create bad software. Who knew.

Our SPAs are thouroughly tested (TDD, near 100% coverage). We make them
mobile-first offline-first so they can be embedded in a phone app as well.

For CRUD, things that need to be searchable and things that need to work
withoutJS, we usually have a rails/node app that renders views the classic
way: server-side.

For static websites, we try to use static page generators like jekyll

~~~
andybak
> inexperienced developers create bad software.

A vast number of websites suffer from these problems. Therefore - your
definition of "inexperienced" must apply to ~70% of web developers.

Maybe when the problem is this extensive it's time to stop blaming individuals
and look for systemic problems.

~~~
tomatotomato37
In my opinion a large percentage of web developers really are unskilled. I
blame the prevalence of those three week development bootcamps, you have a lot
more of those for web development than backend/application stuff

------
LiterallyDoge
Again? Single page apps refresh and respond faster than their HTML
counterparts. Sounds like a mad backend dev posting hate for the evolving
front-end world because they don't want to learn new stuff.

~~~
MrPowers
Nope, he is a "Front-end web consultant and coach":
[https://tinnedfruit.com/](https://tinnedfruit.com/)

------
tim44
I'm building something that's very single-page app for the first time. A
project to use flask, sqlalchemy, and ajax and really just do some fun flashy
things, not necessarily practical things, but I do feel like the SPA space is
much better than last I'd looked. I definitely see how it's easy to create
something bad in a SPA doing it all yourself. My code right looks like that
horse, with 500 lines of jquery full of repeating functionality still in
snippet form. But really, the horses face is just as ugly as his ass.

------
stephengillie
Last year, I wrote a small single-page app engine that takes a JSON
representation of HTML, and writes it to the DOM to build the page in the
browser. The entire app is described in one JSON document, so it's quick to
download and needs no network to change pages. I'm slowly starting to develop
it again. The demo site is still up (with a SPA builder) at
[https://sparational.com](https://sparational.com) and you're welcome to
suggest any improvements.

~~~
nkozyra
Either masterful satire or, ahem, you may want to check your server.

~~~
invalidusernam3
Breaks without www:
[https://www.sparational.com/](https://www.sparational.com/)

~~~
marcosdumay
Seems to break on browsers older than last week too.

------
GorgeRonde
What about using an iframe and refreshing it with links targeting it ? Use
<link rel="preload" ...> to make it really fast. Do so for any subcomponent of
your page that can be updated independently of the rest of the page. Use
browser caching for code assets/dependencies.

Pros: cheap & fast (?)

Cons: obviously the logical structure of your app must (somehow) follow the
structure of nested iframes in the page.

~~~
LiterallyDoge
I think iframes are inferior to the JS approach for a few reasons, one is
usability for people with screen readers / etc - others would be standards
compliance, bookmarking, managing state when pieces do need to talk to each
other, etc.

------
chvid
The problem is that there is a lot of immaturity within the JS world at the
moment. And that makes the complexity go "BOOM".

Thing about it. Should things really get more complex just because we are
moving more of the computation to the client rather than having it sit at the
server? Done right it remains the same.

~~~
LiterallyDoge
State management is hard. It goes boom because lots of things are going on,
not because browsers are naughty.

------
matchagaucho
My ability to rationalize and manage SPAs dramatically improved once immutable
data and functional programming techniques were introduced.

But that can probably be said for any programming environment.

~~~
TeMPOraL
Learning ClojureScript w/ Reagent and re-frame made me feel for the first time
like my sanity is not under constant attack when doing web work.

Still, building SPAs where a reloading site would suffice feels bad, and
upgrading to CLJS is like adding a filter to a cigarette. Still not good for
you or your surroundings.

------
pier25
Going from little jQuery scripts to full JS applications is difficult. People
with desktop UI experience know this, but many JS devs don't.

Another problem is that we still haven't figured out the best way to write JS
SPA applications. Even the React team is improvising as they go along. If you
need any more proof just look at the new hooks api.

------
collyw
This describes the monstrosity I am maintaining just now incredibly
accurately.

------
emersonrsantos
This remembers me the timeless "Do Things that Don't Scale" by @pg.

[http://paulgraham.com/ds.html](http://paulgraham.com/ds.html)

~~~
Scarbutt
I don't see the connection to the article, what do you relate to it?

~~~
emersonrsantos
Why create a framework when you just want to display html?

------
fouc
>Single-page web applications damage businesses.

plus some good points

p.s. I thought vue came before react, but it's the other way around.
Interesting

~~~
mygo
Vue arguably began while it’s creator was working on Meteor, a monolithic
full-stack platform for making reactive SPA’s with thick clients sending data
over the wire. This was around the time where app front-ends we’re trending
more towards data-reactivity as opposed to server-rendered AJAX-style. Vue’s
creator Evan was part of the Meteor core team, which came before React. Evan
left meteor to work on Vue, which was inspired by many front-end frameworks,
such as Angular, Polymer, Handlebars, and React. React and Vue are
contemporaries.

------
pier25
We're experimenting with Jekyll + Vue and it's working great so far.

------
Agathos
TL;DR: try not to suck.

Seriously, if you're committing mistakes 1, 3, and 4, then your multi-page
website is going to be awful, too. "SPA or not SPA" is far down the list of
questions you need to be asking yourself.

------
diddid
This misses the main reason for SPAs which is separation of concerns. Keep
your biz logic out of your UI. Test your tiers independently. Refactor your
tiers as required and if you did it right you can rewrite you api without
messing with your UI and the same the other way.

Want to change your backend from C# to go? Easy. Want to change from angular
to vue? Easy.

But programming is hard, and doing things for the long game is harder, and
finding people with the skill and experience to pull it off is harder still.

Or... you could put all your biz logic in stored procedures and wrap it all
with a nice .net Razer frontend, throw in a bunch of third party controls and
call it a day.

~~~
temporallobe
“Separation of concerns” is only possible if leadership deems it’s necessary.
Often times devs are told to just put tbe business logic in tbe front-end
because it’s easier and scrum masters get a pat on the back for completing
more points. Technical debt be damned.

~~~
diddid
"Leadership" should not have any say in what is necessary for a domain they
don't understand. If someone wants to sacrifice the quality of their trade
then that's their own business. If I tell a plumber I'm OK with cutting
corners and he listens, I don't want that person to be my plumber. Devs should
take their job as seriously.

