Live data from Hacker News

Things I wish I knew before moving 50K lines of code to React Server Components

mux.com

401–410 of 540 posts

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#401

Stop a second before you go into RSCs. Whatever you want to achieve ultimately is much easier/quicker/scalable done in real fullstack (or classic web-) frameworks! Rails/Django/Laravel/… + Turbolinks/Htmx/… or even sprinkle some light clientside JS for fancyness. Or go best-of-all-worlds if you happen to know Elixir/Phoenix. But don’t continue the descent into RSCs, now matter how many people tweet about it. These fo…

> Or go best-of-all-worlds if you happen to know Elixir/Phoenix.

Muxer here, and fun fact, Elixir is a core piece of our infrastructure and has been from the start! At the very beginning our dashboard interface was all rendered by Phoenix and occasionally a page would individually include React if it was a situation that truly needed advanced client-side interaction. Given that our first product was an analytics dashboard, that latter situation quickly became basically our entire dashboard and it simply made sense to move to a full SPA taking advantage of the API we were exposing to customers anyway. This was 2016, so LiveView didn't exist at the time, but I'm still not sure I'd make a different decision for that product today.

The blog post is talking about the application that powers our public marketing site, which has a pretty different set of needs, but figured I'd throw it out there that we use and love Elixir/Phoenix! :)

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#402

Earlier quoted context omitted.

Pure "content" sites don't need to be SPAs, but web "applications" suck ass rendered server side.

Citation needed. 99% of apps are basic CRUD apps. Aside from a few interactive pages - which you could even write with React - there's zero need for this bloat. No, your "application" is not Google Docs, Spotify, etc. It's not a SPA.

I didn't make any statement about what an application is, or isn't, or what percentage of the internet is in fact applications. That being said, things like Figma exist and wouldn't if the web was only static pages, so there's a compelling argument to be made for the existence of SPAs.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#403
I wonder how many people have attempted to build what they want starting from an empty JS file.

I think most people are scared of what they will find.

That the decades they have spent twisting themselves around frameworks and learning all these abstractions, is not actually necessary at all.

We already have a really nice _declarative_ abstraction in the form of HTML/CSS.

I don't know why we decided to cram everything into the view layer.

Separate your logic into a view model, and then data bind to it.

A simple data binding framework is very easy to write. And then you have full control over everything!

Compare the size of the code below and how easy it is to debug/trace....to the enormous React/Angular/etc. codebases.

    const bindings = [] // {elementId, modelId, componentId}

    // Allows looking up functions by strings, that are referenced in server-side code.
    //   Normally we could just reference function objects in memory, but in two separate environments we must use strings.
    const components = {}

    // Model
    ////////////////////

    const models = [{id: shortId(), count: 1}]

    const model = models[0]

    // Server-side render route
    ////////////////////

    function renderPage() {

      // Create view
      const div = createCounterComponent()
      document.body.appendChild(div)

      // Send this to the client.
      const html = document.documentElement.outerHTML
      const ssrScriptEl = document.createElement('ssr')
      ssrScriptEl.textContent = JSON.stringify({models, bindings})
      document.body.appendChild(ssrScriptEl)

      return new Response(html)
    }

    // Client-side main function
    ////////////////////

    function clientMain() {
    
      window.ssr = JSON.parse(document.getElementById("ssr").textContent)

      rehydrate(models, bindings)

      // Update model and notify view.
      model.name = 'goodbye'
      onModelChange(model.id)

    }

    function rehydrate(models, bindings) {
      for (const binding of bindings) {
        const {modelId, elementId, componentId} = binding
        const element = document.getElementById(elementId)
        const component = component[componentId]
        const {setup, render} = component
        setup(element, model)
      }
    }

    function onModelChange(changedModelId) {
      const affectedBindings = window.ssr.models.filter( ({elementId, modelId}) => modelId === changedModelId )
      for (const binding of affectedBindings) {
        const {elementId, render} = binding
        const element = document.getElementById(elementId)
        render(element, model)
      }
    }

    // Component
    ////////////////////

    function createCounterComponent(model) {
      const div = createElement('div', model, createCounterComponent)
      return div
    }

    // Doesn't run during SSR rehydration.
    function render(element, model) { 
      element.innerHTML = model.count
    }

    // Does run during SSR hydration.
    function setup(element, model) {
      element.onClick = () => { model.count++ } 
    }

    createCounterComponent.setup = setup
    createCounterComponent.render = render
    registerComponent(createCounterComponent)

    function registerComponent(component) {
      const componentId = component.name
      components[componentId] = component
    }

    ////////////////////

    function createElement(elementType, model, componentFunction) {
      const {render, setup} = componentFunction
      const componentId = componentFunction.name

      const element = document.createElement(elementType)
      const elementId = shortId()
      element.id = elementId

      const modelId = model.id

      bindings.push({elementId, modelId, componentId})

      render(element, model)

      return element
    }

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#404

