13 ms·

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

• abhisek 1y ago
  Rail is probably one of the most intuitive framework that I have ever used. No doubt it is highly opinionated but it hides all the complexity for small to medium applications.
  • qudat 1y ago
    It’s funny how some claim it’s intuitive while others complain about its magical nature.
    • sosborn 1y ago
      "Magic" and "Intuitive" aren't mutually exclusive.
    • dismalaf 1y ago
      Some people want to get things done and others want to play with legos.
    • kayodelycaon 1y ago
      It all depends what you’re working with. ActiveRecord can get gnarly. The rest of it is pretty easy to understand once you know what methods are called. I think what confuses people is Ruby’s meta programming. The ability to dynamically define named methods makes rails seem far more magical than it actually is. You also can’t tell the difference between method calls and local variables.
    • mattgreenrocks 1y ago
      It is too much to hold in my head at once sometimes. I can understand how it all fits together but the lack of types means I’m holding a lot more in my head at once. I wish I got along better with Rails, honestly.
• reassess_blind 1y ago
  Express JS with Handlebars templating has always been my favourite. Simple, lightweight SSR rendered pages.
• bananatron 1y ago
  Rails is particularly nice in a cursor-first world (probably true of any elder framework that has strong opinions/conventions).
  • cpursley 1y ago
    Languages with stronger types like typescript (unfortunately) perform much better than dynamic languages like Ruby, Elixir or even plain JS in an AI editor world. Because the editors are type smart and you can quickly pop the type error into the AI chat and it will attempt to correct it. The feedback cycle is just insane. I really hate to say it, but Typescript has won.
    • travisgriggs 1y ago
      Have you seen any studies that validate this? I feel this would be the case, but I can’t say I’ve actually seen it work out. Cursor writes better Elixir code for me than it does Kotlin, or at least it anecdotally seems so. I find it confusing. I remember many years ago an akin experience, talking to John Brant and Don Roberts who had done the original refactoring browser in Smalltalk. Java was on its meteoric rise with tons of effort being dumped into Eclipse. They, and others with them, were eager to port these techniques to eclipse, and the theory was they’d be able to do even more because of they typing. But Brant/Roberts that surprisingly it has been more difficult. Part of the problem was the AST. Java, while typed, had a complex AST (many node types), compared to that of Smalltalk (late/runtime typed) which had a very simple/minimal AST. It was in interesting insight.
      • cpursley 1y ago
        No studies other than some serious experimentation on my own. I’m a strong Elixir dev but Cursor and friends are just more productive with Typescript due to the editor type checking cycle and training. Thought Jośe is working on a new MCP project to help: https://github.com/tidewave-ai/tidewave_phoenix https://github.com/tidewave-ai/tidewave_phoenix
• DuzAwe 1y ago
  So begins the slow roll backwards because ai can’t support the new.
  • keeganpoppen 1y ago
    not even ai is smart enough to understand nextjs
    • frainfreeze 1y ago
      Seems to do very well from my experience.
      • keeganpoppen 1y ago
        at what?
• omneity 1y ago
  I switched from Rails to the node.js ecosystem back in the 3.2 to 4 transition, however looking back I share a similar sentiment as the OP. I recently initiated the backmigration and my approach thus far however has been to take out the "administrative" part out into Rails to benefit from all the useful conventions there, but keep the "business services" in JS or Python and have the two communicate. Best of both worlds, and the potential of all of rubygems, npm and pypi combined.
  • quantadev 1y ago
    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.
    • omneity 1y ago
      I think that's very smart, thanks for sharing! With the prevalence of coding agents currently the cost of context/language switching is much lower and these best-of-breed multilang setups are likely to become more prevalent in the future.
      • quantadev 1y ago
        Right, and when I "learned" Python it was basically by asking an AI agent to generate whatever I wanted to do, and then looked at what it generated. For example, I'd just say stuff like "How does Python do hashmaps?" or "How can I loop over this array", etc. AI wrote most of my AI Python code!
    • microflash 1y ago
