Live data from Hacker News

We fell out of love with Next.js and back in love with Ruby on Rails

hardcover.app

331–340 of 533 posts

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#331
I followed the same journey but was unimpressed by Rails attempt at modernization with Hotwire. Decided to give Elixir + Phoenix a try and immediately fell in love. Just like I had with rails years ago. I highly recommend people to check it out, liveview is a game changer for building modern web apps without the complexity of JS, and without the baggage of using Rails to do it. And performance is mind blowing.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#332
post #133

Earlier quoted context omitted.

If your axiom is ‘JS is fine’ then yeah. It isn’t, though. TS is much closer to ‘fine’, but still can’t avoid some dumb JS decisions.

I've been a professional programmer for ~20 years and worked in a variety of languages on a variety of different types of projects, and Typescript with Bun is mostly just fine. It lacks some low level primitives I'd like to have available for certain projects (e.g. Go channels), and the FFI interface isn't as nice as I'd like, but it's basically serviceable for for a very broad range of problems. You should still kno…

I agree, nowadays working on mostly TS backend with some parts in JS written before async/await was introduced and I’m inclined to say TS is better than Python at most things bakcendy. I’m missing sqlalchemy and a sane numerical tower pretty much.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#333

Earlier quoted context omitted.

JS/TS is fine. Why switch back and forth between languages and frameworks and data models and…

What is 0.1 + 0.2 in JavaScript. I'll give you a hint, it's not 0.3. Is that fine?

https://en.m.wikipedia.org/wiki/IEEE_754

To answer your question directly - yes, it’s fine, it’s actually expected behavior.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#334

Earlier quoted context omitted.

I think the confession that "Figma‑ or Gmail‑class apps still benefit from heavy client logic" is a telling one, and the reason I politely disagree with your thinking is that it relies in the app staying small forever. But that's not what happens. Apps grow and grow and grow. I've heard people say they just want "Pure JS" with no frameworks at all because frameworks are too complex, for their [currently] small app. S…

Yeah, wouldn't want to rewrite the frontend in a new framework. Good thing the SPA frameworks are so stable and solid; when I choose one I will surely be able to use it for a good, oh, 3 to 6 months.

React hooks came out in 2019. That's 6 years ago. And they are still the way to write client components. Unless you're moving everything to server components (which you most likely can't and shouldn't anyways) you would be writing the same react code for 6 years.

This is just intentional ignorance.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#335

I followed the same journey but was unimpressed by Rails attempt at modernization with Hotwire. Decided to give Elixir + Phoenix a try and immediately fell in love. Just like I had with rails years ago. I highly recommend people to check it out, liveview is a game changer for building modern web apps without the complexity of JS, and without the baggage of using Rails to do it. And performance is mind blowing.

Funnily enough, a JS library that I often use with Elixir, Phoenix and Live View is StimulusJS (which is part of Hotwire) I also have written a hacky stimulus controller to integrate it with Phoenix hooks for full integration.

Not sure about Rails, haven't used it in more than a decade, but NextJS was a major contributor to massive burnout. Of one thing I'm certain: Phoenix is my last web framework. I love it to bits, and I hope to retire before it stops being cool.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#336
post #328

Earlier quoted context omitted.

People outside tech just get installation instructions and do not care if it’s app store or something else. This is how sanctioned Russian banks continue to serve their customers via apps, when they cannot get into app store. The number of users of PWA is probably on the scale of millions.

I had no idea! Cool to learn. It definitely makes complete sense in that scenario, but remains a very niche usecase where people have no other option. >People outside tech just get installation instructions People outside of tech don't need instructions to install non-PWA, store apps. So all this does to me is reinforce that no one is installing PWAs outside of niche scenarios where 1. people basically have to use th…

> People outside of tech don't need instructions to install non-PWA, store apps.

Depends on age and tech awareness. Many still do, when they cannot rely on a family member to do it for them. Overall installing PWA is no more complicated than getting something from a store.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#337
post #297
post #146

Earlier quoted context omitted.

> Especially if you're working on something that requires interaction with the page that you will be repeating over and over again. That’s honestly not that many things IRL. If you look at all the things you build only a minority actual demand high interactivity, or highly custom JS. Otherwise existing UI libraries cover the bulk of what people actually need to do on the internet (ie, not just whatever overly fancy o…

> Rails has a library that will refresh the page when files change without a full reload What if you have a modal opened with some state? Or a form filled with data? Or some multi-selection in a list of items that triggers a menu of actions on those items? Etc. And it's true Vite can't always do HMR but it's still better than the alternative.

> What if you have a modal opened with some state?

