What else am I missing?

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.

If you're considering k8s, take a look at Kamal (also from DHH): https://kamal-deploy.org/

I think it makes more sense for small clusters.

https://gist.github.com/philipithomas/ed57890dc2f928658d2c90...

https://en.wikipedia.org/wiki/Mount_Olympus_(San_Francisco)

My shorter-term goal is to switch my home internet to Starlink, so that all requests bounce off a satellite before landing at my desk.

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

https://developers.cloudflare.com/ssl/reference/certificate-...

I had 2m35s of downtime due to power outages this week.

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.

So you end up having to put depth and quantity limits, or calculating the cost of every incoming query before allowing it. Another approach I'm aware of is whitelisting but that seems to defeat the entire point.

I use rest for new projects, I wouldn't say never to graphql, but it brings a lot of initial complexity.

Multiple models managed on a single page, each with their own controllers and isolated views.

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.

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.

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.

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

No need for any outside dependencies.

https://www.youtube.com/watch?v=aOk67eT3fpg&ab_channel=Theo-...

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

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.

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?

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

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

</shamelessselfplug>

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.

Feel.

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

I’ve started qualifying such statements… “you mean a real engineer or just a software developer?

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.

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.

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.

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!

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.

here's what I get

`Possible values: importmap, bun, webpack, esbuild, rollup`

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

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

There are a few acquisition companies and teams using Rails inside Amazon.

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.

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)

including the person you replied to

Also, DHH is the one who has started to use his platform to be extremely vocal about politics and push Trumpism. We're allowed to criticize that.

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.