• mountainriver 1y ago
  I’ve written a bit of rails and still don’t really get what the raving is about. It was perfectly fine, I didn’t find anything extra special about it. Having just hit severe scaling issues with a python service I’m inclined to only write my servers in Go or Rust anymore. It’s only a bit harder and you get something that can grow with you
  • omneity 1y ago
    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)
    • thunky 1y ago
      > 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 Convention over configuration and less code is fine, but unfortunately Rails is not a great example of it IMO. The "rails" are not strong enough; it's just too loosey goosey and it doesn't give you much confidence that you're doing it "the right way". The docs don't help much either, partly because of the history of breaking changes over releases. And the Ruby language also doesn't help because of the prolific globals/overrides and implicitness which makes for "magic". So you're encouraged/forced to write exhausting tests for the same (normally dumb CRUD) code patterns over and over and over again. Effectively testing the framework moreso than your own "business logic", because most of the time there barely is any extra logic to test. So I'm also surprised it gained the reputation is has.
      • omneity 1y ago
        Do you have a recommendation for a better incarnation of the principle?
• thembones 1y ago
  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, global state, or a 200 kB hydration bundle—they just need partial HTML swaps. The real driver is complexity cost. Every line of client JS brings build tooling, npm audit noise, and another supply chain risk. Cutting that payload often makes performance and security better at the same time. 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. So yes, the pendulum is swinging back toward the server, but it’s not nostalgia for 2004 PHP. It’s about right‑sizing JavaScript and letting HTML do the boring 90 % of the job it was always good at.
  • vinnymac 1y ago
    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.
    • noodlesUK 1y ago
      I completely agree with the sentiment that we don’t need SPAs and similar tech for news sites and dashboards and the myriad crud apps we use on a day to day basis but I think what you’re proposing is throwing the baby out with the bath water. How would a site like google maps, which I’m sure we can all agree is extremely useful, work in a Web 1.0 style world? It needs to dynamically load tiles and various other resources. The web being a place where we can host and instantly distribute complex cross-platform interactive software in a fairly secure sandbox is a modern marvel.
      • vinnymac 1y ago
        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.
• henning 1y ago
  > hitting a GraphQL API (Hasura) for getting data, and caching as much as possible using Incremental Static Revalidation. The first load was often a bit slow, but caching helped. Why do you need GraphQL here? If your developer workstation can't send a few KB of data over a TCP socket in a reasonable amount of time due to the colossal amount of Zoomer JavaScript abstraction nonsense going on, something has gone terribly wrong. The whole idea of needing "islands" and aggressive caching and all these other solutions to problems you created -- that you have somehow managed to make retrieving a trivial amount of data off a flash storage device or an in-memory storage system of some kind slow -- is ludicrous.
  • ezekiel68 1y ago
    Yeap. Once I squinted hard enough at GraphQL, I realized it was a tantrum against coordinating front end calls with back-end API signatures efficiently, masquerading as a solution. A classic end-around. What's funny is that people struggling after deploying it now think that they have invented the N+1 problem.
  • dyogenez 1y ago
    > Why do you need GraphQL here? The app was initially client-side only. I choose GraphQL over REST because Hasura created a super quick API for the database. Also, our API is public! We started as an alternative to Goodreads when they closed their API.
• rustc 1y ago
  What's the closest thing to Rails in a language with a sound static type system?
  • deleted 1y ago
    [deleted]
  • twodave 1y ago
    Probably something like ASP.NET MVC with C#
    • mattgreenrocks 1y ago
      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#.
      • twodave 1y ago
        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.
        • t-writescode 1y ago
          I've been loving C# since .... 6 or 7? About 10 years now. It's genuinely a great language - took a lot of the rough spots of Java and fixed them and then kept getting better.
  • rc_mob 1y ago
    php8.4 with Laravel
    • touristtam 1y ago
