Using React without using React - by Krasimir Tsonev

In this talk, the speaker explores the principles behind building React-style applications using vanilla JavaScript, without directly importing the React library. He shares insights from his experience as a React developer, emphasizing the importance of component-based architecture and state management. The speaker provides examples of how to structure applications declaratively, using simple functions and JSX-like syntax with tools like ES Build. He reflects on the significance of understanding the fundamental technologies, such as HTML, CSS, and JavaScript, and encourages developers to grasp these core concepts to enhance their programming skills. The session ultimately challenges the notion that one must always rely on frameworks like React to create effective web applications.

Challenge accepted. Challenge accepted. Challenge accepted. P2 is always challenge accepted. Our next speaker comes from the seaside city of Varna. And while most people go to the sea to relax, he spends his time writing JavaScript. >> He's the author of books on note, GJ JS, JavaScript, and React. A longtime open source contributor and frequent international speaker. Today though he's going to show us something that might sound

like a paradox using React without using React. >> It's all about principle behind React components declarative UA UI smart state management but apply it with plain old vanilla JavaScript. >> So whether you're a front end dev full stack or just curious how to build React style apps without importing the library this session is for you. Please welcome to the stage from Varna Bulgaria. Okay. So yeah, I

don't know something will happening. Uh your keyboard cannot be identified. back. >> Quit. Where is this? Where's this play? >> I don't know. I'm not. >> Is there a QA in the room? So, um, since I feel a bit like I'm at the Oscars, I want to first thank to my wife for being always next to me, to my parents. Um, something with the mirroring is not

okay. Uh this please HDM. More people. More people. That's weird. Maybe we could start with the questions and then come back to the talk. What is supposed to patrol? my own one. >> Now you see using React without using React in real life. >> No, no, it's >> I think it's okay now. >> It's coming. This full screen Okay, PLEASE APPLAUD S. >> Sorry about that. Uh,

okay, cool. So, as you find out, I'm Kazit Sonf. I'm a first uh father of two. This is me and my kids a week ago in Italy. Uh but because I'm uh trying to be a tough dad and my kids they saw this picture and I don't want to be uh I want to be book strong. So this is me on the second right of this train

just trying to be the badass. Um so I wrote these books. Um don't buy them. It's maybe only the last one. Uh the others are really outdated so it doesn't really make sense. Um I work uh I just joined recently at this company called Trusty. It's here in software. We're building some apps with React in the insurance uh sector. So today I'm going to um talk about

lessons which I learned in the world of React which I actually started using outside of React because sometimes I have to build apps which are um basically done with just HTML CSS and JavaScript and I realized that I started to think as a React developer even though they're not uh using React. So this is a small app which which I did. Um I click the button wait

a bit to get the data. Um I get the JSON then I populate this dropdown. I pick something from the dropdown and then I render uh a little bit of text and some characters from the show. So if we look at this screen and if we have to u think about what kind of markup we have um then it will be something like this. And immediately if

a react developer starts looking at this uh markup the thing that the react developer does and including me is basically um trying to recognize components. So I'm seeing this uh h1 tuck and I immediately think okay this could be just a title. Um I'm seeing this grit um kind of uh section. Uh then I'm just creating grit and grit um grit item. Um and then I'm seeing

this like a character uh portion of of the page. So I create a character component. So this is the main thing which comes with React and this is why maybe React scales so well. It's so popular. It works for big and small teams. uh it's because it's based on uh components based architecture and this is the very first thing which people uh start doing when they work

outside of react they basically start thinking about components what kind of things we have on the page and how we could create different components and the component has input as output there's something in the middle which is like the life cycle and of course of course there's this um composition enabled by the framework uh but if you don't use react what you could do is just use

functions and in fact you could achieve absolutely the same thing. So here in this example u we could see that I have props like the columns at the top I have children and this is purely just an idea. It's not really the framework doing it. It's it's me just um creating functions and calling functions and they return markup and I could achieve absolutely the same composition by

using um this idea of having components the idea of having children and then nesting different components. Um so this is the first first thing that you could just use outside of React. It's um just simple functions. Um and this is the function kind of like the render function which combines everything. um has has this props um and yeah we could see the mapping then you return the

character component uh so it's it's basically the same so what about the GSX when the GSX came um in the beginning of react all people were kind of uh really against the idea because um we'll be I'll be mentioning the separation of concerns but basically um people are against um writing markup together with the logic together with the styles everything is just in one place and step

