Thoughts on DHH interview on Ruby Rogues podcast? Rails, Front end and (briefly) Phoenix discussed

David Heinemeier Hansson (DHH) was interviewed recently on the Ruby Rogues podcast. It’s a long 90-minute interview, but everything I’ve written here is based on just the first part (maybe 30 minutes?), which is all I’ve listened to so far. I was expecting him to be as opinionated, thought-provoking and entertaining as usual, and he didn’t disappoint:

https://programmingpodcasts.com/episode/the-ruby-rogues/rr-342-rails-development-and-more-with-david-heinemeier-hansson

But I’m curious to know where the Elixir/Phoenix community would agree with him, and where we would disagree. I guess what I’m looking for most of all is a robust critique of his views on Rails, Phoenix and front-end stuff.

I have moderate front-end experience, very little Phoenix experience (yet), and no Rails experience, but here’s my view:

At Basecamp they keep the front end as lightweight as possible (Turbolinks and their own micro-framework working in combination). David was quite negative about the popular JavaScript frameworks (and very anti-Redux, which he likened to J2EE, only worse). He claimed if you’re either building an MVP, or trying to make software with as small a team as possible, why on earth would you want to build and maintain a complex back end AND a complex front end? To me, his approach has great potential, especially with Phoenix. If your back-end Phoenix app is already lightning fast, why bother with a heavy front end if you don’t have to?

His views on Rails and Phoenix were much less convincing for me. Here I would have liked to see him sparring with a robust Elixir and Phoenix combatant/advocate like Jose, Chris or Dave Thomas (preferably all three), rather than being listened to rather passively by the interviewers. (Maybe they challenge him more later on in the interview? In their defence, they probably don’t know Phoenix well enough to challenge him properly.)

So firstly, David as the creator of Rails can presumably get more efficiency, maintainability and performance out of Rails than almost anyone else. So most likely Basecamp is about as-highly-an-optimised Rails app as it’s possible to make. He argued that Rails was easily “fast enough”. But if Phoenix is much, much faster than Rails, then doesn’t that mean a Phoenix developer can put off performance optimisations much longer, perhaps indefinitely? That feels like a big win.

Also, I don’t know what “fast enough” really means. To me, a blazing fast web app like Trello is far, far more attractive than any app that doesn’t almost instantly react to a user.

Then David argued that Rails was a more simple choice than Phoenix. He claimed you had to make more choices yourself with Phoenix. Again, I wonder if this is true. I thought one of the big attractions of Phoenix was that there was much less “magic” than in Rails? That you can easily see exactly what’s going on, giving you greater understanding and putting you in a much stronger position. Also, doesn’t FP have a much smaller surface area than OOP?

Anyway, that’s just some of my thoughts on it. I’m curious to hear what the rest of you thought of the interview. He also talks about Basecamp’s hiring philosophy, and presumably lots more in the section I haven’t listened to yet. It’s definitely one of the most interesting interviews I’ve heard in a while.

9 Likes

I’ve just checked out Turbolinks: https://github.com/turbolinks/turbolinks

I’ve never used Basecamp, but is it normally as fast as shown there? Quite impressive if so!

I think it’s important to consider that this is Ruby Rogues. Sure, they’ve had both Chris McCord and José Valim on there previously, I think, but I don’t think it’s really the platform to have this discussion on. Of course the creator of RoR is going to prefer it over everything else. There are lots of things I agree with DHH on and even more that I’d like to hear his opinion on, but which is the best way to develop web pages and services is not one of them, because I know at least what 99% of that answer is going to be.

One of the points that he made was that things are more a’la carte in Phoenix and isn’t that to some extent true? From what I gather, RoR comes with pretty much everything and every choice is made for you, magically. The complaints I’ve heard from people deep in RoR is usually that they have no control over their pipeline because everything is just there with no choice. If that’s even remotely true, doesn’t that sort of tie into other frameworks being “harder”? If you have no choice in anything, the only thing you can really do is accept what it is and get to work. That’s comparatively easy.

DHH wrote an essay called “Rails is omakase” in 2012 (I remember reading it without having any interested in web development but feeling like I respected his thinking, because he applied a principle and that principle has tradeoffs, but it has upsides) in which he stressed how Rails is a tailored experience. Not for everyone else, but for just one very specific experience. It does everything exactly like they’ve decided it should and if you don’t like it, maybe it’s not for you.

The truth is that the Erlang VM allows us to create things that people usually provision a new server for, but in an afternoon, tailored to our exact problem (so that we can drop the ideas that don’t make sense and implement only the parts that matter for the problem). That isn’t “easy”. It’s a much more involved approach than just installing Ruby on Rails, gem install, bundle install for whatever libraries you might need and then using someone else’s complete binary that does everything, 90% of which you didn’t need.

I prefer having the facilities to build things tailored to the problems I have, which is why the combination of lightweight processes, supervision trees and macros feels so great to me. Together with some FFI usage through something like Rustler, I don’t know if there’s any problem you can’t make not only a decent solution to, but a great one.

I honestly have no idea which approach makes the most business sense or what’s more effective in reality. I’m convinced there is a “better” way, but I don’t know how they’d measure it and how impossible it would be for people to accept the results. The truth is that what makes me happy is mostly what I care about because I never got on this train for money or business, and what makes me happy is building systems. I haven’t yet found a more enjoyable and elegant platform for building living systems than Elixir.

7 Likes

i would like to hear uncle bob commenting about elixir and phoenix.
he used ruby before, and he loves functional programming.

and probably martin fowler, about phoenix 1.3,
he wrote great articles on CQRS and DDD.

1 Like