• joshstrange 1y ago
  I'm thankful that I don't work on projects that have SEO needs. SSG (for JS frameworks specifically) feels too unstable for me. I get the value, I understand why people need to do it, but it just makes everything more complicated. Also, I'm not sure if you can have an offline site with SSG? They might be compatible but I'm not sure. I know some SSG is essentially "SPA with the first page rendered already" so maybe that can work offline? I looked at InertiaJS and it feels like too much "magic" for me personally. I've never used it so I could be wrong but it feels like too many things you have to get working perfectly and the instability in the JS ecosystem makes me worry about adding too many layers.
  • omneity 1y ago
    Tangential but I noticed a certain common conflation between pre-rendering and server-side rendering. Very often plain SSR is all it takes for good SEO performance, SSR in this case simply being rendering the page on-demand before serving it to the user. 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.
  • mvdtnz 1y ago
    What's SSG?
    • tmnvix 1y ago
      Usually refers to Static Site Generator, but I suspect in this context Server Side Rendering was what was meant.
      • joshstrange 1y ago
        Yes, SSR is what I meant, I'm playing with a SSG and I mixed the acronyms in my head. Thank you!
• austin-cheney 1y ago
  When I see articles and discussions about web + stack I can’t but ask “What problem are they actually solving”? The answer is always: put text on screen. When your business goal is put text on screen the next logical step is to ask how much time and money does the tech stack really save? I have never found a developer that answer that question with a number. That’s a really big problem.
  • littlecranky67 1y ago
    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.
    • austin-cheney 1y ago
      Please don’t confuse method for intent. People tend to make that mistake as an equivocation error to qualify a mode of action. They do what they know and then extrapolate why they do it from what they have done.
  • karmakaze 1y ago
    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).
  • deleted 1y ago
    [deleted]
  • jakelazaroff 1y ago
    “Always” is doing a lot of heavy lifting there. At my last few jobs the goals have involved interactive visualizations, 3D model viewers and peer-to-peer screen sharing. There is a huge diversity of business goals outside of things that can be reduced to “put text on screen”.
• moralestapia 1y ago
  I never really got the appeal of SSR, and I've implemented it a cuouple times with Next.JS and things like htmx. Can anyone come up with the ideal use case where SSR shines? I'm willing to buy it if I see it.
  • recursivedoubts 1y ago
    when your app is mostly text-and-images https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/
  • grey-area 1y ago
    Websites. 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.
    • moralestapia 1y ago
      >Websites. Wait, is SSR a thing outside the context of websites?
      • grey-area 1y ago
        No, that's the primary use case. Works pretty well and has done since 1991. The majority of websites use SSR.
        • moralestapia 1y ago
          Weird.
      • int_19h 1y ago
        There was a time when SSR was the only option. All early web apps were SSR. It gets rather painful though, which is why we don't do that anymore.
• hijp 1y ago
  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.
  • sosborn 1y ago
    API only Rails has been a thing for a long time: https://guides.rubyonrails.org/api_app.html https://guides.rubyonrails.org/api_app.html Many teams use this with React.
    • hijp 1y ago
      I've built api only. It would be sick if it were easier to sprinkle react/vue/svelte/whatever in your haml views if you only needed a little bit of interaction but didn't want to spin up a whole other frontend.
  • dismalaf 1y ago
    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.
    • hijp 1y ago
      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.
• littlecranky67 1y ago
  I wonder why there is a debate Next.js vs. SSR. Nextjs is a hybrid and performs quite well. Contrasting with other SPA frameworks, Nextjs produces prerendered html output for fast first loads, efficient js chunks, config switches to eagerly-load those chunks (ie. when hovering over a link or preloading all n+1 links after page render) and efficient image (pre-)loading depending on breakpoint (usually the achilles heel when comparing to a pure SsR solution). I would really be interested in real world performance metrics comparing load times etc. on a stock nextjs app using defaults vs. rails and co.
  • WuxiFingerHold 1y ago
    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.
    • deleted 1y ago
      [deleted]
    • robertoandred 1y ago
      Cost? NextJS is free, and can be hosted on free services like GitHub/Cloudflare Pages.
    • littlecranky67 1y ago
      I challenge the "Bad performance" part. NextJS generates by default all assets and js-chunks with a sha256 hash in the filename - essentially making them immutable. As outlined in the NextJS, I serve my assets folder with `Cache-Control: public, max-age=604800, immutable`. In a webapp where your users use your app on a semi-daily basis that means all assets and resources will be cache forever, or until you re-deploy a new version of the app. The data comes via REST (in whatever backend-language you want to use) so I don't see how any SSR can outperform nextjs here.
