Turbolinks: SPA-like Experience without the SPA-framework Hassle(goiabada.blog)
goiabada.blog
Turbolinks: SPA-like Experience without the SPA-framework Hassle
https://goiabada.blog/can-you-build-a-single-page-application-without-a-front-end-framework-6799cee03750
96 comments
> you can, but please, don't
I think this is a bit short-sighted. While building a framework from scratch is certainly not for everyone, there's definitely value in building one. You say things like `you have to maintain your poorly cobbled-together "framework"` but when you think about it, this was true of authors of major frameworks at some point as well.
Remember when React added id's to every single DOM element? Or when Ember was dog slow? Framework authors and maintainers learn lessons over time and with each project iteration they become more valuable due to their skillsets.
> 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
Again going back to skillsets: this is part of what makes large OSS project developers desirable: they've been through the process of passing-the-baton and they know the importance of things like documentation, maintainability, etc and can take concrete steps to further goals in those areas.
I think this is a bit short-sighted. While building a framework from scratch is certainly not for everyone, there's definitely value in building one. You say things like `you have to maintain your poorly cobbled-together "framework"` but when you think about it, this was true of authors of major frameworks at some point as well.
Remember when React added id's to every single DOM element? Or when Ember was dog slow? Framework authors and maintainers learn lessons over time and with each project iteration they become more valuable due to their skillsets.
> 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
Again going back to skillsets: this is part of what makes large OSS project developers desirable: they've been through the process of passing-the-baton and they know the importance of things like documentation, maintainability, etc and can take concrete steps to further goals in those areas.
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
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
Just to be pedantic: pjax is nearly 7 years old. https://github.com/defunkt/jquery-pjax/commit/3efcc3c968c18c...
The only true caveat is you can’t have multiple dynamic elements per view.
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.
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.
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.
This is easy to do in Rails on your own. Turbolinks is irrelevant to this.
Turbolinks is not a front-end framework. It is a library that has been in Rails for ~5 years. And before that, pjax did basically the same exact thing. This is a pretty battle-tested way of building web applications.
GitLab removed TurboLinks from their site not that long ago. It was the source of a lot of bugs, crufty code, and flakey tests. If you have any JavaScript that modifies the DOM or ever plan to don’t use TurboLinks.
> GitLab removed TurboLinks from their site not that long ago. It was the source of a lot of bugs, crufty code, and flakey tests.
An anecdote is not data.
An anecdote is not data.
> Turbolinks.clearCache() Removes all entries from the Turbolinks page cache. Call this when state has changed on the server that may affect cached pages.
https://github.com/turbolinks/turbolinks#turbolinksclearcach...
This is a nightmare. You will eventually miss a cache invalidation and break browser navigation or invalidate the cache so aggressively that TurboLinks is serving no purpose.
You don't need lots of negative testimonials to see that managing your own client side cache with JavaScript is a bad idea.
https://github.com/turbolinks/turbolinks#turbolinksclearcach...
This is a nightmare. You will eventually miss a cache invalidation and break browser navigation or invalidate the cache so aggressively that TurboLinks is serving no purpose.
You don't need lots of negative testimonials to see that managing your own client side cache with JavaScript is a bad idea.
Haven't had any problems with this in 2 years in production. It also works fine for Basecamp.
Shopify went back to Turbolinks: https://shopifyengineering.myshopify.com/blogs/engineering/r...
That article is from 2014, the golden age of TurboLinks. As far as I can tell they are not using it on their main site or any of their white labeled sites anymore.
https://github.com/shopify-graveyard/turbolinks/
https://github.com/shopify-graveyard/turbolinks/
They forked: https://github.com/Shopify/turbograft to add partial page replacements. It was slated to be merged in TurboLinks 3 but that canned in favour of version 5.
Their new Polaris components are using React though: https://github.com/shopify/polaris
Their new Polaris components are using React though: https://github.com/shopify/polaris
I think at this point it really depends on the type of app, the browsers supported, and exactly what you mean by "without a framework." The sentiment you're expressing, although true to an extent, sounds like something I would have said 10 years ago.
It's VERY rare, almost unheard-of, to find any front-ends these days that are just HTML, CSS, and Javascript. That wasn't the case 10 years ago. IMO we don't know what a modern app would be like without a framework because it's just not done anymore. Even this post here uses Turbolinks, a framework.
It's also rare these days (in my experience anyway) that clients will ask for things that are simply not possible with HTML, CSS, and JS. Website design has started to get very same-y, and both HTML and CSS have gone through huge upgrades. Depending on the requirements you might be able to pull off a modern-looking design with just the basics.
Browser compatibility remains a problem, but most JS tools called "frameworks" don't exist to solve that one, but mostly to help structure large amounts of JS code. These tools simply did not exist at all back then, because people just didn't write that much front-end code. On SPAs, a lot of the code is only there to reinvent things the browser and the back-end could be doing.
If I was starting a new project I would probably go very light on the tooling.
It's VERY rare, almost unheard-of, to find any front-ends these days that are just HTML, CSS, and Javascript. That wasn't the case 10 years ago. IMO we don't know what a modern app would be like without a framework because it's just not done anymore. Even this post here uses Turbolinks, a framework.
It's also rare these days (in my experience anyway) that clients will ask for things that are simply not possible with HTML, CSS, and JS. Website design has started to get very same-y, and both HTML and CSS have gone through huge upgrades. Depending on the requirements you might be able to pull off a modern-looking design with just the basics.
Browser compatibility remains a problem, but most JS tools called "frameworks" don't exist to solve that one, but mostly to help structure large amounts of JS code. These tools simply did not exist at all back then, because people just didn't write that much front-end code. On SPAs, a lot of the code is only there to reinvent things the browser and the back-end could be doing.
If I was starting a new project I would probably go very light on the tooling.
Another factor is that we’re seeing the continued rise of massive front end frameworks at the same time that the native JavaScript environment is becoming faster and easier to use. There’s a non-trivial number of sites where the easiest thing to maintain will be standard JS/CSS rather than whatever was in vogue a few years before.
This is also of interest from the performance angle: frameworks take on a lot of expense maintaining certain levels of magic, convenience, and general applicability which has its benefits but also makes it easier to miss or fix problems. The first time I tried React on a serious project, the coworker who’d been hyperventilating about how fast the virtual DOM would be was surprised to learn that it was something like 40,000 times slower and that there was no easy way to fix it (innerHTML updates on rows in a large table when textContent was sufficient).
The last time I did a fresh project I ended up using just ES6 + SCSS and found it to be quite pleasantly rewarding. So many of the old tedious points have gone away with flexbox / grids, ES6 classes and arrow functions, querySelectorAll and the newer array methods, fetch vs. xhr, etc.
This is also of interest from the performance angle: frameworks take on a lot of expense maintaining certain levels of magic, convenience, and general applicability which has its benefits but also makes it easier to miss or fix problems. The first time I tried React on a serious project, the coworker who’d been hyperventilating about how fast the virtual DOM would be was surprised to learn that it was something like 40,000 times slower and that there was no easy way to fix it (innerHTML updates on rows in a large table when textContent was sufficient).
The last time I did a fresh project I ended up using just ES6 + SCSS and found it to be quite pleasantly rewarding. So many of the old tedious points have gone away with flexbox / grids, ES6 classes and arrow functions, querySelectorAll and the newer array methods, fetch vs. xhr, etc.
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.
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.
See, you don't always need a SPA, you know.
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.
You know, like Angular 1.
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.
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.
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...
[1]: https://adamsilver.io/articles/the-disadvantages-of-single-p...
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.
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.
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.
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 to render static pages server-side and swap the content out with js.
It's not about cowboying or NIH. It's about using a library called Turbolinks https://github.com/turbolinks/turbolinks to render static pages server-side and swap the content out with js.
What about click-bait titles?
> Downvoting everyone answering the title question and not reading the article. You guys should be better than this.
Downvoting you for not paying attention to why people are answering the title question--because it was the title question in the article, which then proceeded to answer a different question.
> It's about using a library called Turbolinks
Which is not answering the title question of the article. The article should have been titled "Build a Single-Page Application Using Turbolinks". Even the part about "without a framework" is false: Turbolinks is a framework.
Downvoting you for not paying attention to why people are answering the title question--because it was the title question in the article, which then proceeded to answer a different question.
> It's about using a library called Turbolinks
Which is not answering the title question of the article. The article should have been titled "Build a Single-Page Application Using Turbolinks". Even the part about "without a framework" is false: Turbolinks is a framework.
> Downvoting you
Which is fine. All contributions not engaging the content should be pushed to the bottom of the stack for the more interesting discussions to bubble up.
> because it was the title question in the article, which then proceeded to answer a different question. > Which is not answering the title question of the article. The article should have been titled "Build a Single-Page Application Using Turbolinks".
Clickbait is exactly why we should be dissecting the article and ignoring the title. Flag the submission if it's that offensive, even. Answering the clickbait question is just noise.
> Even the part about "without a framework" is false: Turbolinks is a framework.
Of course it is. I expect people to call that out as well as clickbait, but that's kind of bikeshedding. What's far more interesting to discuss is the approach: pre-rendered html dynamically swapped vs SPA's, tradeoffs, pros/cons, performance, security, etc.
Which is fine. All contributions not engaging the content should be pushed to the bottom of the stack for the more interesting discussions to bubble up.
> because it was the title question in the article, which then proceeded to answer a different question. > Which is not answering the title question of the article. The article should have been titled "Build a Single-Page Application Using Turbolinks".
Clickbait is exactly why we should be dissecting the article and ignoring the title. Flag the submission if it's that offensive, even. Answering the clickbait question is just noise.
> Even the part about "without a framework" is false: Turbolinks is a framework.
Of course it is. I expect people to call that out as well as clickbait, but that's kind of bikeshedding. What's far more interesting to discuss is the approach: pre-rendered html dynamically swapped vs SPA's, tradeoffs, pros/cons, performance, security, etc.
> Clickbait is exactly why we should be dissecting the article and ignoring the title.
That depends on which topic one thinks is more important: the article's title topic, or the actual article's topic. I personally pick the former, and so, I suspect, do commenters who are focusing more on that than on Turbolinks.
> What's far more interesting to discuss is the approach: pre-rendered html dynamically swapped vs SPA's, tradeoffs, pros/cons, performance, security, etc.
Then by all means discuss it. But don't downvote people who have a different judgment of its relative importance than you do.
(Note: I see that the moderators have now changed the title of this submission in HN, to reflect the article's actual content instead of its title. However, I still think the article's title is fair game for discussion. But I'll leave the final decision on that to the moderators.)
That depends on which topic one thinks is more important: the article's title topic, or the actual article's topic. I personally pick the former, and so, I suspect, do commenters who are focusing more on that than on Turbolinks.
> What's far more interesting to discuss is the approach: pre-rendered html dynamically swapped vs SPA's, tradeoffs, pros/cons, performance, security, etc.
Then by all means discuss it. But don't downvote people who have a different judgment of its relative importance than you do.
(Note: I see that the moderators have now changed the title of this submission in HN, to reflect the article's actual content instead of its title. However, I still think the article's title is fair game for discussion. But I'll leave the final decision on that to the moderators.)
> > What's far more interesting to discuss is the approach: pre-rendered html dynamically swapped vs SPA's, tradeoffs, pros/cons, performance, security, etc.
> Then by all means discuss it. But don't downvote people who have a different judgment of its relative importance than you do.
Well, unfortunately I'm not convinced. I don't judge idea 1 as more important than idea 2, but I will vote based on my opinion of the article being more important than the title as I assume most authors intend to communicate more through the 1500 word defense rather than the 10 word clickbait. Obviously the article has more substance to grapple with. If the title's topic is interesting, I welcome new submissions that actually deal with it.
> Then by all means discuss it. But don't downvote people who have a different judgment of its relative importance than you do.
Well, unfortunately I'm not convinced. I don't judge idea 1 as more important than idea 2, but I will vote based on my opinion of the article being more important than the title as I assume most authors intend to communicate more through the 1500 word defense rather than the 10 word clickbait. Obviously the article has more substance to grapple with. If the title's topic is interesting, I welcome new submissions that actually deal with it.
It seems like most people are more interested in discussing the question posed by the title than discussing the product the article is advertising.
Perhaps because the title is classic clickbait, and people on HN don't expect too be hoodwinked like that - and are responding in good faith to a self-contained question as in the title.
why blame the reader for being baited by the actual title of the post, and not the post itself, which has chosen a very misleading title?
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.
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.
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.
That’s one of the reason I prefer libraries to franework and if at all possible core libraries get wrapped in access objects or delegates abd such - a library can be replaced if it gets discontinued or some issues arise down the road, a framework intwrtwine with your code too much and it’s a risky proposition for anything you plan to maintain for more than five years, i.e. devs who bet on angular.
Don’t get me wrong I like the react structure for example and I see the value in having the whole foundations laid out and a strict structure to follow and they seem stable enough for a project, but there’s no way to use it and still maintain control over your code, they become one and if anything happens it’s either a rewrite or one of the purported drop in replacement or you have to get in the code or provide a bug report and wait for a release... and all that is incompatible with enterprise softwares with a sla.
Don’t get me wrong I like the react structure for example and I see the value in having the whole foundations laid out and a strict structure to follow and they seem stable enough for a project, but there’s no way to use it and still maintain control over your code, they become one and if anything happens it’s either a rewrite or one of the purported drop in replacement or you have to get in the code or provide a bug report and wait for a release... and all that is incompatible with enterprise softwares with a sla.
I'm not confident the PSRs have been all that great (Caching / HTTP in particular). They really lend themselves towards creating leaky abstraction. It didn't actually replace the adapter pattern anywhere, now you just get PSRX adapters for everything
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.
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?
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.
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.
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.
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.
IMO, it doesn't behave like a single page app. It just performs like one (aka, it's fast as heck).
[deleted]
Turbolinks isn't that complicated. You should spend a day or two to learn it. Definitely useful in for #1. Depends on what you want to do for #2.
I guess I should have clarified.
I just don't like how it does things I don't want it to do, because when I'm using rails + simple javascript, there's a reason why I'm doing that instead of API + frontend JS framework SPA approach--I WANT it to work like a website, with full page refresh and all.
And I would like to say, for most use cases this is actually much better user experience than trying to make it work as SPA because users want to see "clear cut answers" to their actions.
This used to be simple when web pages just refreshed, but with single page apps, there are so many points of failure that you have to build all kinds of middleware just to make sure this type of client/server inconsistency doesn't happen. And I think this is overkill. Most people have been using regular websites just fine, and even when I've built tons of SPA for living, I myself still prefer regular web pages, you know, like hacker news. It's simple and it works. No state inconsistency, no memory hog.
I just don't like how it does things I don't want it to do, because when I'm using rails + simple javascript, there's a reason why I'm doing that instead of API + frontend JS framework SPA approach--I WANT it to work like a website, with full page refresh and all.
And I would like to say, for most use cases this is actually much better user experience than trying to make it work as SPA because users want to see "clear cut answers" to their actions.
This used to be simple when web pages just refreshed, but with single page apps, there are so many points of failure that you have to build all kinds of middleware just to make sure this type of client/server inconsistency doesn't happen. And I think this is overkill. Most people have been using regular websites just fine, and even when I've built tons of SPA for living, I myself still prefer regular web pages, you know, like hacker news. It's simple and it works. No state inconsistency, no memory hog.
Interesting points. Hasn't been my experience Turbolinks does anything I don't want since Rails5.
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.
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.
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.
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.
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.
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/
I don't use it for everything, but it's great for a lot of my work.
https://github.com/LeadDyno/intercooler-js/
I don't use it for everything, but it's great for a lot of my work.
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)
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)
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.
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.
If you're looking for a little more control but don't want to go all-in SPA, also check out Unpoly:
https://unpoly.com/
https://unpoly.com/
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.
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.
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.
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.
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.
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.
Your front end web server can call your backend API, so you can decouple without it being SPA.
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.
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
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
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
There are some good blog posts on HTML and HATEOAS too:
http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...
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...
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.
Either you'll end up with a mass of spaghetti, or you'll end up inventing your own, probably buggy, front-end framework.
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.
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?
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.
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".
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.
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.
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.
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.
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.
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.
It’s just clickbait link spam.
It's not very hard, and it's a good exercise if you have time.
> Keeping the heavy work in the server-side with Turbolinks
.. and paying AWS for it.
.. and paying AWS for it.
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.
The Answer: Yes, but use this Front End Framework.
Making your own tools is a great learning experience but probably not the best idea for production processes.
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.
granted I totally make my living around the same phrase applied to my own software.
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.
Awful title. Guess no one would read it if it was called "how to use turbolinks."
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.
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.
It is complex in its own way though, so there's no free lunch here.
Is perceived latency for the user lower?
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.)
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.