351–360 of 533 posts
What's the closest thing to Rails in a language with a sound static type system?
Exposed is a solid-enough ORM for my tastes, Ktor is easy-to-use and clean; and Kotlin gives me a type system and fluent / Ruby-style method chaining.
Earlier quoted context omitted.
Yep. It’s ASP.NET. Arguably ASP.NET’s ORM is better than ActiveRecord even. With Blazor SSR you can use components on the server. IMO Blazor SSR needs a bit more time to bake and not reload is a huge mess currently. But the stack is great and will probably be undervalued simply due to the fact it is in C#.
It’s really more so because it’s Microsoft. And this is a shame, since C# has been IMO one of the great languages for at least 5 years now (C# 9/.NET 5), and has only gotten better since then.
I keep hearing good things about Rails. What are the downsides, other than learning a new language and framework?
If you "screw up and succeed" by gaining many users/customers, any Ruby or Python framework provides orders of magnitude fewer requests-per-second on the same VM or hardware than a comparable solution deployed with node.js, go, Java, C# (Including DotNet Core on Linux), or rust. And this will quickly ballon your cloud compute costs to keep up.
Earlier quoted context omitted.
You had to manage state on the frontend even before spa though, if you wanted anything but the most basic experience.
No you really don’t. I’ve worked on exceptionally complex legacy applications with essentially no state in the front end. At most, you’re looking at query parameters. You just make everything a full page reload and you’re good to go.
I remember reading their blog post about how moving from pages router to app router in Next.js helped their SEO last year. This time they are moving from Next to React+Inertia.js because of growing bills from Vercel even though deploying the same app on your own VPS instead of relying on cloud provider would probably solve the issue. Nonetheless, I still don't understand their yearn for complexity - does book trackin…
As far as I understand hardcover was really created because goodreads discontinued their api and the team at hardcover saw how many people relied on it for a myriad of different niche projects.
If hardcover was just a replacement for the goodreads platform, then I'd agree with you. But it's not. It's there for the api, with the platform around it intended as a way to ensure free access of the api for everyone. And from that pov choosing GraphQL makes a lot of sense imo. You can't anticipate all the cool and different things people might want to do with it, so they chose the most flexible api spec they could.
On the other hand, I'm not sure if a complete rails rewrite was the right choice. The App was slow and sluggish beforehand, with frequent ui glitches and it still has those same issues. Their dev blog claims significant performance increases, but as a user I haven't noticed a big difference. Sticking with next.js, but moving to a selfhosted instance and then iteratively working on performance improvements would've been (imho) the better way forward. I see no reason why next.js somehow fundamentally couldn't do what they're trying to do, but rails can. Especially with just 30k users (which tbc is a great achievement, just not impressive from a technical standpoint).
Earlier quoted context omitted.
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)…
See here:
https://github.com/heartcombo/devise/blob/main/lib/devise/co...
def self.define_helpers(mapping) #:nodoc:
mapping = mapping.name
class_eval It hurts my soul.
I truly wonder what people do when they want JS full stack both frontend an backend especially with a DB involved. ORM situation looks pretty fragmented or you write pure sql. And then you still have to decide on the backend. Going raw with express? Next.js, well known, but with a questionable agenda (, Remix, Astro, TanStack, and so on. It's a mess, because you always have to recalibrate and re-evaluate what to use.…
Yep. The ORM situation in JS is not great. There’s no one go-to, and it seems like the question often prompts a patronizing response about how ORMs aren't really necessary. Kysely is really great, but it’s not an ORM. My take: the JS ecosystem tends to avoid abstraction for whatever reason. Example: they don’t believe that their web framework should transparently validate that the form submission has the correct shap…
Earlier quoted context omitted.
What CI provider?
Was using TeamCity, then dropped some moving to another system. The broader point was basically that the Rails UI integration tests took a very long time, and required the whole system up, and we had a pretty large team constantly pushing changes. While not 100% unique to Rails, it was exacerbated by RoR conventions. We moved much of the UI to a few Next.js apps where the tests were extremely fast and easy to run loc…
How many integration tests do you have? I generally only test a few core flows and then leave the rest to controller/request tests.
Just my opinion but, server‑side rendering never really went away, but the web is finally remembering why it was the default. First paint and SEO are still better when markup comes from the server, which is why frameworks as different as Rails + Turbo, HTMX, Phoenix LiveView, and React Server Components all make SSR the baseline. Those projects have shown that most dashboards and CRUD apps don’t need a client router,…
Having a server provide an island or rendering framework for your site can be more complex than an SPA with static assets and nginx. You still have to deal with all the tooling you are talking about, right? You’ve just moved the goalpost to the BE. And just like the specific use cases you mentioned for client routing I can also argue that many sites don’t care about SEO or first paint so those are non features. So ho…
> You still have to deal with all the tooling you are talking about, right? You’ve just moved the goalpost to the BE.
Now you're dealing with 2 sets of tooling instead of 1.
> And just like the specific use cases you mentioned for client routing I can also argue that many sites don’t care about SEO or first paint so those are non features.
There is no app which would not care about first paint. It's literally the first part of any user experience.
> So honestly I would argue for SPA over a server framework as it can dramatically reduce complexity. I think this is especially true when you must have an API because of multiple clients.
So SEO and first paint are not necessary features, but an API for multiple clients is? Most apps I've worked with for over 15 years of web dev never needed to have an API.
> I think the DX is significantly better as well with fast reload where I don’t have to reload the page to see my changes.
With backend apps the reload IS fast. SPA's have to invent tooling like fast reload and optimistic updates to solve problems they created. With server apps, you just don't have these problems in the first place.
Earlier quoted context omitted.
No you really don’t. I’ve worked on exceptionally complex legacy applications with essentially no state in the front end. At most, you’re looking at query parameters. You just make everything a full page reload and you’re good to go.
So you make incrementing a counter a full page reload?