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

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 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.

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.

People are jumping into nextjs because react is pushing it hard even tho it’s a worse product and questionable motives.

As somebody with an expert level knowledge with MVC frameworks like Ruby on Rails and Phoenix Framework, etc., and an experience building large-scale enterprise-grade apps using simpler technologies like jQuery, StimulusJS and plain old JavaScript on the front end with a little bit of React thrown in here and there, I found Development cycles to be much faster with these simpler stacks overall. The complexity of the code base never ended up turning to be a liability that it creates significant overhead and bottlenecks for new engineers joining the team to jump in and understand the end-to-end workflows of things.

Fast forward to what I am doing today in my new job. We have a pretty complex setup using Redwoodjs along with several layers of abstraction with Graphql (which I approve of) and a ton of packages and modules tied together on the front end with react, storybook, etc. and some things I am not even sure why they are there. I see new engineers joining our team and banging their heads to make even the smallest of changes and to implement new features and having to make code changes at multiple different places. I find myself doing similar things as well from time to time - and I always can't help but think about the complexity that I used to deal with when working with these MVC frameworks and how ridiculously easy it was to just throw logic in a controller and a service layer and and the view templates for the UI stuff. It all fit in so easily and shipping features was super simple and quick.

I wouldn't discount react as a framework but I am also starting to some cracks caused by using TypeScript on the backend. This entire Javascript world seems to be a mess you don't want to mess with. This is probably just me with an opinion, but but using Turbo, Stimulus and and sprinkles of LiveView got me really really far very quickly.

> Of course, Figma‑ or Gmail‑class apps still benefit from heavy client logic, so the emerging pattern is “HTML by default, JS only where it buys you something.” Think islands, not full SPAs.

Figma is written in C++ to webasm.

This is not my field, but my mental model was that server side mostly died when mobile apps started being mainstream, and treating the web app as another frontend for your common api was considered the best way to handle client diversity.

Was this not the case? And if so, what has fundamentally changed?

> Every line of client JS brings build tooling, npm audit noise, and another supply chain risk.

IME this is backwards. All that stuff is a one-off fixed cost, it's the same whether you have 10 lines of JS or 10,000. And sooner or later you're going to need those 10 lines of JS, and then you'll be better off if you'd written the whole thing in JS to start with rather than whatever other pieces of technology you're using in addition.

For me it definitely never went away, as I mostly done Java (JSP, JSF, Spring), or ASP.NET (Web Forms, MVC), with sprinkles of JavaScript islands.

And what makes me like Next.js, besides the SaaS SDKs that give me no other framework choice, it is being quite similar to those experiences.

I don't know.

Many interactions are simply better delivered from the client. Heck some can only be exclusively delivered from the client (eg: image uploading, drag and drop, etc).

With HTMX, LiveViews, etc there will be challenges integrating server and client code... plus the mess of having multiple strategies handling different parts of the UI.

> they just need partial HTML swaps.

Been a web dev for over a decade, and I still use plain JS. I have somehow managed to avoid learning all the SPAs and hyped JS frameworks. I used HTMX for once project, but I prefer plain JS still.

I was a JQuery fan back in the day, but plain JS is nothing to scoff at these days. You are right though, in my experiences at least, I do not need anything I write to all happen on a single page, and I am typically just updating something a chunk at a time. A couple of event listeners and some async HTTP requests can accomplish more than I think a lot of people realize.

However, if I am being honest, I must admit one downfall. Any moderately complex logic or large project can mud-ball rather quickly -- one must be well organized and diligent.

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 your build process to be just "run npm". And that's what something like Next gets you.

"Monolithic RoR app with HTML templates on VPS" would introduce more problems than it solves. If Next-style frameworks had come first, you would be posting about how RoR is a solution in search of a problem that solves nothing and just overcomplicates everything. And you'd be right.

What did you move to? We've been using NextJS as a frontend with somehelpful server-side/api handling, but the backend is done in Django. We are basically just using ReactJS with the convenience of NextJS (like file based routing)

> put text on screen

I get where you're coming from but that's actually quite a bit of an oversimplification even for many web apps outside of the 1% for which a lot of modern web development solutions and frameworks seem to have been created.

