
Turbolinks: SPA-like Experience without the SPA-framework Hassle - filipewl
https://goiabada.blog/can-you-build-a-single-page-application-without-a-front-end-framework-6799cee03750
======
disconnected
I know they are trying to promote their own Front-End Framework (while trying
to pretend that it isn't one), but with regards to the question on the title,
my experience is: you can, but please, don't.

It actually isn't THAT hard, but what will happen is that you'll end up
reinventing the wheel badly, and you'll be chasing bugs and fixing platform
inconsistencies for months.

It won't be optimized and it won't work in some random obscure browser, or
under some random platform (and there's always THAT user that just happens to
have that browser/platform combo... Murphy's Law spares no one).

Also remember: YOU have to maintain your poorly cobbled-together "framework"
for the next 2, 3, or more years. If anything changes and pages stop working
"right", you get to pick up the pieces. Yes, "you", because since your
framework is something that you pieced together, there are no "tutorials" nor
stack overflow questions nor manuals to refer to.

If someone DOES pick it up after you, (the poor bastards), they are going to
be bothering you day and night, or go insane after 2 weeks.

In conclusion, just grab something that works for you and is reasonably well
supported (and looks like it will REMAIN supported in the future) and use
that. Don't fall into the "NIH syndrome" trap.

~~~
bruncun
Turbolinks evolved from Pjax (4 yrs old) and is part of Ruby on Rails (11 yrs
old). Not only does it respect back/reload out of the box, but it also
supports native. Its as mature as it is supported as it is powerful.

It really just works - drop it into a project and you instantly have a SPA.
Its far from a framework - its API has less surface area than even React. The
above comment couldn't apply less to Turbolinks.

The only true caveat necessary is that it's written in CoffeeScript. :P

~~~
dcwca
The only true caveat is you can’t have multiple dynamic elements per view.

~~~
bruncun
It allows you to do partial updates, but indeed it doesn’t support view
transitions out of the box. :/ That said, the native wrappers offer built-in
transitions, and you could probably hack web transitions with some modding and
a component library.

~~~
jwandborg
I like your optimism, but I would like to remind (scare) you:

If you decide to put your effort into customizing the framework, you increase
your risk of building

> [...] your poorly cobbled-together "framework" for the next 2, 3, or more
> years. If anything changes and pages stop working "right", you get to pick
> up the pieces. Yes, "you", because since your framework is something that
> you pieced together, there are no "tutorials" nor stack overflow questions
> nor manuals to refer to.

------
nicc
I don't think you'll find anyone who thinks it's hard to build 1 SPA without a
framework.

The thing is that if you build 2, 3, 100, you'll find yourself doing the same
stuff over and over again (and always better than the previous time, so that
you'll want to replace all your old code, which is now obsolete), and that's
when frameworks are useful.

~~~
ourmandave
_so that you 'll want to replace all your old code, which is now obsolete),
and that's when frameworks are useful._

You know, like Angular 1.

~~~
jchw
It ain't an easy transition, but transitioning from Angular 1.x to Angular 2.x
can be done. A path forward was forged in 1.x updates that let you
incrementally make your code more Angular 2-y. Also, there doesn't seem to be
a huge breaking change in the foreseeable future either.

That being said, React seems far less likely to pose this threat, with the
caveat that you do have smaller pieces you may have to rewrite as the
ecosystem evolves. That being said, in a few years of using React, the only
things that have hugely changed are:

1\. React Router 2\. Use of ES6 classes 3\. Better compilers/tools

...That's it. And the latter 2 don't really mean you need to rewrite code,
although often you can to take advantage of new stuff. All in all, not at all
a raw deal. You get a lot from the work.

------
WA
Yes, you can. Maybe you even should, because then you at least understand all
the moving parts. Because there are way too many shitty SPAs out there that
break functionality (Twitter and Facebook when hitting the back button) or are
annoyingly slow and unreliable (iTunes Connect, Play Developer Console). Read
[1] to see all the disadvantages and understand them. Then maybe build an SPA.

[1]: [https://adamsilver.io/articles/the-disadvantages-of-
single-p...](https://adamsilver.io/articles/the-disadvantages-of-single-page-
applications/)

~~~
cname
Building your own is educational and maybe even fun (to a point), but it's not
going to magically fix these kinds of issues. Most if not all frameworks
support navigation and custom framework XYZ probably isn't going to do a
better job.

The fact that some sites do a bad job at navigation, performance, or whatever
really seems orthogonal to me. We can also come up with numerous examples of
"classic" sites that are slow, bloated, and have a bad UX.

~~~
WA
That’s precisely my point: a good SPA is more than a framework and the only
thing that helps to make it good is education.

------
libria
Downvoting everyone answering the title question and not reading the article.
You guys should be better than this.

It's not about cowboying or NIH. It's about using a library called Turbolinks
[https://github.com/turbolinks/turbolinks](https://github.com/turbolinks/turbolinks)
to render static pages server-side and swap the content out with js.

~~~
s73ver_
It seems like most people are more interested in discussing the question posed
by the title than discussing the product the article is advertising.

~~~
libria
Is it a useful discussion, though? We all seem to already agree reinventing
wheels is a waste of time.

~~~
s73ver_
I would say it's more useful than discussing the ad. Which is still to say,
not very.

------
sebringj
If you are not on a team and don't have any budget requirements, then sure. Do
it all from scratch and in your own arbitrary flavored-way in your basement,
then write documentation later and put it on hacker news as the next great js
framework to use out of plethora already there, then someone writes an article
like this and places it on hacker news, then repeat the process again.

~~~
jwdunne
I think we've had some of this on the backend too. I've seen "you don't need a
framework" a few times outside of the current JS atmosphere.

Seems like the easier it is to get going, the more frameworks you'll get. PHP
is similar - a good whack of frameworks. The community has banded together,
producing a group of developers, one from each major library or framework just
so they can figure it out. It's called the Framework Interoperability Group
and is responsible for the PSRs which have done a lot of good for the PHP
ecosystem.

JavaScript, I'm not sure you'd have the same luck simply because any
interoperability group would need an arena or virtual equivalent just to
start. That's ignoring the communication issues and length of decision making
time.

~~~
sebringj
I actually prefer coding by myself as I get to do my own thing but when it
comes to working with teams, I strongly prefer a framework because its kind of
like how religion helped form alliances or like how a river flows in the same
direction. Its all arbitrary bullshit but helps reduce collisions and
arguments. After all, highly documented, well tested bullshit, is much better
than highly untested, no-documented bullshit.

~~~
jwdunne
Oh I agree. It's a good way to learn how something works. How do you become
"good enough" to build production ready libraries that solve particular
problems without practice solving said problems?

------
cocktailpeanuts
Actually the first thing I do nowadays when I start a new project using rails
is turn off turbolinks. Rails has so many "magic" hidden underneath and
Turbolinks is the epitome of this problem. I have no idea how it works, but
all I know is it breaks my apps too often if I ever make use of a lot of
JavaScript code.

Nowadays I do:

1\. Pure old school websites with no SPA approach (Surprisingly, most web apps
work just fine this way. You're just being tricked into building SPA when you
don't need one)

2\. Use rails as API backend and use frontend JS framework (I do this when I
know I will need to make this work both on the web and mobile. Since I just
need to write the API once and use it cross platform, it's much more efficient
this way IF I'm doing something like this)

Turbolinks actually doesn't fit into any of this workflow and just complicates
things IMO.

~~~
toasterlovin
As a counterpoint, Turbolinks has been an unmitigated success for a huge app
that I work on. 80% of the performance and responsiveness of an SPA with about
5% of the work. Granted, the app is very vanilla-Rails. I can see Turbolinks
getting in the way if you have a bunch of other "complicated" Javascript, but
if your app is mostly standard Rails views plus some jQuery, Turbolinks is an
amazing hack.

~~~
cocktailpeanuts
Yes, but my point was that if I want my app to be "vanilla rails with jQuery"
(which actually is all you need for most web apps), I actually WANT it to
behave like a "website", meaning I DON'T want it to behave like a single page
app because it's confusing both for users and the developer (myself), which is
where turbolinks comes in.

~~~
toasterlovin
IMO, it doesn't _behave_ like a single page app. It just _performs_ like one
(aka, it's fast as heck).

------
wanda
It’s the wrong question to ask. Frameworks exist so that devs can stand on the
shoulders of wheel reinventors/optimisers, and perhaps more importantly
debuggers. If you’re going to build an SPA, you may as well use a framework.

The question to ask is: _should_ you build an SPA? Many complaints we as
developers have, especially regarding browser history issues with SPAs, are
issues that the end-user also experiences, but under the umbrella
classification of “the website doesn’t work well.”

An SPA offers much in the way of developer ergonomics, but does it benefit the
end-user? I’m inclined to think it doesn’t in many cases. Aside from the issue
of downloading Javascript libraries, SPAs often make the user experience
unnecessarily jarring when even simple things can seem to take longer because
the browser is hanging while JS occupies the main thread — which, in the end,
is at least on the same level as a full page refresh, in terms of user
experience.

Of course, I’m no UX expert, but speaking from my own experience and the
experience of some non-developers with whom I communicate, I have concluded
that web applications which do the bulk of the work server-side and emit fully
rendered HTML without the need for Javascript libraries etc. tend to offer
preferable experiences for end-users.

Obviously React blurs the line a little with server-side rendering, but it's
rare that you see a truly well-executed example in the wild. Maybe I'm wrong,
I don't have a good sample size to make remotely objective conclusions.

All I know is that Github is a website that works very well (in my opinion)
and its full page refreshes never bother me. Same goes for a handful of other
websites (FreeAgent, an accounting platform, was also very nice to use when I
was a freelancer). I just can’t shake my scepticism about SPAs as a result,
despite the fact that working on them comprises my profession, my every day
life.

It makes me miserable sometimes though, to feel dubious about the things I
help build day after day, but I don't have the luxury of being able to just
build what I want, I need money so I build what others want.

~~~
GoToRO
Frameworks are used because they provide a lot of functionality for zero
dollars. You then sell the SPA to the client including that functionality for
non-zero sum. The part in which the site stutters and the like, comes after
the client paid and it's too late.

There are also clients that want a website done in Angular. That's what they
want and that's what you have to give them.

These are two use cases I found for frameworks and these are the reasons they
exist.

------
ronneybezerra
Hi, as the author of this article I would like to thank you all for the
discussion about the title. Thinking in retrospect, I see it was misleading
indeed, but it wasn’t intentional, just a bad choice. So I decided to change
it in order to better describe its content. Now it’s called Turbolinks: SPA-
like Experience Without The SPA-framework Hassle.

------
quantumofmalice
Turbolinks is OK, but I prefer intercooler for HTML-based apps because it
gives me a lot more control:

[https://github.com/LeadDyno/intercooler-
js/](https://github.com/LeadDyno/intercooler-js/)

I don't use it for everything, but it's great for a lot of my work.

~~~
mhd
I've experimented with Intercooler, and it's a nice intermediate step between
just enhancing a site with some jquery or vanilla JS and full-fledged SPAs.

This is almost a general theme in webdev, the middle ground is often left out,
with things accumulating either on the complex or purposely minimalistic.
Rails/Sinatra, Flask/Django, React/Angular... (and yes, I'm aware that it's
slightly ironic that RoR is now my "monolith" end of things, given how light
it was back when we were doing horrible things with Struts and J2EE)

~~~
quantumofmalice
I hadn't thought of it in those terms, but I definitely agree. I also like
that I don't have to decide up front that I'm going to write my whole app
using it and can add it in later on where it makes sense. I don't know what to
call that, but it's nice.

I wouldn't try to write a video game or anything like that with it, but for
most of what I do it gives me what I want with very little complexity.

------
tbirrell
Er... Yes. Its fairly easy. Granted I've never done anything on the scale of
FB or Netflix, but SPAs are not as difficult as everyone likes to think they
are.

~~~
Scarbutt
Its no the difficulty, its that it is more work and takes more time. A small
example: with a SPA that's needs a backend (most apps) you need to do routing
in two places, the backend and fronted, versus just doing routing in the
backend.

------
archi42
Hmm, my backend is some SQL, a bunch of PHP scripts handle requests and return
JSON to my SPA. Only thing I use is jQuery since I didn't want to handle the
FX stuff; everything else goes through some wrappers I wrote in half a day and
which take care of browser glitches.

JSON to html5 content is now at a few thousand SLOC, but still easy to
maintain - by me, but honestly not by others. Would it be better with a
framework? No, because my employee is a C.S. company with an entirely
different focus (applying some corner theory stuff to industrial products): no
one here is an expert in PHP Frameworks, instead we have some pretty good C++
and ocaml masters.

~~~
ch4s3
If you have some OCaml masters, why not slap together some BuckleScript to
call an simple OCaml wrapper around the sql and call it a day?

~~~
archi42
They're working on more important stuff ;)

------
jand
From my point of view SPA and solid backend APIs go hand in hand. I see the
main reason to use a SPA is to decouple front- and backend.

Doing so allows you choose a new frontend after some years while keeping the
backend - or rewriting performance critical backend code while reusing the
frontend.

Do you think the SPA-ish look and feel really is the key? That would surprise
me.

It is more of an architectural design choice to me.

~~~
ec109685
Your front end web server can call your backend API, so you can decouple
without it being SPA.

~~~
Scarbutt
Correct, but its arguable which will be more work, with a front end server and
backend API you are still writing two applications, and most probably, you
still need to sprinkle some JS for UX enhancement.

------
dustingetz
Server side rendered javascript means you can mix and match turbolinks style
with spa style

For example, initial load SSR but popovers SPA, all same codebase, you could
even configure which components render which way _after_ the code is deployed

------
quantumleap22
If you want more fine grain control over your app than turbolinks, but like
the general idea, intercooler.js gives you that:

[https://github.com/LeadDyno/intercooler-
js](https://github.com/LeadDyno/intercooler-js)

There are some good blog posts on HTML and HATEOAS too:

[http://intercoolerjs.org/2016/05/08/hatoeas-is-for-
humans.ht...](http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html)

------
twobyfour
Yes, of course, but why would you want to?

Either you'll end up with a mass of spaghetti, or you'll end up inventing your
own, probably buggy, front-end framework.

------
gscott
Reading a bit into it they never say the word Ajax but that is what it is.
Something used for years they are pitching as something new and exciting.

~~~
ccachor
It's actually PJAX.

------
endlessvoid94
Does anyone have a good resource for using the iOS and Android wrappers for
Turbolinks? I find the official documentation to be kind of lacking.

------
stevedonovan
Discussion about frameworks and SPA focuses on developer convenience, but it's
necessary to look at user happiness. Is the bloat of the modern web a
necessary consequence of big frameworks or a result of incompetence? That is,
are people just bad at using them?

------
ubersoldat2k7
Yes, I've made a few vanillajs SPA for HbbTV apps which were very unhappy
about loading any framework everytime you change channels. Hardest part is the
"router" which ends up being a big'ol switch statement.

~~~
mtpn
Once, I made an SPA for an interview with plain JS and handlebars for
templating. It was for a react team and I was not big into react but wanted to
show I get how all the pieces fit together, but still be able to understand
and debug what I had written for them. Instead of being in unfamiliar
territory with react debugging. Anyhoo, the switch-statement router based on
changes in the URL hash was just about where they couldn't take it anymore.
They couldn't see why I hadn't used some library for the routing. I had
genuine flubs aside from that in the interview and definitely wasn't right for
them, but it was funny to see heads quizzically turn to the side during that
portion. I was like "well, what a weird little detail to get hung up on".

------
TheCoelacanth
No. You can build one without using a framework that someone else wrote, but
you will inevitably end up with an ad hoc framework of your own design.

~~~
hawski
If that's the case every program ever contains a framework. That would be
quite an useless definition.

I assume that it depends on how general the internal code is. If it's very
specific it's not really a framework. Of course people often forget about
YAGNI principle and end up with an ad hoc framework.

------
scelerat
Beyond the simplest of apps, if you don't use someone else's framework, you
will -- like it or not -- be building your own framework.

------
CaptSpify
Sure. I build them all the time. It's dead simple as long as you keep it
simple.

I'd argue that the bigger problem is knowing when you need an SPA. Every
website thinks they need an SPA, even when they obviously don't. Your news
site doesn't need to be an SPA, your document-sharing service doesn't need to
be an SPA, your movie recommendation service doesn't need to be an SPA, etc.

------
ComputerGuru
It’s just clickbait link spam.

------
jaux
It's not very hard, and it's a good exercise if you have time.

------
1001101
> Keeping the heavy work in the server-side with Turbolinks

.. and paying AWS for it.

------
mattnewton
For the purposes of this exercise, are we talking vanilla js only or can I
build my own with excellent libraries like page.js? Because if the former,
sure we can, but I wouldn’t want to ship a product on a deadline that way.

------
robinduckett
The Answer: Yes, but use this Front End Framework.

------
ggg9990
Making your own tools is a great learning experience but probably not the best
idea for production processes.

------
zzzeek
ah, the old, "it's not a framework, it's a library" switcheroo. a classic.

granted I totally make my living around the same phrase applied to my own
software.

------
pier25
The title is misleading since this is basically a TuboLinks article and
doesn't really explore the problems of building an SPA without a framework.

~~~
bodyloss
Agreed. TurboLinks itself seems unnecessarily heavy. So you avoid a full page
reload, but you do still have to fetch the whole page over the network and
render it. Just without the browser loading icon spinning.

~~~
ch4s3
Well, you can use data-turbolinks-permanent to prevent turbolinks from
trashing a dom subtree, so that lightens it up a bit. Its also often paired
with caching so that big chunks of the page are pulled from the cache so you
can often do a sub 300ms refresh of the page with turbolinks while working
well on slow mobile connections that choke on large js bundles.

It is complex in its own way though, so there's no free lunch here.

------
ebbv
Absolutely. It's really not that hard. I did it with the first version of my
little meeting agenda app Meeting Rainbow. I rewrote the UI using Angular 1.4
later, and honestly it wasn't any easier using Angular than no framework.
Angular just made things different, and depending on your opinion made the
code easier to understand (though both versions are several years old at this
point and far from what I'd consider a good codebase.)

