
Front-End Walkthrough: Building a Single Page Application from Scratch - rizz0
https://blog.poki.com/front-end-walkthrough-building-a-single-page-application-from-scratch-d47c35fdc830
======
hitgeek
"We knew we wanted to build a single page application (SPA) in order to have
more control over the user experience of our website, making it as smooth as
possible. On top of this, it also helps speed our website up since there’s no
longer a need for full page reloads. We only need to load the data that we
don’t have yet, and then re-render the page."

I'm bothered by this perception that SPAs inherently provide a better user
experience. They certainly can provide a different user experience, but
"better" is entirely up to the developers. I'd argue its actually quite hard
to create a better UX in an SPA than the simple page based UX metaphor
everyone is used to that the browser provides. Netflix is an example of a
great UX from an SPA, nba leaguepass is an example of a disaster SPA.

Also there is no inherent speed boost from an SPA. Anything that is slow on
the server will still be slow, and its up to the developer to create a good UX
for latency. In page driven applications, the browser provides a fairly
standard UX for page loading that most people are used to. In SPA apps, the
developer needs to roll this themselves. Widgets popping in all over the place
at different times, moving things all over the page, is a common UX I see in
SPAs that is not good.

~~~
ko27
> "Also there is no inherent speed boost from an SPA"

There is: superior caching & resource management. Even if your non-SPA
perfectly caches resources (impossible with bundling), you are still wasting
time on parsing/compiling/executing cached scripts on every page reload, which
can take up to a few seconds on smartphones.

~~~
smoe
In theory yes, and if you only aim your site at flagship smart phone owners.

In my experience in Latin America with 50-150$ Android phones, very few
developers/managers in the "western world" actually care about their SPAs
performance and in about 9/10 cases the simple backend rendered sites provide
a better experience for me.

edit: Of course there also plenty of devs that add a ton of inperformant js to
their backend rendered sites, destroying the experience.

------
daliwali
Alan Kay was right, programming is pop culture.

It's increasingly harder to find non-legacy single page apps that aren't using
React or Angular (Vue and Ember are distantly trailing behind). Corollary:
it's increasingly harder to find jobs for anything other than React or
Angular.

After technology du jour becomes popular, people will use it not because it's
good or even necessary, but because it will ensure their employment. And then
the rationalizations sink in afterwards.

~~~
arkitaip
Hard to find? How about the wast majority of apps don't use react or angular.
Seriously, let's get out of the echo chamber that is HN.

~~~
daliwali
Sorry, I should have qualified it as Single Page Applications, not web apps in
general. Still, hard to find a front-end job that isn't about SPA anyways.

~~~
savanaly
If you're going to make a SPA, why the heck wouldn't you use one of the
frameworks that has tons of tutorials, walkthroughs, supporting libraries, and
a zillion asked and answered questions on SO? In other words why not use one
of the top 5 frameworks of the current time? It seems efficient to do so to
me.

~~~
daliwali
It's expedient for many reasons to use a major framework, but it doesn't mean
there are no drawbacks.

There are learning curves, inner platform effect (have to do the framework way
of doing things), major breaking changes and outdated information, opinionated
authors you may not agree with, huge dependencies for users to download,
performance bottlenecks and gotchas arising from not using the framework
properly or even the framework itself is slow. These things are basically
guaranteed.

------
throwaway2016a
This seems like a great writeup with some good information in it.

But to be picky, the title needs work. It isn't as describe. In fact it
contradicts itself.

The title is:

> Front-end Walkthrough: Building a Single Page Application from Scratch

Half way down the article:

> When it comes to building a SPA, you can either do things from scratch or
> use a library to help you out. Building from scratch is a lot of work and
> adds a lot of new decisions to be made, so we decided to go with a
> framework.

I would be very interested to see an article in 2017 that is actually from
scratch. Bonus points for not using a ES6 transpiler. Like "Linux from
Scratch" (the book)... useless from a practical standpoint but awesome from a
learning standpoint.

Edit: as a side note, when I started making web apps, jQuery was still in beta
so I didn't even use it. A lot has changed, obviously, for one SPA didn't
really exist then.

~~~
zokier
The title was editorliazed by the poster, the orginal articles title does not
contain "from scratch":

> Front-end Walkthrough: Designing a Single Page Application Architecture

> We documented our journey towards a shiny new stack.

~~~
throwaway2016a
> The title was editorliazed by the poster, the orginal articles title does
> not contain "from scratch":

I actually copied and pasted my quote from the article title not the HN title.
They were the same but they changed the article title (maybe after seeing my
comment?). Which is completely OK, it's a good change.

------
z3t4
I want to point out that it works perfectly fine making a JavaScript web app
in just vanilla JavaScript using NodeJS as server and the browser as client.
You do not need any frameworks!! Vanilla JavaScript works for both small
projects and big projects. And it performs well! (at least compared to the
popular frameworks) and it's very nice to debug! There is no complication
step! And your code will be supported _for ever_ unlike the framework's that
will make your code obsolete within a year or so.

~~~
SwellJoe
"And your code will be supported for ever unlike the framework's that will
make your code obsolete within a year or so."

This is a confusing assertion. How does using a framework make your software
unsupported in ways that not using a framework would not? i.e. if I build an
application, whether I use a framework or not, and then I stop touching it,
forever, why is the non-framework code more resilient to not breaking in the
future?

The framework will keep evolving, but you're under no obligation to upgrade,
if you don't need to keep developing. It seems silly to complain about the
code you didn't have to write.

