React vs HTMX - A Fascinating War

Summary

This video script delves into a comparative analysis of React, Solid, and HTMX, exploring their architectures and server-rendering capabilities. It highlights React's new server components and their role in the unified model for UI development. Solid is praised for its emphasis on primitives over abstractions and simplicity over ease of use, which positions it well in the JS framework landscape. HTMX is introduced as a server-centric approach that challenges the SPA norm, offering interactivity with minimal client-side scripting. The discussion invites viewers to consider the trade-offs of each framework and decide which approach best fits their project needs.

Takeaways

• 😀 The script discusses a blog post that deep dives into comparing React, Solid, and HTMX, focusing on their rendering processes and server relationships.
• 🤔 It emphasizes the importance of understanding React Server Components (RSC) within the context of the new React architecture rather than in isolation.
• 🔍 The author of the blog post argues that the term 'React Server Components' might not fully encapsulate the changes in React's architecture, suggesting a need for a better term.
• 🏗️ The new React architecture is described as a server-client model that allows components on the server side to access new computing environments and resources.
• 📈 Despite the benefits, the new React architecture may come with increased bundle size and tooling challenges, particularly with server components.
• 🌟 Solid is highlighted for its focus on primitives over abstractions and explicitness over implicitness, aiming for simplicity over ease of use, which is beneficial at scale.
• 🚀 Solid's approach to server-side rendering is through server functions that leverage existing bundler features, allowing for RPC calls and streamlined server support.
• 🔄 HTMX is introduced as a simple library that extends HTML with hypermedia attributes, reducing the need for client-side JavaScript and promoting a server-centric approach.
• 🛠️ HTMX challenges the traditional single-page application model by allowing sophisticated behaviors to be encoded directly into HTML, simplifying interactivity without extensive scripting.
• 💡 The script ponders the future of these frameworks and libraries, suggesting that each has its strengths and is suited to different use cases, with no one-size-fits-all solution.
• 🧐 The author invites viewers to consider which approach aligns best with their needs, whether it's the full-spectrum coverage of React, the client-side focus of Solid, or the server-centric simplicity of HTMX.

Q & A

What is the main topic of the blog post discussed in the video?

The main topic is a deep dive comparison of React, Solid, and HTMX in terms of their rendering process, architecture, and relationship with the server.

What does the author suggest is the biggest failure of the new React architecture?

The author suggests that the biggest failure is the lack of a term to describe the comprehensive changes in the new React architecture, not just the introduction of React Server Components (RSC).

What is the author's opinion on the term 'React Server Components'?

The author believes that 'React Server Components' might be a misnomer and that the new React architecture should be the focus, as RSC is just one part of it.

How does the author describe the new React architecture?

The author describes it as a unified model for UI development that brings both client and server ends under a single coherent paradigm, a true one-app architecture.

What are some potential pitfalls of the new React architecture mentioned in the video?

Some pitfalls include increased bundle size, issues with server resource access leading to waterfall issues, and the need for improved tooling and messaging.

What is the main focus of Solid according to the video?

Solid's main focus is on using primitives over abstractions, explicit over implicit, and simplicity over ease of use, especially as applications grow in complexity.

What is the significance of Solid's approach to reactivity?

Solid's approach to reactivity emphasizes simplicity and explicitness, which can lead to more sustainable and maintainable code at scale, even though it might be harder to adopt initially.

How does HTMX differ from traditional JavaScript frameworks?

HTMX extends HTML as hypermedia, encoding behaviors directly into HTML attributes, which is the opposite of JSX, where JavaScript writes the template.

What is the core goal of HTMX?

The core goal of HTMX is to enable server-centric web applications that can match most single-page apps in terms of interactivity and modern UX with little to no client-side scripting.

What are the limitations of HTMX compared to frameworks like React or Solid?

HTMX has lower interactivity ceilings and is not suitable for complex applications that require heavy client-side behaviors, such as 3D rendering or distributed systems.

What is the author's perspective on the future of these frameworks?

The author suggests that there is no clear winner and that different approaches have different trade-offs, benefiting different use cases, and that it's too early to predict which approach will prevail.

Outlines

00:00

🤔 Deep Dive into React, Solid, and HTMX

The paragraph discusses a blog post that compares React, Solid, and HTMX, focusing on their rendering processes and server relationships. It emphasizes the importance of understanding the new React architecture in the context of React Server Components (RSC). The author agrees with the notion that RSC should be seen as part of a broader architectural shift rather than an isolated feature. The paragraph also touches on the challenges of adopting new technologies within the existing React ecosystem and the potential for RSC to change the way developers think about UI development.