For one thing it doesn't take any account of input. When someone draws something with Figma or writes something in Google Docs or buys something from Amazon - or indeed any online shop at whatever scale - or gets a set of insurance quotes from a comparison site or amends something in an employee's HR record or whatever it may be the user's input is a crucial part of the system and its behaviour.

For another, we're not just putting text on the screen: we're putting data on the screen. And whilst data can always be rendered as text (even if not very readably or comprehensibly), depending on what it represents, it can often be more meaningfully rendered graphically.

And then there are integrations that trigger behaviour in other systems and services: GitHub, Slack, eBay, Teams, Flows, Workato, Salesforce, etc. Depending on what these integrations do, they can behave as inputs, outputs, or both.

And all of the above can result in real world activity: money is moved, orders are shipped from warehouses, flow rates are changed in pipelines, generators spool up or down, students are offered (or not offered) places at universities, etc.

If you reduce things so much that all detail is lost, you can't really reason about the original thing any more. The obvious counterpoint here is, you try turning amazon.com into a plain TXT file and see how much sales increase.

What kind of answer would you expect to a question like that? I couldn't tell you how much time and money I save writing in a programming language instead of raw machine code but I can rest assured that it's the right call.

Are people on this site just stuck in the 90s or something? The product I work on is nowhere near Figma or Google Docs level of complexity, but we're still MILES away from "just rendering text on screen".

That's about as absurd a statement as saying all of Backend is just "returning names matching a certain ID" for how out of date and out of touch it is.

I know two reasons for server-side rendering: (1) site indexing, (2) time to first screen update. With faster networks and client devices (2) isn't as important as it used to be.

The reasons I prefer client-side rendering: (1) separation of concerns UX in the front, data/business in the back (2) Even as a back-end dev, prefer Vue to do front-end work rather than rendering text + scripts in the backend that run in the browser, (3) at scale it's better to use the client hardware for performance (other than initial latency).

But you are not just putting text on screen. That is a drastic simplification. To put text on screen, we had TV teletext/videotext. You can also just put a .txt file as your index.txt and serve that as your website. Or create a PDF from your word document. You won't need any developers at all for that.

This is overly reductive. Sure, you can say all webdev does is put letters on screen. Oh, and graphics - don't forget about those. Just letters and graphics! Oh wait, that actually describes everything anyone has ever coded.

It's like saying that the entire job of a politician is to speak words out loud. You're reducing a complex problem to the point that meaningful discussion is lost.

> The answer is always: put text on screen.

I wonder how you'll handle image uploading, drag and drop, media players, etc with simple static content rendering.

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 shape because that’s too magical. Instead the Right Way is to learn a DSL (such as Zod) to describe the shape of the input, then manually write the code to check it. Every single time. Oh and you can’t write a TS type to do that because Reasons. It all comes off as willful ignorance of literally a decade or more of established platforms such as Rails/Spring/ASP.NET. All they had to do was steal the good ideas. But I suspect the cardinal sin of those frameworks was that they were no longer cool.

I have a hard time relaying this without sounding too negative. I tried to get into SSR webdev with TS and kept an open mind about it. But the necessary ingredients for me weren’t there. It’s a shame because Vite is such a pleasure to develop with.

Yes, my experience as well. Last year I had to make a decision for the stack of a small app at work that needs a SPA (3D viewing large data sets using threejs and agGrid if anyone cares) and with long term stability as very high prio.

Long story short: I ended up choosing ASP.NET Core with Minimal APIs. The main reason was indeed EF Core as ORM, which I consider as one if not the best ORM. In the Node world there's so much promise (Prisma, Drizzle, ...) but also so much churn.

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 actually have any experience with the libraries that we are using, even though they've used other libraries in the node ecosystem. With rails, however, pretty much everybody with experience in a rails app will be able to jump into our application and will see a lot of stuff that is familiar right out of the gate.

I'm personally an elixir Phoenix Fanboy now, so I don't choose rails as my first choice for personal projects, but I think it is an excellent choice for a company. In fact, I would probably recommend it the most over any framework if you need to hire for it.

