Not sure about Rails, haven't used it in more than a decade, but NextJS was a major contributor to massive burnout. Of one thing I'm certain: Phoenix is my last web framework. I love it to bits, and I hope to retire before it stops being cool.

Yep! It'd be possible with Next.js. The difference is how it's organized. In Next.js with RSCs, we were fetching data for each part of the page where it's used (trending books, Live events, blog posts, favorite books). Each of those could be their own cache hit to Redis.

One advantage of Rails is the controller. We can fetch all data in s single cache lookup. Of course it'd be possible to put everything needed in a single lookup in Next.js too, but then we wouldn't be leveraging RSCs.

I tried self-hosting Next.js on Digital ocean, but it crashed due to memory leaks without a clear way to understand where the leak was. Google Cloud Run and Vercel worked because it would restart each endpoint. We have more (and cheaper) hosting options with Rails.

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

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

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

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

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

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

See here:

https://github.com/heartcombo/devise/blob/main/lib/devise/co...

        def self.define_helpers(mapping) #:nodoc:
        mapping = mapping.name

        class_eval <<-METHODS, __FILE__, __LINE__ + 1
          def authenticate_#{mapping}!(opts = {})

It hurts my soul.

---

I have now done several Google searches to - well, admittedly, to try and counter your argument; but what I've since found is:

  * Every friggin' benchmark is wildly different [0, 1]
  * Some of these test pages are obnoxious to read and filter; **BUT** Javascript regularly finds itself to be **VERY** fast [0]

I will probably be able to find another benchmark that says completely different things.

Benchmarking is hard.

I'm also having trouble finding the article from HN that I was sure I saw about Next.JS's SSR rendering performance being abysmal.

[0] https://www.techempower.com/benchmarks/#section=data-r23

[1] https://web-frameworks-benchmark.netlify.app/result?asc=0&f=...

Customer.limit(1000).to_a

completes in about 10ms, whereas:

Customer.last(1000).pluck(:id, :name, :tenant_id, :owner_id, :created_at, :updated_at)

runs in around 7ms.

Active Record methods are defined at application boot time as part of the class, they're not rebuilt each time an instance is created. So in a typical web app, there's virtually no performance penalty for working with Active Record objects.

And when you do need raw data without object overhead, .pluck and similar methods are available. It’s just a matter of understanding your use case and choosing the right tool for the job.

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.

What app stores don't like is you reinventing javascript i.e shipping your own VM. What they don't mind is you reinventing html and css.

So it is common for servers today to send mobile apps

  {"Elementtype": "bottom_sheet_34", "fg_color": "red",..., "actions": {"tap": "whatever"}, ... }

This is what the GP is talking about.

It covers a surprising number of usecases, especially since many actions can be simply represented using '<a href>' equivalents -- deeplinks. With lotties, even animations are now server controlled. However, more dynamic actions are still client-controlled and need app updates.

Additionally, any new initiative , think new feature, or think temporary page for say valentine's day, is all done with webviews. I'm not clued in on the review process for this.

Nevertheless, if your app is big enough then almost every rule above is waived for you and the review process is moot, since once you become popular the platform becomes your customer as much as you are theirs. For example, tiktok ships a VM and obfuscated bytecode for that VM to hinder reverse engineering (and of course, hide stuff)

I could be misremembering, but didn't browsers used to have this built in? Like there used to be a status bar that showed things like network activity (before we moved to a world where there is always network activity from all of the spying), upload progress, etc.

I don't remember if it was in Firefox, but SeaMonkey even has a "pull the plug" button to quickly go offline/online in the status bar.

Bizarre that "progress" is removing basic functionality and then paying legions of developers to re-add it in inconsistent ways everywhere.

Maybe, but it doesn't necessarily need to be a SPA framework though. There are simpler libraries/frameworks like htmx that considerably reduce complexity and also let you avoid direct DOM manipulation.

Further, being against a bloated framework is not the same as being against frameworks. Those frameworks are actually principles. It’s possible for a team to come up with or use existing principles without using a framework.

Finally, “always use React” brings other costs. You need a team to build your system twice. That means you need bigger teams; more funding to do the same thing, and so on. You add complexity at the team level and at the software level when using frameworks. The person above you said that blindly “following best practices” is bad while stating a “best practice” of always start with React. That particular “best practice” not always being the best practice is the entire point of this thread.

So, the components themselves will look something like this:

    fun HtmlBlockTag.radioButtonWithLabel(
        groupName: String,
        id: String,
        hidden: Boolean = false,
        radioButtonFunc: (INPUT.() -> Unit)? = null,
        func: LABEL.() -> Unit
    ) {
        radioInput(name=groupName) {
            this.id = id
            this.hidden = hidden
            radioButtonFunc?.invoke(this)
        }
        label { this.htmlFor = id; func() }
    }

  call.respondHtml {
      body {
          div(CSS_CLASS_NAME) {
              radioButtonWIthLabel(MORE_CSS_CLASS_NAME, "group", "id") {
                  +"Text for the label"
              }
          }
      }
  }

I've also got whole files dedicated to single extension functions that end up being a whole section that I can place anywhere.

