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

Post by yellow_lead » Sun, May 04, 2025, 4:29 PM UTC

petetnt wrote: post #392

yellow_lead wrote: post #389

Earlier quoted context omitted.

I don't have this delay personally. Probably the page speed metric is more accurate because it smooths out anecdotes like ours.

Page speed metric shows 5.2s for the first contentful paint for the mobile home page too: https://pagespeed.web.dev/analysis/https-hardcover-app-feed-...

Post by lemonwaterlime » Sun, May 04, 2025, 4:44 PM UTC

quantadev wrote: post #147

CooCooCaCha wrote: post #77

Earlier quoted context omitted.

I’ve been saying this for a long time. It takes very little effort to spin up a react app so there’s little point in starting a project without it or whatever front-end framework you prefer. As I’ve become more senior I’ve realized that software devs have a tendency to fall for software “best practices” that sound good on paper but they don’t seem to question their practical validity. Separation of concerns, microser…

I agree, just use React from day one. The reality is that web pages are hardly ever perfectly static, and once there's any dynamic nature to it at all you need something like React or else you'll have a train wreck of JS DOM-manipulation calls before you know it. React is perfect. You just update your state and the page magically re-renders. It's a breeze.

Post by dyogenez » Sun, May 04, 2025, 5:01 PM UTC

Version467 wrote: post #355

3sbi wrote: post #112

I remember reading their blog post about how moving from pages router to app router in Next.js helped their SEO last year. This time they are moving from Next to React+Inertia.js because of growing bills from Vercel even though deploying the same app on your own VPS instead of relying on cloud provider would probably solve the issue. Nonetheless, I still don't understand their yearn for complexity - does book trackin…

I stumbled upon hardcover when I was looking for a book info api and saw that goodreads discontinued theirs. Although it's pretty rough around the edges I've been using it extensively since then. As far as I understand hardcover was really created because goodreads discontinued their api and the team at hardcover saw how many people relied on it for a myriad of different niche projects. If hardcover was just a replac…

Post by t-writescode » Sun, May 04, 2025, 5:13 PM UTC

catgirlinspace wrote: post #375

t-writescode wrote: post #256

Earlier quoted context omitted.

Not OP; but when I was thinking about using Next.JS, and doing a deep investigation, I came to the decision that, for server-side rendering, I'm quite happy to use Kotlin and Ktor (my backend is also Kotlin - I have a lot of client-types, which is why they're separate), and I've been quite happy with Ktor's html dsl + htmx for speed. And Kotlin + Ktor feels very good to write in on serverside. Fast, easy and fluent t…

How are you doing reusable components with the html dsl? From the little bit I’ve tried ktor this was something I could not figure out and it kinda just pushed me away since I couldn’t find anything.

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

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

Post by t-writescode » Sun, May 04, 2025, 5:35 PM UTC

neonsunset wrote: post #368

t-writescode wrote: post #353

Earlier quoted context omitted.

I believe(?) stats have shown that Java, C#, Elixir, Rust and friends are going to be quite fast, but Node.JS is going to be even slower than Ruby. At least, Next.JS (which is on top of node, I think?) will be.

Sounds improbable. Unlike Ruby, JavaScript has multiple runtime implementations with capable JIT compilers that sometimes let it even compete with Java on numeric code. Ruby is very, very far away. Please note that Elixir is also in the same single-threaded performance ballpark as Ruby and Python, of course it does not suffer from any of the single-threaded bottlenecks the other two do though.

  * 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]