The font looks weird and uneven horizontally (some characters are "fatter" like if they were randomly bold). Is it supposed to look like that? Firefox + Windows.
It depends a lot on the specific business and company stage. E.g. CTOs at boutiques basically meet clients and put on a performance to instill trust. CTOs on product startups with little funding are more like "I'll hire a teammate that can put up with the mess I wrote". CTOs after the product startups have large investments are more like "I'll pretend I know what I'm doing and let the principal engineers actually run the tech and fix my legacy mess so we don't go out of business". CTOs at corpos are just C-suite politicians. Etc.
I find CTO as a title meaningless. At most it means they've got the signature powers.
I was CTO from 2 to 100, over 6 years, and led the core tech development the entire time. Tech Co-Founders certainly can and do code. I was a Principal Engineer before and after.
In a sense, you are right that the title is meaningless, and only means signature powers.
And you are right that other principals rewrote legacy stuff. But I also participated at the same level. I just knew I was only above due to some market luck lining up with my experience. Will never know exactly how much influence I had over that situation.
But I have a Jazz background. It is easy for me to respect equally everyone on the team. Sports can do the same, but I think music is probably more effective, because it is inherently more spectator than competitive. Musicians tend to make incredible team players, if they stuck with it for long enough. Many leaders in band are leaders in sports, in school. And the formal language abilities are already demonstrated in musicians.
LMAO I asked GPT-4o and it was doing good until...
> The twist is that the nurse’s logic ("you are a dog") prevents her from realizing the real issue — likely, again, that the surgeon is the boy’s mother, and everything else is a red herring or metaphor for society’s failure to recognize this due to bias or absurd bureaucracy.
> So:
> > Why can't the surgeon operate on the boy?
> Because she is his mother, and the nurse's bias or absurd assumptions (like mistaking her for a dog) prevent her from seeing that.
o4 fails spectacularly in a different way:
> 1. The nurse says “Sir, you are a dog… Canines cannot be in an operating room” because she’s picturing a human hospital law that bars dogs from surgery.
> 2. In fact, this is a vet clinic—so it’s perfectly normal for a dog-veterinarian to scrub in and operate on a puppy (the “boy”).
> 3. The surgeon cannot operate on a human boy because he’s a dog and holds no human‐medical license; instead, he only operates on animals.
As someone that knows both Lisp and RSC, I don't think this is a great analogy since it misses nuances and intention in both sides of the equation.
The crux of Lisp's code-is-data-is-code is that you can manipulate S-expressions since they're a very simple data structure (think metaprogramming). I know you touched upon this in the article but acknowledging it doesn't make it less central to the issue.
I don't see the parallels except a very superficial similarity due to code being "serialized" (for lack of a better term, since that's not even what Lisp does) but that's just (1) a technical detail that glosses over the actual intention/capabilities and (2) not even true if we go down to the technicals.
But that might just be my personal priors, so take it with a grain of salt.
To me, the common thing is having a first-class way to deal with something that's poised to execute later. RSC's way to do it is opaque, whereas quoting isn't opaque. In that sense, quoting is more powerful — which is why it can express both RSC and more mixed paradigms like Electric. But I think it's a meaningful connection because it's both about intent and capabilities. There aren't a lot of programming paradigms that enable cross-runtime composition and orchestration.
Maybe it's where I'm imagining we're headed (and not where we're actually headed) but I think it will bring us into the sweet spot that I want/need: good old PHP-like server-rendered sites (or even static pages) with custom interactive components (think e.g. forms with client-side validation) without the mess that mixing PHP+jQuery used to be.
Server rendering is enough for the 80% use case. Browsers are optimized for it. Sprinkle interactivity without the impedance mismatch of jQuery and you're in heaven. No more overengineered state syncing between client and server. Just. Fetch. HTML.
Currently frameworks are trying to shoehorn it into the 2018 React mindset but that's not what I think is needed for them to succeed.
I think RSC is trying to answer the question, “How can we make server rendering and sprinkles of interactivity composable?” What if you want your sprinkles to have server rendered content inside of them, each of which may contain other interactive/dynamic elements?
I posit that any composable version of sprinkles or the “island architecture” will closely resemble RSC.
Only a small fraction of apps will ever use the full power of the RSC architecture. However, the React team doesn’t build apps, they build primitives for building apps. And good primitives are composable.
What they did wrong tho was to morph React into this mess. RSC should be React Server and live along React DOM and React Native, something almost unrelated to the previous concept of React. But we got this an entangled mess.
You either make presentation the server job or the client job. Spreading it between the two results in the same trouble that distributed systems are trying to solve to this day. At least backend have a reason for going the distributed route (resources and risk management).
It's all relate to consistency. If presentation is the job of the server (html templates), the server is the source of truth and the client state is expected to be transient. That is a good model for most web applications including this forums.
There's some case where local state is more important (figma, google maps, chat app) and the backend is expected to act as a data source with a domain-specific API. Any mixture between the two and you will make the separation between the two domain (server concerns and client concerns) at the wrong place, making the design more complex (however well you hide it behind the curtains).
> If presentation is the job of the server (html templates), the server is the source of truth and the client state is expected to be transient.
Which is exactly why the client state should be transient non-application state like datepickers, dropdowns, text boxes, etc. and it does not belong in the server (essentially what jQuery was used for back in the day, interactive sprinkles). And the other way around.
Perhaps you agree with me but there was something lost in translation?
Something was lost. I was arguing either send the presentation layer as data to the web browser as resources, or send data that from which the browser and the UI library (react, svelte,...) will derives the UI from.
RSC does a weird split where the engine is the same on both ends instead of a clear separation layer where one does not need to know about each other. I much prefer HTMX approach (samey old backend where you mostly take care of everything in the frontend) and Laravel Livewire approach (where you take care of everything backend side, with optional client side scripting).
No need to reinvent the world to fix a single problem.
reply