---

And then to test those single-function components, I'll do something like this:

  class SingleSectionTest {
      private suspend fun ApplicationTestBuilder.buildApplicationAndCall(
          data: DataUsedForSection
      ): Document {
            application {
                routing {
                    get("test") {
                        call.respondHtml {
                            body {
                                renderSingleSection(data)
                            }
                        }
                    }
                }
            }
    
            val response = client.get("test")
            val body = Jsoup.parse(response.bodyAsText())
    
            return body;
        }

      @Test
      fun `simple test case`() = testApplication {
          val data = DataUsedForSection("a", "b", "c")
          val body = buildApplicationAndCall(data)
          
          // all the asserts
      }
  }

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.

Even the search box itself lags when typing because somehow the text input is synced to the autocomplete search?

/rant

How many integration tests do you have? I generally only test a few core flows and then leave the rest to controller/request tests.

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

Then the security looks also annoying to manage, yeah sure the front-end can do whatever it wants but nobody ever wanted that.

You write:

  <div id="moo" />
  <form hx-put="/foo" hx-swap="outerHTML" hx-target="#moo">
     <input hidden name="a" value="bar" />
     <button name="b" value="thing">Send</button>
  </form>

  <div id="moo" />
  <form>
     <input hidden name="a" value="bar" />
     <button name="b" value="thing" onclick="handleSubmit(event)" >Send</button>
  </form>

  <script>
  async function handleSubmit(event) {
    event.preventDefault();
  
    // the form submit stuff
    const form = event.target.form;
    const formData = new FormData(form);

    const submitter = event.target;
    if (submitter && submitter.name) {
      formData.append(submitter.name, submitter.value);
    }

    // hx-put
    const response = await fetch('/foo', {
      method: 'PUT',
      body: formData,
    });

    / hx-swap
    if (response.ok) {
      const html = await response.text();
      // hx-target
      const target = document.getElementById('moo');
      const temp = document.createElement('div');
      temp.innerHTML = html;
      target.replaceWith(temp.firstElementChild);
    }
  }
  </script>

https://github.com/bigskysoftware/fixi

People with bad intentions can make those slow queries happen at high volume with custom tooling, they don’t have to restrict themselves to how the frontend uses the queries

The tools and patterns to limit these (very common, in any kind of system) drawbacks are so well-established that its a non-issue for anyone sincerely looking at the tech.

Didn't everybody say the exact same thing about Node, React, jQuery...? There is always a new and shiny frontend JS solution that will make the web dev of old obsolete and everyone loves it because it's new and shiny, and then a fresh crop of devs graduates school, the new shiny solution is now old and boring, and like a developer with untreated ADHD, they set out to fix the situation with a new frontend framework, still written in JavaScript, that will solve it once and for all.

I still build websites now the same as I did when I graduated in 2013. PHP, SQL, and native, boring JavaScript where required. My web apps are snappy and responsive, no loading bars or never-ending-spinning emblems in sight. shrug

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.

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.

'Twas before my time. What was so great about it? I remember needing it installed for Netflix like 15 years ago. Did you ever work with Flash? How was that?

https://www.w3.org/TR/html-imports/

So, I did end up going with #1 with a slight variation.

You also commented on another comment of mine stating:

> if you are using the htmx javascript API extensively rather than the attributes, you are not using htmx as it was intended

There seems to be some confusion, and I apologize. I extensively used attributes. That wasn't the part of the API I was referring to. Rather, I should have specified that I was heavily relying on a lot of the htmx.on() and html.trigger() methods. My usage of htmx.trigger() was predominately due to something being triggered on page load, but also, it needed to be triggered again if a certain condition was met -- to refetch the html with the new data -- if that makes sense.

I should also preface that I was working on this project about two years ago. It looks like a lot has changed with HTMX since then!

Most companies aren’t international.

I greatly prefer Java with Spring Boot for larger backend projects.

If you can exchange static content, you need very little scripting to be able to pull down new interactive pieces of functionality onto a page. Especially given that HTML and CSS are capable of so much more today. You see a lot of frameworks moving in this direction, such as RSCs, where we now transmit components in a serializable format.

Trade offs would have to be made during development, and with a complex enough application, there would be moments where it may be tough to support everything on a single page. However. I don’t think supporting single page is necessarily the goal or even the spirit of the web. HTML imports would have avoided a lot of unnecessary compilers, build tools, and runtime JS from being created for example.

https://www.w3.org/TR/html-imports/

Yes, obviously, but do these maintain state after hot reload?

Do you understand how compiled queries in GraphQL (or even an old-school RDBMS) work? All that gets sent over the wire is the query id. There's physically no way to make the server execute a query the author didn't write.

As fun side anecdote, if you're doing scientific computing in a variety of fields, Fortran 95 is mostly still fine ;)

They should have designed it as a proper native experience.

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.

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.

1. Fetch index.html 2. Fetch js, css and other assets 3. Load personalized data (json)

But usually step 1 and 2 are served from a cdn, so very fast. On subsequent requests, 1 and 2 are usually served from the browser cache, so extremely fast.

SSR is usually not faster. Most often slower. You can check yourself in your browser dev tools (network tab):