05:02

🏆 Solid's Rise and the Quest for Simplicity

This paragraph highlights Solid's impact on the JavaScript front-end landscape in 2023, noting its win at the T3 Awards and the community's growing recognition of its ideas. The author discusses Solid's core principles, such as favoring primitives over abstractions and explicitness over implicitness, which contribute to its sustainability at scale. The paragraph also addresses the potential for Solid's reactivity model to influence other frameworks and the upcoming Solid 2.0 release, which promises a renewed reactivity implementation and the official Solid web framework.

10:03

🌐 Solid's Approach to Server Functions

The author explores Solid's strategy for server-side rendering and data fetching, which leverages existing React ecosystem primitives and emerging bundler features. Solid's server functions are likened to React's server actions, utilizing RPC calls for direct access to server resources. The paragraph also compares Solid's server functions to other data fetching and state management solutions, noting their potential to offer a comprehensive package that combines the best features of various technologies.

15:03

📚 HTMX: Challenging the SPA Paradigm

This paragraph introduces HTMX as a simple library that extends HTML with hypermedia attributes, allowing for sophisticated behaviors to be encoded directly into HTML. HTMX challenges the mainstream single-page application (SPA) model by offering a server-centric approach that minimizes client-side scripting. The author discusses HTMX's potential to simplify web development by reducing the need for complex client-side frameworks and enabling advanced interactivity with minimal effort.

20:03

🛤️ Crossing the Network Chasm with HTMX

The final paragraph delves into HTMX's philosophy and its implications for web development. It contrasts HTMX's server-centric approach with the traditional client-centric SPA model, highlighting how HTMX enables developers to build interactive web applications with less complexity. The author also discusses the limitations of HTMX and acknowledges that it may not be suitable for all types of applications, but appreciates its value in simplifying the development process for certain use cases.

Keywords

💡React Server Components

React Server Components (RSC) are a new feature in React's architecture that allows components to be rendered on the server, leveraging server-side resources. This concept is integral to the video's theme as it discusses the evolution of React and its impact on UI development. The script mentions RSC as part of the 'new React architecture' and discusses its role in creating a unified model for UI development.

💡Backwards Compatibility

Backwards compatibility refers to the ability of a system, product, or service to work with older versions or features without issues. In the context of the video, it is mentioned that the new features in React, including server components, maintain this compatibility, allowing developers to continue using older React code while also opting into new features.

💡One-app Architecture

The one-app architecture is a concept where the same codebase runs both on the client and server sides, creating a seamless user experience. The script discusses this in relation to React's new architecture, suggesting that it represents a significant shift from traditional JavaScript-centric web frameworks and brings both ends under a single coherent paradigm.

💡Waterfall Issues

In the script, waterfall issues refer to a series of dependent operations that must complete in sequence, which can cause delays and inefficiencies. The video discusses how these issues manifest differently when they occur on the server versus the client, and how the new React architecture addresses these concerns.

💡Solid

Solid is a JavaScript library for building user interfaces, which emphasizes fine-grained reactivity and simplicity. The video script highlights Solid's influence in the JS front end landscape in 2023 and discusses its philosophy of 'primitives over abstractions' and 'explicit over implicit,' positioning it as a standout in the crowded JS framework space.

💡Reactivity

Reactivity in the context of the video refers to the ability of a user interface to respond to state changes. Solid's approach to reactivity is highlighted, with the script mentioning its 2.0 update and a renewed reactivity implementation that emphasizes simplicity and explicitness over ease of use.

💡HTMX

HTMX is a lightweight library that allows developers to add dynamic, interactive features to their web applications without writing much JavaScript. The video script discusses HTMX's approach to web development, which extends HTML with hypermedia attributes, positioning it as an alternative to JavaScript-heavy frameworks like React.

💡Hypermedia

Hypermedia refers to the use of hypertext links to connect and navigate through different pieces of content. In the script, HTMX is described as encoding sophisticated behaviors directly into HTML as hypermedia attributes, which is a contrast to JSX and represents a server-centric approach to web development.

💡Client-Centric

Client-centric refers to an approach where the client-side of an application is the primary focus, with the logic and interactivity primarily handled by the client. The script contrasts this with server-centric approaches, noting that React and Solid are client-centric but offer different ways to integrate server-side capabilities.