• copperx 1y ago
  Rails is still wonderful. But someone should fork Rails so it ceases to be associated with DHH. CEOs who reveal who they really are become really toxic to the brand. We've seen that happen with Tesla.
  • wordofx 1y ago
    What’s DHH done?
    • code_biologist 1y ago
      Beyond Rails and 37signals, I'm most familiar with him as a car racer, photography enthusiast, and his recent "buy once"/post-subscription software advocacy. This is an interview with him last year on "one person" approaches to web app development that I liked a lot: https://www.youtube.com/watch?v=0rlATWBNvMw https://www.youtube.com/watch?v=0rlATWBNvMw
    • antfarm 1y ago
      Maybe parent is referring to DHH's stance on DEI. https://world.hey.com/dhh/the-waning-days-of-dei-s-dominance-9a5b656c https://world.hey.com/dhh/the-waning-days-of-dei-s-dominance... https://world.hey.com/dhh/dei-is-done-minus-the-mop-up-b3bbbb64 https://world.hey.com/dhh/dei-is-done-minus-the-mop-up-b3bbb...
      • deleted 1y ago
        [deleted]
    • ahnick 1y ago
      He became very unpopular for his no politics at work stance at the time, but it seems to have ultimately been the right call in the long run. The toxic individuals left and 37signals is stronger than ever.
      • twodave 1y ago
        FWIW I’d love it if HN adopted such a policy. It’s not practical to expect them to, but I find myself taking breaks to avoid the echo chamber here.