by step people realize that this is actually a pattern which um really works well and what GSX is is just a syntax sugar um it's something that we write then we use some sort of a tool which is like a bundler compiler or transpiler or it depends how you call it um but what this tool is doing is reading our source code and it's transforming ing this

um gsx elements to something else in in by default it's react.create element. So the code above is actually absolutely the same as the code below. The code below is the one that we ship to to the browser. So now if you don't use react can I still use JSX? And yes we can. I strongly recommend a tool called ES build. um mainly because it's really small, it's

really fast and it's not uh it doesn't involve any other things than just reading the code, transpiling it and maybe bundling if you want to be bundled. Um but it's purely about transforming your code from Typescript or uh JSX to just valid JavaScript. And there is one little um um one option to the configuration of these two and this is called JSX factory. So I could by

default is react.createelement but I could add whatever I want. So if I add banana dance then um what happens with the code below is what I get um at the bottom of the screen and what I get is actually just a function. So it's just um up to me what this function is doing and I could implement my own logic about rendering my own uh composition. Usually

it's just composition. uh people don't deal with virtual DOM and stuff on their own because it's too complex. But you could create um some JavaScript JSX files. You could still use JSX and then at the end you just like concatenate strings and you receive um HTML for your page. Um during my practice I saw some weird cases about using JSX and this is one of them. Clearly

someone was a bit too excited about uh writing uh GSX and these people were writing CSS using HTML which was a bit weird. Um more valid use case was um when the company was using ExpressJS as a node server but they really liked how react router is defining um the different roots. Of course, they didn't have React. Um, so they decided to use JSX and just transpiled

stuff with ES build. Um, and you could see below the JS factory function is just this R function. Um, and of course they implemented what's um, what's in there. So the separation of concerns in React was a topic in the very beginning. Uh, and it's touching a lot on how you build apps if you're not using a framework. Um, back in the days this was a really

big thing. Uh a lot of people are including me we are advocating about separation of concerns meaning you put your templates in one place then you put your logic your styles in different place and you manage all these three things um in a different way. uh when React came this all become into one single component and this was kind of like a shock for a lot of

people. They they were against this framework this library because of that. But to be honest during the years I realized that actually React helped u a whole generation of developers to separate better because nowadays when you write React components you don't really put everything into one place into one single component. You still write components which are purely about styles. You still write components which are about logic

about about templating. So in this example you could see how I have the styles at the top. I have some logic in the middle. Um this get products function is fetching something from somewhere and at the end I have this um markup which I kind of compose and render based on the data and the state. So now here we there is no separation of concerns. Everything is

just in one place. Um but no one is writing writing react like that. It's usually you either extract this get products into a custom hook for example or it's just not there. It's it's a a function that you add at the top. The styles are actually exported into a button uh component. And this function becomes something like this because uh yeah you want everything to be manageable.

So people started following separation of concerns not because they know where it comes from not because they know the pain that we failed before but this is because just how um the react development is um is made nowadays. So just behind the scenes actually react is advocating about separation of concerns and people started implementing these patterns and ideas um not because of the problems in the past

but because it's better and it's scaling and um yeah there are a lot of benefits of doing stuff like that. It's just more manageable. So there is definitely not a problem with separation of consumers and in fact I think React is contributing to this to this idea. And if you go outside of React, um the companies they start thinking this way. They they see I have I

I have styles maybe I have components like a design library. I'll develop all my stuff into a place which is okay. I have a button, I have a title, I have a uh components for text and everything. Um so it is separated. It is um what about the control? So this little app which I showed you um it starts with a button on the top left. Then

we have you click the button there is this um spinner which is showing a message loading get the data render the select then we click something of the select and we rerender the page. So this is basically the flow of this little app that uh that I did. And if I have to describe this into a list of steps that happen, it's it's something like that. Like

rendering the button, handling the click, fetching the data, rendering, handling change, rendering again. So if I go out of react and in fact if I didn't use React so far, um I could start doing some vanilla JavaScript with this. Um at the top, I just use inner HTML. I place some HTML into some DOM element. Um then this DOM element triggers a function. I get the data.

I have another function which renders my select um element on the page. Uh and then I change something of the select and I rerender again. So this is um the so-called imperative programming. Um without React the decorative programming wasn't really that popular and everyone was writing front end using imperative code which means that you're basically um not only saying what will happen but you are doing it

