Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

hardcover.app

Post reply on HN
Print view View original

191–200 of 533 posts

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

#191

Post by snkzxbs »

qq99 wrote: post #150
bckr wrote: post #98

I keep hearing good things about Rails. What are the downsides, other than learning a new language and framework?

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?

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

#192

Post by twodave »

mattgreenrocks wrote: post #177
twodave wrote: post #22

Earlier quoted context omitted.

Probably something like ASP.NET MVC with C#

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.

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

#193

Post by moralestapia »

grey-area wrote: post #93
moralestapia wrote: post #69

Earlier quoted context omitted.

>Websites. Wait, is SSR a thing outside the context of websites?

No, that's the primary use case. Works pretty well and has done since 1991. The majority of websites use SSR.

Weird.

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

#194

Post by vinnymac »

gameman144 wrote: post #59
vinnymac wrote: post #28

Earlier quoted context omitted.

You misunderstand me, I’m not proposing we get rid of JavaScript. I am saying that allowing for JavaScript to be dynamically downloaded and executed after the page is ready was a mistake. You can build your Google docs, your maps, and figmas. You don’t need JS to be sent after the page is ready to do so.

Wouldn't this make users pay for every possible feature they could ever use on a given site? For instance, in Google Maps I might use Street View 1% of the time, and the script for it is pretty bulky. In your ideal world, would I have to preload the Street View handling scripts whenever I loaded up Google Maps at all ?

If you’re asking if it would incentivize us to be more careful when introducing additional interactive functionality on a page, and how that functionality impacted performance and page speed, I expect it would.

Thinking about how the web was designed today, isn’t necessarily good when considering how it could work best tomorrow.

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

#195

Post by const_cast »

procaryote wrote: post #70
stavros wrote: post #52

Earlier quoted context omitted.

I disagree, the problem with an SPA is that now you have two places where you manage state (the backend and the frontend). That gives you much more opportunity for the two places to disagree, and now you have bugs.

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.

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

#196

Post by vinnymac »

bartread wrote: post #46
vinnymac wrote: post #16

Earlier quoted context omitted.

I believe allowing the dynamic loading of scripts was a mistake, and we should undo support for it. So were iframes. Everything after ready should have been static content.

That ship has sailed. The web is nowadays an application delivery platform and there is no going back. Dynamic loading, iframes, and a whole host of other features all have their uses within that context - the issue is really their misuse and overuse.

I don’t disagree at all mind you. I’ve been developing websites for 25 years or so now. I just think we could have done better with the standard.

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

#197

Post by const_cast »

nine_k wrote: post #75
stavros wrote: post #52

Earlier quoted context omitted.

I disagree, the problem with an SPA is that now you have two places where you manage state (the backend and the frontend). That gives you much more opportunity for the two places to disagree, and now you have bugs.

Unless you can guarantee RTT under 100ms, you have to manage some state on client side, else your UI will feel sluggish.

It’s trivial to achieve under 100ms in the US with even just one server.

Most companies aren’t international.

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

#198

Post by vinnymac »

stavros wrote: post #55
vinnymac wrote: post #28

Earlier quoted context omitted.

You misunderstand me, I’m not proposing we get rid of JavaScript. I am saying that allowing for JavaScript to be dynamically downloaded and executed after the page is ready was a mistake. You can build your Google docs, your maps, and figmas. You don’t need JS to be sent after the page is ready to do so.

How are you going to stop it, when you already are running JS? I can write a VM in JS that I can load, then I can load static assets after the page has loaded, and execute them in the VM. How would you block that?

I am thinking about a different time, when JS did less, and these decisions were being made.

Today, what you are saying is definitely a concern, but all APIs are abused beyond their intended uses. That isn’t to say we shouldn’t continue to design good ones that lead users in the intended direction.

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

#199

Post by const_cast »

chipsrafferty wrote: post #162
baq wrote: 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.

It is fine, though.

No, it’s footgunny and riddled with bugs. Most JS barely works and edge cases just aren’t addressed.

I’ve seen undefined make it all the way to the backend and get persisted in the DB. As a string.

JS as a language just isn’t robust enough and it requires a level of defensive programming that’s inconvenient at best and a productivity sink at worst. Much like C++, it’s doable, but things are bound to slip through the cracks. I would actually say overall C++ is much more reasonable.

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

#200

Post by hijp »

dismalaf wrote: post #68
hijp wrote: post #33

I think if Rails had focused on giving real first party support to interoperability with whatever frontend framework you brought to the table it would be so much bigger right now. They put a lot of work into Hotwire but I just want to use React, and I'm sure others want to use what they're familiar with.

Rails can be API only and use any frontend you want. Hotwire is the default and they develop it because DHH wants to, but they're not putting up any barriers to you using whatever you want. Also, DHH doesn't seem to care about how big it is. His stated goal is for it to forever be a framework that's usable by a single dev.

Yeah but I wish in an alternate reality DHH chose a different route. If you go API only then you lose half of what makes rails great. It would be sick if you could render React/Vue/Svelte easily in your haml views and not have to have a js repo then figure out jwts and auth.

Dunno I loved rails, built monoliths, built api only, but when I tried sprinkling a bit of react in my views (say you only need a little bit of interaction, or want to use a react date picker) then theres all these sharp edges.

The reason I want it to be bigger is that user base helps the single dev, with help resources, up to date gems, and jobs.

Post reply on HN