Earlier quoted context omitted.

Please help the guy before he gets too far along. Some of us might have to work with him. Seriously though, I saw someone described as a 22 yr old software engineer in an article. There is a better term: "Software Engineering Apprentice"

Unionize already. It's not just about wage, it's about assigning appropriate work to peoples level and having them progress through the most efficient steps to mastery while also completing billable hours

> ...it's about assigning appropriate work to peoples level and having them progress through the most efficient steps to mastery...

that's the opposite of what a union does. A union rewards seniority and nothing else.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#405

Earlier quoted context omitted.

“This technology we heavily rely on is completely changing the way it works. Should we update now and get into the ecosystem?” “Nah, this guy on hacker news said we’re dumb hipsters for adopting the new normal for react. We should stay on the old versions.” That’s like saying you don’t trust a company because they updated from PHP 5 to PHP 8.2

More like "hey we just spent 8 months of investor money on a rewrite and this works much worse than the previous solution. But hey, they're throwing this out and the new thing is ReactWebLogic, let's do a new rewrite!"

This might be fair if this was a rewrite in a vacuum (or took anywhere close to 8 months) but it wasn't. We were also undergoing a large design refresh for the site, which was going to require a ton of work on the existing site anyway. Using the opportunity to also update to the newest version of the technology we were using wasn't nothing, but I'd argue it was also probably a pretty small marginal increase.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#406

I'm old enough to remember when servers rendered everything and you used CSS and Javascript to enhance the pages after they were rendered. The web is in such a dark and overengineered place. It's almost unbelievable. It's why my approach to building apps is server-rendered first and then enhanced after the fact.

I agree for the most part. Collapsable dropdowns and jQuery drag-and-drop are nice-to-haves, but I also clearly remember the hellscape of state management in js/jQuery and I'm not to keen on going back to that.

To this day I don't understand people saying this. Can you describe a project or instance where it was tough? I never had any issues even in complicated projects with thousands of lines of JS.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#407

In server-side rendering, clients are sent HTML that they can see immediately I noticed this too. You can put a plaintext file on the server and it gets transferred to the browser pretty fast. You can also put another plaintext file ending with .css on the server and it can make things on the first page move and look really nice just because the browser knows what to do with it. It’s a neat trick but still second to…

My brother just started learning web development this past year and his mind was blown when I told him you could send HTml over HTtp.

Reminds me of the joke about, "Omg, that's amazing, the new iPhone will support voicechat ... and you can use your phone number as your screenname!"

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#408
post #349

Earlier quoted context omitted.

I slapped my forehead when I was reading a thread about HTMX and someone asked. "How can you send HTML to the browser without JavaScript?"

It's not React's fault but the ignorance of the average React dev never stops surprising me. From using divs for buttons or links to this.

Yeah modern JavaScript frameworks heavily discourage semantic markup, and I’m salty about it.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#409
post #199

Earlier quoted context omitted.

If your career can be significantly affected by devs fresh from bootcamp, you probably need to sort out your own issues than to complain here mate.

If your career can be significantly affected by devs fresh from bootcamp Well, there are certainly problems if that's the case. But it's not necessarily senior ICs that are the problem. I've experienced a few companies where "boot camp yahoos" wound up essentially running the show to ruinous effect. Why? They had numbers, essentially, and management was too hands-off to prevent it. To give a specific example: we had…

You describe the scenario I am complaining about. These boot camp developers do not have the background for large scale engineering, yet get cast into it side by side with real seasoned engineers. However, that real seasoned engineer is a small fraction of the "dev team" and gets overwhelmed by the boot camp developer's group thinking - their opinion is just as good as the guy with the CS degree they figure, after all, their boot camp crowd seems to win the debates! And the employer's development quality goes to shit as the people actually trained on large scale project development are overwhelmed by fast food educated "developers".

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#410
post #216
post #174

Earlier quoted context omitted.

Basically avoiding the mistake Angular made (moving from 1.x to 2+)

And yet Angular is now the less complicated framework and easier to work with (IMO).

I admire parts of Angular's vision and think there are patterns where it shines, but it's never quite felt like they actually hit 2.0 to me. I haven't worked with it in a few versions, but I think it's just a different set of complexities.

There's always some big or missing thing right around the corner... reworking Material components for years, reworking internationalization, improvements to reactive forms, zoneless Angular, single file components, etc. And, for as many bugs as they fight down, it's always felt like there were several obvious frustrations waiting to be fixed. It's all just left me with an impression that the team bit off more than they could chew in creating such a holistic solution and can't quite get to something solid, hence the need to shed things like Protractor.

Hopefully the cumulative effort to improve gets them somewhere and helps get Angular into a more complete and compelling place for folks.

Post reply on HN