15 Hacker News comments link this video. Each one links back to its thread.
petefordeMar 2019Strongly recommends
Okay, I have lots of good news for you. First, CoffeeScript is formally deprecated. Turbolinks sucked, but Turbolinks 5 is an entirely new beast and it rocks. You need to give it a second look. I recommend this talk, sped up to 1.5x: ▶ this video Finally, there absolutely is an opinionated client library that is designed to pair beautifully with Turbolinks 5. It's called Stimulus and it rocks. [link] You can play with all of these frameworks using the --webpack parameter: rails new future --skip-sprockets --skip-coffee --webpack=stimulus --database=postgresql --skip-test As a bonus for anyone starting a new Rails project today, you're going to want to bookmark [link] Let me know if you have any questions.
in “Why I believe Rails is still relevant in 2019” · View on HN
petefordeMar 2019Strongly recommends
I urge/beg you to check out the Turbolinks 5 + StimulusJS libraries, which are by the same (Rails team) people, which is no coincidence. ▶ this video
in “I Miss Rails” · View on HN
thrownaway954Mar 2019Strongly recommends
I keep looking at C# and Blazor myself If you want an SPA type Rails way of doing things, you can use Turbolinks. This talk at RailsConf 2016 is really an eye opener. ▶ this video
in “I Miss Rails” · View on HN
trcollinsonJan 2019Strongly recommends
I found this video and talk to be very enlightening. I know it's not the neatest, most exciting framework, but Rails with Turbolinks sure can do the trick. My last two mobile applications were built in the same way that Sam Stephenson describes here. ▶ this video
in “Ask HN: First mobile side-project: What stack to choose in 2019?” · View on HN
petefordeJan 2019Strongly recommends
I urgently encourage you and anyone else reading this to check out Turbolinks 5, ideally in tandem with Stimulus. ▶ this video [link] [link] You can get all of the benefits of server-generated pages with the speed of an SPA. 90%+ of the sites built using SPAs would be better served by Turbolinks and Stimulus.
in “Ask HN: Go-to web stack today?” · View on HN
petefordeJul 2018Strongly recommends
I have nothing against SPAs for complex UI interactions. It's sort of like taking anti-biotics; there should be a moment of reflection when you should justify your true need, lest the cure be worse than the disease. Most developers of a certain age have come up when it's SPA by default, and can't truly defend why they need it. In this thread, there are several claims that it's impossible to write well-organized jQuery. That sounds an awful lot like dogma to me. Also, your inability to write well-organized code says more about your coding and team-management skills than it does about any one approach. Any tech is only as good as the team using it. A few years ago, Sam Stephenson (who originally wrote the Prototype library, before jQuery was a thing) gave an excellent talk on Turbolinks at RailsConf. I recommend the whole talk (turn it up to 1.5x speed, of course) but at 4:12 he does an amazing job of showing how the SPA path leads to insanity. ▶ this video Here's a mental exercise for you: the next time you start a new project, instead of deciding which SPA framework to use, start with an assumption that an SPA is wild overkill for the first iteration of your application - especially if few people on your team have working expertise with the SPA in question. Then see if you can argue FOR the tech. It's much harder to justify something you don't need if you start with an honest conversation about how you probably don't need it. (This works for throwing out CDs, too: start with the a
in “Escaping the SPA rabbit hole with modern Rails” · View on HN
Show 9 more comments
trcollinsonDec 2017Strongly recommends
I built a rather extensive application for a client over the last 18 months using Rails API and Angular, using a number of these sorts of principles. While it is entirely possible to use what the article suggested, I argue it's a premature optimization and may be a detriment to the entire project. We're now actively removing the Angular portion of the project and going back to the good old way. I wouldn't say this decision was made without careful thought nor without weighing many options. But when it comes down to it, many line of business applications (which is what I see a lot of in the market) don't need the level of sophistication the instructions in this article gives. Most applications need to be reasonably fast, reasonably responsive, and extremely easy to maintain and extend. Does working with all of these modern front end tools that change so quickly and given at least one order of magnitude increase in complexity also give the application a equal increase in speed, responsiveness, maintainability, and extensibility? I don't think so. I'm not the first person to say this. Take a look at this presentation by Sam Stephenson, it will be worth your while: ▶ this video
in “Modern Front-end in Rails” · View on HN
elamjeApr 2020Recommends
If you are a Rails developer, this Turbolinks presentation makes a strong case to be used for mobile apps. ▶ this video It seems like there is a strong productivity gain from using rails here since it’s extremely productive and you can make simple wrapper apps to release to the Play and App Store that really just wrap the web view. The biggest gain is obviously reusing most of the web app across three different platforms, and the ability to add native navigation and interaction as needed, later. You also avoid needing a big javascript library.
in “Ask HN: What stack should I use for my mobile app?” · View on HN
petefordeApr 2019Recommends
That's brilliant! Have you had the opportunity to play with Turbolinks 5? It sounds like there will be some crossover with what you have already done, but if you're intellectually curious, you might pick up some good tricks, too. [link] ▶ this video TL5 just happens to pair beautifully with a tiny library called Stimulus, which would be YAF except that it's a) by the same team as TL5 and b) that team is also behind Rails, so there's some claim to legitimate best practices. [link]
in “JQuery 3.4.0 Released” · View on HN
foucFeb 2019Recommends
I'm a rails dev too, last year I was making a mobile web app where I was concerned about frontend, so I started making a SPA in mithril.js and using Rails as the API. Later I abandoned the SPA and went back to rails views, using turbolinks to make it fast. In reality rails + turbolinks is fast enough for most cases, and then I can sprinkle in extra javascript or use SPA on one or two pages as needed. The reason I think it's almost better to avoid SPA + API approach is to keep the codebase simple and easier for one person to maintain. ▶ this video [link]
in “Ask HN: What tech stack would you use to build an open-source Google Keep clone?” · View on HN
thrownaway954Sep 2018Recommends
You achieve the same thing with Rails and Turbolinks. Watch this presentation by Sam Stephenson to see what I mean. ▶ this video
in “Rails, still?” · View on HN
andrei_says_Mar 2018Recommends
Managing complex DOM transformations and avoiding pageloads on every change do carry benefits. Some examples: chat, Facebook-like functionality, complex custom interfaces. There is however a strong tendency to build complex front-end apps because of the trend to do so. This increased complexity results in higher costs without significant benefits (I’m very open to changing my mind). Turbolinks for example is a fantastic backend-agnostic library which eliminates the pageloads in CRUD apps at close to zero development costs and makes the speed almost indistinguishable from SPA implementations. I highly recommend this talk on managing the complexity of basecamp and sharing a codebase between web and native apps. ▶ this video Unless you’re building extremely complex interfaces and if you are able to correct for trendiness you may conclude that a monolithic app with possibly Turbolinks and some front end sugar is the best choice. You can always offload some work to the client once you get to a billion users and servers become too expensive. Until then maybe focus on launching.
in “Ask HN: Benefits of front-end JavaScript frameworks?” · View on HN
thrownaway954Feb 2018Recommends
▶ this video if you haven't seen Sam Stephenson Turbolink talk from RailsConf 2016, you should give it a watch. What they did in a year with a small team is amazing.
in “Ask HN: Best web framework in 2018” · View on HN
pier25Jun 2020Cites it
They could simply solve this with a PWA, no? They already have a web client which is all server rendered with Rails and uses Turbolinks. If I'm not mistaken they also use this approach for the Basecamp iOS app [1]. [1] ▶ this video
in “Apple rejects Hey for second time, threatens removal from App Store” · View on HN
thrownaway954May 2018Cites it
there was a talk at RailsConf 2016 by Sam Stephenson about how Basecamp used Turbolinks to create version 3 of their, an android and ios version in 18 months. ▶ this video
in “Ask HN: How are you building cross-platform (mobile and browser) apps?” · View on HN