💡Server Functions

Server functions, as mentioned in the script, are a feature in Solid that allow for server-side logic to be executed and are similar to server actions in React. They are part of Solid's strategy to bring server capabilities closer to the client-side without requiring a full server-rendered architecture.

💡Virtual DOM

The Virtual DOM is a concept used in React where a lightweight in-memory representation of the UI is kept and updated, rather than the actual DOM. The script discusses the Virtual DOM in the context of React's rendering process and how it differs from Solid's approach, which doesn't require rerunning components on the client side for hydration.

Highlights

This blog post provides a deep dive comparing React, Solid, and HTMX, focusing on rendering, server interaction, and architectural differences.

React Server Components (RSCs) should be understood within the context of the new React architecture, not in isolation.

The new React architecture supports both old and new components, maintaining backward compatibility while introducing server-side capabilities.

Solid JS has gained attention for its fine-grained reactivity and simplicity, winning the 2023 web framework of the year.

Solid's approach focuses on primitives over abstractions, simplicity over ease of use, and explicitness over implicitness.

HTMX offers a server-centric approach, extending HTML with attributes to encode behaviors, reducing the need for client-side scripting.

HTMX gained significant popularity in 2023, becoming the second most starred JavaScript framework on GitHub.

HTMX simplifies development by allowing sophisticated behaviors directly in HTML, offering a different route to the one-app architecture.

The new React architecture presents a unified model for UI development, integrating server and client-side components under a single paradigm.

Solid's minimal bundle size and cheap hydration costs make it efficient, avoiding the need for extensive server-side rendering.

React's virtual DOM approach requires re-running components on the client for hydration, whereas Solid's state-based approach skips this step.

HTMX challenges the mainstream single-page application model by eliminating most client-side scripting in favor of server-rendered HTML.

HTMX's approach reduces complexity by avoiding extra dependencies, build steps, and advanced tooling, making it suitable for simpler applications.

React aims to cover the full spectrum of server-client interactions, Solid focuses on client-side reactivity with server capabilities, and HTMX emphasizes server-centric development.

The choice between React, Solid, and HTMX depends on specific use cases and the trade-offs each framework presents in terms of complexity, performance, and developer experience.

Transcripts

react solid and HTM X this is an

interesting blog post that I knew I had

to talk about as soon as I saw it it's a

pretty good Deep dive comparing react

solid and HDMX in terms of how they

render and work and relate to the server

all things that we should concern

ourselves with and think about more

often so let's do just that react how

far can components go saves it not a

single day passes without someone on

Twitter wondering what rsc's are really

about I've made my own attempt at

cracking it he has a blog post RSC is

react server plus component arguing that

react server components are best

understood in the context of the new

react architecture not in isolation this

I fully fully agree with I didn't read

the sentence before reading like

skimming the post before yeah I already

know I'm going to like this guy so the

biggest failure of the new react stuff

is that we don't have a term for all of

the things that are changing with other

Frameworks we have like vue3 where

everything's different from vue2 or we

have angular 2 which is different from

angularjs the difference here is that

everything being added still supports

the old stuff and everything's fully

backwards compatible so the idea of this

version number change doesn't properly

represent things we don't have a term

for this movement because server

components are just one piece of the new

react architecture he refers to it as

the new react architecture which is a

very good way to put it because people

try to learn server components the

concept not server components and how

they affect react's architecture so

really important call out here I think

it's important to not conflate react

server components with the new way we do

react and think about react architecture

which again is entirely optional and opt

in you can still use your old react code

so let's see how he frames this cuz I'm

already excited what we have here is not

some new magic kind of components but a

server client architecture that speaks

react on both ends and grants components

if placed on the server side direct

access to new Computing environments and

their resources this is one of the best

summaries of what server components

actually are okay already huge shout out

to Boba Kang hopefully I pronounce your

name correctly because this is

phenomenal after another month of

closely following the RSC discourse I

still stand by it and personally I think

react might be making mistakes by

picking RSC as an umbrella term I

promise I didn't pre-ad I skimmed to

make sure it was what I thought it was I

like this person a lot nonetheless I

appreciate the new react architecture is

a unified model for UI development that

brings both ends under a single coherent

Paradigm a true oneapp architecture this

is a significant departure from most JS

Centric web Frameworks including those

built on top of react that provide

various server sites features like

server side props in next as well as

loader and action in remix things like