Stimulus controllers can store state.

> Or a form filled with data?

Again, you can either use a Stimulus controller, or you can just render the data into the form response, depending on the situation.

> Or some multi-selection in a list of items that triggers a menu of actions on those items?

So, submenus? Again, you can either do it in a Stimulus controller (you can even trivially do things like provide a new submenu on the fly via Turbo), or you can pre-render the entire menu tree server-side and update just the portion that changes.

None of these are complex examples.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#338

Earlier quoted context omitted.

We currently have two major apps, One in typescript and one in rails. I have to hire devs for both, and I have not experienced it being any more difficult to find a rails developer or a node/typescript developer. If anything, I think finding a rails developer with relevant experience is even easier because the stack is so much more standardized. With people with node experience, there is a huge chance that they won't…

I really hope that Elixir / Phoenix will gain more traction. It is very easy to write a server with it, hosting and deploying is painless, upgrading it (so far) has been painless, linting and debugging has been a breeze. If you're coming from Ruby, then learning Elixir requires a small mental adjustment (from Object Oriented to Functional). Once you get over that hump, programming in Elixir is just as much fun as Rub…

Agree. The one thing LiveView is missing is 1:1 Tailwind and Shadcn libraries that are more or less interchangeable with the huge ecosystem around them. I just want to be able to pull in popular components for the wider dev community. There’s some commendable attempts at UI libraries for LiveView, but they are too opinionated stylistically or just slightly off mainline shadcn. I don’t really want to hang my hat on this type of thing and later get burnt when it’s no longer maintained (which is more often the case). Also, the AI tooling for Elixir is greatly lagging which is disappointing as that language is particularly well suited for it.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#339
post #157

Earlier quoted context omitted.

Every webapp built with something other than GraphQL ends up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL. Yes, a book tracking app absolutely needs GraphQL. Do you need a separate frontend framework? No, probably not, and that's exactly the problem that Next solves - write your backend and frontend in the same place. Do you need a complicated build process? No. You want yo…

GraphQL is the new mongodb. This fancy new thing that people want to use and makes no sense in reality and just causes more problems than it solves. It solves a very specific problem that makes sense at Facebook. It makes 0 sense for companies that have a web app or web and mobile app. And nothing else. Anyone deciding to use graphql is making a dumb decision.

Facebook does not really use GraphQL in their public apps. The apps call named queries defined server side, so GraphQL is just a glorified RPC mechanism, not a query language.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#340
post #150

Earlier quoted context omitted.

The biggest downfall in my experience has been it can be a massive pain to find out where a method is defined in a huge codebase, especially with all the crazy ways in which one can declare methods. You can spend a non-trivial amount of time just trying to find the definition for a method.

Sorry if this sounds like a stupid question but - is there no "Go to definition" command in an IDE that can help with something like this? I mean, I understand that there is, but it doesn't work well with Ruby. Why?

Other people have mentioned "dynamic typing" as being the reason for this, but that's not actually true. The real reason is two Ruby features: `define_method` and `method_missing`.

If you have a class `Customer` with a field `roles` that is an array of strings, you can write code like this

  class Customer
    ROLES = ["superadmin", "admin", "user"]

    ROLES.each do |role|
      define_method("is_#{role}?") do
        roles.include?(role)
      end
    end
  end
In this case, I am dynamically defining 3 methods `is_superadmin?` `is_admin?` and `is_user?`. This code runs when the class is loaded by the Ruby interpreter. If you were just freshly introduced into this codebase, and you saw code using the `is_superadmin?` method, you would have no way of knowing where it's defined by simply grepping. You'd have to really dig into the code - which could be more complicated by the fact that this might not even be happening in the Customer class. It could happen in a module that the Customer class includes/extends.

The other feature is `method_missing`. Here's the same result achieved by using that instead of define_method:

  class Customer
    ROLES = ["superadmin", "admin", "user"]

    def method_missing(method_name, *args)
      if method_name.to_s =~ /^is_(\w+)\?$/ && ROLES.include?($1)
        roles.include?($1)
      else
        super
      end
    end
  end
Now what's happening is that if you try to call a method that isn't explicitly defined using `def` or the other `define_method` approach, then as a last resort before raising an error, Ruby checks "method_missing" - you can write code there to handle the situation.

These 2 features combined with modules are the reason why "Go to Definition" can be so tricky.

Personally, I avoid both define_method and method_missing in my actual code since they're almost never worth the tech debt. I have been developing in Rails happily for 15+ years and only had one or two occasions where I felt they were justified and the best approach, and that code was heavily sprinkled with comments and documentation.

Post reply on HN