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.
Turbolinks: SPA-like Experience without the SPA-framework Hassle
61–70 of 97 posts
Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle
#62If 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...
Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle
#63Server 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
Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle
#64If 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 Fram…
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
Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle
#65I 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…
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…
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.
Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle
#66I 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…
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
Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle
#67I 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.
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.
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.
Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle
#68Actually 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.
Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle
#69Turbolinks 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.
Re: Turbolinks: SPA-like Experience without the SPA-framework Hassle
#70Er... 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.