that it's doubtless that these things

are useful but they fundamentally are

external to the core UI application

placed squarely on the client side

speaking my language so hard when your

mind is already separating server and

client this strictly where you have

these specific points that are inputs

and outputs to the server the new model

doesn't map to that because the new

model is as he said a true onea

architecture combined with composability

of all of these Primitives instead of

defining a loader that affects this URL

you define a function that your

component calls wherever the component

is yeah I'm going to like this in

practice the new react architecture

isn't without pitfalls without careful

planning react components with access to

server resources still suffer from the

same waterfall issues even though

they're Now hidden from the network tab

on the browser Dev tools locking this

new architecture also comes at the cost

of increased bundle size in server

components support in tooling which is

still at an early stage mostly Fair one

important Point here is that waterfalls

are fundamentally different when they

happen on the server versus the client

because when a waterfall happens on the

client you have to redo a bunch of

things like you have to reauthenticate

the user you have to call an external

server from the user's device you have

to process things with JavaScript you

have to do a lot of different things in

order to make each of those waterfall

requests rather than on the server where

you've already authenticated the user

you can just do all of those things and

stream the results serers side

waterfalls are so much less bad that

it's almost not worth talking about as

much anymore previously we ignored

waterfalls which caused a bunch of

problems when they happen on client now

it's a little more valuable for us to

ignore which is interesting that it's

changed that much you want to know more

about waterfalls and why I think these

things I have 15 videos where I talk

about it so just search server

components or data with my name and

you'll find it on YouTube that said I

believe these are more Growing Pains

rather than critical deficiencies

inherent to the new model if react can

successfully address these pain points

via improved tooling and messaging 2024

shall be the year where everything

finally clicks for the mainstream

audience versel Can you hire this person

they understand this so well as I noted

in an earlier blog post react versus the

world react has a proud history of

challenging the Contemporary norms and

conventions of UI development including

the ones it helped to popularize and

winning over the world despite all the

noise and confusion in the ongoing

server component discourse react appears

confident that it can repeat the history

again relax it's react I don't know if

I've read this blog post I am saving

this for later for sure I I'm liking

this a lot oh boy now we're just going

straight in solid how far can primitive

go if anyone asked me I'd say solid one

the JS front end in 2023 not because it

overtook reaction usage not even close

but because it's ideas one saying solid

won the JS front end in 2023 is really

funny to me because I opened 2023 with

the T3 Awards one of my most

underappreciated things I we put a lot

of work into this poor Mir spent so much

time editing down this 4-Hour stream

into a 2-hour video and adding nice

overlays and such but the web framework

of the year was of course solid I

compared all of the different ones here

but the winner oh I I even pulled chat

to see if they could guess which one it

would be and they actually successfully

guessed it it was

solid which uh I think is pretty cool at

the time solid was really pushing these

ideas and Ryan carniato in particular

was becoming more and more involved in

the greater web development discourse

and yeah it was pretty clear to me that

solid's ideas were doing well the solid

framework and Community were going

places no one had ever imagined before

and it felt important to call that out

and give them a literal award at my

award show no we're not doing one this

year some more fun things for the

developer Awards coming soon anyways as

the author was saying pretty much every

framework but react has implemented

signals in some form and even react

adopted the language of reactivity to

describe its optimizing compiler under

development this is the uh reactivity

compiler react forget blog post but this

begs a question what's next for solid

will the success of fine grain

reactivity lead to the fall of solid

which can no longer stand out from from

the crowd solid's answer is no in 2024

solid will reach 2.0 with a renewed

reactivity implementation as well as

solid start the official solid web

framework which will reach 1.0 as I

follow the ongoing development it's

getting clearer to me that I like many

others have been missing the point of

solid the point of solid is not signals

or fine grain reactivity that's more a

happy accident the real point is about

The Primitives over abstractions

explicit over implicit in Simplicity

over ease of use I take back what I said

about versell Ryan you need to make sure

this guy doesn't end up at versell

because you need him anyways this is

this is so well put specifically the

idea of Simplicity over ease of use this

is something I didn't realize I fight

constantly but I absolutely fight

constantly where I'm always looking for

Simplicity and people pretend these two

things are the same and they show me

something that's easier that is less

simple this is one of my favorite

examples of what we're talking about

here with Simplicity versus ease of use

spelt solution here is objectively

easier to use let count equal zero and

now if you want to change count you set

it to something else later on react