Thanks for the reply. I especially liked reading DHH’s “Rails is omakase” essay. (Really made me laugh too.) And I get that Phoenix is more à la carte. I’m just wondering what the reasoning is for that. Something to do with the difference between FP and OOP? Something to do with BEAM? Other reasons? Is it because a microservices-like architecture is a great fit for Phoenix apps?

My impression is that Phoenix is currently in the process of moving further away from a more Rails-like convention-over-configuration approach, and that people like Dave Thomas (and Johnny from the Elixir Fountain podcast?) would like to see it go further in that direction. What’s their reasoning?

I guess part of my wondering is that – as a relative newcomer to Elixir and Phoenix – I would really appreciate travelling along a well-beaten path, i.e. one with lots of educational resources supporting it, and a path that would help me avoid making a lot of mistakes along the way.

Now if I decide to get stuck into the more à la carte Phoenix rather than Rails, is it realistic to hope that I can build a fairly decent Phoenix web app at the first attempt, if I stick to all the Phoenix conventions and don’t attempt to stray from the most common path? Am I more likely to run into problems than I would building with Rails, with its more enforced architecture?

I have lots of questions, as you can see. :slight_smile:

I found the Chris McCord interview on Ruby Rogues you mentioned. Thanks for the tip-off:

https://devchat.tv/ruby-rogues/253-rr-phoenix-and-rails-with-chris-mccord

(I added it to the podcasts thread already.)

It’s a great interview covering how similar/different Rails and Phoenix are, and some really interesting stuff about the actor model and the origins of OOP. It’s from March 2016 but feels very relevant, at least to me. And it’s an excellent counterweight to the DHH interview.

Is Ruby Rogues worth listening to again? I gave up on it after all the kerfufulle a couple years ago.

That’s when I stopped listening as well. :wink:

6 Likes

I would honestly like to know where this impression is coming from. Phoenix by default says how you talk to the database, how you write your tests, how you do websockets+presence and comes with an asset pipeline too. Sure, we don’t come with caching layers and with a background job toolkit but you are way less likely to need those in Phoenix anyway, which is a good thing.

10 Likes

I like DHH. He and Matz are my first two programming heroes - because if it wasn’t for Ruby and Rails I wouldn’t have got into programming (I still love Ruby and Rails!)

Having said that, I don’t think DHH is the right person to be listening to about Phoenix (I haven’t heard the podcast btw). Some time ago I saw him tweet something along the lines of “Rails is not your application, if it’s a web app, like ______ it is!” - which I assume was a pot shot at “Phoenix is not your application” and so to me, just showed his ignorance and that he didn’t really know what he was talking about.

Now, if he’d taken the time to learn Phoenix (perhaps by doing something like PragDave’s course :101:) I’d be more inclined to listen to his views about it :lol:

Also remember, he’s hardly going to sell you Phoenix when he’s the creator of Rails. Listen to him to what he’s got to say about Ruby and Rails, but when it comes to anything that is competition… it might be better to take what he says with a pinch of salt.

Oh I forgot to say - I do agree with him to some degree about JS; use it as little as possible!! :044:

8 Likes

Basecamp’s JS library they were talking about just got released yesterday.

7 Likes

I wonder the same. To me Phoenix also is a very opinionated framework as well, only with less coupled components and more explicit about dependencies. After 10 years work almost exclusively in Rails projects, I feel in home when working with Phoenix, all good thinks of Rails are there, and more other wonderful niceties only possible by Erlang/BEAM.

3 Likes

To me the biggest difference in the “batteries included” experience of Rails and Phoenix is in the way that is done. With Rails, the integration is done directly in core Rails - it’s enough to include rails and you get everything.
With Phoenix, this integration is done by generating code in the application - phoenix itself does not depend on various elements, yet when you generate the application you get everything you’re going to need.

Some examples of this would be the database framework (AR vs Ecto), default middleware stack (implicit in Rails and explicit in Phoenix in the generated Endpoint module), the HTML part being directly included or provided as a separate (but included by default) package, etc.

I like the Phoenix approach better - on one hand this allows providing similar out-of-the-box solution, yet on the other hand, if you want to customize something you can just modify the code in your application - no need to monkey patch things around. But yeah, I don’t think I would describe this approach as “a la carte” in the way that many nodejs frameworks are “a la carte”, where you need to build the whole stack yourself. Phoenix provides defaults, it’s just that instead of being deep inside phoenix, they are generated in the target application.

16 Likes

Great definition!

1 Like

That came straight from DHH in the interview. In the segment from 21-25 minutes he actually says you have to go “way more a la carte” with Phoenix. I’m too much of a Phoenix beginner to have any useful opinion of my own yet, but I’m really pleased to see his view has been robustly opposed by you and others on this thread.

2 Likes

Ah! Now I see you beat me to the “pinch of salt” gag (to go with DHH’s “a la carte” comment). :laughing:

I feel like I agree with DHH about JS too. Which is kind of sad, given that I’m currently a front-end developer. :anguished: I guess it gives me a ton of incentive to learn Phoenix as fast as possible. :blush:

But maybe that should be the subject of another thread? “Ideas on how to use the minimum amount of JS in your Phoenix app”?

4 Likes

Sure go for it - although maybe check out the threads in this section first in case they cover the topic - we have lots and lots of threads about all the different approaches for developing on the front end :003:

1 Like

I’m in the same position. I love JS, but I don’t get why a large, or at least vocal, portion of the community tries to shoehorn everything into SPA’s that add a huge amount of complexity to their stacks.

4 Likes

I wonder if Turbolinks would be a good fit for Phoenix? I’m curious how it interoperates with React, and how it works for building iPhone/Android native apps. Can anyone relate some real-world experience?

There are threads and blog posts about that on the forum arleady
Edit: this is a reply about Tutbolinks to @AndyL

That’s true. I’ll check back through those and see if they cover the topic already.