• ronbenton 1y ago
  The whole isomorphic framework trend has always scared the poo out of me. I feel like it's just asking for security issues. For people who commonly use these frameworks -- is it common to have issues where data or code intended only for server execution makes its way onto the client? Or are there good safeguards for this?
  • dan_can_code 1y ago
    Next.js has introduced some keywords such as 'use server' and 'use client' that you enter in the file at the top. Much like 'use strict'. If you attempt to use server code in a client file for example, it will get caught by the ts compiler / Linter. 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.
    • tmpz22 1y ago
      Not just accidental inclusion but intentional insecure inclusion. FE developer gets a BE ticket (because why not that's the whole point right?) and forces something through all proper-channels leading to trusted (server) code running on the client.
• lofaszvanitt 1y ago
  From one catastrophe to another. Good.
• swyx 1y ago
  > Our hosting bill grew from $30 in April to $142 by June, $354 in August. Hardcover was growing, but 10x cost increase in a few months was too much. without ANY irony or sarcasm, i just want appreciate that its funny how that happens completely without explicit desire or intention to have this effect from the developers of Next (i'm serious, don't hate me guys, we are friends, i do believe that this ofc is not intended) i'm sure there's a good and meaningful explanation (that I'm interested in reading) but lots of little microdecisions compound when the developer of the framework does not also experience it as a paying customer (or, more subtly, the developer of the framework wants to serve the 10000x larger enterprise customer and needs to make choices to balance that vs the needs of the small)
• zombiwoof 1y ago
  [flagged]
• ww520 1y ago
  For my most recent project, it was Spring Boot with Java at the backend and Solid.js at the frontend, with REST api in the middle. It has work very well. Solid has a very solid signal based React-style stack. Spring Boot is mature and stable that covers pretty much everything you need at the backend. The only wrinkle is we need to connect to a number of different database systems and the default DataSource can’t do the job. We ended up writing our own multi tenant datasource. We code gen most of the backend code for the hundreds of db tables. The path from DB to the frontend is automated. The whole project took 4.5 months with 1.5 junior developers and .5 architect and senior dev. One advantage is the business side has been nailed solid, with firm spec and feature sets.
• dzonga 1y ago
  inertia is so nice. rescues you from the hotwire mess. you choose your own frontend framework could be react, vue, svelte while at the same time not spinning an api or dealing with client state etc.
• bckr 1y ago
  I keep hearing good things about Rails. What are the downsides, other than learning a new language and framework?
  • entropie 1y ago
    I tried rails when it was pre version 1 and the early stages. I always felt like rails is very powerful and lots of things feel like magic until you come to a point where you want something that isnt implemented in that way. You can prototype stuff very fast with rails and its a mighty tool in the right hands.
  • MarcelOlsz 1y ago
    Did you miscalibrate your time machine and just make it back?
    • anon22981 1y ago
      Instead of being rude and snarky you could just answer the question. Or just not reply at all. Not everyone has looked into or tried everything.
      • MarcelOlsz 1y ago
        My bad!
    • deleted 1y ago
      [deleted]
  • tomnipotent 1y ago
    You have to be comfortable with the ORM in every layer - it lives inside your domain models, rather than in another layer shuffling DTO's to presentation/rendering. It also makes it easy to avoid separation of concerns and stuff all your logic in a controller method and call it a day. 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.
• madethemcry 1y ago
  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. I often see myself going back to Ruby on Rails for my private stuff. It's always a pleasure. On the other side, there are so few rails people available (compared to js) that it's not viable for any professional project. It would be irresponsible to choose that stack over js and often java for the backend. Anyone have similar feelings?
  • freedomben 1y ago
    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.
    • chao- 1y ago
      >If anything, I think finding a rails developer with relevant experience is even easier because the stack is so much more standardized. This has been my experience.
    • realusername 1y ago
      That's a point which cannot be underestimated, almost every Rails codebase looks mostly the same while I've never seen two similar node projects. Standardization also has advantages on training and hiring.
• 3sbi 1y ago
  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 tracking app really need GraphQL, separate frontend framework and complicated build process or all that could have been solved by sticking to deploying monolithic RoR app with HTML templates on VPS from the very start?
  • lmm 1y ago
    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.
    • makeitdouble 1y ago
      > ad hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL. Everytime I hit the "should we use GraphQL" question in the last decade we balked because we already had fast REST like APIs and couldn't see a how it would get faster. To your point it was more of a mish-mash than anything with a central library magically dealing with the requests, so there is more cognitive load, but it also meant we had much more control over the behavior and performance profile.
    • Diggsey 1y ago
      > Every webapp built with something other than GraphQL ends up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL. Not remotely true. There are plenty of web apps that work just fine with a standard fixed set of API endpoints with minimal if any customization of responses. Not to mention the web apps that don't have any client-side logic at all... GraphQL solves a problem that doesn't exist for most people, and creates a ton of new problems in its place. The value of GraphQL is also its downfall. The flexibility it offers to the client greatly complicates the backend, and makes it next to impossible to protect against DoS attacks effectively, or even to understand app performanmce. Every major implementation of GraphQL I've seen has pretty serious flaws deriving from this complexity, to the point that GraphQL APIs are more buggy than simpler fixed APIs. With most web apps having their front-end and back-end developed in concert, there's simply no need for this flexibility. Just have the backend provide the APIs that the front-end actually needs. If those needs change, also change the backend. When that kind of change is too hard or expensive to do, it's an organisational failing, not a technical one. Sure, some use-cases might warrant the flexibility that GraphQL uses. A book tracking app does not.
• tonyhart7 1y ago
  give it a few months the title would be: "why we go back to (another)JS framework"
• revskill 1y ago
  The problem with Next.js, is they over-engineered the whole things for no purpose. But i also think it's related to limitation of technical teams. "Simplicity is achieved when there's nothing left to remove".
  • twodave 1y ago
    That’s funny, after using it on a couple projects I felt that it was under-engineered/lacked some basic things I was used to having in other frameworks.
    • revskill 1y ago
      Look at how complicated it is to have so limited functionality.
      • twodave 1y ago
        Oh, yes, this we can agree on.
• deleted 1y ago
  [deleted]
• welder 1y ago
  Just eww... you were an expert at Rails 10+ years, failed to become an equivalent expert at Next.js so you went back to what you're used to. You just didn't dive in deep enough. I was the same expert level with Python, now I'm using trpc, nextjs, drizzle, wakaq-ts, hosted on DO App Platform and you couldn't pay me enough to go back to Python, let alone the shitstorm mess that's every Rails app I've ever worked on. I've also not seen the 1s Next.js pageloads you had, but I'm confident of figuring a fix if that becomes a problem.
• qq99 1y ago
  If you're thinking about going back to SSR, I think you owe it to yourself to check out Phoenix LiveView (Elixir) and play with it for an afternoon. I've built a few apps in it now, and to me, it starts to feel a bit like server-side React (in a way). All your HTML/components stream across to the user in reaction to their actions, so the pages are often very light. Another really big bonus is that a substantial portion of the extras you'd typically run (Sidekiq, etc) can basically just be baked into the same app. It also makes it dead simple to write resilient async code. It's not perfect, but I think it's better than RoR
  • tmnvix 1y ago
    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?
    • cultofmetatron 1y ago
      while its true that phoenix liveview's default is to have all state be on the server, there are hooks to run javascript behavior on the frontend for things like optimistic updates and transitions. This gives plenty of ways to make the frontend feel responsive even when the roundtrip is 300+.
    • mike1o1 1y ago
      Yes, unfortunately that is the big weakness of LiveView. It also suffers from what I call the elevator problem, where LiveView apps are unusable with unstable connections and flat out stop working in an elevator or areas with spotty connections. However, Elixir and Phoenix is more than just LiveView! There’s also an Inertia plugin for Phoenix, and Ecto as an “ORM” is fantastic.
• stevebmark 1y ago
  Is this article comparing apples and oranges? For example > loading the entire homepage only takes one query [if you're logged out] You can do this with Next.js SSR - there's nothing stopping you from reading from a cache in a server action? They also talk about Vercel hosting costs, but then self host Rails? Couldn't they have self hosted Next.js as well? Rails notoriously takes 3-4x the resources of other web frameworks because of speed and resources.
  • dyogenez 1y ago
    > You can do this with Next.js SSR Yep! It'd be possible with Next.js. The difference is how it's organized. In Next.js with RSCs, we were fetching data for each part of the page where it's used (trending books, Live events, blog posts, favorite books). Each of those could be their own cache hit to Redis. One advantage of Rails is the controller. We can fetch all data in s single cache lookup. Of course it'd be possible to put everything needed in a single lookup in Next.js too, but then we wouldn't be leveraging RSCs. I tried self-hosting Next.js on Digital ocean, but it crashed due to memory leaks without a clear way to understand where the leak was. Google Cloud Run and Vercel worked because it would restart each endpoint. We have more (and cheaper) hosting options with Rails.
    • yawaramin 1y ago
      This is my exact criticism of RSCs, they basically encourage the N+1 query problem. Basically nobody should be organizing their data fetches like this.
• ezekiel68 1y ago
  Even a cursory glance at the runtime performance difference between these two frameworks reveals that either this project won't scale to the point that cloud costs are relevant or they have a dubious prioritization of DX over deployment economy. We are talking orders of magnitude fewer RPS for Rails.
  • ramoz 1y ago
    I don’t understand your integration of performance and cloud costs here. “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.
    • ezekiel68 1y ago
      Quite simply: at certain threshold counts of users you will be forced to add many more cloud instances/pods running Rails than you would need running node.js (or Java or go or many others). But it doesn't stop at instances because this will also require more persistent disk / object storage, more logs, more alerts, more notifications from the cloud provider that instance xyz needs to be restarted (due to a firmware upgrade or whatever), etc. etc. All of these have human management overhead costs and most of them increase monthly financial costs.
      • dyogenez 1y ago
        It's less expensive now with Rails than our hosting was with Next.js. If there was more traffic, we'd save even more money in comparison. That was mentioned in the post.
• amaran1999 1y ago
  [flagged]
• twodave 1y ago
  We used NextJS on a couple of projects where I work and are already phasing them out. The reasons are manifold, but a few key factors: * difficult auth story. next-auth is limited in a few ways that drove us to use iron-session, such as not being able to use a dynamic identity provider domain (we have some gov clients who require us to use a special domain). This required us to basically own the whole openid flow, which is possible but definitely time we didn’t expect to have to spend in a supposedly mature framework. * because the NextJS server wasn’t our primary API gateway we ended up having to proxy all requests through it just to add an access token to avoid exposing it on the client. The docs around this were not very clear, and this adds yet another hop with random gotchas like request timeout/max header size/etc. * the framework is very aggressive about getting you on their cloud, and they make decisions accordingly. This was at odds with our goals. * the maintainers aren’t particularly helpful. While on its own this would be easy to look past, there are other tools/frameworks we use in spite of their flaws because the maintainers are so accessible and helpful (shout out to Chillicream/HotChocolate!)
  • vdfs 1y ago
    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)
    • t-writescode 1y ago
      Not OP; but when I was thinking about using Next.JS, and doing a deep investigation, I came to the decision that, for server-side rendering, I'm quite happy to use Kotlin and Ktor (my backend is also Kotlin - I have a lot of client-types, which is why they're separate), and I've been quite happy with Ktor's html dsl + htmx for speed. And Kotlin + Ktor feels very good to write in on serverside. Fast, easy and fluent to write in, like Ruby; but with Java's ecosystem, speed and types.
      • catgirlinspace 1y ago
        How are you doing reusable components with the html dsl? From the little bit I’ve tried ktor this was something I could not figure out and it kinda just pushed me away since I couldn’t find anything.
• chrisweekly 1y ago
  > "Sometimes it’s tricky to understand if a problem is in Rails, Inertia-Rails, Inertia.js, React.js or Vite." You mentioned giving up on Remix after poking at it for a day. IMHO that was a mistake.
• insane_dreamer 1y ago
  Many SPA websites don't need to be SPAs, and the overhead in terms of complexity vs "old-fashioned" server-side ajax calls (even using something as "ancient" as jQuery) is not worth it, and do not improve the user experience.
• morsecodist 1y ago
  I feel like the elephant in the room here is that their back end was in RoR before Next.js and remained that way the entire time. They then switched from next.js to a framework designed, in part, with RoR in mind. It seems unsurprising that they had a much better experience using a thing that was tailored to their use case. I love Next.js. I have used other frameworks including RoR and there is nothing like it (except Svelte or Nuxt but I view them as different flavors of the same core idea). But I only use it to make monoliths. I can see getting frustrated with it if I was using it alongside a different back end.
• exabrial 1y ago
  Server Side Rendering is awesome and FAR simpler and productive and immensely less buggy. Hoping we continue to see people leave the js framework madness behind.
• outlore 1y ago
  IMO the problem with Next is that it can’t decide whether it wants to be a framework for client side apps that require interactivity or server side rendered mostly static content sites. To support both it has codeveloped some baffling features in React like RSC which have made it far less fun to work with. “use client”, server actions that aren’t scrutable in a network tab, laggy page transitions, and, until recently, inscrutable hydration errors: these are some of the recent paper cuts I experienced with Next. I’d still use it for new projects, but I am keen to use TanStack Start when it’s ready i’m personally really interested in the next wave of frameworks that make local first development intuitive, like One or something that bakes in Zero
• ummonk 1y ago
  I can't speak to the technical aspects here (I'm only familiar with nextjs not rails, so it's unclear to me how much of the article is just a reflection of the author's own comfortability with rails or a reflection of a more technically suitable architecture). But I do find it really weird that a company which apparently has multiple software engineers is worried about infrastructure costs amounting to less than $1k a month... Seems penny-wise pound-foolish to be worried about hosting bills.
  • gedy 1y ago
    Yeah, we were spending 10s of thousands of dollars on CI costs a month for a huge Rails app's integration tests alone..
    • adenta 1y ago
      What CI provider?
      • gedy 1y ago
        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 locally.
        • PapaPalpatine 1y ago
          > Rails UI integration tests took a very long time How many integration tests do you have? I generally only test a few core flows and then leave the rest to controller/request tests.
          • gedy 1y ago
            A lot. We were moving towards that approach when I left, though the detailed UI tests were then in JS tests which didn't need the whole app running.