The JS ecosystem would be so much better if developers concentrated to contributing to libraries rather than writing new frameworks. After about 10 years of JavaScript, I recently moved over to .NET and I'm finding that my team can focus on actually developing features than maintaining the plumbing.

Can't speak to ORMs, but I'd have a look at SolidStart. If you need an API, add in tRPC. End result is highly typed, can do SSR, and once you get used to it, it's a much better experience than using React.

I still haven't found an ORM with JS that really speaks to me.

> there are so few rails people available (compared to js) that it's not viable for any professional project

I don't think this is true; Shopify is a Rails shop (but perhaps it's more accurate to say it's a Ruby shop now). It feels easy to make a mess in Rails though, imo that's the part that you could argue is irresponsible

Yeah, we were spending 10s of thousands of dollars on CI costs a month for a huge Rails app's integration tests alone..

API only Rails has been a thing for a long time: https://guides.rubyonrails.org/api_app.html

Many teams use this with React.

I’m hardly an expert with Rails, and I integrated React twice, on two very different sites, using API controllers. The nice thing about React is that you can limit it to an island on the page, and don’t need to buy into the router, etc. that said, I did disable Hotwire to make my life easier.

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.

I've been curious for a while now. One thing that gives me pause though is how Phoenix LiveView apps perform when you're dealing with high latency. I'm aware that many apps will be serving primarily the US market and so might not recognise this as much of an issue. I'm also aware that I could deploy 'at the edge' with something like fly.io. Still, when I run a ping test to 100 different locations around the world from NZ, the majority of results are 300ms+. That seems like it would have a pretty noticeable impact on a user's experience.

TLDR; Are most Phoenix deployments focused on a local market or deployed 'at the edge' or are people ignoring the potentially janky experience for far-flung users?

NextJS has a lot of significant drawbacks, that's why there's an ongoing debate (which is healthy):

- Cost

- Complexity

- Learning curve

- Scalability

- Frequent changes

- And surprisingly bad performance compared with the direct competitors

Nowadays, NextJS is rarely the best tool for the job. Next and React are sitting in the "never got fired for buying IBM" spot. It is a well earned position, as both had a huge innovational impact.

Do you need best in class loading and SEO with some interactivity later on? Astro with islands. Vitepress does something similar.

Do you need a scalable, cost efficient and robust stack and have moderate interactivity? Traditional SSR (RoR, Django, .NET MVC, whatever) with maybe some HTMX.

Do you have a highly interactive app? Fast SPA like Svelte, Solid or Vue.

What makes Rails stand out is the focus on convention-over-configuration as a guiding principle in the ecosystem which results in a lot less code (have you seen these relatively thin models and controllers?), as well as established dependencies and the lack of tendency to bikeshed in libraries (geocoder or devise for example have been mostly stable over close to a decade, with few popping up to replace it)

Rails has ActiveRecord, which has an extremely elegant REPL. It's a delight to use.

The prevailing sentiment is that once you hit scaling issues with frameworks like Rails or Django you should have enough resources to simply throw money at the problem either in the form of more hardware, cloud computing, or better software engineers that can identify bottlenecks and optimize them.

Since most websites will never scale past the limitations of these frameworks, the productivity gains usually make this the right bet to make.

There's really nothing to rave about because the ideas it introduced have all become standard. Rails is aggressively OK.

Reminds me of what I did to bring AI into my SpringBoot Java app. I just created a Python-based WebService (microservice), that deploys as part of my docker stack, and now I get the benefit of everything going on in the AI world which is mostly Python, with no lag. Meanwhile other Java Develpers are busy trying to port all that stuff over into Java language. To me that porting is just a waste of time. Let AI stay in Python. It's a win/win, imo. Of course I had to learn Python, but as a Java Dev it came easy. Other Java devs are [mostly] too stubborn to try Python if you ask me. Sorry if this drifted off topic, but it shows how you don't have to be a purist, but you can just do what works and is easiest.

This is a good approach I think. Rails is outstanding at delivering a good CRUD experience and data model management - sir I find it powerful to build the data model and admin tools using it, and allow other frameworks to access either the database or specific services as needed. Best of all worlds!