yourself. You write all the code yourself. You change DOM elements, you swap DOM elements, you apply you change the content of the D do elements, you change the styles yourself. uh while when react came uh it's kind of preached this idea about decorative programming where you just describe how the UI should be at some point of the time based on the state and this idea I can't

tell you how many people are just thinking this way they don't know any other way of writing front ends they know that there should be a state somewhere and they know that if you have a UI it's just based on it's a function of the state so you change the state and you change the UI. This is kind of u injected into their brains and this is

how they think. So if I have to change this example uh with imperative code with um with the curative programming then I have this state thing which keeps u all the all the variables of my app which is like the holding flag the data and the selected show um and then I have a function which is changing the state and it's calling render and then I have

in the render function based on a state I render everything. So this is now I'm doing the same thing that React is doing in a declarative way but I'm writing it with the new JavaScript and it's not that difficult. You could see that this are like 30 lines of code and I'm just doing fine. Um so one direction data flow is something really really important and it's

uh it's done in the every single component um you know on a really small level. If you look at your react tree, u every single component is basically following this because when you state in your components, this is what happens. When you state in on your application level, this is what happens. And people they think like that nowadays. So this is u together with the idea of

having components components based architecture. Maybe this is the second thing which is um introduced with react and people just learn and they use everywhere without thinking. Um even if if you put someone which is uh spent years writing React into an app which is not written in React, they would definitely try to implement something like this because it's really easy to reason about. It's it's really easy

to think uh to fix bugs to see what's happening. It's just u yeah it makes the app really simple. So um yeah, I'm showing how it works. Um what about state management? So I could make a whole talk maybe even more maybe a whole conference about state management because we know that state management is something which um usually is they say the most difficult thing in in

in front end programming and it is in fact it is um but what I got from react is not about how to manage state um it's more about uh the approach about state management basically looking at uh what kind of state you have this is basically the the key think you have to realize what kind of state you have and then then you find the tools to

deal with it and um last couple of years people actually stop using that much of a libraries but they started using only react about state management uh because you may have state on some really small component about showing and hiding a text so this is a local state then you have a form which have more state then you have application state which is configuration whether the user

is authorized or not so it's really about um separating different types of states and knowing where to manage the state. It's not about tooling. And this has nothing to do with React or any other library. It has to do with just how you write front end. Um and I hope more and more people will start thinking about state management this way, not about throwing redox everywhere and

keeping everything into your context at the very top. um just manage the state by just looking at the state and um if you use if you write vanilla JavaScript apps you just could use the same approach um you don't have to put everything into a global store for example um so Redux is definitely uh something which uh came with react but we all know that you could

implement it with 13 lines of code and I bet that most people did it this is the same like flux when came back in the case um this is just a pattern and this is the beautiful thing in react I think it's it's a library with really thin layer of like API there are not so many things to do but there are different patterns which the library

teaches and you could just get these patterns and apply them without um uh without the library itself. So now um I'll do a simple demo and I'll show you how uh how the React developer thinks and how the React developer does a front end app. Um so let's say that I'm a senior React developer and I have to do a form. So the form starts with something

like this. Um, I have a little input field, some radio buttons, but because it doesn't look really nice, uh, I need some space around my elements. And what every developer does when um, he or she needs space is just adding break ts, right? This is how we make space around the elements. And uh, really quickly, this is a bit ugly. So people just start using diffs everywhere

because the div is a DOM element. Everything is just uh now on a new wine. So that's cool. But um because I'm a React developer, I need to write some styling, right? And um I'm not going to use just CSS. I'm going to use Tailwind. So I start adding classes here and there. And I add uh 17 classes to this div element to make it a button.

Yeah. So just typing, typing, typing, typing. And at the end this register will become um a really nice really nice button. So this is all cool. But then when I go to this radio buttons when I click them they're not exclusive, right? So I can't even click on the labels. So here I'm going to use my React power skills and basically um implement some uh some state

management. I use the state tools of React and I'll add a bunch of hands uh to apply click events to my to my elements. So now I'm able to click and everything is working just fine. Then I can't click on the yes and no. So what I'm going to do is that I'm going to wrap this yes and no into a spanax and I'm adding more events.

