En 2008, hubo una película llamada Vantage Point. Era una historia contada desde muchas perspectivas diferentes, y ves cómo las diferentes perspectivas pueden ser muy diferentes entre sí y contarte diferentes historias. Pero luego, cuando las juntas todas, puede surgir algo nuevo. De todos modos, soy Naman, trabajé en Meta durante ocho años. Y durante los últimos cuatro a cinco años, estuve trabajando en StyleX. Entonces, ¿qué es StyleX? Es una solución de estilo CSS y JS, pero es en tiempo de compilación, por lo que no hay inyección de estilo en tiempo de ejecución. Produce una hoja de estilos atómica altamente optimizada, similar a Tailwind. Yo diría que es una de las mejores soluciones de estilo que existen, mucho mejor que Tailwind. Hay algunas otras que la gente no conoce, pero eso no viene al caso. Independientemente, el punto importante es que el concepto de Atomic CSS está ganando. Pero no siempre fue así. Hubo un largo tiempo en el desarrollo web donde los paquetes cargados de manera diferida eran ubicuos. Teníamos paquetes específicos de ruta de CSS, los cargábamos de manera diferida a medida que navegábamos por las páginas, usábamos extensiones de sintaxis como Sassless, y usábamos arquitecturas como BEM y OOCSS, que en realidad era algo que teníamos que aprender, y no había herramientas para ello. Pero luego llegó Atomic CSS y cambió completamente la ecuación. Y la razón por la que tuvo tanto éxito es que simplemente escala mejor. En lugar de que tu CSS crezca con el número de componentes, donde simplemente obtienes CSS más y más grande, con Atomic CSS, después de un tiempo, tu CSS simplemente deja de crecer. Y como resultado, puedes tener un pequeño paquete de CSS cargado todo al frente. No necesitas cargar más CSS de manera diferida. Tu HTML se vuelve un poco más grande, claro. Tienes más nombres de clase. Pero en general, un HTML más grande sigue siendo mucho más barato que un archivo CSS más grande. Y a escala, te das cuenta de cómo un archivo CSS grande puede convertirse en un cuello de botella de rendimiento, que de otro modo no notarías. Así que comencé a pensar, ¿podemos hacer también Atomic JavaScript y cambiar la ecuación en el mundo de JavaScript?

He estado usando React durante los últimos 12 años, y comencé a usarlo para el renderizado del lado del servidor. Pasé por React Create class, componentes de clase ES6, componentes de función con componentes de orden superior, Redux, y luego Hooks. Pero luego, este gran cambio ocurrió recientemente, llamado RSCs. Y RSCs de alguna manera voltearon el modelo de React, donde ahora todo es orientado al servidor. Los datos son orientados al servidor. Comenzamos a pensar, ¿por qué enviar componentes al cliente si la salida siempre va a ser estática? Podemos tener un paquete de cliente más pequeño si gran parte de nuestra UI puede ser representada con datos o marcado en esta situación. Todavía podemos tener componentes de cliente para la interactividad. Así que comencé a pensar, ¿pueden los componentes del servidor ser interactivos por sí mismos? Hola, soy Naman, y no soy fan de HTMX. Pero hay algunas cosas que todavía me parecen interesantes al respecto. Así que este es un demo muy simple de HTMX, y lo que me gusta de él es que la lógica de tu aplicación está justo ahí en el HTML. No hay JavaScript extra para cargar, no hay paquetes adicionales. Todo se reduce a algo muy simple, muy eficiente, en términos de los datos que tienen que cargarse en el navegador. Pero también, HTMX tiene lógica imperativa por todas partes. Estás actualizando cosas por IDs y inner HTML y outer HTML. No hay un sistema declarativo para hacer un seguimiento de todo y no hay componentes, no hay flujo de datos consistente. Eventualmente, comienza a sentirse como jQuery con pasos adicionales. Pero luego también, por otro lado, JSX puede usarse sin React. Y hay un marco de servidor llamado Hano. Es un competidor de Express, que tiene soporte de primera clase para JSX, pero solo para renderizar HTML regular. Y así comencé a pensar, ¿podría hacer un modelo de componente declarativo que genere algo como HTMX? Hola, soy Naman, y no soy un gran fan de Web Components. Pero he estado investigando las APIs, buscando algo de valor en todo eso que hemos construido y puesto en los navegadores. Así que comencé a mirar qué son los Web Components, qué compone los Web Components. Así que la primera cosa de la que todos hablan, porque es la parte más controvertida, es Shadow DOM. Shadow DOM te da aislamiento de estilos. Ese es su gran valor. Cualquier CSS fuera del Shadow DOM no se aplica al mockup dentro del Shadow DOM, y cualquier CSS dentro del Shadow DOM no afecta nada fuera de él. Pero ahora tenemos Atomic CSS. No tenemos conflictos. No necesitamos este alcance de CSS en la mayoría de los casos.