SPA: https://www.solidjs.com/

vs.

Poster child SSR: https://nextjs.org/

So much complexity and effort in the nextjs app, but so much slower.

SSR also has excess round trips by nature. Without Javascript, posting a form or clicking a like button refreshes the whole page even though a single <span> changed from a "12 likes" to "13 likes".

Please forgive the self-promotion but this was exactly the premise of a conference talk I gave ~18 months ago at performance.now() in Amsterdam: https://www.youtube.com/watch?v=f5felHJiACE

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.

That's never the case.

Yes, that one. I want that experience please.

This is where I know that, some people, are not actually programming in either of these languages, but just writing meme driven posts.

JS has a few footguns. Certainly not so many that it's difficult to keep in your head, and not nearly as complex as C++, which is a laughable statement.

You've "seen null make it to the database," but haven't seen the exact same thing in C++? Worse, seen a corrupted heap?

Make std::string null. You can’t. Make std::vector null. You can’t. It’s one of the benefits of a value types.

That, alone, eliminates a whole class of bugs that’s JS has. Yes, there’s edge cases in C++ too. The edge cases are the common cases in JS in this regard and that’s why I class them differently. Really, every language can do everything, basically. But how easy is it, and how common is it?

Also, for the record, using an initialized variable will result in a warning or compilation error.

None of this is to say that C++ does not have other glaring problems that JS does not. But, in my experience, it’s slightly more difficult to create logic bugs in C++. I also have worked with PHP - similar situation to JS. Too footgunny that in practice the codebase is riddled with bugs that rarely manifest, but are there. Everything you do has, like, a dozen implications and edge cases you need to consider.

I agree with this. Sprinkle in the JS as and when it is needed.

> The problem with SPAs is that they force having to maintain a JS-driven system on every single page, even those that don't have dynamic behavior.

I don't agree with this: SPAs don't force "... having to maintain a JS-driven system on every single page..."

SPA frameworks do.

I think it's possible to do reasonably simple SPAs without a written-completely-in-JSX-with-Typescript-and-a-5-step-build-process-that-won't-work-without-25-npm-dependencies.

I'm currently trying out a front-end mechanism to go with my high-velocity back-end mechanism. I think I've got a good story sorted out, but it's early days and while I have used my exploratory prototype in production, I've only recently iterated it into a tiny and neat process that has no build-step, no npm, and no JS requirement for the page author. All it uses is `<script src=...>` in the `<head>`, with no more JS on the rest of the page.

Very limited though, but it's still early days.

Notification count in the top right?

Remaining credit on an interactive service (like the ChatGPT web interface)?

So, maybe two(!) business use-cases out of thousands, but it's a pretty critical two use-cases.

I agree with you though - do all normal HTML form submissions, and for those two use-cases use `setInterval` to set them from a `fetch` every $X minutes (where you choose the value for $X).

Which is what HN does and it sucks. It's very common for me to vote on a couple things and then after navigating around I come back to see that there are comments that don't have a vote assigned.

Of course the non-JS version would be even more annoying. I would never click those vote buttons if every vote caused a full page refresh.

> You can write each endpoint by hand instead of using GraphQL, but it's like writing your own collection datatypes instead of just pulling in an existing library.

Everyone else is "pulling in an existing library", they have names like Express and Kysely, and thinking that Apollo is the only library that deserves this designation is a bit of a head-scratcher.

If you take the time to invest in a proper REST API first, odds are the endpoint may already exist, and you may not need to wait for a new backend build; not investing in a custom endpoint for every frontend change unless real-world performance requirements actually dictate it. You get tooling that is more mature and easier to maintain as a result, makes it easier for Product to experiment (remember: not forcing a backend change for every frontend change), and not using a fad-of-the-month just because it came out of a FAANG.

I think that’s a feature not a bug.

But then again, I generally like and use Typescript.

The horrors I’ve seen. Constructing a custom string based off of user input and then tacking on () and calling it as a function? We can do that? Apparently yes we can. The most cursed type of polymorphism where nothing makes sense and you’d have more success communing with the dead than deducing the control flow.

I can't really speak for those sites anyway, or why they are so slow doing things on the client, but like I said, I've written client-side processing and used my 2011 desktop, and there has been no pegging of the CPU or large latencies when filtering/sorting data client-side.

> while absolutely massively complex and large server-rendered HTML loads and renders in an eyeblink.

I've not had that experience - a full page refresh with about 10MB of data does not happen in an eyeblink. It takes about 6 seconds. There's a minimum amount of time for that data to download, regardless of whether it is pre-rendered into `<table>` elements or whether it is sent as JSON. Turning that JSON into a `<table>` on the client takes about 40ms on my 2011 desktop. Sorting it again takes about 5ms.

For this use-case (fairly large amounts of data), doing a full-page refresh each time the user sets a new sort criteria is unarguably a poorer experience than a bit of JS that goes through the table element and re-orders the `<tr>` elements.

In this case, using server-rendered HTML is always going to be 6000ms whenever the user re-sorts the table. Using a client JS function takes 5ms. On a machine purchased in 2011.