So I change the state more. Um and now everything seems like it's working. Um, of course I have to add um click handler to my um to my div element because this is a button now. Um, and yeah, I'm done. So, do you think that this is a cool way of building apps using React? Do I do you think that is the right way of doing it?

No. Right. Um, so and it's not it and this has nothing to do with React. It has to do with the web and how web works. So the way to go from here is basically to use a form element first because you're building a form and most people don't know what this changes but it changes a lot. There are elements which when you put them into the

form element they actually uh provide more functionality. They work in a different way. Um the next thing will be to um maybe use field set for the different sections of the form and I don't know if it's visible enough but um the browser actually renders this nice sections. Uh so it's even kind of grouping this elements. Then um the next thing that we do is that we

kill all this crap about state management. This is just insane. This is basically the the React developer is implementing what the browser is doing already. So uh when we remove the state management we could just add uh name property of the input radio elements because if the name property is equal everywhere this u these two elements they are grouped and so I could click one and the

other and they are exclusive. Um, then if I want to be able to click on the labels, then I just add another nice element called label and I wrap these guys into um um kind of this grouping. And so I'm to click here and there. Um, and last but not least, uh, I don't really need to write a diff instead of a button. I know that this

sounds ridiculous, but uh I could tell you that I'm still seeing this. People are writing diffs everywhere. They copy pasting snippets from Tailwind. They style their buttons this way and um everything seems fine. And it's not it's not because not because the page is um it's not accessible. We're not talking even about that. It's because it doesn't work like that because the tabbing doesn't work. And then

you fall into the case where you want to actually fix the uh fix the tabbing then on the page like even now for example I could go to the radio button and I use the keyboard um on my laptop to switch between the options. So think about how if you don't use uh just web you have to reimplement all this on your own which means attaching a

handware about catching the keystrokes of my keyboard understanding that oh this is the left arrow this is the right arrow then I switch the state and it's it's so much work for something which the browser is already doing and um the the submit handware now because I'm using a button and because the type attribute of button has a default value of submit and if you put a

button inside the form this button acts it's something which submit this submits the form. So all we have to do is just to attach a handware to the form uh saying on submit and then we handle whatever happens to the form. So, um all this uh is here, this example is here just to um to kind of show you that um even though React is really cool

and it's it makes your life easier, you don't really have to have to use it and have to know and and know everything about it and or maybe have to use it every time. Um some time ago I had the chance to um to help to the company hiring hire new front-end developers and maybe out of 100 people um the majority of them they didn't know web

they knew only react and this picture I generated it with chat GPT is illustrating really well how people just get the elevator every time they take the shortcut to oh let's build the app okay we'll throw vit and then we'll just build up really quickly. Okay. And they copy paste a bunch of stuff from Tailwind website about some ready to use components and they throw them there

some glue code and it's done. And very soon when something more complicated comes uh people just can't handle it because they don't know the the the platform. So don't take the elevator uh take the stairs because every stair is actually will make you a better developer. I believe that knowing your like the fundamental fundamental of what you're using is really really important. So don't skip the HTML

CSS because it's boring or it's not a language. Yeah, it's not. But you have to learn how to write semantically u proper code. You have to know what the CSS specificity is. You have to know how to write CSS without using just tailwind. Um, I'm not even talking about the the basic JavaScript APIs in the browser like the history API or how to read a cookie or

something. Um, try building apps with just vanilla JavaScript. It's good that React is teaching concepts and patterns because then um you could take all this stuff and just use them in in just vanilla JavaScript and they work. They work because they're really really simple. Um this is one of the reasons why in the past I I didn't really um I didn't feel that angular for example is

my thing because angular was teaching uh APIs it's indeed enterprise software it's better maybe for bigger companies um but when you learn something in this context you can't apply it into uh other world and all these years maybe there I don't know maybe eight years I'm writing react apps and um all this stuff that I No, I could just use them in my vanilla JavaScript apps and

they work because this is just patterns and this is the beauty of the library. So use React when you go there but use the stairs first. Uh learn learn the basics. Um I believe this is much better for you and for your career. Um yeah, thank you Thank you, Crassy. Any questions? >> That's that maybe in the speakers corner. >> Uh, we have time for questions. It's

okay. We have four minutes for questions here. If are there qu any questions from here? >> Okay. So, the questions will be asked in the speakers corner. And now let's send off uh the stage our friend Graasi Grairon.