solution is less easy to use because

you're calling all these other things

you're importing things you're doing all

this stuff react solution here

unintuitively is actually quite a bit

simpler like significantly so because

react solution is using JavaScript is

Javascript it's not adding new things on

top the same way spelt is using a

compiler to change this so much so that

spelt actually went in this Direction

with their recent changes with runes if

you look at spelt runes you'll realize

oh these are actually quite a bit more

complex than the previous solution

because instead of let count equals zero

it's let count equals dollar sign state

zero this is less easy to use but the

result is simpler because it's not

compile step generating these things in

a spelt file it's actually using

Primitives that are reusable and

composable across things and as they

said here it doesn't even feel felt like

but as they say here the reality is that

as applications grow in complexity

figuring out which values are reactive

and which ones aren't can get tricky and

the heris stics only work for let

declarations at the top level of a

component which can cause confusion so

even though the other way was easier to

use it becomes significantly less simple

especially as your code base gets bigger

and you have more and more complex

things ease of use makes it easier to do

a snippet for a sample but it doesn't

help you solve hard problems over time

Simplicity might be harder to adopt but

it means these problems hurt you less

over time which is why there are so many

big react code bases that are getting

bigger every day that are doing just

fine that are shipping major updates

without issues because react Primitives

even the more complex to learn end up

being simpler at scale so yeah this blog

post is giving me realizations which is

a really really good sign and the

Simplicity over ease of use point is a

huge one here this also fits with The

Primitives over abstractions and

explicit over implicit doing these

things explicitly makes things more

sustainable and that's how solid remains

a standout to the crowded JS framework

space where others often seek to attract

developers with easy to use abstractions

that feel magical I'm actually curious

what he linked there for the feel

magical good reference magical not magic

there subtle line between something

feeling magical and something feeling

like magic we want spelt to feel magical

want you to feel like a wizard when

you're writing spelt code historically I

think felt went too far into magic

territory where it's not 100% clear why

things work a certain way and that's

something we're rectifying with spelt 5

yeah really good reference in solid to

is eyeing on solving the server side of

the equation with a new set of

Primitives albeit from a different angle

instead of creating its own version of

server component solid is betting on

streamline support for Server functions

solid's server function looks similar to

server actions in react they're both

marked with the US server directive and

with a bundler help they get turned into

RPC calls this is actually one of the

interesting things I think Ryan's done a

great job with is recognizing The

Primitives that exist within the react

ecosystem that aren't specific to react

solid is the first popular jsx based

framework that isn't react which is kind

of crazy when you think about it that

other Frameworks didn't take advantage

of this open primitive standard that

anyone could use they chose to which

made it way easier for me to transition

to solid from react and vice versa

they're also taking advantage of new

things that react is introducing like

you server since this is now a bundler

feature that many bundlers are

implementing they can hijack the syntax

and the feature use those same pipes

that were built for react but instead

using them for the things solid wants to

do differently which is super cool to

take these Concepts these Primitives

these supported ecosystem pieces and use

them to assemble something entirely

different really cool stuff when

combined with solid's official router

and its data API which has action cache

create async somewhere hybrid between

what react's doing now and what remix

did before solid server functions can

offer pretty much everything that you'd

want from a data fetching SLS server

State Management Solution Direct access

to server resources via flexible RPC

interfaces with caching and Route level

parallel fetching the best of relay

tanet query trpc and remix all in a

single package the fact that you're

calling out relay suggests you're way

deeper than almost anyone watching this

video let me know in the comments if

you've actually shipped relay because

I'm convinced the only people who have

are employees of meta or people with

multiple phds so let me know in the

comments also recall that a solid

component is more like a setup function

that runs once to wire up the reactivity

graph then a render function that

continually reruns the produce the

latest UI I just talked about this a

bunch in the video I did earlier today

which hopefully is out before this

talking about how the new Vue Vapor

compiler Works comparing how these

render strategies work so if you want a

deep dive on this I'll link that video

in the description this means that the

potential gain for moving components to

server is much smaller for solid than it

is for react plus solid already has a

minimal bundle size and its hydration

cost is relatively cheap so it's

understandable why solid doesn't

consider server component to be a

critical piece of its take on the onea

architecture I'm trying to decide if I

want to go deeper into the virtual Dom

thing here cuz I just just talked about

it so much but it's a different video

can I need to repeat the context I'm

going to repeat it I'm sorry I I know I

just said watch my other video but I'm