It's very, very new. This was just some crazy idea I had about a year ago, and I've been thinking about it for a while, and I decided to build it for the conference. It's far from feature complete, although I have an idea of how every single feature that we want in a real app would work. Suspense would work. Data fetching in components is actually already implemented, but suspense isn't, so I couldn't demo that.So just async components are a first-class feature because it's all server-side. It breaks many CSS selectors. As you notice in the HTML, there's a whole bunch of extra tags, extra elements. So if you do any direct child selectors or direct sibling selectors, those are not reliable. So I'm assuming you will use Atomic CSS. There is a way to work around it. I could also write a PostCSS plugin, which would make all of those work.But I actually think it's better to use Atomic CSS and not rely on those selectors. It generates a bigger HTML file. I assume that's faster because that's been faster in other domains that I worked in, but this is new, so I don't know if it actually is faster. Custom elements may not be the best implementation detail. And there are actually some other similar solutions, which I'll get to in a second. But also, it might be a good solution because there's no double-data problem.

We don't need this scoping of CSS in most cases. And it really makes SSR hard, or sometimes impossible, if you have to support older browsers. So my conclusion was, it's only really useful for some special cases. Like if you're trying to build your own CodePen-like demo, you might need something like Shadow DOM to encapsulate arbitrary styles. But for my use cases, let's burn it on fire. I don't want it.Next, there's template tags. They're just strings. They're just strings that happen to live in HTML. I don't hate them, but they're also not all that exciting. Finally, there's custom elements. Custom elements, they're just any elements where you put a hyphen in the name. But they do have something of value, which is that they give you lifecycle events for mounting, unmounting, and updates. Without custom elements, there's actually no events in HTML to do that.You have to use mutation observers and track when HTML is being loaded, which also doesn't tell you when something is unloaded. So it makes that part a little bit easier. So there might be something of value here. Using that, I think it should be possible to put some logic, some programming in HTML itself, turn this mock-up language into a programming language. So I started thinking, could custom elements be used to create a lighter-weight HTML or sorts? If you're looking at all the perspectives, you might be putting it all together, figuring it out, or you might be really, really confused. What the hell am I talking about? Just wait. I'll explain it. It'll make sense.Yes, I built a new framework. Introducing Solenoid. It's like SolidJS, but with extra steps. It's a server-first atomic JavaScript framework. It is JSX on the server. The components are on the server. The signals are defined on the server, but then they are implemented in HTML. And then everything runs in the browser.

So how does it work? To give you a high-level overview, you write code like this, which is very React-y, SolidJS-y, and the framework generates something that looks like this. This is a custom element that defines the signal globally in the HTML for you so that other HTML can use it. But you don't have to write this gross, custom-element web component code. You can write code like this, which is, again, very SolidJS-like or React-like, except instead of state, you have signal, so they're functions. Everything is functions instead of data.And then the framework generates something that looks like this, which again uses a custom element that tells it which signal to look up and bind to and subscribe to so the data can be updated. So do you want to see a demo? All right. I have to switch. So before getting any further, this is an HTML file. It's an output. The framework is still very much under construction. So it kind of works. It's a counter component. We know what that looks like. But let me show you what it took to build it.So the counter component looks very similar to any Solid... Bigger. Bigger. Is that better? All right. Get lost. Okay. So a component in Solenoid looks like SolidJS. The signal API is slightly different, because it's using alien signals, where the signal is a function that is both a reader and a writer. So if you read it without... If you call it without arguments, it's a read. If you call it with arguments, it's a write. Other than that, it's just like SolidJS. There's no special syntax. All arrow functions are compiled in a certain way. All non-arrow functions are treated as components.

