[HN Gopher] We fell out of love with Next.js and back in love wi...
___________________________________________________________________
We fell out of love with Next.js and back in love with Ruby on
Rails
Author : mike1o1
Score : 231 points
Date : 2025-05-03 18:26 UTC (4 hours ago)
(HTM) web link (hardcover.app)
(TXT) w3m dump (hardcover.app)
| bananatron wrote:
| Rails is particularly nice in a cursor-first world (probably true
| of any elder framework that has strong opinions/conventions).
| cpursley wrote:
| 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.
| DuzAwe wrote:
| So begins the slow roll backwards because ai can't support the
| new.
| keeganpoppen wrote:
| not even ai is smart enough to understand nextjs
| omneity wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| The right tool for a given problem is usually much more
| ergonomic and productive. To me purism of language or tooling
| is a disservice to an engineer's instinct of solving a
| problem. Use Python where it is a strong option. Use Spring
| Boot where it makes sense.
|
| BTW, I'm also on a similar trajectory using a mix of Java,
| Python and Node.js to solve different problems. It has been
| very pleasant experience compared to if I had been bullish on
| just one of these languages and platforms.
| matthewmacleod wrote:
| 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!
| mountainriver wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| Do you have a recommendation for a better incarnation of
| the principle?
| jonnycat wrote:
| Phoenix with Elixir is for sure "a better Rails".
|
| Although that's really selling it short - it's so much
| more than that! But in the context of this conversation,
| it's a good place to look.
| thunky wrote:
| Django is similar but done better IMO.
| dlachausse wrote:
| 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.
| mountainriver wrote:
| Hard disagree on this. I went with this sentiment and deeply
| regret it. With LLM assisted coding it's very fast and easy
| to write a Go or even a Rust server. They have less bugs and
| can actually do things like threads that you end up working
| around in python/ruby.
| henning wrote:
| There's really nothing to rave about because the ideas it
| introduced have all become standard. Rails is aggressively OK.
| matthewmacleod wrote:
| They honestly really haven't though. I'd've thought they
| would've by now, but I still find bringing up a backend with
| something like Go to be annoyingly tedious and feature-
| incomplete in comparison.
|
| Like yeah, I know you can do it. But it was much more effort
| to do things like writing robust migrations or frontend
| templates. I'd love to find something in Go or Typescript
| that made me feel quite as productive as Rails did.
| fteem wrote:
| Preach. I found the whole "just use stdlib" culture in Go
| so annoying. I love the language (both Go and Ruby
| actually), but Go's ecosystem and tooling is eons behind.
|
| Maybe I am comparing apples and oranges, not sure.
| drx wrote:
| Rails has ActiveRecord, which has an extremely elegant REPL.
| It's a delight to use.
| karmakaze wrote:
| ActiveRecord may be both the best and worst part of Rails.
| Currently the largest scaling problem that I'm facing is with
| all the before_* and after_* callbacks which run _per model
| record_ rather than a batch of changed records. This is an
| N+1 query landmine field for which ActiveRecord offers no
| solutions.
| benblue wrote:
| I agree that ActiveRecord isn't particularly opinionated
| about how to deal with updates to batches of records, but
| there are multiple ways of approaching this and AR won't
| get in your way.
|
| upsert_all[1] is available to update a batch of records in
| a single write that does not invoke model callbacks.
|
| activerecord-import[2] is also very nice gem that provides
| a great api for working with batches of records.
|
| It can be as simple as extracting your callback logic and a
| method (def self.batch_update) and running your callback
| logic after the upsert.
|
| [1] https://api.rubyonrails.org/classes/ActiveRecord/Relati
| on.ht... [2] https://github.com/zdennis/activerecord-import
| karmakaze wrote:
| By upsert_all not invoking model callbacks, it's
| admitting that the ActiveRecord approach doesn't scale.
|
| "It can be as simple as extracting your callback..."
| Isn't this the kind of repetitive thing a framework
| should be doing on your behalf?
|
| _To be fair, ActiveRecord isn 't a fault Rails invented.
| Apparently it's from one of Martin Fowler's many writings
| where each model instance manages its own storage. Even
| Fowler seems to say that the DataMapper approach is
| better to separate concerns in complex scenarios._
| cpursley wrote:
| AR is the worst thing about Rails - it's anti-pattern
| central. The Ruby REPL is amazing, however.
| thembones wrote:
| 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.
| dlachausse wrote:
| People also forget just how far you can get without using
| client side JavaScript at all today. HTML and CSS have a lot of
| features built in that used to require JavaScript.
| joshstrange wrote:
| New inputs types have been glacially slow to come out and
| often underwhelming. Every new HTML thing I've seen (modals,
| datetime inputs, datalist select, etc) had better JS versions
| out for years before they released. I understand that the
| HTML spec is setting a baseline of sorts but most of the UI
| is ugly and sometimes not themeable/styleable.
| timewizard wrote:
| The best approach is to use both. Which is why I never
| understood the pure server side or the pure "reactive"
| approach. Having to manage rendering in server side code is
| pure pain, and having to return DOM markup from inside a
| function is likewise just madness. They both break the
| separation of concerns.
|
| The first framework I ever got to use was GTK with Glade and
| QT with designer shortly there after. These, I think, show
| the correct way to arrange your applications anywhere, but
| also it works great on the web.
|
| Use HTML and CSS to create the basis of your page. Use the
| <template> and <slot> mechanisms to make reusable components
| or created widgets directly in your HTML. Anything that gets
| rendered should exist here. There should be very few places
| where you dynamically create and then add elements to your
| page.
|
| Use javascript to add event handlers, receive them, and just
| run native functions on the DOM to manage the page. The
| dataset on all elements is very powerful and WeakMaps exist
| for when that's not sufficient. You have everything you need
| right in the standard environment.
|
| If your application is API driven then you're effectively
| just doing Model-View-Controller in a modern way. It's
| exceptionally pleasant when approached like this. I have no
| idea why people torture themselves with weird opinionated
| wrappers around this functionality, or in the face of an
| explosion of choices, decide to regress all the way back to
| server side rendering.
| quantadev wrote:
| I think the confession that "Figma- or Gmail-class apps still
| benefit from heavy client logic" is a telling one, and the
| reason I politely disagree with your thinking is that it relies
| in the app staying small forever. But that's not what happens.
| Apps grow and grow and grow.
|
| 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.
| lazypenguin wrote:
| That's absurd, that's like saying we should only use C++ for
| backend code because my CRUD business app might one day scale
| to infinity. Better be safe than sorry and sling pointers and
| CMake just in case I need that extra juice!
| willsmith72 wrote:
| Not really. If you use react router, you can have a client
| side js app and add SSR with a couple of hours work. You
| have your cake and eat it
| freeone3000 wrote:
| The idea that apps can never be done and can never stop
| adding new features is the key determiner of web bloat. This
| is the problem.
| room271 wrote:
| The problem is that people are frequently using SPA JS
| frameworks for things that are clearly _not_ gmail of figma
| -- i.e. news websites and other sites with minimal
| interactivity or dynamic behaviour. If you are genuinely
| building an 'app'-like thing, then of course you need some
| kind of JS SPA framework, but too often people are reaching
| for these tools for non-app use cases.
| quantadev wrote:
| I say if you have any reactivity whatsoever you need a
| framework. If you don't your code will be crap, and there's
| really no getting around that. Once you start doing DOM
| calls to update GUI you've got a mess on your hands
| instantly, and it will only get worse over time.
| spenczar5 wrote:
| Yeah, wouldn't want to rewrite the frontend in a new
| framework. Good thing the SPA frameworks are so stable and
| solid; when I choose one I will surely be able to use it for
| a good, oh, 3 to 6 months.
| CooCooCaCha wrote:
| This feels sarcastic but in reality ever since react switch
| to using hooks I've largely written the same style of react
| code for years. You don't have to live on the edge.
| CooCooCaCha wrote:
| I've been saying this for a long time. It takes very little
| effort to spin up a react app so there's little point in
| starting a project without it or whatever front-end framework
| you prefer.
|
| As I've become more senior I've realized that software devs
| have a tendency to fall for software "best practices" that
| sound good on paper but they don't seem to question their
| practical validity. Separation of concerns, microservices,
| and pick the best tool for the job are all things I've ended
| up pushing back against.
|
| In this particular case I'd say "pick the best tool for the
| job" is particularly relevant. Even though this advice is
| hard to argue against, I think it has a tendency to take
| developers down the path of unnecessary complexity.
| Pragmatically it's usually best to pick a single tool that
| works decently well for 95% of your use cases instead of a
| bunch of different tools.
| quantadev wrote:
| I agree, just use React from day one. The reality is that
| web pages are hardly ever perfectly static, and once
| there's any dynamic nature to it at all you need something
| like React or else you'll have a train wreck of JS DOM-
| manipulation calls before you know it. React is perfect.
| You just update your state and the page magically re-
| renders. It's a breeze.
| vinnymac wrote:
| 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 wrote:
| 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 wrote:
| 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.
| stavros wrote:
| 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?
| vinnymac wrote:
| 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.
| gameman144 wrote:
| 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_?
| vinnymac wrote:
| 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.
| bartread wrote:
| 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.
| vinnymac wrote:
| 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.
| qudat wrote:
| 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.
| freeone3000 wrote:
| But on the flip side, you can program the backend in anything
| you like, instead of being bound to javascript.
| sroussey wrote:
| JS/TS is fine. Why switch back and forth between languages
| and frameworks and data models and...
| baq wrote:
| 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.
| chipsrafferty wrote:
| It is fine, though.
| const_cast wrote:
| 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.
| SJC_Hacker wrote:
| You haven't had to deal directly with JS on front end since
| Dart released over 10 years ago
| stavros wrote:
| 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.
| procaryote wrote:
| You had to manage state on the frontend even before spa
| though, if you wanted anything but the most basic
| experience.
| stavros wrote:
| Not between page loads.
| tomnipotent wrote:
| You absolutely did. It was common practice to stuff
| things in cookies or query strings to retain state
| between trips to the server so that some JS could do its
| job.
|
| Every form also normally ends up duplicating validation
| logic both in JS for client-side pre-submit UX and
| server-side with whatever errors it returns for the JS to
| then also need to support and show to the user.
| stavros wrote:
| Right, but validation logic and state transferred by the
| server isn't in-memory state. The fact that the pages
| completely reload on each request clears a lot of cruft
| that doesn't get cleared on pages whose lifetime is tens
| or hundreds of views.
| tomnipotent wrote:
| Every SPA I come across, especially when using React,
| uses persistent state so that in-memory changes are
| synced to cookie/localStorage/server so they survive
| refreshes. Every popular state management library even
| supports this natively. And all of that state combined
| still requires less memory than any of the images loaded,
| or the JS bundles themselves.
| actsasbuffoon wrote:
| I absolutely loathe that. State is the source of most
| bugs. If the page crashes then refreshing it should clear
| out the state and let me try again.
|
| Anecdotally, it seems like I encounter a lot more web
| apps these days where refreshing doesn't reset the state,
| so it's just broken unless I dig into dev tools and start
| clearing out additional browser state, or removing params
| from the URL.
|
| Knock it off with all the damn state! Did we forget the
| most important lesson of functional programming; that
| state is the root of all evil?
| const_cast wrote:
| 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.
| nine_k wrote:
| Unless you can guarantee RTT under 100ms, you have to
| manage some state on client side, else your UI will feel
| sluggish.
| freetonik wrote:
| I'd rather have sluggish UI with proper feedback than
| potentially inconsistent states which I often experience
| with modern SPAs. At least that represents reality. Just
| today I was posting an ad on the local classifieds page,
| and the visual (client) state convinced me that
| everything was fast and my photos are uploaded. Turned
| out all state was lost and never reached the server, and
| I had to redo everything again.
| const_cast wrote:
| It's trivial to achieve under 100ms in the US with even
| just one server.
|
| Most companies aren't international.
| ajb92 wrote:
| Who says your backend needs to manage state?
| cstew913 wrote:
| You don't have a database?
| ivan_gammel wrote:
| Client-server model is known for decades, state management
| between them isn't hard.
| throwaway7783 wrote:
| I have repeated this elsewhere. APIs for UI tend to diverge
| from APIs in general in practice.
|
| For applications that are not highly interactive, you don't
| quite need a lot of tooling on the BE, and since need to have
| a BE anyway, a lot of standard tooling is already in there.
|
| React style SPAs are useful in some cases, but most apps can
| live with HTMX style "SPA"s
| whatnow37373 wrote:
| Agreed. We started with one API to rule them all. What
| happened? Now we got two.. and now we have to communicate
| like this:
|
| "So the backend gave this weird ..."
|
| "What backend?"
|
| "The backend for the frontend..."
|
| "So not the backend for the backend for the frontend?"
|
| I jest, but only very slightly.
| throwaway7783 wrote:
| Exactly. And state is in two places now. It's like
| building two applications and trying to somehow keep them
| in sync.
| recursivedoubts wrote:
| https://htmx.org/essays/splitting-your-apis/
| __abc wrote:
| If you truly need for MVC to manage all things state,
| component communications, and complex IxD in the front-end,
| sure, but not every app has that level of front-end
| complexity to warrant a SPA, in my opinion.
| 0cf8612b2e1e wrote:
| I think the DX is significantly better as well with fast
| reload...
|
| As a user, the typical SPA offers a worse experience.
| Frequent empty pages with progress bars spinning before some
| small amount of text is rendered.
| zozbot234 wrote:
| > As a user, the typical SPA offers a worse experience.
|
| Your typical SPA has loads of pointless roundtrips. SSR has
| no excess roundtrips by definition, but there's probably
| ways to build a 'SPA' experience that avoids these too.
| (E.g. the "HTML swap" approach others mentioned ITT tends
| to work quite well for that.)
|
| The high compute overhead of typical 'vDOM diffing'
| approaches is also an issue of course, but at least you can
| pick something like Svelte/Solid JS to do away with that.
| eastbound wrote:
| Requires additional engineering.
| boomskats wrote:
| > Your typical SPA has loads of pointless roundtrips
|
| This is an implementation choice/issue, not an SPA
| characteristic.
|
| > there's probably ways to build a 'SPA' experience that
| avoids these too
|
| PWAs/service workers with properly configured caching
| strategies can offer a better experience than SSR (again,
| when implemented properly).
|
| > The high compute overhead...
|
| I prefer to do state management/reconciliation on the
| client whenever it makes sense. It makes apps cheaper to
| host and can provide a better UX, especially on mobile.
| int_19h wrote:
| My biggest annoyance with SPAs is that they usually break
| forward/back/history in various subtle (or not so subtle)
| ways.
|
| Yes, I know that this can be made to work properly, in
| principle. The problem is that it requires effort that
| most web devs are apparently unwilling to spend. So in
| practice things are just broken.
| jefozabuss wrote:
| I still have some ptsd from payment gateway integrations
| via iframes about 6-7 years ago. If you thought SPAs are
| bad by themselves for history tracking imagine those
| banking iframes randomly adding more entries via inside
| navigation/redirection that you have to track manually.
| brandensilva wrote:
| We have been moving to localized cache stores and there
| aren't any client side loaders anymore outside of the
| initial cache generation. Think like Linear, Figma, etc
|
| It just depends on what you are after. You can completely
| drop the backend, apis, and have a real time web socketed
| sync layer that goes direct to the database. There is a row
| based permissions layer still here for security but you get
| the idea.
|
| The client experience is important in our app and a backend
| just slows us down we have found.
| dingnuts wrote:
| >and have a real time web socketed sync layer that goes
| direct to the database
|
| you might be able to drop a web router but pretending
| this is "completely drop[ping] the backend" is silly.
| Something is going to have to manage connections to the
| DB and you're not -- I seriously hope -- literally going
| to expose your DB socket to the wider Internet.
| Presumably you will have load balancing, DB replicas, and
| that sort of thing, as your scale increases.
|
| This is setting aside just how complex managing a DB is.
| "completely drop the backend" except the most complicated
| part of it, sure. Minor details.
| veqq wrote:
| > We have been moving to localized cache stores and there
| aren't any client side loaders anymore outside of the
| initial cache generation. Think like Linear, Figma, etc.
|
| That's never the case.
| switz wrote:
| So here's the kicker: React Server Components don't need a
| server. They are completely compatible with a static bundle
| and still provide major benefits should you choose to adopt
| them (dead code elimination, build-time execution). This is
| effectively the design of Astro Islands, natively in React
| Server Components. Letting you write static and client-side
| dynamic code in a single paradigm through componentization
| and composition.
|
| If you are curious, my most recent blog post is all about
| this concept[0] which I wrote because people seem to be
| misinformed on what RSCs really are. But that post didn't
| gain any traction here on HN.
|
| Is it more complex? Sure-but it is also more powerful &
| flexible. It's just a new paradigm, so people are put off by
| it.
|
| [0] Server Components Give You Optionality
| https://saewitz.com/server-components-give-you-optionality
| chipsrafferty wrote:
| Then they are poorly named.
| switz wrote:
| I generally agree. Naming things is among the hardest
| problems in computer science
| dmix wrote:
| The obsession with DX tooling is exactly why JS is such an
| awful developer experience. They always chase something
| slightly better and constantly change things.
|
| Maybe the answer was never in JS eating the entire frontend,
| and changing the tooling won't make it better, as it's always
| skirting what's actually good for the web.
| pier25 wrote:
| > _The obsession with DX tooling is exactly why JS is such
| an awful developer experience._
|
| I used to agree but these days with Vite things are a lot
| smoother. To the point that I wouldn't want to work on UI
| without fine-grained hot reloads.
|
| Even with auto reload in PHP, .NET, etc you will be wasting
| so much time. Especially if you're working on something
| that requires interaction with the page that you will be
| repeating over and over again.
| ivan_gammel wrote:
| Eh, I recently stumbled into an open bug in Npm/vite and
| wasted two days before just reinstalling everything and
| re-creating frontend app. Hot UI reloads are cool, but
| such things kill any productivity improvements.
| dmix wrote:
| > Especially if you're working on something that requires
| interaction with the page that you will be repeating over
| and over again.
|
| That's honestly not that many things IRL. If you look at
| all the things you build only a minority actual demand
| high interactivity, or highly custom JS. Otherwise
| existing UI libraries cover the bulk of what people
| actually need to do on the internet (ie, not just
| whatever overly fancy original idea the designers think
| is needed for your special product idea).
|
| It's mostly just dropdowns and text and tables etc.
|
| Once you try moving away from all of that and questioning
| if you need it at every step you'll realize you really
| don't.
|
| It should be server driven web by default with a
| splattering of high functionality islands of JS. That's
| what rails figured out after changing the frontend back
| and forth.
|
| > Even with auto reload in PHP, .NET, etc you will be
| wasting so much time
|
| Rails has a library that will refresh the page when files
| change without a full reload, using Turbo/Hotwire. Not
| quite HMR but it's not massively different if your page
| isn't a giant pile of JS, and loads quickly already.
| ezekiel68 wrote:
| >To the point that I wouldn't want to work on UI without
| fine-grained hot reloads.
|
| No -- but you could. And it wouldn't be the end of the
| world. So I'm just saying, DX doesn't eclipse all other
| considerations.
| whatnow37373 wrote:
| > dramatically reduce complexity
|
| If you ever worked seriously on anything non-SPA you would
| never, ever claim SPAs "dramatically reduce complexity". The
| mountain of shit you have pull in to do anything is
| astronomical even by PHPs standards and I hate PHP. Those
| days were _clean_ compared to what I have to endure with
| React and friends.
|
| The API argument never sat well with me either. Having an API
| is orthogonal: you can have one or do not have one, you can
| have one _and_ have a SSR app. In the AI age an API is the
| easy part anyway.
| princevegeta89 wrote:
| 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.
| catlover76 wrote:
| What would you say the good and bad of GraphQL are? Like,
| when it is a value-add, and when should it be avoided?
| princevegeta89 wrote:
| The good news is GraphQL is very quick and easy to pick up
| and it gives that inbuilt functionality to fetch exactly
| the amount of data that we need. On top of it, it also has
| enough flexibility to integrate with your business logic.
| So it can be a straightforward replacement for a
| traditional REST API that you would have to manually build.
|
| For the disadvantages, I cannot think of any. It is a bit
| slower than hand rolling your own REST API, but the
| difference is not severe enough to make you give up on it.
| Aeolos wrote:
| GraphQL APIs can easily DOS your backend if you don't
| configure extra protections (which are neither
| bulletproof nor enabled by default), they suffer from N+1
| inefficiencies by default unless you write a ton of extra
| code, and they require extra careful programming to apply
| security rules on every field which can get very complex
| very fast.
|
| On the plus side, it does have offer communication
| advantages if you have entirely independent BE and FE
| teams, and it can help minimize network traffic for
| network-constrained scenarios such as mobile apps.
|
| Personally, I have regretted using GraphQL every time.
| demilicious wrote:
| My biggest gripe is losing the entire layer of semantics
| that HTTP gives you. POST is the only verb and different
| error states are conveyed via error objects in the
| returned JSON.
| ivape wrote:
| "Right-sizing" is probably the most diplomatic take on all tech
| churn. It's the right way to look at it. It's not that we're
| _done with it once and for all_ , it's just it's not the _end
| all be all_ that conferences /blogs/influencers make things out
| to be. It's more of an indictment of the zealotry behind tech
| evangelism.
| pier25 wrote:
| 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.
| AlchemistCamp wrote:
| Hours so? I've found that Phoenix LiveView has made
| integrating the server and client code much simpler. It's
| dramatically reduced the need to write JavaScript in general,
| including for things like image uploads. Or are you speaking
| of one of its many clones?
| lmm wrote:
| > 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.
| chipsrafferty wrote:
| This is ChatGPT
| henning wrote:
| > 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 wrote:
| 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.
| abhisek wrote:
| 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 wrote:
| It's funny how some claim it's intuitive while others complain
| about its magical nature.
| sosborn wrote:
| "Magic" and "Intuitive" aren't mutually exclusive.
| kayodelycaon wrote:
| 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.
| dismalaf wrote:
| Some people want to get things done and others want to play
| with legos.
| mattgreenrocks wrote:
| 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.
| rustc wrote:
| What's the closest thing to Rails in a language with a sound
| static type system?
| twodave wrote:
| Probably something like ASP.NET MVC with C#
| mattgreenrocks wrote:
| 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 wrote:
| 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.
| rc_mob wrote:
| php8.4 with Laravel
| pjerem wrote:
| Unironically, if you want something as mature as Rails, with
| batteries included, and static typing, the closest in my mind
| is aspnet core.
|
| 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.
| ldjkfkdsjnv wrote:
| spring boot
| purplerabbit wrote:
| Everyone ITT will hate me for saying this, but: T3 stack.
| diordiderot wrote:
| Adonisjs
| joshstrange wrote:
| 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 wrote:
| 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.
| austin-cheney wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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).
| jakelazaroff wrote:
| "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".
| bartread wrote:
| > _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.
| austin-cheney wrote:
| You are confusing information for data. I suggest reading
| about the DIKW model. Nonetheless, the relational ontology of
| content has no bearing on the tech stack used to display
| such, which is why well written content on paper does not
| require a tech stack to achieve what you describe.
| stavros wrote:
| 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.
| tedunangst wrote:
| I would use a craigslist skinned amazon.
| pier25 wrote:
| > _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.
| renewiltord wrote:
| Are people going on with an estimate of how much time and money
| a specific tech stack saves? You come up with a number for this
| and it's accurate, I assume. Like if I were to say
| Node+TypeScript+Express vs. Golang you'd have an answer. If you
| get that right more often than not then the answer is you're
| really good at it in a way most people aren't.
| moralestapia wrote:
| 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 wrote:
| when your app is mostly text-and-images
|
| https://htmx.org/essays/a-real-world-react-to-htmx-port/
|
| https://htmx.org/essays/when-to-use-hypermedia/
| grey-area wrote:
| 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 wrote:
| >Websites.
|
| Wait, is SSR a thing outside the context of websites?
| grey-area wrote:
| No, that's the primary use case. Works pretty well and has
| done since 1991. The majority of websites use SSR.
| moralestapia wrote:
| Weird.
| int_19h wrote:
| 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.
| ezekiel68 wrote:
| What is the specific pain? Are you just referring to
| dynamic content on the client in general or different
| issues?
| littlecranky67 wrote:
| I use nextjs with static exporting (so technically no SSR). You
| get SEO and quick first page loads. Once the user is logged in,
| I use CSR only and the data loads via REST.
| nop_slide wrote:
| SEO.
|
| 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!
| trinix912 wrote:
| Unrelated, but big kudos to you for running
| skatevideosite.com. Such a great resource.
| hijp wrote:
| 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 wrote:
| API only Rails has been a thing for a long time:
| https://guides.rubyonrails.org/api_app.html
|
| Many teams use this with React.
| hijp wrote:
| 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 wrote:
| 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 wrote:
| 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.
| elondaits wrote:
| 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.
| littlecranky67 wrote:
| 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.
| copperx wrote:
| 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 wrote:
| What's DHH done?
| code_biologist wrote:
| 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
| antfarm wrote:
| Maybe parent is referring to DHH's stance on DEI.
|
| https://world.hey.com/dhh/the-waning-days-of-dei-s-
| dominance...
|
| https://world.hey.com/dhh/dei-is-done-minus-the-mop-
| up-b3bbb...
| ahnick wrote:
| 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 wrote:
| 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.
| dismalaf wrote:
| Has aggressively moderate political opinions...
|
| Americans don't seem to understand nuance, so when DHH posts
| about support for people's right to protest, how he loves
| being a father, how he doesn't want politics in the workplace
| and doesn't proclaim the sky is falling because of politics
| they seem to think he's the devil.
| miragecraft wrote:
| He's politically naive. I agree with him on much, such as
| don't make workplace political, and cancel culture and DEI
| have in many cases gone mad, but his tolerance, even gentle
| celebration of Trump in the name of free speech is a classic
| example of the paradox of tolerance.
|
| https://en.m.wikipedia.org/wiki/Paradox_of_tolerance
|
| However he is right in many cases, and I don't expect anyone
| to be right all the time, myself included. It's strange to
| look for political leadership from a programmer anyhow.
| dismalaf wrote:
| Or maybe American culture warriors should chill a bit. First
| they tried to cancel Matz, now DHH for holding opinions that
| are considered progressive everywhere in the world except SV.
| insane_dreamer wrote:
| I disagree. DHH is opinionated, and a bit arrogant at times,
| but he's not obnoxious, petty and childish like Musk.
| ronbenton wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| From one catastrophe to another. Good.
| swyx wrote:
| > 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)
| ww520 wrote:
| 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 wrote:
| 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 wrote:
| I keep hearing good things about Rails. What are the downsides,
| other than learning a new language and framework?
| entropie wrote:
| 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 wrote:
| Did you miscalibrate your time machine and just make it back?
| anon22981 wrote:
| 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.
| tomnipotent wrote:
| 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.
| IshKebab wrote:
| You have to program it using Ruby which is not a good language.
| It's slow. It doesn't have good static type annotations (as far
| as I can tell the community "gets it" even less than in
| Python).
|
| 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.
| faizshah wrote:
| I think from a business perspective, the hiring pool for Rails
| is small and younger engineers don't have an interest in
| learning Rails (check recent university hackathons). It takes a
| decently long time (2-3+ months) to upskill a non-ruby engineer
| to be productive in Rails (although this is dampened by AI
| tools these days) and many senior non-ruby engineers aren't
| interested in Rails jobs whereas you can get an Node or Java
| engineer to come to your Go shop and vice versa. Rails can also
| be hard to debug if you work in a multi-language shop, you
| can't map your understanding of Java or Typescript over to a
| Rails codebase and be able to find your way around.
|
| 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.
| x0x0 wrote:
| Downsides:
|
| 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.
| qq99 wrote:
| 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.
| snkzxbs wrote:
| 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?
| ezekiel68 wrote:
| 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.
| insane_dreamer wrote:
| yes but that depends a lot on your application and how users
| interact with it
| madethemcry wrote:
| 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 wrote:
| 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.
| qq99 wrote:
| 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
| mattgreenrocks wrote:
| 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.
| 3sbi wrote:
| 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 wrote:
| 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.
| tonyhart7 wrote:
| give it a few months the title would be: "why we go back to
| (another)JS framework"
| revskill wrote:
| 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 wrote:
| 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 wrote:
| Look at how complicated it is to have so limited
| functionality.
| twodave wrote:
| Oh, yes, this we can agree on.
| welder wrote:
| 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 wrote:
| 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 wrote:
| 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?
| stevebmark wrote:
| 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.
| ezekiel68 wrote:
| 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 wrote:
| 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.
| twodave wrote:
| 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!)
| chrisweekly wrote:
| > "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 wrote:
| 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.
___________________________________________________________________
(page generated 2025-05-03 23:00 UTC)