
A Front End Does Not Have to Be Rich - cnorthwood
https://www.apress.com/us/blog/all-blog-posts/your-front-end-does-not-have-to-be-rich/16537718
======
duncan-donuts
I agree with what is being said, but I don't really see any new thoughts here.
This is such a tired conversation. I used to have opinions about this, but
I've grown to have a position of, "ship over anything else". Do whatever you
can to ship faster. If that is nextjs, great. If that just a bunch of PHP
files on an apache server? great. None of it is one-sized fits-all. /shrug

~~~
collyw
In my experience going SPA seems to double the amount of code needed (at
least).

~~~
sbhn
Yay, the world is waking up, google search is not spa, Ebay is not spa,
Wkipedia is not spa, Youtube is not spa, Stack exchange is not spa, Duck Duck
Go is not spa, HomeIdea3D.com is spa though

~~~
Conlectus
YouTube is indeed a SPA.

~~~
ngrilly
YouTube is not really a SPA as in React or Vue. It looks like they use
something similar to TurboLinks or Intercooler:
[https://youtube.github.io/spfjs/](https://youtube.github.io/spfjs/)

Edit for downvoters: Ok, technically, YouTube is a SPA. What I meant, in the
context of this discussion, is that YouTube uses a technique similar to what
GitHub does, where the server returns fragments of HTML.

------
ergothus
I feel odd dissing this article, because there's nothing wrong with it: Saying
that you should consider your audience, focus on your content, and use "rich"
(oh man, I remember when RIA was the buzz-de-jour) websites when, and only
when, appropriate, is not controversial.

That said, I don't feel like there's much actually said. Just restating what
is commonly advised (if not practiced) best practices, and not really doing
anything to address WHY it isn't practiced. It also failed to mention the
differences when you have an application that DOES benefit from being "rich",
how progressive enhancement is still a good theory (I'll be honest, none of my
workplaces have DONE it).

I've seen plenty of dismissive "web coders are trash" and "lol, Js, learn to
code" comments (paraphrasing) in various discussions, as well as more informed
discussions as to what is and is not a real cost/benefit of various
approaches, but I've not seen much in-depth discussion about why the best
practices really are rare, and how to fix that. I wish the author had gone
beyond the basics and addressed that.

~~~
_hardwaregeek
Yep. There's a proliferation of reductive posts that essentially repeat the
same truisms we've all heard: You don't need a SPA; NPM is a ghetto; Front end
web development has too much churn.

Who cares? If you don't like the state of web dev, leave or learn to make it
better. If someone were to write yet another NPM sucks article, BUT include in
it a description of a PR they opened to improve the process, I'd happily
upvote them. But instead people seem to be satisfied with complaining with
little action.

~~~
cnorthwood
I'm not sure how you drew the last 2 conclusions from this article. The point
is to make sure people think twice before they default to an SPA to make sure
it's the right decision - in my experience a lot of people are jumping to the
SPA pattern without considering the alternatives. Do you not think an article
like this, which aims to increase awareness of non-SPA architectures, is
helping to make it better? What else would you like to have seen this article
cover?

~~~
_hardwaregeek
The last two points are not specific to the article but to the category of
vaguely contrarian points about modern web development in which the article
resides. And I’m a little skeptical of the premise, which is that we need to
increase awareness of non-SPA architectures. Even though there is a lot of
hype around SPA’s and fancy front end driven architectures, I’d bet that the
vast majority of code written and new developers minted are primarily focused
on server side web applications. It’s just nobody ever says “yknow what’s new
and hot and the thing everybody should use? Java servers!”

------
myth2018
Agree 100% with the need to consider the project in question. I don't know the
context of you guys, but at least in mine, I don't see such kind of planning
very often.

I'm currently involved with two projects. One is a youtube-like app and the
other one, a business management application. In the former I'm using SPA and
rich front-ends as if there is no tomorrow; in the last I'm coding as if it
were 2000's, with form submits, page reloads and client javascript only to the
minimum level needed to ensure a reasonable responsiveness.

However most projects I'm aware of are using Angular or even React + Material
Components to build business apps with lots of data tables and input forms. In
my opinion this is a serious drawback, since it increases the project
complexity and adds basically zero value to end users, who get a good-looking
application which, at best, does the same thing but it's more expensive to
write and maintain.

P.S. those are my impressions about my local market (Brazil), your mileage may
wildly vary.

~~~
jotato
>However most projects I'm aware of are using Angular or even React + Material
Components to build business apps with lots of data tables and input forms. In
my opinion this is a serious drawback, since it increases the project
complexity and adds basically zero value to end users, who get a good-looking
application which, at best, does the same thing but it's more expensive to
write and maintain.

So what (if any) framework do you use for the business-like apps that don't
need a rich frontend? I agree that using something like Angular can be
bloated, but it does offer some nice "shortcuts" for even the blandest of UIs.
Specifically model binding.

~~~
myth2018
It depends.

I have routines using vanilla javascript, believe it or not.

Model binding is a requirement only if you are going to deal with your model
in javascript. Maybe to perform an ajax call or something alike. But I often
simply do a form submit like in the old days.

In more complex routines I may use Angular.js (not Angular). But not as a
single page application, bundling code, minifying it etc. I often get away
with an angular.js application locally to the page which is going to use that
script.

I won't lie, the codebase is ugly, inconsistent and unpredictable as hell and
new developers, when arrive to the team, get immediately convinced that the
architecture was planned by some amateur who don't know what he is doing.

They are probably right, but get familiar with the project really quickly and
understand that there is order under that apparent surface of chaos.

I'm pretty sure this leads to more code having to be written, but it's code
easier on the brain, easier to split in tasks to different developers and so
on. We are not typists after all, experience shows that it's best to spend
more fingers and less brains.

This is the best I could do so far to make a fairly inexperienced team deliver
at a reasonable pace while dealing with users changing their minds at
relativistic speeds.

------
writepub
I think there's a conflation of client-side-SPA === rich/complex here. For all
practical purposes, this may be true as SPAs have gotten reliant on _complex_
frameworks like React, Vue, ..

In 2019, with ES6, I believe frameworks to be an overkill. When React was
introduced, it did goad people into thinking in components, etc. However,
classes and higher-order-functions in ES6 allow one to think modularly without
a framework. And the Virtual-DOM's value proposition is questionable when DOM
updates are properly batched ( like when using
[https://github.com/wilsonpage/fastdom](https://github.com/wilsonpage/fastdom)
).

Complexity is bound to increase with features, either in the back-end or
front. But SPAs (with PWAs) offer advantages of being fully functional when
offline, or with spotty connectivity, which is a significant value
proposition. Not to mention lower server-side costs (in use-cases where server
costs are prohibitive, SPA-PWAs is the only economically viable option).

My takeaway is to evaluate not just the reliance on SPA/PWAs but also on
complex frameworks with diminishing returns.

~~~
dvdkon
I actually tried to implement a SPA using just ES6 (in Typescript) some years
back and ran into quite a few problems with data flow, which frameworks like
Vue.js readily solve.

I think that (for example) Vue by itself is quite light (mu Vue apps were
never slow, even on a computer that choked on most other webpages). The
problem is that many web developers don't care about performance and will
hapilly fire tens of HTTP requests while loading the page, which happens to be
over 1M because of all the unnecrssary JS and CSS libraries (looking at you,
Bootstrap!).

------
paperpunk
Equally it's acceptable to go down the single-page-application route and just
make sure you prioritise performance. A lot of SPAs/"rich" web applications
are not slow because of inherent performance disadvantage to that model,
they're slow because they're poorly written.

Perhaps just because I've dedicated a lot of time to it but I think something
like React makes it a lot easier for me to find where my performance
bottlenecks are and eliminate them vs. mixed server-side dynamic HTML /
progressive enhancement.

~~~
smacktoward
_> A lot of SPAs/"rich" web applications are not slow because of inherent
performance disadvantage to that model, they're slow because they're poorly
written._

I feel there is a wrinkle here, though. SPAs aren't _inherently_ slow, but
they are built around models that will ineluctably _tend towards slowness_
unless the developer works hard to avoid that.

SPA frameworks are all about breaking your site down into small, self-
contained interface elements that can then easily be composed into a larger
whole. When each interface element is acting independently, though, you end up
with lots of network requests getting fired as each one builds up its state
independently of the others. Network requests are slowwwwww, and it only takes
one of them stalling out to make the whole page feel sluggish or broken.

There are ways to architect around this problem, but they require
understanding that it actually is a problem, and they take away some of the
"shared nothing" developer independence that made the SPA approach so
appealing in the first place. So it's not surprising that so many SPAs either
don't take advantage of them or do so incompletely.

~~~
barbecue_sauce
To build on this, I think it may be an issue with the REST model specifically
as opposed to SPAs themselves (which you may have been alluding to). It
inherently encourages several small network requests. I'm not a huge GraphQL
fanboy and I haven't worked with it closely, but it's a lot more conducive to
batching data fetches into only a few requests. You can get around this by
violating some REST assumptions like making heavy endpoints that return all of
the data you know you'll need at the initial loading of an application, but
then you open yourself up to criticism from pedants.

------
timw4mail
SPAs should just die out. As a user the experience virtually always means slow
loading, large downloads, and more fragility.

Seeing a loading spinner makes me cringe.

~~~
davnicwil
It's funny, I have the opposite association.

Usually with any website which involves booking tickets, if I see it's a SPA I
think there's a good chance that the company spent some effort on this and
therefore care and it's likely to work OK.

If it's a server-rendered forms type application, I almost expect it to be
poorly implemented, be frustrating to use or fail completely.

My suspicion is that, because these server-rendered forms type frameworks are
very mature and much easier and faster to build something with, they are the
go to option when budget is low, i.e. when quality is not a priority, and I
think that may explain the correlation I've seen. Nothing to do with the
underlying technology of course.

~~~
didgeoridoo
My experience matches yours for large organizations; fairly or not, if I’m
booking a plane ticket through the airline, an SPA page makes me feel
confident that there was some real work put into it, while a basic server-side
forms + JS approach makes me worry it’s a semi-abandoned afterthought.

That’s reversed for websites & apps for small companies and startups. In those
cases, SPAs tend to feel fragile, buggy, and full of weird defaults and
unusual behavior, especially compared to the relative simplicity of a basic
form with some JS sprinkles.

No idea why that is, or if the perception is even accurate.

~~~
je42
please keep in mind server-side doesn't mean necessarily "basic" you can have
a server-side app and still have the same user experience as a full-blown SPA
app, as long as you know what you must do in the client for a great user
experience.

------
baldeagle
I've been wondering over the last couple years what the state of the art is on
server side rendering. There seems to be a lot of energy on the FE side with
react and angular, but other than dockerization, I don't hear about the same
class of big FAANG shiny backend rendering tools. Even the article is just
pointing out that server side exists. I'm working on setting up a small
website for my wife's business and am still thinking of running Flask/gUnicorn
just like I did years ago. Maybe there is something with Elixer / Erlang, but
that seems niche. What should I be looking at, if I want to skill up to the
new shiny in server side rendering.

~~~
timw4mail
Server-side rendering doesn't really have "new shiny". It works, just as it
has, and that is a feature, not a bug.

~~~
baldeagle
This is why the next generation of dev's is going to be FE heavy, I think.
Because the big marketing of mindshare and talks is going to all the
developments on FE, vs server side where it is steady and reliable.

------
btbuildem
Another argument for keeping business logic server-side is, well, that your
proprietary and presumably valuable code remains on the server instead of
being widely disseminated.

~~~
Eire_Banshee
This is my biggest issues with SPAs. Its not that it is that hard, its just so
much easier to keep it secure if its being done server-side.

~~~
tyre
What's an example of something that would be proprietary, reasonably on the
front-end, and stealable from minified source?

In my mind, anything complex would probably be server side anyway for
performance reasons (though I admit there are many, many SPAs with seemingly
little thought about performance.)

~~~
creatornator
An inexperienced dev might do something like put API keys in frontend code.
You can even do an advanced search of Github to find people's keys to steal to
get access to paid APIs.

~~~
Can_Not
Inexperienced devs already leak keys into front end code before SPAs.

------
ehnto
Considering we have had an entirely new paradigm shift in front end
development, I have yet to see anything that has blown my mind for usability
or UI. Usually it's the same site and design except now it jiggles about as
stuff loads asynchronously or repaints. I see way more degradations than I do
improvements. I would love to see the creme of the crop, if anyone has any
good applications using new tooling they think are a good example?

------
dugluak
> business logic being implemented in the client

I disagree, typically business logic is implemented in the API not in the
client.

~~~
duncan-donuts
Yeah, business logic in the client is not a great idea. What happens when you
add a new client (mobile app?), and you get to relive all of the same bugs you
fixed? Just don't do it.

~~~
dugluak
exactly, that's one of the advantages or the modern way of web development -
decoupling business logic and UI (HTML)

------
igl
Going back to the early 2000s with freemarker/twig/mustache is what he means I
guess? Nextjs and Gatsby are what they are for very good reasons and backend
apis can be written in whatever you please these days... Why would you
consider using those dinosaurs again? When that is all you and your team is
comfortable with?

------
thieving_magpie
I'm a really late comer to web development. I got introduced to it through
angular and react SPA. At this point I don't know how to do anything except
these types of projects and not a lot of time to dedicate to learning a new
(or old, depending on your view) way of doing things.

I need some type of remedial web dev training.

~~~
halfjoking
Just type "jquery" in front of every programming-related web search you do.

If you want something old-school but even more advanced... type "jquery
plugin."

I know what you're thinking... I should write an ebook. But I'm too deep in
mountains of jquery slop at work, I barely have time to write this comment.

~~~
cuddlecake
No, we don't think you should write Yet Another E-Book. :(

------
je42
agreed:

everything that you must do client-side because of latency, offline and/or
device capabilities: do it client side.

everything else should go to the server.

------
amelius
Product designers and managers might disagree.

