Live data from Hacker News

Rails for everything

literallythevoid.com

241–250 of 250 posts

Re: Rails for everything

#241

Earlier quoted context omitted.

I’ve literally pointed out real issues that you have to slog through when you start with Spring.

There are plenty of Spring Boot starter dependencies that you can pull in to do some of the things you're mentioning. Can you say "install spring"? Yeah, I think so, there's the Initializer that comes in different modalities. Migrations, you ask? Not sure what kind, but Flyway or Liquibase are some popular dependencies, which are natively supported by Spring Boot. Again, it's all a breeze, as I'm sure Rails is too. I…

My point was that Rails and Spring prioritize different things. And while you can end up with roughly equal result with both, the path can be drastically different. Never wanted to suggest that whoever uses Spring over Rails is an idiot and vice versa. Cheers.

Re: Rails for everything

#242
post #240

Earlier quoted context omitted.

Agreed on the tooling, I won't be adopting Elixir until the IntelliJ tooling is there. It's just too crippling switching to another IDE.

what exactly is present in intellij that isn't available in vscode / neovim with lsp / newer emacs? I ask because, I use(d) intellij for java and maybe i'm not using most of its capabilities or they're hidden away in plain sight, but i haven't noticed anything special aside from the slow ui.

For me there are two axes that are lacking (based on Scala and Elixir usage):

1. The feature set is just far weaker. If an LSP implementation and the client both hit 100% coverage, then you might end up having the same refactoring, code generation, follow definition/load docs/infer typing support. But of course the Elixir LSP matrix shows that basically none of the LSPs offer a complete feature set and you basically get to pick which features are missing. What about debugger support?

2. This could be viewed in some ways as a recapitulation of point one, but I actually appreciate the Integrated in Integrated Development Environment. I very much dislike when adopting a new technology having to cobble together a disparate number of tools to create a good editor experience, especially in a time where as a novice I'm actually not at all qualified to understand what a good editor experience would be! I actually call this the Clojure Problem, which is that many Clojure devs decide they have to learn emacs or a complicated fireplace.vim setup in addition to Clojure and wind up learning neither.

Regarding speed, don't get me wrong, I empathize with complaints about it and whenever I'm doing C# work for one of our services I'm reminded of just how slow developing Scala can be in particular. But I don't think of LSP approaches as fast, either. Perhaps they are async and don't block the UI, but now I'm just sitting here typing and getting constantly out of date feedback from the editor as it and the LSP catch up to whatever text has been entered.

Re: Rails for everything

#243
post #47

Rails is awesome, and so is Django. I’ve built mission-critical apps in both and still do with Python. That said, I’d love to switch to Go for building large monoliths since it has a tighter type system and better concurrency constructs. The problem is, Go community has never really filled that gap. I love Go, but the whole "Go doesn’t need a Rails or Django" mindset is part of why it hasn’t taken off in this space.…

Ruby has Sorbet if you want to add typing. And better concurrency constructs for Ruby are in the final stages of being backed with Fibers. For example, Falcon is the new Ruby web server that’s built with Fibers. It’s not quite ready to replace Puma but Fibers are coming along.

Re: Rails for everything

#244
post #185

There’s a thing here that seems to separate people like the article author from…well, from me. They just have a deep, deep affection for Ruby and Rails. It makes everything great, and every new surprise is like discovering that your new special friend also knows how to juggle! And speaks Cantonese! How cool is that?? Oh, they’re afraid of spiders? How cute. But did you know they went to Ecuador in college? There’s a…

Very accurate. Every programming language or framework has this kind of emotional attachment of enthusiastic users, to a certain extent. But nothing quite like Rails. Its in the culture.

I find this fascinating as well. And I think it’s because part of the ruby & rails cultures are to deliberate cultivate delightful touches in the language & framework. This creates a positive feedback loop that has kept the “honeymoon phase” alive much longer (at least for me) than many other technologies I’ve fallen in love with.

Re: Rails for everything

#245

Earlier quoted context omitted.

