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

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.

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.

Figma is written in C++ to webasm.

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

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.

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.

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.

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 loved building things that way.

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. So they get an app working, and all is good, right until it hits say 5000 lines of code. Then suddenly you have to re-write it all using a framework and TypeScript to do typing. Better to just start with an approach that scales to infinity, so you never run into the brick wall.

Everything after ready should have been static content.

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.

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.

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.

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

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

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.

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.

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.

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.

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

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?

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

Many teams use this with React.

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.

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

But for sure the lack of clear lines for where the server ends and the client begins has always been a pain of these kinds of framework offerings.

Pre-rendering (as popularized by static site generators) is the additional step that increases complexity significantly, sometimes security issues too when session-protected cached pages are mistakenly served to the wrong users.

It’s honestly a really underrated framework, smartly designed, with probably the best ORM that exists and a great ecosystem.

Unfortunately, the documentation is painfully bad and the Getting Started guides are really boring compared to Rails or Django.

There may also be Laravel but I can’t say anything about it since I never tried it.

“Deployment economy” is also new.

Rails has a very strong track record of matching internet scale.

Cloud is highly optimized for traditional server applications. From my experience with Next.js - this is the opposite. A lot of deployment components that don’t naturally fit in, and engineering required to optimize costs.

All that being said I still use (and like) Rails, currently comparing Phoenix/Elixir to Rails 8 in a side project. But I use typescript w/ Node and Bun in my day job.

You can prototype stuff very fast with rails and its a mighty tool in the right hands.

Rails also uses way too much magic to dynamically construct identifiers and do control flow.

The over-use of magic and the under-use of static types makes it extraordinarily difficult to navigate Rails codebases. It's one of those things where you have to understand the entire codebase to be able to find anything. Tractable for tiny projects. For large projects it's a disaster.

Rails is a bad choice (as is Ruby).

My favourite web framework at the moment is Deno's Fresh. You get the pleasure of TSX but it's based around easy SSR rather than complex state management and hooks. Plus because it's Deno it's trivial to set up.

Rails is a sharp knife. There is Rails way to do things. You may of course choose to do them differently (this is a contrast with other toolkits that fight this hard), but you are going to have to understand the system well to make that anything but a giant hassle.

With rails, the way it scales is statelessness. You have to map the front end actions to individual endpoints on the server. This works seamlessly for crud stuff (create a thing; edit a thing; delete a thing; list those things). For other use cases it works less seamlessly. NB: it works seamlessly for nested "things" too.

Complex multi-step flows are a pain point. eg you want to build data structures over time where between actions on the server (and remember, you must serialize everything you wish to save between each action), you have incomplete state. Concretely: an onboarding flow which sets up 3 different things in sequence with a decision tree is going to be somewhat unpleasant.

You must keep most state on the server and limit FE state. Hotwire works extremely well but the FE must be structured to make hotwire work well.

I've actually found it to work pretty well with individual pages build in react. My default is to build everything with hotwire and, when the FE gets too complex, to fall back to react.

Rails is nobody's idea of a fast system. You can make it perform more than well enough, but fast it is not.

Upsides, my take: it is the best tool to build websites. The whole thing is built by developers for developers. DX and niceness of tools are valued by the community. Contrast with eg the terrible standard lib that other languages (hi, js) have. Testing is by far the most pleasant I've used, with liberal support for mocking rather than having to do DI. For eg things like [logic, api calls, logic, api calls, logic, db calls] it works incredibly well. It is not the most popular toolkit and it's not react, so that can count against you in hiring.

The upsides is that by not trying to hide the database and pretend it doesn't exist you can avoid a whole class of work (and the safety abstractions provided) and be incredibly productive if the requirements align.

What's funny is that people struggling after deploying it now think that they have invented the N+1 problem.

Most websites are significantly simpler to build and maintain with SSR and traditional tools. An entire generation has forgotten this it seems and still thinks in terms of JS frameworks even when trying SSR.

As one example take this website, which serves the page your wrote your comment on using an obscure lisp dialect and SSR.

https://htmx.org/essays/a-real-world-react-to-htmx-port/

https://htmx.org/essays/when-to-use-hypermedia/

I run skatevideosite.com and accidentally did the first rewrite when I took it over in react because that’s all I knew. I absolutely tanked the seo.

Rewrote it in rails and got everything back in shape and it’s been a fun experience!