• t-writescode 1y ago
  Frontend and Backend developers have never really been good at talking, for as long as I've been a developer. As a historically backend-developer, I've tended to dislike Html/JS/CSS. It's a meaningfully different paradigm from the Swing/Awt, WinForms, Android UX, etc. That alone was enough to frustrate me and keep me on the backend. To learn how to make frontend, I've had to since learn those 3. They're finally becoming familiar. BUT, for front-end developers, they needed to learn "yet another language"; and a lot of these languages have different / obnoxious build systems compared to nvm and friends. And then, like anyone who's ever changed languages knows, they had to learn a whole bunch of new frameworks, paradigms, etc. Well, they would have, but instead, some of them realized they could push Javascript to the backend. Yes, it's come with *a lot* of downsides; but, for the "Get Shit Done" crowd - and especially in the world of "just throw more servers at it" and "VC money is free! Burn it on infra!" these downsides weren't anything worth worry about. But the front-end devs - now "full stack devs" but really "javascript all the things" devs -, continued to create in a visible way. This is reflective of all the friggin' LinkedIn Job Postings right now that require Next.JS / Node.JS / whatever roles for their "full stack" positions. One language to rule them all, and all that. Just some ramblings, but I think it's strongly related to why people would choose Next.JS __ever__, given all its downsides.