There are trade offs when using existing software to do things you want to do,
sure. But, you get the core web app functionality you needed to implement,
anyway, and it's been tested by a lot more developers than your code likely
ever will be. In fact, I'd argue compatibility with a framework will be better
than implementing it yourself, assuming you cover the same amount of
functionality in each app; again, because of the heavier testing a widely used
framework gets.

~~~
briantakita
The devil is in the details. From experience, upgrading framework code is
time-consuming. It's mainly because frameworks have a layer of architecture
that you app needs to adhere to. When the architecture changes, so must the
app.

When you roll your own, that is a non-issue. You can switch out libraries as
you wish. I have made several major refactorings on my client's app with
significantly less pain than it took to upgrade my previous clients'
framework-based (i.e. Rails, angular) codebases.

When you roll your own, you can wait until libraries mature, or you can choose
to use snippets of the essential code (thereby avoiding bloat).

I utilize patterns that minimize structural architecture, by utilizing
dependency injection, es6 modules, promises, async/await, factory methods,
agents with events. I avoid classes by utilizing factory methods.

[http://www.briantakita.com/posts/sveltejs-from-
riotjs/](http://www.briantakita.com/posts/sveltejs-from-riotjs/)

~~~
SwellJoe
"When you roll your own, that is a non-issue."

I don't see how it can be. You've got to build and maintain it yourself now,
instead of relying on a huge community of volunteers. If you're OK maintaining
the entirety of the view layer framework (or whatever) yourself, where's the
harm in starting from a known-good state? If you don't want to upgrade but
want to add new features to the framework you picked, you can fork it and do
that.

Now, if you don't _like_ a given framework, having a framework is a loss
because it'll suck to work on. I've seen this a ton. But, that's not the same
problem and one that can be avoided by doing an extra day or two of due
diligence and building a simple app before settling on your favorite. I dunno
about you, but I've built libraries that I decided I hated after I was done
with them. Sometimes, I rewrote them after I figured out why I was originally
wrong about what I like, and sometimes I spent more time finding an
appropriate replacement that somebody else made (this is usually the better
choice).

------
water42
yet another web framework medium article with a misleading angular vs react
comparison.

it isn't angular 2 anymore. it's just angular. it's been out for over a year
and if people were having problems running it in production, we would hear
about it. there are many sites running angular 2-4 in production, google it
and see for yourself. just because google didn't rewrite gmail in angular
doesn't mean you shouldn't use it.

I wonder if there is some highly ranked google search result that spreads this
misinformation, months after some of these points were valid.

~~~
mattgreenrocks
The pop culture cuts both ways it seems.

~~~
water42
Every framework is going to have flaws, but if you perform a comparison I
think there's a responsibility to accurately represent the frameworks being
compared.

------
ecesena
Recommendation for poki, make it easier to reach your website from your blog.

When I go to blog.poki.com, if I like what I read I typically delete "blog."
to checkout what "poki.com" is about -- which should be the purpose of
blogging. In this case it doesn't work, and I had to manually type "www.".

~~~
dragonwriter
Rather than relying on URL rewriting by the reader (and, thus, specific URL
relationships), it would be better just to put a prominent link to the
(www.)poki.com website from the blog.

Relying on manual URL rewriting to navigate to a related page is missing the
entire point of the web.

~~~
ecesena
I guess both will be useful - not having http(s)://poki.com configured seems
also missing the point of the web :)

------
CryoLogic
Most of the issues cited with Angular and React aren't really issues in
EmberJS right now. I always find it interesting that so many people jump right
into frameworks that have design philosophies against maintainability.

~~~
romanovcode
The problem with Ember is that finding developers is a lot harder so nobody
will use it. I'm not saying it's bad, but if I would start a company now and
had to do a SPA (hopefully not) it would definitely be either React or Angular
just because finding developers would be easier.

------
peter_retief
I am doing SPA with vuejs and django backend, its a huge step in the right
direction as far as (my) web development goes. Initially I was sceptical of
webpack, now I see what an asset it is in compiling static content and many
other handy features. I prefer vuejs to react or angular but I haven't really
given them much time, maybe one day

~~~
komali2
This is a debate that can be done to death (which is good, that's how these
frameworks improve), but as someone that's used backbone/marionette, angular,
and react react/redux, I can say the day I found the Vue docs was like a
reawakening. I don't mean to get poetic, but I genuinely had a sense of "holy
shit, _this_ is what docs should look like!" I only got more and more excited
as I read through and learned more about it.

Vue is fucking awesome. I'm just now learning it and I can't wait to build
something more serious than a todo app with it.

~~~
peter_retief
I haven't yet met a developer that doesn't like vue

~~~
reaperducer
I have. I once worked at a shop that tried to rebuild all of its web sites as
SPA's with Vue. Four devs, two with deep JS experience, and it was a complete
disaster. Vue isn't ready for enterprise, and the documentation is a joke.

I don't work there anymore, but looking at the sites now, I can see the old
ones are still online — TEN months later, no sign of Vue.

~~~
komali2
Woah, so looks like we disagree completely.

Why don't you like the docs? I love how it has a great introduction guide[1]
that really dives deep into the hows and whys, but also has a full API guide
when you just gotta know one specific thing [2].

[1]([https://vuejs.org](https://vuejs.org))

[2]([https://vuejs.org/v2/api/](https://vuejs.org/v2/api/))

