I like the term biphasic! The prior terms for this with Javascript web development were "isomorphic" or "universal". I don't think these ever really caught on.

I like the term biphasic! The prior terms for this with Javascript web development were "isomorphic" or "universal". I don't think these ever really caught on. I've been rendering the same React components on the server and browser side for close to decade and I've come across some really good patterns that I don't really see anywhere else. Here's the architectural pattern that I use for my own personal projects. For fun I've starting writing it in F# and using Fable to compile to JS: https://fex-template.fly.dev https://fex-template.fly.dev A foundational element is a port of express to the browser, aptly named browser express: https://github.com/williamcotton/browser-express https://github.com/williamcotton/browser-express With this you write not only biphasic UI components but also route handlers. In my opinion and through lots of experience with other React frameworks this is far superior to approaches taken by the mainstream frameworks and even how the React developers expect their tool to be used. One great side effect is that the site works the same with Javascript enabled. This also means the time to interaction is immediate. It keeps a focus on the request itself with a mock HTTP request created from click and form post events in the browser. It properly architects around middleware that processes an incoming request and outgoing response, with parallel middleware for either the browser or server runtime. It uses web and browser native concepts like links and forms to handle user input instead of doubling the state handling of the browser with controlled forms in React. I can't help but notice that React is starting to move away from controlled forms. They have finally realized that this design was a mistake. Because the code is written in this biphasic manner and the runtime context is injected it avoids any sort of conditionals around browser or server runtime. In my opinion it is a leaky abstraction to mark a file as "use client" or "use server". Anyways, I enjoyed the article and I plan on using this term in practice!