• dagorenouf 1y ago
  I followed the same journey but was unimpressed by Rails attempt at modernization with Hotwire. Decided to give Elixir + Phoenix a try and immediately fell in love. Just like I had with rails years ago. I highly recommend people to check it out, liveview is a game changer for building modern web apps without the complexity of JS, and without the baggage of using Rails to do it. And performance is mind blowing.
  • sph 1y ago
    Funnily enough, a JS library that I often use with Elixir, Phoenix and Live View is StimulusJS (which is part of Hotwire) I also have written a hacky stimulus controller to integrate it with Phoenix hooks for full integration. Not sure about Rails, haven't used it in more than a decade, but NextJS was a major contributor to massive burnout. Of one thing I'm certain: Phoenix is my last web framework. I love it to bits, and I hope to retire before it stops being cool.
• kookamamie 1y ago
  I find it funny how the generation of content is now called ”server-side rendering” to make it sound cooler than what it actually is.
• arvinsim 1y ago
  I fell in love with React because of its SPA approach, as opposed to SSR. You must imagine my chagrin when React started moving towards rendering on the server(SSR, Server Components, etc). I was happy to move to a full client implementation. Sadly, SEO cannot be ignored.
  • robertoandred 1y ago
    NextJS et al are still SPAs. SPA and SSR/SSG are not mutually exclusive.