So you write something like this. And then it generates code that looks like this. So in the head section, there's a small runtime that's loaded in all apps. The runtime is currently nine kilobytes. It is currently lacking a couple of features, so there's no context or suspense yet. So at most, it should be 20 kilobytes. And other than that, there should be no additional framework JavaScript. Other than that, the only JavaScript that ever ends up in the browser is specific arrow functions, which are compiled to hoist out the closure. I'll show you how that works in a second.And again, I've made it a little simple, just to see. In a real production app, this would be an import statement, and functions would be deduplicated. So the important part here is I said atomic JavaScript a while ago. These functions will be hashed. So if you use the same logic in multiple places, even with different data, it'll hash to the same ID and it'll be reused across multiple parts of your app, just like atomic CSS. And then we define a signal, which is a count. We define some buttons that update that count. We define a signal text that uses that count. And then there's even ifs already implemented. Loops are in progress at the moment. And that's what gives you this working code. And it's literally that HTML file. There's no extra magic here. It's not even running through a server at the moment.To show you the compilation step of this, I'm going back to the counter. So that counter gets compiled into something that looks like this. So this part is mostly JSX, so that's not super interesting. What is more interesting is all the functions that you write, every single arrow function that you write in your component, might be using some data that is a parameter or an argument, but it might be using other data that just was around in the closure. So the compiler detects everything that was used from the closure, turns it into another argument called closure, and makes it a standalone function that can be serialized and sent to the server, which is how this works. Ready to show you, okay, that's running there. So when you run that component through the render function on the server, it generates a stream that looks kind of like this.

So it's generating script tags that define functions, it's generating let signal that defines the signal, and it defines all of the HTML that I showed you in the HTML file anyway.One final demo, which is over here, and I will come back to why this works, but one of the big value propositions of why I started building this is that there is no hydration. It is interactive while streaming in. So this is a special server that I've created that streams down the same HTML file one line at a time, and there's a one-second delay between each line. So I just want to show you how that works. So you see nothing for a while, then you see the count. It's already interactive while the HTML is still streaming in, and when the double count comes, it's already updating as well, and then when the final thing comes in, it's already interactive as well. So there's no delay for interactivity. There's no time to interactive. Interactivity happens before Contentful Paint, essentially.Going back to extended display, going back to keynote. So I want to give a special thanks to Vikram Rangarajan. He was my co-worker at Meta a few years ago. He helped with a lot of the framework. I would not have been able to build all of this in time for the conference, so I just wanted to do that. Right after that, there's a question of, is this whole thing a really bad idea? So there are some pretty major trade-offs and unknowns. So firstly, the whole thing just barely works at the moment.

But also, it might be a good solution because there's no double-data problem. So every modern framework today, when you server render, renders the HTML. Then it sends all of the data payload that you used for the server rendering and then sends all the components that were used to convert that data into this markup. And then it hydrates on the client, and then it just repeats everything twice. So you're sending all of the HTML twice, once as the HTML, once as the component. And you're sending all the data twice, once as the HTML and once as data. Here everything is just in the HTML and there's no duplication whatsoever. There are no hydration, there's no hydration, so everything is interactive. Which means there's no hydration errors. The HTML is the source of truth. Hi, I'm Naman, I accidentally created a quick JS clone. Thank you.First of all, I want to ask a question for me, which is classic, like, oh I have a problem to solve, let's build a framework. And this kind of, it will lead into some of the other questions, but first of all, at what point did you go, okay, framework is time. At what point did the kind of problem you were trying to solve hit a point at which you're like, moving into a, building something new is the strategy? So I would say it didn't go in that way. I wasn't trying to solve a problem. This was an idea. And it was just, like, honestly, I don't know if this framework is a good idea or a bad idea as my conference ended. I know it has some interesting qualities about it. It's different from how everything works today. Eventually it may be good or bad, but I only built it because I was curious if it was possible. And that was like my journey of like, I had all these thoughts. I was watching Ryan Carnazzo's stream on YouTube, who's the creator of Solid.js. So I've just been seeing things in this industry, I've been getting all these ideas. I've been seeing people complain about things. And I was like, this idea formed over the last one year. I was like, let me see if it's possible. And turns out it is possible. So we'll see. That makes sense.

That makes sense. All right, we've got some questions coming in. Thank you, and keep them coming. The first one is how do you perform debugging in your framework? There's lots of different dev tools that people can use built into the frameworks they have. So how would your approach debugging, and maybe it's something you're going to solve in the future? Yeah, so firstly, they are fully honestly, I haven't thought about it. Barely got the demo working. I got the last streaming demo working two hours ago. So it's not like very done or anything. But just thinking about it, since everything is so declarative, since the entire data flow is represented in HTML, I assume that debugging would be a lot easier, especially for performance. Because I don't know if people are familiar with all the tooling that David Cappiano of what do you call it? Next state. Next state. Yes. Fame is known for he builds really cool visualizations. To build cool visualizations, you need like static data that you can consume. Usually with code, that's not easy because you have code and you at best you get ASTs. But in here, you have the entire data stream, like the entire tree of data dependencies represented in your HTML. So there's a whole bunch of tooling possible where you could just be like, look at the HTML generator graph, you can see how well it's performing. And you can see which specific elements are slow and which elements are fast.Oh, no, I love that. That's a very, very detailed answer. And the next one is someone's asking a clarification question, which is, did they understand correctly that the function shape is meaningful? So can't use arrow functions to define a component? Yes, that is that is currently the decision on how the compiler works. So Quick.js, which is very similar in many ways. They made some like the implementation is completely different. It was after I had built like 80 percent of it that it was pointed out to me that it's actually somewhat similar to Quick.js. They use a lot of wrapper functions and dollar signs to indicate what gets compiled and what doesn't get compiled. And I decided that I needed everything inside the component compiled anyway. So I'm saying components must be function declarations and everything inside the component must be arrow functions and everything will work fine.That makes sense. We've got another one. This one's from Mikhail Vandaros Heinemann.

