71–80 of 97 posts
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 f…
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 ch…
Your front end web server can call your backend API, so you can decouple without it being SPA.
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…
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.
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.
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)
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 f…
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.
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 "m…
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.
Earlier quoted context omitted.
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.
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.
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…
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.…