> The other glaring omission being an inbuilt admin interface -- which may have been added after I moved on. with scaffolding and other rails generators with custom templates is that really a big asset? might not look amazing out of the box but you can find css templates easy enough too. maybe they should make an admin generator but rails is king of crud and if you need it ootb you can use one of the many gems.

I think so. You could also make that same argument about the new authentication feature, ActionStorage/Jobs/whatever. Yes, of course, _there's a gem for that_ but after having used Django, it's really very nice to have those features included and not have to spend any time thinking/arguing about which Gem to choose and remembering/endeavoring to keep that Gem patched, etc.

I agree this is something missing. I wish the framework had it. I bookmarked this to try out soon: https://github.com/igorkasyanchuk/rails_db

I know there are a few other projects like this which I’ve seen over the years, but I’ve yet to truly investigate any.

Re: Rails for everything

#246

The essential convention over configuration ideas still prevail when you want to pile on functionality quickly and without boilerplate.

I was going to write a bite more about convention over configuration in regards to AI, but it didn’t feel super tight. I think that the doctrine of convention over configuration leads to content that is much more legible to LLMs in training. I find querying Claude for Rails issues to be really helpful. I suspect would be very helpful to a novice.

I too find Claude for Rails to be really helpful, except for some of the newer features in Rails 8 for which there is a lot less documentation. I use Claude within Cursor and it has the ability to at-mention documentation so any time I run into this I just follow up with “Can you please double check the @rails8 docs and try again.” (likewise for @stimulus and @hotwire docs)

Re: Rails for everything

#247
post #182

Anyone know any good hosting options for little personal, experimental Rails apps that might not go anywhere (i.e. that I might well lose interest in but forget to cancel)? I’ve always liked Vercel’s approach for these kind of side-projects, as I don’t have to worry about cancelling anything if I stop using it. But I guess that is a perk of it being serverless, which precludes Rails. What’s the next best option, some…

I just use Fly ( http://fly.io ) for toys... and it works pretty well. Have not tested at scale / reliability for a real thing.

Render is another good option. I too prefer Fly for my toy apps, but it has a little bit more of a learning curve than Render.

Re: Rails for everything

#248
post #142
post #133

for auth - instead of devise or the rails 8 auth - you can also opt for authentication-zero. what's hardly ever mentioned is how great hotwire is. it takes time getting used to, documentation is sparse but oh man oh man - hotwire is nice. you get to skip a majority of spa shenanigans.

I am really struggling to get hotwire running to be honest. I now just postponed implementing it till after the launch. Any good ways of getting up to speed on hotwire and debugging it?

It’s really a different mindset shift. In react, you think about components — updating components and replacing one component with a new component. But in hotwire, you think about pages. First implement everything as full page transitions. Only after you get all your functionality working with full page transitions, then you do a pass back through it and ask: how can I minimize the amount that changed between the transition from this page to that page? “Oh, just wrap this part in a turbo frame or have this one controller action reply with a turbo stream in this one case.”

I don’t know if that’s helpful, but realizing that I needed to shift from thinking about components to pages was the a-ha when Hotwire all started making sense.

Re: Rails for everything

#249
post #99

Title says "everything" but author didn't mention Android/iOS apps.

https://native.hotwired.dev/ — I’m curious how well this works

And this just landed too: https://pragprog.com/titles/jmnative/hotwire-native-for-rail...

I’ve done one app with Hotwire Native and it’s a pretty interesting solution. However, just like a truly complex and dynamic web UI can reach a level of polish with React that is hard with Hotwire, a truly complex and dynamic mobile UI can reach a level of polish with Swift/Kotlin that is truly hard with Hotwire. It makes the vast majority of experiences much faster to build, but certain complex experiences are hard to get polished.

However, Hotwire (web & native) can get you almost the full way there and you can just drop a React/Swift/Kotlin view in for parts of the app where you need it.

Re: Rails for everything

#250
post #92

Earlier quoted context omitted.

When do you switch from Flask/Express/Sinatra/Gradio/Hono to Rails?

When you realize that all you need to add to X to make it great is a crappy reimplementation of all of the things that ship with Rails before you can start building your app.

That could be day -1...
Post reply on HN