Confreaks
6 HN recommenders · recommended in 12 months, 2017–2020
37:37 · 61K views · May 26, 2016
Sam Stephenson's RailsConf 2016 talk on Turbolinks 5, showing how small teams can ship fast Rails apps in the browser and hybrid iOS and Android apps sharing one set of web views.
Repeatedly urged on people choosing a stack, as a case against heavy SPA complexity and for shared web and native code.
15 comments from Hacker News
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
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
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.
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.
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