We fell out of love with Next.js and back in love with Ruby on Rails
331–340 of 533 posts
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#332Earlier 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…
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#333Earlier 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?
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
#334Earlier 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.
This is just intentional ignorance.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#335I 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.
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
#336Earlier 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…
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
#337Earlier 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.
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
#338Earlier 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…
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#339Earlier 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.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#340Earlier 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?
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.