Of course back then we didn't use dynamic anything, a static web page worked.

Now get off my lawn!

And it wasn't static: We because peoples connections were mostly so slow, we used a CGI that shelled out to ping to estimate connection speed, and return either a static image (if you were on a dialup) or a fancy animated gif if you were on anything faster.

(the ping-test was obviously not reliable - if you were visiting from somewhere with high latency, you'd get the low bandwidth version too, no matter how high your throughput was - but that was rare enough; it worked surprisingly well)

Thousands and thousands of lines of quality conversation, interaction, humanity.

To be honest, I kind of miss those days.

I love to think that the web of the future is just going to be everyones' mac Mini or whatever.

Big Data™ has always irked me, frankly.

I started thinking about that around an implementation that could run under Google’s App Engine free tier, but never completed it.

In most cases businesses justify the cost of managed databases for less risk of downtime. A HA postgres server on crunchy can cost over $500/mo for a measly 4vCPU.

I would agree that it's the least of concerns but for a different reason. Spending all your time optimizing for optimal performance (assuming sensible indexing for what you have) by continuously redesigning your DB structure when you don't even know what your company will be doing next year isn't worth the time for a few hundred a month you might save.

I read this as "in building your startup, you should be paranoid about team members never making mistakes". I really try to read otherwise, but can't.

/s

It's a cool project. I might do it too. I have an M4 Mini sitting on my desk that I got for $550.

I don’t find it approaching unruliness, quite the opposite really.

Why did you go for Cloudfare tunnel instead of wireguard?

We also hosted web pages before the average script kiddie could run tens of Gbps DDoS on sites for the lolz. And before ISPs used CGNAT making direct inbound connections impossible.

Even having IPv6 is not a proper solution because of laggy ISPs(currently reaching ~50%) and the even the ISPs who deploy, do not deploy it properly. (dynamic prefixes or inbound blocked IPv6)

Add to the mix that lot of people does not understand IPv6, internet became more centralized and will keep doing so for the foreseeable future.

I wrote a visualizer for the traffic that I think people will appreciate [1]. I will post it next month once I add it on github. It was fun to watch an article that went #1 on HN.

[1]: https://ibb.co/cXT3VNDR

I run a windows server at my office where we connect to it using RDP from multiple locations. If I could instead buy the hardware and use cloudflare tunnels to let my team RDP to it then it would save me a lot of money. I could recoup my hardware cost in less than a year. Would this be possible?

(I wouldn't mind paying for cloudflare tunnels / zero trust. It just should be much smaller than the monthly payment I make to Microsoft)

I do think Cloudflare has proven itself to be very developer/indie-friendly. One of the only tech unicorns that really doesn't impose its morality on customers.

I'm pretty sure Tunnels supports RDP and if you don't use a ton of bandwidth (probably under a 1TB/mo), Cloudflare probably won't bother you.

I’ve served (much) greater-than-HN traffic from a machine probably weaker than that mini. A good bit of it dynamic. You just gotta let actual web servers (apache2 in that case) serve real files as much as possible, and use memory cache to keep db load under control.

I’m not even that good. Sites fall over largely because nobody even tried to make them efficient.

I understand that the USA is big, but no fiber in SF?

AT&T has put fiber out in little patches, but only in deals with a guaranteed immediate ROI, so it would mean brand new buildings, where they know everyone will sign up, or deals like my old apartment, where they got their service included in the HOA fee, so 100% adoption rate guaranteed! AT&T loves not competing for business.

Sure, others have been able to painstakingly roll out fiber in some places, but it costs millions of dollars to string fiber on each street and to get it to buildings.

Caught an AT&T tech in the field one day, and he claimed that if 8 (or 10—memory's a little fuzzy) people in the neighborhood requested it, they'd bring it in.

I never did test it, but thought it interesting that they'd do it for that low a number. Of course, it may have been because it was already in the area.

Still, may be worth the ask for those who don't already have it.

I’ve had a number of database-driven sites hosted on $5/month VPS that have been on the front page here with minimal cpu or memory load.

The CPU is more powerful than I need. I didn't pass 8% utilization in the last 24 hours as HN slammed the box.

Now, however, what is the point? To learn server config? I am running my blog with GitHub pages. A couple of posts made it to the top of HN, and I never had to worry.

Always bewilders me when some sites here go down under load. I mean, where are they hosting it that a static page in 2020s has performance issues?

Not only does is have a built in UPS, but also comes with a screen, keyboard and trackpad for you need to do admin tasks physically att the console!

Although you could use a backup USB cellular modem, plugged directly into the Mac!

At some I imagine I'll inherit or acquire a cheap older M1 Macbook Air, which will be perfect!

I also have whole home battery backup and solar, so I technically have a UPS for everything!

Where I live the power tends to go out from time to time!

I monkeyed around with cheap ex-lease Dell Micro PCs with Intel 8th Gen to 11th Gen CPUs. But they not as performant as I'd like, and once you've experienced modern CPUs like Apple's M series, you dont really want to go back!

In fact, most of them are just implemented by feeding an LLM the text, and asking "is it AI generated?". You cannot trust that answer any more than any other LLM hallucination. LLMs don't have a magic ability to recognise their own output.

Even if your "detection tool" was using exactly the same model, at the same exact version... unless the generation was done with 0 temperature, you just wouldn't be able to confirm that the tool would actually generate the same text that you suspect of being LLM-generated. And even then, you'd need to know exactly the input tokens (including the prompt) used.

Currently, the only solution is watermarking, like what Deepmind created:

https://deepmind.google/discover/blog/watermarking-ai-genera...

but even that, it requires cooperation from all the LLM vendors. There's always going to be one (maybe self-hosted) LLM out there which won't play ball.

If you're going to accuse someone of pushing LLM-generated content, don't hide behind "computer said so", not without clearly qualifying what kind of detection technique and which "detection tool" you used.

Yes, compared to an all-or-nothing approach, it's better to be upfront about the uncertainty, especially if the tool surfaces the probability by-sentence.

But how are those probabilities computed? You mention gptzero, but https://gptzero.me/technology doesn't clarify at all how it works. They link papers using GPTZero (i.e. from other researchers), e.g. https://arxiv.org/pdf/2310.13606

And these very same papers highlight how everything is still unknown

> Despite their wide use and support of non-English languages, the extent of their zero- shot multilingual and cross-lingual proficiency in detecting MGT remains unknown. The training methodologies, weight parameters, and the spe- cific data used for these detectors remain undis- closed.

GPTZero seems to be better than some of the alternatives, but other discussions here on HN when it was launched highlight all of the false positives and false negatives it yielded:

https://news.ycombinator.com/item?id=34556681

https://news.ycombinator.com/item?id=34859348

But all of that is pretty old, there have been a couple of posts in the last year about it, but both are about the business, rather than the quality of the tool itself.

https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=fal...

So, to check if now it's any better I tried it myself: I got it to yield a false negative (50% human and 50% AI rating, for a text which was wholly AI-generated), and I haven't got it to yield a false positive.

But all of this is just anecdotal evidence, I haven't run a rigorous study.

For sure, if some competent people believe that the tool won't generate false positives, I'll be mindful of it and (In the rare cases in which I write a long posts/blog articles, etc.) I'll check that it doesn't erroneously flag what I write.

It's bittersweet: if a tool that can be relied upon really exist, that would be good news. But if that tool is closed source (just like ChatGPT, Gemini, etc.) that doesn't inspire confidence. What if the closed source detection tool will suddenly start erroneously flagging a subset of human texts which it didn't before?

At least, even with the closed source LLMs, we have a bunch of papers that explain their mechanism. I hope that GPTZero will be more forthcoming about the way it works.

>Today I'm working on Chroma Cloud, designed for exploring and managing large datasets, and Next.js powers its advanced interactions and data loading requirements.

which is unlikely to have been written by an LLM.

And it mostly makes too much sense apart from "most drivers don't know how many gears their car has" which has me thinking huh? It's usually written on the shifter.

Contrast that, to more "app-y" patterns, that might have some unifying calendar, or mix things into a dashboard. Those patterns are also useful!! And of course, all buildable in rails as well. But there is something nice about the simplicity of CRUD apps when I end up coming across one.

So even though you can build in any style with whatever technology you want:

Rails feels like it _prefers_ you build "1 model = 1 concept = 1 REST entity"

Next.js (+ many other FE libraries in this react-meta-library group) feels like it _prefers_ you build "1 task/view = mixed concepts to accomplish a task = 1 specific screen"

Inevitably, once one update is done, they'll say "oh and we just need to add this one thing here" and that cycle repeats constantly.

If you have a single page front end setup, and a "RESTful" backend, you end up making a dozen or more API calls just to show everything, even if it STARTED out as narrowly focused on one thing.

I've fought the urge to use graphql for years, but I'm starting to think that it might be worth it just to force a separation between the "view" of the API and the entities that back it. The tight coupling between a single controller, model and view ends up pushing the natural complexity to the wrong layer (the frontend) instead of hiding the complexity where it belongs (behind the API).

Different widget related front-end views will need different fields and relations (like widget prices, widget categories, user widget history and so on).

There are lots of different solutions:

- Over fetching. /widgets/123 returns not only all the fields for a widget, but more or less every possible relation. So a single API call can support any view, but with the downside that the payload contains far more data than is used by any given view. This not only increases bandwidth but usually also load on the database.

- Lots of API calls. API endpoints are tightly scoped and the front-end picks whichever endpoints are needed for a given view. One view calls /widgets/123 , /widgets/123/prices and /widgets/123/full-description. Another calls /widgets/123 and /widgets/123/categories. And so on. Every view only gets the data it needs, so no over fetching, but now we're making far more HTTP requests and more database queries.

- Tack a little "query language" onto your RESTful endpoints. Now endpoints can do something like: /widgets/123?include=categories,prices,full-description . Everyone gets what they want, but a lot of complexity is added to support this on the backend. Trying to automate this on the backend by having code that parses the parameters and automatically generates queries with the needed fields and joins is a minefield of security and performance issues.

- Ditch REST and go with something like GraphQL. This more or less has the same tradeoffs as the option above on the backend, with some additional tradeoffs from switching out the REST paradigm for the GraphQL one.

- Ditch REST and go RPC. Now, endpoints don't correspond to "Resources" (the R in rest), they are just functions that take arguments. So you do stuff like `/get-widget-with-categories-and-prices?id=123`, `/get-widget?id=123&include=categories,prices`, `/fetch?model=widget&id=123&include=categories,prices` or whatever. Ultimate flexibility, but you lose the well understood conventions and organization of a RESTful API.

After many years of doing this lots of time, I pretty much dislike all the options.

If you just have one single monolithic database, anything clever you do on the other levels just lets you survive until the single monolithic database becomes the bottle-neck, where unexpected load in one endpoint breaks several others.

When a project is new and small, whatever approach I take feels amazing and destined to work well forever. On big legacy projects or whenever a new project gets big and popular, whatever approach I took starts to feel like a horrible mess.

Rails' initial rise in popularity coincided with the rise of REST so these patterns spread widely and outlasted Rails' mindshare

However, I'm biased. A lot of my jobs have been writing "backoffice" apps, so there's usually models with a really clear identity associated to them, and usually connected to a real piece of paper like a shipment form (logistics), a financial aid application (edtech), or a kitchen ticket (restaurant POS).

Those sorts of applications I find break down with too many "Your school at a glance" sort of pages. Users just want "all the applications so I can filter to just the ones who aren't submitted yet and pester those students".

And like many sibling comments mention, Rails has some good answers for combining rest entities onto the same view in a way that still makes them distinct.

LiveView is amazing and so is Phoenix but Rails has better support for building mobile apps using Hotwire Native.

This is fine!

> I've fought the urge to use graphql for years

Keep fighting the urge. Or give into it and learn the hard way? Either way you'll end up in the same place.

The UI can make multiple calls to the backend. It's fine.

Or you can make the REST calls return some relations. Also fine.

What you can't do is let the client make arbitrary queries into your database. Because somebody will eventually come along and abuse those APIs. And then you're stuck whitelisting very specific queries... which look exactly like REST.

You can define any schema and relations you want, it's not an ORM.

Funny enough, see this assumption frustrating a lot of people who try to implement GraphQL APIs like this.

And even if you do turn it into a pseudo-SQL, there's still plenty of control. Libraries allow you to restrict depth, restrict number of backend queries, have a cost function, etc.

REST calls are fairly narrowly tailored, return specific information, and it's generally easy to notice when someone is abusing them. "More like RPC".

Your naive GraphQL API, on the other hand, will let me query large chunks of your database at a time. Take a look at Shopify's GraphQL API to see the measures you need to take to harden an API; rate limits defined by the number of nodes returned, convoluted structures to handle cursoring.

GraphQL is the kind of thing that appeals to frontend folks because they can rebalance logic towards the frontend and away from the backend. It's generally a bad idea.

No it won't, because it's not tied directly to the database and does not allow for arbitrary queries.

Any of the "aha!" gotchas you mention are the same issues as you could have with REST, JSON-API, etc.

I'm sorry you don't understand what I'm pointing out, but thanks for the convo though.

There are of course products that do this automatically, but it's not really that simple. There's a reason things like Hasura are individual products.

The GraphQL structure can be totally independent from your DB if need be, and (GraphQL) queries on those types via API can resolve however you need and are defined by you. It's not a SQL generator.

On the other hand, unless you've put some serious work into hardening, I can craft a GraphQL query to your system that will produce way more data (and way more load) than you would prefer.

A mature GraphQL web API (exposed to adversaries) ends up whitelisting queries. At which point it's no better than REST. Might as well just use REST.

(I'm not aware of any, but if there are actually gems or libraries that do expose your DB to GraphQL this way, that's not really a GraphQL issue)

Like the Read for a dashboard could have a controller for each dashboard component to load its data or it could have one controller for the full dashboard querying multiple models - still CRUD.

The tight coupling is one of many approaches and common enough to be made default.

Separate entities on the backend - a unified update view if that’s what’s desired.

No need for any outside dependencies.

It's seemingly more work than graphql as you need to actually intentionally build your API, but it gets you fewer, more thought-out usage patterns on the backend that are easier to scale.

Rails really doesn't encourage this architecture, quite the opposite in fact.

> designers and users of the applications I have been building for years never want just one model on the screen.

... and this is where Rails excels. When you need to pull in some more data for a screen you just do it. Need to show the most recent reviews of a product in your e-commerce backend? It's probably as simple as:

    <%= render @product.reviews.order(created_at: :desc).limit(5) %>

---

Going back to the GP post

> Rails feels like it _prefers_ you build "1 model = 1 concept = 1 REST entity"

That's definitely the simple path, but there are very few constraints on what you can do.

Query whitelisting makes sense when you're building an API for your own clients (whom you tightly control). This is the original and most common usecase for graphql, though my personal experience is with using it to provide 3rd party APIs.

It's true that you can't expect to do everything identically to how you would have done it with REST (authz will also be different), but that's kind of the point.

Much better to just do that in rails in the first place.

I really like easy problems too. Unfortunately, creating database records is hardly a business. With a pure CRUD system you're only one step away from Excel really. The business will be done somewhere else and won't be software driven at all but rather in people's heads and if you're lucky written in "SOP" type documents.

There are two types of complexity: essential and incidental. Sometimes, a straightforward CRUD app won't work because the product's essential complexity demands it. But at least as often, apps (and architectures, and engineering orgs, and businesses) are really just CRUD apps with a bunch of incidental complexity cluttering up the joint and making everything confusing, painful, and expensive.

I've served dozens of clients over my career, and I can count on one hand the number of times I've found a company whose problem couldn't more or less be solved with "CRUD app plus zero-to-one interesting features." No technologist wants to think they're just building a series of straightforward CRUD apps, so they find ways to complicate it. No businessperson wants to believe their company isn't a unique snowflake, so they find ways to complicate it. No investor wants to pour their money into yet another CRUD app, so they invent a story to complicate it.

IME, >=90% of application developers working today are either building CRUD apps or would be better off if they realized they were building CRUD apps. To a certain extent, we're all just putting spreadsheets on the Internet. I think this—more than anything else—explains Rails' staying power. I remember giving this interview on Changelog ( https://changelog.com/podcast/521 ) and the host Adam asking about the threat Next.js posed to Rails, and—maybe I'd just seen this movie too many times since 2005—it didn't even register as a possible contender.

Any framework that doesn't absolutely nail a batteries-included CRUD feature-set as THE primary concern will inevitably see each app hobbled with so much baggage trying to roundaboutly back into CRUD that it'll fall over on itself.

The choice to spend 10x-50x the resources and deal with the agony of increasing complexity doesn’t make sense to me. Especially in the last few years since Rails’ Hotwire solves updating page fragments effortlessly.

Of course everything is just CRUD. That's all a database can do. But writing every piece of software at that level is insanity. When I say pure CRUD I mean software that is literally just a thin veneer over a database. Now that actually is useful sometimes but generally you'll want to be able to write higher level abstractions so you can express your code in a more powerful language than CRUD. Are you really saying you've consulted for businesses that just do CRUD? As in they have meetings about creating, updating and deleting database records?

> Rails has started to show its age amid with the current wave of AI-powered applications.

Not everything needs to have bloody AI.

Half the net merrily runs on PHP and jQuery. Far more if you index on company profitability.

> Not everything needs to have bloody AI.

Some things are an anti-signal at this point. If a service provider starts talking about AI, what I hear is that I'm going to need to look for a new service provider pretty soon.

Sadly, I'm not even talking cool stuff like imaging (though it's there too), but anything to do with clinical notes to insurance is all AI-ified.

Truly, it is the new crypto-web3 hype train, except there'll be a few useful things to come out of it too.

Not at all my experience, actually it was incredibly easy to get this working smoothly with hotwire and no javascript at all (outside the hotwire lib).

We have a Rails app with thousands of users streaming agentic chat interfaces, we've had no issues at all with this aspect of things.

A lot of them prefer to write Ruby because it is simply the most beautiful language they know of. Technical details are merely a formality expressed in code that borders art.

I was under the impression the industry was collectively moving in that direction, but then bootcamps ushered in a new era of midwit frontend developers hell bent on reinventing the wheel from scratch (poorly).

The commenter you're replying to, in fact, is saying lack of fundamentals is the reason people AREN'T using Ruby

I'd rate it as about 90%-ish of what react gives you at 5-10% of the development effort. React sites can definitely be nicer, but they are so much more work.

React is a good choice if you’ve got a huge dev team that can split things into components and independently work on things but otherwise React is so full of footguns that it’s almost comical that people choose it for anything other than bloated VC projects.

A plug for Django + gevent in this context! You have the Python type system, and while it's inferior to TypeScript's in many ways, it's far more ubiquitous than Ruby's Sorbet. For streaming and any kind of IO-bound parallelism, gevent's monkey-patches cause every blocking operation to become a event-loop yield... so you can stream many concurrent responses at a time, with a simple generator. CPU-bound parallelism doesn't have a great story here, but that's less relevant for web applications - and if you're simultaneously iterating on ML models and a web backend, they'd likely run on separate machines anyways, and you can write both in Python without context-switching as a developer.

I've never quite gotten comfortable with gevent patches, but that's more because I don't personally understand them or what their edge cases might be than a commentary on their reliability.

Detecting this might require external health checks and the like. And runaway regexes can trigger this too, not just tight loops. But those are also problems that asyncio has!

The only other one is that you’ll want to think about forking models with servers like gunicorn, and patch at the right time - but this is a one-time thing to figure out per project, and documentation is quite good now.

Generally I'd say any senior rails dev, given the right task, can write decent elixir code on their first day. There are a lot fewer foot guns in elixir and Phoenix, and so other than language ergonomics (a simple rule that doesn't stretch far but works at the beginning is use pipe instead of dot), there's minimal barriers

I've watched Elixir with much interest from afar, I even recently cracked open the book on it, but I feel like my biggest pain points with Ruby are performance and lack of gradual typing (and consequent lack of static analysis, painful refactoring, etc), and it doesn't really seem like Elixir has much to offer on those. What does Elixir solve, that Ruby struggles on?

Typing is coming, some is already here, and if you're impatient you can use dialyzer to get half way there. But in my experience you need it less than you'd think. Elixir primitives are rather expressive, and due to the functional nature there really isn't any "new" data structure that isn't easy to dive into. And with each function head being easy to pattern match in, you can dictate the shape of data flow through your application much as you'd do in a typed language.

The ide story isn't great, but it's getting better. There are a few LSPs out there, and an official one coming soon. And I'd say all of them beat solargraph handily

But most of all I'd say that, since it's a bit more strict, elixir saves you and your coworkers from yourselves and each other. There are still several ways to do something, like Ruby, but going out of your way to write very cutesy code that the next programmer will loathe is more difficult. Not impossible, but harder. And with the rock stable concurrency systems in place, a lot of the impetus to come up with clever solutions isn't there

Re types, I think what I really want is just comprehensive static analysis. Coming from Rust, where I can immediately pull up every single call site for a given function (or use of a struct, etc.), I find refactoring Ruby/Rails code to be comparatively very painful. It is several orders of magnitude more laborious and time-consuming than it should be, and I just don't find the justification for that cost convincing - I'd trade every last bit of Rails' constant runtime metaprogramming cleverness for more static analysis.

What I like about Rails is its batteries-included nature, but I honestly could do without those batteries materialising via auto-magic includes and intercepted method calls. I appreciate that that's just the culture of Ruby though, so I don't expect Rails to ever change.

The lack of cutesiness in Elixir sounds lovely. I don't know if functional approaches could make up for a lack of typing for me; I think I'd need to try it. I've used and enjoyed Haskell, but of course that's very strongly typed.

As for magic, elixir can have what looks like magic, but upon closer look it's nothing more than macros, which are generally pretty easy to decipher and follow. It has minimal automatic code generation, what it has is mostly the form of generators you'd run once to add things like migrations

I'm looking forward to the upcoming gradual type system - it can only be an improvement - but I would still encourage people to try Elixir now, and let go of their preconceptions about static typing.

Wrote about it more here: https://arrowsmithlabs.com/blog/you-might-not-need-gradual-t...

I cracked open an Elixir book last night, and with the benefit of a few chapters, I can see how Elixir's pattern matching can obviate some of the issues I have with purely dynamic, Rails style programming.

I also note that there appears to already be more static typing going on than I realised. In your add_comment/2 code, for instance, you focus on the {published: true} pattern matching. That is very neat, but what stands out more to me is that all clauses of that function require BlogPost, a struct type.

Am I right in thinking that every instance of BlogPost type must be constructed explicitly in your code? I.e. that every possible instance of BlogPost in the code base is knowable at compile time, along with its entire life cycle?

Or does Elixir partake of the horror that is duck typing, where any conforming untyped map of indeterminate provenance will pass the guard check for a BlogPost?

> Would you like another undefined method exception on that NilClass?

*thousand yard stare*

In practice I find that I hardly ever need to think about things like this. A few times I've done macro expansion to peek under the hood and figure something out but that's partially Lisp damage, I could probably just as well have read some documentation.

Almost. You can create a struct dynamically at runtime like this:

    struct(BlogPost, %{title: "The Title"})
    # => %BlogPost{title: "The Title"}

> any conforming untyped map of indeterminate provenance will pass the guard check for a BlogPost?

Nope. In the `add_comment/2` example, If I pass anything except a %BlogPost{} to that function, I'll get an error.

While I remain haunted by thoughts of someone e.g. deserialising a YAML file into a map, which then sneaks in some __struct__ key and squeaks past the guard clause, I also appreciate this seems fairly unlikely in practice. I think I'm just traumatised by Rails. It sounds like the culture around Elixir eschews excessive cutesiness, though. Promising!

The performance of my crummy web apps. My understanding is that even something like ASP.NET or Spring is significantly more performant than either Rails or Phoenix, but I'd be very happy to be corrected if this isn't the case.

I appreciate the BEAM and its actor model are well adapted to be resilient under load, which is awesome. But if that load is substantially greater than it would be with an alternative stack, that seems like it mitigates the concurrency advantage. I genuinely don't know, though, which is why I'm asking.

> Elixir is gaining set theoretic type system, so you are showing up at the right time. https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...

Neat! Seems clever. Looks like it's very early days, though.

Phoenix has significantly faster templates than Rails by compiling templates and leveraging Erlang's IO Lists. So you will basically never think about caching a template in Phoenix.

Most of the Phoenix “magic” is just code/configuration in your app and gets resolved at compile time, unlike Rails with layers and layers of objects to resolve at every call.

Generally Phoenix requires way less RAM than Rails and can serve like orders of magnitude more users on the same hardware compared to rails.

The core Elixir and Phoenix libraries are polished and quite good, but the ecosystem overall is pretty far behind Rails in terms of maturity. It’s manageable but you’ll end up doing more things yourself. For things like API wrappers that can actually be an advantage but others it’s just annoying.

ASP.NET and Springboot seem to only have theoretical performance, I’m not sure I’ve ever seen it in practice. Rust and Go are better contenders IMO.

My general experience is Phoenix is way faster than Rails and most similar backends and has good to great developer experience. (But not quite excellent yet)

Go might be another option worth considering if you’re open to Java and C#

I've written APIs in Rust, they were performant but the dev experience is needlessly painful, even after years of experience using the language. I'm now using Rails for a major user-facing project, and while the dev experience is all sunshine and flowers, I can't shake the feeling that every line I write is instant tech debt. Refactoring the simplest Rails-favoured Ruby code is a thousand times more painful than refactoring even the most sophisticated system in Rust. I yearn for some kind of sensible mid-point.

Elixir seems extremely neat, but I've been blocked from seriously exploring it by (a) a sense that it may not be more any more performant than Ruby, so why give up the convenience of the latter, and (b) not having seen any obvious improvement on Ruby's hostility to gradual typing / overuse of runtime metaprogramming, which is by far my biggest pain point. I'm chuffed to hear that the performance is indeed better, that the magic in Phoenix happens at compile time, and that gradual types are being taken seriously by the language leadership.

I guess I'll have to take Phoenix for a spin.

The community and it's values, because you enjoy it, because the technology fits your use case. Most web apps fit. 1 and 2 are personal and I'd take a 25% pay cut to not spend my days in ASP or Spring, no offense to those who enjoy it.

I think the community tends to overestimate the ecosystem’s maturity which is one of the big things holding it back, both because it blinds the community to areas that need improvement and leads to bigger shocks when newcomers do unexpectedly run into the rough edges.

I'm a big fan of Ruby, but God I wish it had good, in-line type hinting. Sorbet annotations are too noisy and the whole thing feels very awkwardly bolted on, while RBS' use of external files make it a non-starter.

I am one of the authors of RDL (https://github.com/tupl-tufts/rdl) a research project that looked at type systems for Ruby before it became mainstream. We went for strings that looked nice, but were parsed into a type signature. Sorbet, on the other hand, uses Ruby values in a DSL to define types. We were of the impression that many of our core ideas were absorbed by other projects and Sorbet and RBS has pretty much mainstream. What is missing to get usable gradual types in Ruby?

Sorbet type annotations are noisy, verbose, and are much less easy to parse at a glance than an equivalent typesig in other languages. Sorbet itself feels... hefty. Incorporating Sorbet in an existing project seems like a substantial investment. RBS files are nuts from a DRY perspective, and generating them from e.g. RDoc is a second rate experience.

More broadly, the extensive use of runtime metaprogramming in Ruby gems severely limits static analysis in practice, and there seems to be a strong cultural resistance to gradual typing even where it would be possible and make sense, which I would - at least in part - attribute to the cumbersome UX of RBS/Sorbet, cf. something like Python's gradual typing.

Gradual typing isn't technically impossible in Ruby, it just feels... unwelcome.

When I do need types inline I believe it is the editor's job to show them dynamically, e.g via facilities like tooltips, autocompletion, or vim inlay hints and virtual text, which can apply to much more than just signatures near method definitions. Types are much more useful where the code is used than where it is defined.

I follow a 1:1 lib/.rb - sig/.rbs convention and have projection+ files to jump from one to the other instantly.

And since the syntax of RBS is so close to Ruby I found myself accidentally writing things type-first then using that as a template to write the actual code.

Of note, if you crawl soutaro's repo (author of steep) you'll find a prototype of inline RBS.

+ used by vim projectionist and vscode projection extension

This has (in my opinion) lead to a false sense that if something is not hyped as often, then its not used either.

At this poitn you can find tools that can make demos easier to build or get you further in a hackathon, but Rails embodies "Slow is steady and steady is fast." If you're trying to build something that will stick around and can grow (like a startup outside of the latest VC crazes) then Rails will arguably do better at keeping your tools relevant and supported in the long run. That is, assuming you're building something that needs a steady backend for your application.

I don't understand this at all. ruby on rails is probably peak technology for getting something up an running fast at a hackathon. its a very streamlined experince with a ton of drop in plugins for getting to the product part of the mvp. Maintaining a ruby app is a nightmare overtime. At least it was 5 years ago the last time I worked fulltime in a startup using ruby on rails.

These days I use elixir. its higher performance and reasonably fast to write in but I woudln't say its as productive as ruby on rails if you're competing in a hackathon.

Nothing in ruby forces you to make it a monolith of course, but the lack of types hurts

I do share your opinion on the untyped part, it's a bit of a bummer but there are gems to Ruby that helps with that.

Regarding the monkey patches, it's a concern many have and because of that, there is now a cleaner way of doing it! It's called a refinement. It's like monkey patching but in a more controlled way where you don't affect the global namespace.

https://docs.ruby-lang.org/en/master/syntax/refinements_rdoc...

Lmao you really think Stripe is still running primarily on Ruby? Yeah it's good for prototyping because it's fast to write in, but unmaintainable as hell for a real business.

Update: found a thread here on HN: https://news.ycombinator.com/item?id=29834840 I doubt they’ve rewritten everything to Java for the last three years.

Go and Rust are amazing languages, but why can’t they produce a Rails-like framework?

Is it just a matter of time before Go/Rust create a Rails-like framework, or is something fundamental preventing it?

Perhaps this article by Patrick Li (author of Stanza language) has the answers [1].

[1] Stop Designing Languages. Write Libraries Instead:

https://lbstanza.org/purpose_of_programming_languages.html

The Go community is more framework-averse, preferring to build things around the standard library and generally reduce third-party dependencies. Go also tends to be used more for backends, services and infrastructure and less for fullstack websites than Ruby/Python/PHP/C#.

The key to Rails is the Ruby language, it's very flexible. Someone were able to meta program Ruby code to the point that it was able to run JS code.

I didn’t mean like embed another languages runtime, I meant that they monkey patched Ruby to the point that they where able to run Javascript syntax as if it was plain javascript code.

It didn’t have the js runtime embedded, it was all still Ruby. The point was to showcase how much you can flex and bend the language and turn it into whatever DSL you like.

I’ve been trying to find the video but can’t find it, I believe it’s from RubyCon.

It's the reason Ruby has been used to create so many DSLs too.

That creates the closest thing I've seen in the wild the Aspect Oriented Programming, as it was explained to me in grad school at least. The ecosystem is pretty incredible because of it.

I'm about as big of an Elixir fanboy as you'll ever meet, but I'm constantly mentally torn between Elixir and Rails as the best options for projects because of this aspect of Ruby.

If you ask about this in rust communities online, they will tell you they don't want something like this, that Actix etc do everything they need. I'm baffled! Maybe they're making microservices, and not web-sites or web apps?

Ruby, meanwhile, optimizes for programmer happiness and Rails optimizes for programmer productivity. What other language-framework ecosystem has the same values alignment?

I've heard this criticism a few times – the fear that LLMs will be bad at Rails because there's no types – and I don't think it's accurate.

At least in my experience (using the Windsurf IDE with Claude 3.5 Sonnet) LLMs do a very good job in a Rails codebase for stuff like "I want to create a new page for listing Widgets, and a Create page for those Widgets. And then add pagination.". I've been able to spin up whole new entities with a model/view/controller and database migration and tests, styled with tailwind.

I think the reason strong types don't matter as much as we might assume is because Rails has very strong conventions. Routing lives in routes.rb, controllers go under app/controllers, most controllers or models will look very similar to other ones, etc.

Type information is something that has to be presented to the LLM at runtime for it to be accurate, but convention-over-configuration is stuff that it will have picked up in training data across thousands of Rails apps that look very similar.

On top of that, the core Rails stuff hasn't drastically changed over time, so there's lots of still-accurate StackOverflow questions to train on. (as opposed to something like Next.js which had a huge upheaval over app router vs pages router, and the confusion that would cause in training data).

In my opinion the future of LLM-aided Rails development seems pretty bright.

I just ran into an example of this trying to get it (Windsurf + Claude) to "rewrite this Objective C into Rust using the objc2 crate". It turns out objc2 made some changes and deprecated a bunch of stuff.

It's not figuring stuff out from base principles and reading the types to write this code, it's just going off of all the examples it was trained on that used the old APIs, so there's lots of errors and incorrect types being passed around. Hopefully it'll keep getting better.

Rails and especially Ruby lends itself to describing business logic as part of source code closer to natural language than a lot of typed languages imo and that synergizes really well with a lot of different models and neat LLM uses for code creation and maintenance.

Definitely agree I think Ruby's closeness to natural language is a big win, especially with the culture of naming methods in self-explanatory ways. Maybe even moreso than in most other languages. Swift and Objective C come to mind as maybe also being very good for LLMs, with their very long method names.

ETL pipelines, we catalogue and link our custom transformers to bodies of text that describes business cases for it with some examples, you can then describe your ETL problem in text and it will scaffold out a pipeline for you.

Fullstack scaffolds that go from models to UI screen, we have like a set of standard components and how they interact and communicate through GraphQL to our monolith (e.g. server side pagination, miller column grouping, sorting, filtering, PDF export, etc. etc.). So if you make a new model it will scaffold the CRUD fully for you all the way to the UI (it get's some stuff wrong but it's still a massive time save for us).

Patterns for various admin controls (we use active admin, so this thing will scaffold AA resources how we want).

Refactor recipes for certain things we've deprecated or improved. We generally don't migrate everything at once to a new pattern, instead we make "recipes" that describe the new pattern and point it to an example, then run it as we get to that module or lib for new work.

There are more, but these are some off the top of my head.

I think a really big aspect of this though is the integration of our scaffolds and recipes in Cursor. We keep these scaffold documents in markdown files that are loaded as cursor notepads which reference to real source code.

So we sort of rely heavily on the source code describing itself, the recipe or pattern or scaffold just provides a bit of extra context on different usage patterns and links the different pieces or example together.

You can think of it as giving an LLM "pro tips" around how things are done in each team and repo which allows for rapid scaffold creation. A lof of this you can do with code generators and good documentation, but we've found this usage of Cursor notepads for scaffolds and architecture is less labour intensive way to keep it up to date and to evolve a big code base in a consistent manner.

---

Edit: something to add, this isn't a crutch, we require our devs to fully understand these patterns. We use it as a tool for consistency, for rapid scaffold creation and of course for speeding up things we haven't gotten around to streamlining (like repetitive bloat)

I agree with The Grug Brained Developer (https://grugbrain.dev/) that “type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug”.

This already is being heavily replaced by LLMs (e.g. copilot) in many people’s workflows. Co-pilot’s suggestions are already mostly higher level, and more useful, than the static typing auto-complete.

I believe the quality-of-autocomplete gap between typed and untyped languages has already largely converged in 2025. Co-pilot today writing TypeScript just doesn’t produce overwelmingly better auto-complete results than JavaScript. Compare with 4 years ago, where Javascript auto-complete was trash compared with TS. And even then, people argued the merits of untyped: all else being equal, less is more.

What happens when “all else” IS equal? ;-)

Currently, static typing can help the LLM generate its code properly, so it has value in helping the LLM itself. But, once the LLM can basically hold your whole codebase in its context, I don’t see much use for static typing in implementing the “hit dot on keyboard, see list of things you can do” advantage. Essentially, the same way type inference / auto lets languages skip repetitive specification typing, by holding your whole codebase in memory the LLM can mostly infer the type of everything simply by how it is called/used. LLMs take type inference to the next level, to the degree that the type barely needs to be specified to know “press ., see what you can do”

I rarely use the static typing type of auto-completion when programming now, almost everything I accept is a higher level LLM suggestion. Even if that’s not true for you today, it might be tomorrow.

Is the remaining 10% of “formal correctness” worth the extra volume of characters on the screen? I suspect Rust will do well into the distant LLM future (used in contexts where formal correctness is relatively important, say kernels), and I suspect TypeScript will decrease in popularity as a result of LLMs.

In any case static types have many advantages, not just auto-complete. There's:

* refactoring

* finding references

* go to definition

* documentation

* bug prevention

LLMs are a million miles from being able to do any of that stuff automatically.

Yes, if only just for the ease of large-scale refactorings. And "extra volume of characters" is very limited if you use a modern language. In Haskell you could even not write a single type annotation in all of your code, although that's not recommended.

I doubt most people who like static types only do so because of autocomplete.

Does it suggest using rails generators for this - and/or does it give you idiomatic code?

With Ruby, it doesn't have as much information, so it has to rely on testing or linters for feedback.

Overall with Rails though, testing has always been pretty important partly because of the lack of types. I have noticed Windsurf is pretty good at taking a controller or model and writing tests for it though!

But everything old is new again.

Today there is better tooling than ever for these tools. I am using Django with htmx + alpine.js and sending HTML instead of JSON. Breaking free from JSON REST APIs is a huge productivity boost.

I worked at a company that, when faced with the choice between rewriting its Django apps in Python 3, and rewriting them in RoR, decided to go with the latter.

Now, I didn't like that since I was on an undermanned team that had literally just started a major update of a Django site, and it arguably wasn't the right way to go business-wise, but a lot of ideas that have come into Django over the years were ideas that existed in RoR.

I'd like to see that sort of innovation happen in some of the other spaces that Python is in, if for no other reason than to prevent monoculture in those areas. There needs to be offerings for Ruby in other areas, like scientific computing, machine learning/AI, and data analysis that get the same uptake that Rails does.

I think the language itself is definitely good enough to support the things Python does. But Ruby lacks in things like documentation and standards. RDoc isn't great, neither is bundler and there's no alternative to PEP.

Ruby's ecosystem does have some interesting alternatives to Pythons ecosystem. Like Numo for numpy, and Jupyter also supports ruby. But for a matplotlib alternative you have to bind to gnuplot.

I still use Ruby much more than Python anyway, my scripts often don't need external packages and Ruby as a language is such a delight to work with.

I base the above assertion mainly on looking at Who’s Hiring posts btw.

sidenote - is NextJS really the best “convention over configuration” approach for react? I’d love to just use ember, but most of the community has moved to react, but I really enjoy the opinionated approach

You might like Remix [0] (I do).

[0]: https://remix.run

If Intertia.js development halts, then you're stuck with either a) adopting something else, or b) maintaining the tool for your own use cases. Using something like this would, imo, be closer to building a Rails app in API mode with a separated frontend than adding a new library on top of Rails.

It looks like inertia has additional features though.

The main problem I have is the mixing up of low-level logic like web and database etc with high-level logic (ie. business rules). The easy path leads to a ball of mud with duplicated business rules across views and forms etc. How are people dealing with this? Does RoR fit into a larger application architecture where it does just the CRUD part and some other systems take over to do the business part?

It always seems to start well, you have your models, and views just doing CRUD stuff. But then someone says "I don't want to have to create an author before I create a book, let me enter new author details when I enter a book", and then the whole thing breaks. You need some logic somewhere to create authors but only in certain cases and of course the whole thing needs to be one transaction etc. Then you end up basically undoing all the simple views you did and essentially fighting the system to handle logic it was never designed to handle.

In essence, these systems make the easy stuff easy and the hard stuff even harder.

There are some people who have tried to abstract such things into yet another framework on top of Rails, e.g. I recall Trailblazer[0], but I have no idea if anyone still uses it.

[0]: https://trailblazer.to/2.1/

From the first page of Next.js docs: "Next.js is a React framework for building full-stack web applications"

> You don't need to worry about compiling, routing, code splitting, etc

IMO that's the least you'd expect from a web framework.

Also Rails only recently got authentication. For more than a decade you needed Devise or something else.

Meanwhile.. last I checked you still had to choose how you were going to roll your own auth in rails. Are people not often just installing bcrypt and adding a users table with their password hash? Or is there a generator for all that now?

Anyway, I disagree with the idea that Next is Rails-like. Adonis is probably still the closest in the JS/node ecosystem, though Redwood might also serve a similar niche for the types of apps it works for.

Next and the other "frontend metaframeworks" (as they're called now), are certainly much closer than the most popular choices 7 or 8 years ago (often cobbling together React and Express and an ORM like Prisma, making a bunch of other decisions, and then doing a bunch of the integration work by hand)

You get much out of the box with Rails 8 now like deployment, caching, job queue, Hotwire, Turbo Frames and mobile.

DB access (drivers are automatically started, connected, and wired for use), queues, cron jobs, websockets, uploads, API helpers, simple routing, caches, indexes...

It gets ignored, but there are (sane) options. I'm quite proud of the APIs, too. Easy to learn, tidy, and everything just works.

[1] https://cheatcode.co/joystick

Having mostly done agency work my whole life I have seen a lot of frameworks, in a lot of languages. Rails and Laravel are the standouts for just QoL experience, and Getting Shit Done.

They're engineered to get out of the way, and modular or extensible enough to enable deeper modifications easily.

It's kind of fascinating to me that all the frameworks in 'slow', dynamic languages (Rails, Laravel) are feature packed and ready to roll, and everything in 'fast', static languages is so barren by comparison. The two seem almost exactly inversely proportional, in fact.

A batteries-included web framework in Rust with comparable built-in functionality to Rails, and comparable care for ease-of-use, would be game changer.

I think there is a space for a more dynamic and high-level web framework in Rust, with an appropriate balance between leveraging the powerful type system and ease of use.

Rails isn't the right tool for every job, but I find that it's the right tool more often than not.

Rails is architected really well. Many decisions don't need to be made at all, and everything has a place. Plus, it's very friendly to extensibility and has a healthy ecosystem. It's mostly about the code that I don't need to write. It's really years beyond most other frameworks. Next will get there, but it will take it another 5 years. No shade on others, but Rails is just well built software with many years of learning and improving.

For highly reactive or "dynamic" systems, it probably isn't the right tool. Building a Figma or Notion. As @graypegg said in their comment, most websites work best as "CRUD forms". Though I would have said the same about email, but Hey.com exists so YMMV...

A feature, not a bug. Rails will continue to be good for building things long after the AI boom has died down.

Hotwire/Turbo/Stimulus with import maps is the prescribed way. Tailwind is emerging as the preferred CSS lib.

You could use Next.js + any API to create an application.

You could use Next.js + a sync engine to create an application.

You could use React Router + Vite + any API to create an application.

You could use React Router + Vite + a sync engine to create an application.

From the comment above: Next.js is the opposite of a "batteries included" framework. No abstractions for ORM, background jobs, sending emails, managing attachments, web socket communication - all very basic stuff when dealing with a production application.

So if that's the battery that you need, pretty much nothing else has it except for Next.js.

These days, I tend to want a web framework to do the hard things for me rather than the tedious/boilerplate but simple things like email-sending.

And frankly I'd like to see it since that's a really hard problem to just roll your own solution. And probably a huge waste of time if you're trying to ship a real product on top of it.

This makes absolutely no sense. HTTP is HTTP. Maybe one framework makes something more convenient than the other, but more "polished"? What does that even mean and what exactly is Next.js enabling?

But anyone who tries it without really understanding JS is eventually going to have a bad time. It’s important to know how to work with the event loop, how to properly use promises, etc. Server-side JS is a lot more unforgiving than front-end JS when it comes to these concepts.

What's the struggle specifically? How these general articles of opinion get to the first page of HN I'll never understand. Just random statements without anything to back them up.

Do those companies still run their businesses on RoR? My impression was that companies started out with it, but migrated to something more robust as their traffic grew.

Shopify is actually quite active in Ruby development and famously uses the new JIT compiler.

Stripe is still in on Ruby too; they're behind the Sorbet gradual type system, and Ruby is a first-class language for working with their API.

I always hear the stereotype of companies starting on Rails and migrating later, and I think it sticks around because it makes some level of intuitive sense, but it doesn't actually appear to happen all that often. I guess successful companies don't see the need to rewrite a successful codebase when they can just put good engineers to work on optimising it instead.

[0] https://shopify.engineering/ruby-yjit-is-production-ready

I started using rails in 2014, and I think this is some of the most exciting days in rails. Hotwire, Turbo, Stimulus + no build JS pushed the framework into what feels like next generation web development.

While all the same patterns exist in javascript, it seems like there are 5, 6, 7, 8 ways to do everything. Something as trivial as authentication has multiple implementations online, with multiple libraries, which is hugely frustrating.

The constant that's been with me from start to end: Django. Because it's fantastic and versatile. I still am kind of bitter the tutorial I followed wasted so much time on tangents regarding VirtualBox, Vagrant, Chef... I program most things in rust, but not web, because there is nothing there that compares.

What else would both teach programmers that nice languages exist, and that OOP leads to a nondeterministic spaghetticode hellscape? ;)

(I once spent an entire month debugging a transient login issue (session loss bug) on a million-line RoR app. Most of the bug ended up being something which merged a HashWithIndifferentAccess with a regular Hash, and key overwrite was nondeterministic. This type of bug is doubly impossible in something like Elixir- both since it is data-focused and not inheritance-focused, and because it is immutable.)

And I find that the "convention based" approach lends itself well to having AI write stuff for you.

Well, then there are those of us who use Django for similar reasons :)

This is a fascinating perspective, because building PWAs with raw js and very early react I always felt these were as good as iPhone app quality.

RoR got there first, but Python is a more relevant PL with broad ecosystem.

I would always recommend learning Django over RoR, unless you specifically want to learn a niche language.

It's a terrible and difficult transition that makes you question if the first language was really such a good choice after all, although it did get you where you are right now, which is more than you can say for a bunch of companies trying to do everything future proof from day 0

(* well, some people do, but they don't tend to survive)

I'd MUCH rather be a pessimist in Europe, languishing with an energy 9mm pointed at my head ... than an optimist under the Trump/Elon cabal ...

RIP DHH.

And if you’re gonna downvote, by all means - prove me that I’m wrong with stats. I sincerely hope that I am, because that last 60mins with the Germans churned my stomach hard.

> Moral point? “Democratic” European countries lock up more people for “mean” tweets and silent protests than autocratic Russia (who doesn’t claim to be democratic btw).

(Which, I don't think is true. I believe it is very-very false.)

[0] : https://pa.media/blogs/fact-check/russia-has-far-more-restri...

Dunno, maybe Brits or Germans want less economic growth, less freedom, more migrants and for Russia to invade them? Kind of tracks with their current trajectories I guess.

This isn't a majority position in Germany and probably not in many other European countries either: https://world.hey.com/dhh/leave-it-to-the-germans-94dd4bbe

In fact DHH admits as much in that very post.

Many Europeans I know (if we're trading anecdotes) find it deeply infuriating that an American vice president would meddle in German interior politics in such a way.

> Kind of tracks with their current trajectories I guess.

This is flamebait and against the spirit of the site.

Also, if anyone that wasn't JD Vance said the same thing about free speech in Europe, I'm sure the reaction would be much different. Germany's anti "insult" laws are ridiculous. Try that in Czech Republic or France, the whole country would insult everyone on social media just for the sake of it...

Just in December eight people were convicted in France for the beheading of teacher Samuel Paty. The lie of a schoolgirl skipping class led to a social media campaign against Paty, an imprisoned imam issued a Fatwa and then the murder of Paty by an 18-yr-old Chechen muslim. https://en.wikipedia.org/wiki/Murder_of_Samuel_Paty

So far those eight adults and six teens got sentenced but there are idiots who think it's cool to praise the murderer (who was shot by the police) as martyr and get themselves into prison/deported for that. I don't care what anyone's reasoning was, but no one's feeling can be hurt that much that it justifies the killing of another human being.

I guess in the US, where nothing can be done about almost daily school shootings, there's nothing they could do about this sort of Freedom of Speech, even worse: Not accepting election results and inciting an attack on Congress still gets you re-elected. It's sad DHH doesn't see that a few years in Malibu have turned him into a Free Speech Absolutist.

Freedom of Speech must end where it hurts others or even touches the limits of their freedom.

If they make threats or disrupt the work, sure, that's over the line. That's true regardless of their motivation though.

We are all human beings not robots. We have emotions. You can understand why a colleague wishing you didn't exist as a person is a net negative to the company right? Even outside work people move away from abusive relationships. Not tolerate it saying that's part of living in the world.

Which version of rails?

Did you work in rails for a year, then rewrite?

How long did the rewrite take?

Was it a rails monolith - server side rendering and no api?

Was the database schema good - did you keep it for the rewrite?

Was it a good fit for react?

That said, I've encountered a solid number of Rails projects that have been dumpster fires because their devs didn't follow conventions AND had horrible modeling/schema issues.

(Example: let's create our own job system that's many times worse than Active Job for no real reason...)

The other recurring thing that I see come up a lot with Rails projects is that nobody can really agree on where to put their business logic for anything complex.

So as to not be disingenuous, I suspect you're making a false dichotomy that rails = backend and nextjs = frontend and so they solve different problems?

But that said, I do sometimes choose Next.js because to me the biggest problem it solves is performance by allowing doing the rendering where it makes the most sense, even within the same page. Next.js allows you to seamlessly do rendering at different points depending on requirements. For example the static portions can be rendered once at build time (SSG) and served statically. If you don't have any dynamic stuff you can just serve your whole site with nginx and not even have node in the deployed stack! You can also SSR on each request, which allows you to do compute intensive things very quickly, and allows rendering differently based on server-side information (like DB queries, etc). You can also use standard client-side rendering for stuff that fits better there. That's especially useful for menus and reactive components.

It makes sense why nextjs kills my soul every time I touch it. For side-projects it's just me, for startups it's a few people where the entire premise of the company may change monthly, not to mention the API and product assumptions.

Perhaps it's just the millennial in me. Intentional frontend/backend bounded expertise is rather silly in a fledgling company.

Adding a separate JS frontend is a good way to double your costs and dev time. There's few situations that demand such heavy JS but people follow trends like sheep. And I say that as a frontend engineer who wrote JS/TS for a decade.

In fact, I've never seen a RoR job posted in my area. Mostly PHP, Python and JS.

But you know, you gotta give credit where credit is due. Laravel would not be a thing if it weren't for RoR. RoR was incredibly influential.

Ok, so maybe I exaggerated, I've dabbled in these languages. Not really formally learned them. Or at least .... I can't say I've learned them if I haven't done any paid work with them.

The trick is to get jobs where people don't care about your tools but only the results. And then you can use whatever tools you want. Did that long ago with Django when there was literally no Python jobs in my area.

But it is a fun language.

Also latest Python is faster than the current Ruby let that sink in. You can go even faster if you do a compiled Python like PuPu.