going to dive a little bit into this

because it's important react has a

virtual Dom which is a full

representation of all of your components

that exists in your memory in JavaScript

and when you make a change it reenders

all of those things in the virtual Dom

to compare the difference before and

after to see if it's different and if it

is then it updates the web page

accordingly but in order for those

components to know which element they're

bound to on the page it has to run in

your browser so even if you generate an

HTML page on the server using react and

using the virtual Dom over there once it

shows up in your browser in order for

react to run and update things it

doesn't know which component goes where

until it's run all your components again

which means react has to rerun the same

client side JavaScript code in order to

hydrate to bind those components to the

right places in the HTML and that takes

enough compute that whole Frameworks

have been built arguing about it quick

exists exclusively because of that

hydration problem the fact that you have

to rerun the same JavaScript on the

client in order to match it up with the

HTML solid skips that because as I

mentioned in the view video that I

referenced earlier solid doesn't create

a tree of components it creates a tree

of state and every time you use a

stateful element in different places it

creates a tree of updates for all of

those things which means as long as it

knows where those stateful bindings are

you don't have to rerun your components

you just have those values and when they

change they change that means you don't

have to ship as much JavaScript it means

you don't have to run as much JavaScript

and it means a lot of the issues that

would make you want to server render

aren't as present but it's still very

nice to get good HTML down from your

server so there's a balance here for

sure notably solid's approach does not

require any radical shift in mental

model it still feels very much client

Centric but with additional Primitives

that can be combined to bring the server

closer it's modular incremental familiar

and practical potentially a winning

combination I agree and I'm very excited

to see where it goes speaking of where

things are going let's go to HTM X and

see how far hyper media goes with it

2023 saw an unexpected entrance to the

JS framework War HTM x a simple Library

consisting only of a single JS file came

to the scene seemingly out of nowhere

and took the web developer Community by

storm adding 15,000 new GitHub Stars

HDMX earned the second place in the 2023

JavaScript Rising Stars for the

front-end framework category which puts

them just behind react and pretty close

in terms of new stars gained that year

when you think about it that's pretty

nuts JavaScript framework for people who

hate JavaScript is number two for most

stars in the year while hmx is not a new

library in fact it came out in late 2020

and its predecessor by the same author

intercooler reached 1.0 back in 2016 its

increased awareness and adoption means

that 2024 will be the first year for HTM

X to really shine and also its

robustness to be tested HTM X presents

an approach that is fundamentally at

odds with what has been the mainstream

for over a decade in this case a single

page application entirely controlled by

a react likee JavaScript framework

directly manipulating Dom and exchanging

data with mostly Json apis instead HTM X

extends HTML as hyper media with HTM X

we can encode sophisticated behaviors

directly into HTML as attributes this is

the exact opposite of jsx which is an

XML like syntax extension to JavaScript

itself for templating purposes it lets

the JavaScript write the template rather

than the HTML write the behaviors

previously in like the OG world of like

the jQuery days your HTML was your

template and your JavaScript was your

logic your update layer and you would

start with some HTML that you wrote in

HTML file and then the JavaScript would

make changes as needed jsx was what if

we just put the template in the HTML in

the JS HTM X is what if we put the logic

in the things that change in the HTML an

HTM X app is server Centric like the web

one dayss but it's able to match most

single page apps in its ability to

support Advanced interactivity and

modern ux all with little to no client

side scripting very good points and that

is largely its goal what's particularly

intriguing to me is that HTM X shows us

a different route to the one app

architecture by the way of killing the

client side entirely it's important to

note that HDMX is not a 100% solution it

shouldn't be controversial to state that

interactivity ceilings are much lower

for HDMX than something like reactor

solid I hate that this is controversial

cuz I've gotten in trouble for saying

this even though the HDMX team agrees in

an old world and by old I mean when I

worked at twitch a few years ago back in

in front we're pretty separate and we

had a thing in between that was almost

the translation layer between the two

for us it was graphql this was a way

that we could make rules and agreements

where the back end could go do its thing

the front end could do its thing it

would all come

together something that started to

happen is we saw more and more react

devs realizing that they could benefit

from running some things on the server

maybe they don't want to manage the

whole database themselves but they want

to render their page on the server maybe

they need an API endpoint quickly and

they don't want to wait for the backend

team to do it maybe they need to hit

three different things at once once

you're authenticated and massage that

into the right shape for the data maybe

they just want to do everything quick