• petetnt 1y ago
  Great that it's working for them, but for the end user the feel of the site nearly unusable. There's 1s+ of delay on every interaction - pressing "home" button from explore tab takes 1,85 seconds (on a gigabit connection) before home view comes active, without any other feedback to the end user except for "Home" icon becoming active. You cannot just blindly trust the page speed metric but it should be impossible to miss things like this when you are actually using the site. Compare the experience to something like GoodReads that's using plain old SSR and you'll immediately notice the difference.
  • yellow_lead 1y ago
    I don't have this delay personally. Probably the page speed metric is more accurate because it smooths out anecdotes like ours.
    • petetnt 1y ago
      Page speed metric shows 5.2s for the first contentful paint for the mobile home page too: https://pagespeed.web.dev/analysis/https-hardcover-app-feed-all/pn7c0gal28?form_factor=mobile https://pagespeed.web.dev/analysis/https-hardcover-app-feed-...
      • yellow_lead 1y ago
        I didn't realize you were trying mobile initially. When I tried mobile, it also seems incredibly slow. My desktop didn't have this issue (when going from explore page to home). Everything seems a lot slower on mobile.
      • dyogenez 1y ago
        That is one of the slower pages on the entire app. I'd like to move that one to use an InertiaRails.deferred setup, so it loads instantly with a loading spinner - like you'd see with Suspense + RSC. (Hardcover founder here)
  • jakubmazanec 1y ago
    True, the 1s+ delays (both on mobile and desktop!) and no spinners is a very annoying UX. I've been saying this forever and this is a great reminder for those React-hating folks here on HN: usually it's the developer's fault his web is slow, not the framework's.
• deleted 1y ago
  [deleted]
• chagel 1y ago
  Exploring web programming from the frontend view (e.g., Island Architecture) is always intriguing. I'd love to see how JS/SPAs surpass the SSR/HTTP paradigm with LLM/AI. Until then, focus on mastering infrastructure, protocols, databases, and APIs — engineering over designing.