If the front end logic changes nested DOM, nested DOM instead of text and the notation is JSX, are you streaming HTML or JavaScript to the browser? It's a combination of both. So again, in my HTML demo, yes, it was a very minimal demo. Hopefully it made some sense, but it's mostly just HTML streaming. Everything gets converted to HTML on the server, but the HTML contains little bits of JavaScript, which are the things that cannot be represented in HTML, which is again, event handlers and data transformations and that's it.That makes sense. All right, we've got time for one more. How can you use the components in other files? Is all the compiled atomic JavaScript loaded every time we use them? No, only whatever is actually rendered gets streamed to the client. There's actually no bundler. You don't bundle your JavaScript to send to the client. You write server code and the server runtime generates HTML at runtime and that's it.That's awesome. I'm sure there are many people who want some clarification, want to answer some more questions. They can find you over in the speakers Q&A spot. Thank you so much. We're going to have a short break. Remember, if you are taking the headphones off, leave them on your chair and let's give them a round of applause.

React Summit

React Summit 2025

Compiled Atomic JavaScript?

¿JavaScript Atómico Compilado?

React Summit US

React Summit US 2025

En 2008, la película Vantage Point inspiró la exploración de diversas perspectivas en el desarrollo de software. La evolución del CSS tradicional a estilos atómicos en StyleX y la ventaja de escalabilidad de JavaScript atómico son áreas de interés significativas. Repensar el renderizado del lado del servidor con React, Web Components y el marco Hano introduce nuevas posibilidades para componentes interactivos. Los elementos personalizados, Shadow DOM y el marco Solenoid abordan desafíos en el alcance de CSS y SSR para HTML más ligero. Las funciones de señal en Solenoid ofrecen un enfoque único para la gestión de datos y el desarrollo de componentes, mejorando la eficiencia de la aplicación. La configuración interactiva en tiempo real del servidor, el desarrollo innovador del lado del servidor y el uso de HTML como fuente de verdad contribuyen a la velocidad y eficiencia del proyecto. La depuración, la definición de componentes, la transmisión de HTML y el uso de componentes destacan la naturaleza declarativa y las capacidades de transmisión del HTML generado por el servidor.

¿Podemos aplicar las lecciones de CSS a JavaScript?Mientras trabajamos en StyleX usamos la compilación y la técnica Atomic CSS para crear un sistema más eficiente. Tener pequeñas reglas CSS atómicas maximiza la reutilización y reduce drásticamente el tamaño del CSS a escala. Un compilador potente hace que el proceso sea automático y libera de tener que pensar en DSLs personalizados. ¿Podemos hacer lo mismo para JavaScript? ¿Cuáles serían las compensaciones? ¿Puede resultar en beneficios únicos no posibles con la mayoría de los otros enfoques?

Naman Goel

JSNation US

I’m attending JSNation US. Join me there for free with 10k other JS engineers and 50+ great speakers. Just follow this badge.

JSNation US 2025

TechLead Conference

I'm attending TechLead Conference 2024 – get your free remote ticket and join me there

TechLead Conference 2025: AI in Orgs

Productivity Conference for Devs and Tech Leaders

I'm attending Productivity Conf - get your free remote ticket and join me there with 5k professionals and 25+ great speakers

AI Coding Summit

React Advanced

React Advanced 2025

React Advanced Canada

React Advanced Canada 2026

Node Congress

I’m attending @NodeCongress, the biggest conf on #JavaScript backends – by clicking the badge you may get a free remote ticket & join me there with 5k other #nodejs devs & 15 great speakers #deno #cloudflare #awscloud

¿JavaScript Atómico Compilado?

Comments

Available in other languages:

Subscribe to the top JS conferences