what nextjs enabled is for this line

between the back end and the front end

to be crossed by react previously there

was a hard wall between these things

that you would Bridge with another tool

like graphql or even just Json apis with

nextjs with mix with the stuff that

we're talking about with solid and solid

start with all these other tools and

solutions react now has the option to go

towards the server some amount this is

great if you don't need to make a really

complex back end if you were building a

Twitter clone you don't need to reinvent

the data layer you don't need to do

really powerful optimized things there

you can throw it on something like

Planet scale attach it and hook it up

via versel serve it via next and you're

good and done is it as optimal as

somebody writing a quality rust or go

backend that's autoscaled with

kubernetes

no but it's pretty damn close and it's

good enough for a lot of developers that

exist on this side that want to do

enough on the other side and they'll

fill out the gaps with sasses like as I

just said versel Planet scale clerk up

stash axium all the things that I talk

about sponsored by Etc here the magic of

next in these new patterns is how much

further we can get over the line here

without having to call on a backend

person or team to do that eventually you

might want to move off of these sasses

and hire a backend Dev or a team of

backend devs to build this site for you

but you shouldn't have to hire a backend

Dev just to deploy your web app and have

apis this is where I think HTM X is

really interesting because if you're a

backend developer and you want to make a

Twitter clone previously your options

were either to learn something like

react so you could have good client side

behaviors or don't and every time you do

anything the whole page has to refresh

when I make a new tweet I don't see it

until the page reloads and then I lose

whatever tweets were below it building

something like Twitter entirely on the

back end where you're just shipping HTML

would be a terrible experience but in

order to have a better experience on the

client you would have to adopt react the

same way in the past in order to have a

backend for your react code that fetch

the right data you would need go or node

or any other set of Technologies as well

as an API layer like graphql next lets

you skip that if you don't need those

details you just need the capability and

with HTM X you can do a lot more of the

client side stuff than you could

previously if you want to have a tweet

show up right below it once you post it

without having to reload the page HTM X

gives that to you if you want to have a

search field that you don't have to

reload the whole page when you change

the inputs HTM X gives that to you a lot

of the core behaviors that previously

required you to opt into a JavaScript

framework no longer do if you want to

build a heavy canvas app or 3D rendering

or a super interactive UI or figma HTM X

is not going to help you at all the same

way if I wanted to build a distributed

system next isn't going to help me at

all but if I'm not trying to build a

distributed system I'm trying to build a

web app next means I can skip the

backend team if I'm not trying to build

figma I'm trying to build Twitter HTM X

lets me skip the front end team that's

the value of HTM X it's not that it can

do everything react can do is that if I

only need to do this part of what react

can do I don't need to use react anymore

and that's a huge win but part of this

win is acknowledging the chunk here of

things HTM X cannot and will not help

with because HTM X does not do this area

it cannot do this area and it's not

interested in doing this area and it

shouldn't be the same way that next

shouldn't be interested in competing

with kubernetes check out my truth about

htx video if you want a much longer rant

about this yeah I got in trouble for

that take I hope this author doesn't

because they are correct the same way I

was correct and as they say here even

though it only gets you 80% of the way

there it gets you there with radically

less complexity no extra dependencies no

more build steps no more advanced

tooling now Rewritten and rust no

complicated State Management no double

data problems no hydration mismatches

just write your HTTP server and return

HTML in a way htx is not a solution but

a question what are you really building

does it really need more than HTM X

which way to cross though most all web

Frameworks aim to bridge the network

Chasm I'm learning that this Chasm

cannot be closed it can only be crossed

so which way do you want to cross it

react solid and HDMX all present

distinct answers here with react we see

an attempt to cover the full spectrum at

once within the same component model

with solid we see a focus on the client

side with New Primitives to bring the

server closer to it and with HTM X we

see a good old server Centric approach

but with a Twist that is supercharged

hyper media maybe too early to predict

which way will wi out maybe such a

prediction is mere nonsense there is no

Silver Bullet remember different

approaches with different trade-offs

will benefit different use cases

differently nonetheless I believe that

react solid

of this video because this post is

actually one of the best I've read ever

especially for a video thank you for

this awesome blog post and for everyone

watching which horse are you betting on

do you think that solid's focus on

client is the win do you think HTM X

going back to the server is the best

call or do you think that the weird

chaotic react compositional hybrid

approach has the Merit that we all seem

to love let me know in the comments and

I'll see you guys next time peace NS