Client-side vs Server-side Web Frameworks

hey there so I came back to this YouTube channel to have a little chat with you about the grand topic of client side where the server side web Frameworks and uh I just came back from Portugal last night and you know my train got delayed and everything so I didn't have milk this morning for my coffee I'm in a great mood to talk about the pros and cons of different Frameworks and why do I want to talk to you about this today well last week um or two weeks ago maybe a whole Twitter thread started again between backend folks and front and folks discussing pros and cons well discussing uh I would say rather fighting over uh the pros and cons of pro of server side and client side rep Frameworks um the hay calendar in particular was uh criticized for its not responsiveness and then dhh got involved of course um protecting its own little child and yeah as dhh does he's not subtle with his criticism so that started a whole discussion where also Theo got involved he looked at it um from his from his own perspective and he made it really good video about it so if you want to watch that one it is called rails deserves better and he goes into the whole discussion a bit more but then Elixir got involved or lifeu got involved because Ryan Florence and yeah he got called out by us and um he you know us asked him to review the live beads live VI web app and to break it you know to also apply the same scrutiny that Theo and others um appli to the hey calendar to a life view app which is a service at r that Ryan looked at it um yeah he I I actually after I I read his um I watched his video I got a little bit upset because I was like yeah you kind of broke the web app like you you broke the app not the framework you know but then I watched some of his other videos about other uh demos that he reviews and uh I understand now that he's more on the side of looking at the product and just you know playing around with the product and to see whether he can break it or not instead of looking at the underlying framework and kind of like you know breaking that one so there was nice though that the discussion happened uh it was a little bit heated as all discussions on Twitter are so I wanted to take today to have a little chat with you about what is client side Frameworks what are service side Frameworks what are server side rendering client side rendering aesthetic side generation uh optimistic update what is all of that stuff so what is the the foundation here the technological Foundation that we talk about in this um in this discussion all right and I think it is important to first understand the underlying problem that every web framework tries to solve and the underlying problem in 99% of the cases is that you have some persisted State somewhere and you need to make that accessible for your users so persisted pisted State and this state might live in a database or it might be a file that you have on your on your hard drive or it might be in a cache like a memory cach somewhere or anything but there something you persist and it's something you can't just give access to to your users you can't give them a direct database connection that they can use to query and update this uh data you have to kind of control the access to it and yeah on the on the other side on the the like on the the other side of the equation you have your user and the user sits at home and wants to access the information through a usually it's a browser in our situation because we talk about the web and yeah they're going to use it and then in between the user and your system lies something called the internet all right and this is a barrier that you will have in every web application you know unless your user physically plugs into your server there will be something like a network in this case the internet in between your browser and this part here and what you have on the other side of the internet is usually a server that will uh yeah get your request like it will receive the request from users for viewing or updating or modifying the positionist state and this is also where you do all the authentication of the user this is where you do the business logic where you apply the business logic to uh to check that your position state will always stay in a um in a in a good State you know it will not be compromised it will always stay consistent with your business logic all right so now if you want to give access to your possess state to your user usually you add some HTML or you render some HTML in the browser over here and then the user Cana with that HTML and uh you know click a button submit a form or something and that's already that brings me already to the first point of this discussion like when I listen to people who Advocate client side Frameworks like Spas you know like uh react or nextjs or remakes um sometimes they like pretend that is no delay like sometimes they pretend that their apps don't need to talk through the internet to the server and update the data you know it kind of like seems oh you know if you press this button immediately the model pops up well yeah but if you submit the model you still need to wait until the server receives your date or update something the database and then you know returns to response so every interaction almost every interaction but you know I'm I'm getting I'm going to get to the more nitty gry details later so almost almost every interaction you have between your browser and the server goes through the internet and there are always like two major protocols that people use nowadays one of them is HTTP and the other one is web sockets and yeah these two protocols they are used in almost all web Frameworks nowadays they are the the standard you know that that we all use so it doesn't matter which framework you uses use like if you use a server rendered framework like live view if you use something client that rendered like react they all will need to use HTTP request and web sucket or web sucket messages to communicate with your server to wait for a response and then you know to show that response to the user that is with all of them now the waiting time until you get the response you can make that rating time prettier or less pretty right sometimes you just show a spinner until you get you get a response or you can already update the HTML in the browser without waiting for the response and that is called optimistic updates okay so this is something a technique you can use in your front end to update your HTML before you even get the response from the server you know so you you submit like uh the calender entry um and you already show it in in the front and in the in the grid and then then only later you will get the server response that actually says well yeah I actually created this um this calendar entry now this optimistic update thing that is something where the web Frameworks differ like this is something that yes client side Frameworks can do better than server side Frameworks but you know there are some some shades some grades to this like it's not a black and white thing where server side Frameworks can't do optimistic updates and server side Frameworks can like it's not that you know only one side can do it and the other is not but we will get to that a little bit later now where these Frameworks differ is um basically where they fall on this divide between the internet like yeah off the internet do they fall on the front end side or do they fall on the back end side let me add a new thing here on the right now if you have a server side rendered framework so server side rendered these server side render Frameworks like live view or Hotwire they compile the HTML on the server and then send it to the user through the internet let me just extend this a little bit so they basically they take the data from the posed State and then they render the HTML and they send it back to the user okay and whenever the user interacts with the HTML you they they mostly send web socket connections but they can also send HTTP requests so they they send some kind of um request to the server s side render framework this one processes the request and sends it back to the the user okay this should be better and this is what a lot of frontend folks or client side rendered folks criticize they say well whenever I submit a button or a form I have to wait for this request here you know this goes through the internet it is handled by the server the server might create the the you know calendar entry and then respond with a yes 200 or 2001 um I created a calendar entry and then it sends back the updated HTML to the user also here there are some you know nuances so but this is like the the B you have the HTML being rendered on this on the server side and then only the HTML is sent to the front end and not just plain data now where the front end people differ from the the back end from the server side render people let me just extend this a little further is that they add a whole new layer to the frontend here and they they render the HTML basic basically so this is client site rendered and this might be something like react or nextjs which is basically re uh remix others view um angular what's the other one I forgot swelter so many clients that rendered Frameworks and yeah let let me add this to this side here now what the client side render people do is they only get the data from the backend so they request the data like get data and this is most often it's Json Json format and then based on that data they render the HTML and they just replace it in the browser so this way the HTML is maintained by the client by this framework on the browser like so like when you update the HTML it is right there you know if you show a model uh and you need to render the model for whatever reason it is done all on the browser of the of the user it is done almost instantaneously whereas if you do it on server side rendered there has to be a request to the backend to the server and back and only then you know like the browser will update the HTML whereas with the client side rendered the updating is almost instantaneously again however this only holds true if the client s side doesn't need to wait for the server to respond right if it needs to respond it is exactly the same as the servers that render there's also an a request in between they need to wait until until the server you know acknowledges the request sure like you send Jason instead of HTML back all these kind of things like you know but the principles here are the same like there's always a network request if the user for example submits uh a form and yeah again this is something that I often see um being neglected all of these Frameworks need to deal with the internet in between all right now the advantage of the client side render things is with one particular state which is not persisted let me let me show you what I mean so next to the persisted State you also have temporary State and now temporary is maybe not a good word but I wouldn't call it UI state but the UI state is also a little like it's a tricky word because people might say well the data I'm seeing is the UI state but it's actually the posed state so what I mean with UI state is just stuff like you know whether here this drawer is open or not whether I click this button or click this button whether I open the side drawer on this side you know all these things that are Irrelevant for the persisted State like I don't need to store that data in my database maybe I need I need to but that's part of my use case but usually it's not the case just like you know I open a drawer here okay it's instantaneously there if my internet connection is slow like opening these drawers might need to make a call like this would be a call to the server the server would say well yeah you should open the the the drawer or like the the model here and only then it shows right like if I have if I have a server side rendered framework unless I optimize for it like clicking for example the libr button here would be a network request to the back end the back end would say well yeah sure you should show the side Roar and this is the HTML and then the my browser would receive back the HTML and then render it and this is what a lot of client side people criticize you know they say well the interaction isn't smooth because there's an inter like a network request in in between and I agree you know this is like this clicking this model or like this drop down or this drawer like it should be instantaneous and if my connection is bad you know still the the drawer should open immediately there's no reason for me that I should wait for this like that I should wait for a server to to render this for me yeah and this is again this I think is the main point that clients side rendered people criticize about service side rendered Frameworks however what they like what they look at the the the core data you know the core thing that they are concerned about is this particular state the UI State the temporary State you know whether this thing is open or not whether this thing is open or not whether I can open this model here right and yeah that is different from the persisted state so don't confuse these two things like whether or not you can open a drawer instantaneously or not doesn't matter like it doesn't matter for your web framework whether it can or cannot change modify uh and and retrieve the persisted state right and and that is something we need to take into account like this is something you need to keep in mind when people criticize service side render Frameworks all of these web Frameworks they can modify the position State all of the service side rendered ones can easily change the position State retrieve it update it whatever client that rendered once not so much actually it's much harder to change your positioned state in the database if you have a client side rendered framework like re basically you can't right like you need to have a server you need to have some backend code here that handles all these requests and yeah immediately you know clients that render ones they're like you know this the the most important state of the whole system is the business State it's the business state that lives in your in your database right so like having clients that rendered Frameworks they're great for the UI State for the temporary State you know for showing models and whatever but they're not great for actually doing the business stuff you know they can't do it without a server again a lot of nuances there and I think that is something to keep in mind this is really important server side rendered Frameworks they make it really easy to change your business State and most often these are already very established um languages like rail like Ruby on Rails or Elixir um PHP also that offer you this framework so you already have a really powerful backend language that has all the libraries you need to build a very complex uh backend application and then on top of that they already give you the server side render framework where you can now Al where where you can now also render the browser the the HTML on the browser so it's a very nice extension of previously only backend focused Frameworks to now having interactive Dynamic front ends as well so service start Ren at once make it really easy to change your position client side RN ones make it really easy to change your temporary the UI state right um they make it really easy or make it much more possible to create very rich user experiences and this is the important part here this is a decision you need to make for your use case and your project that you're working on how rich does my user experience need to be right if you have something like Google docs for example where you have collaborative work on a single document and a lot of buttons and you know a lot of UI stuff yeah that is a very complex um experience that you need to support with the framework of your choice so in that case a client side rendered framework that then uses a an API in the back end to get and and update the data might be the best solution however if you decide oh you know the the project I'm building it doesn't need to be super fan it literally just needs to be a form well why then would you go for a client side rened framework if you could get it out of the box with a serti one because the persisted state is much more important in your use case than the temporary UI state right and that is also something that Chris mcord he mentioned in his keynote 20 in 2019 when he announced live VI which is basically you need to find on this scale between basic ux and Rich ux where your application should lie right um Chris didn't say we don't need any SP Spas anymore he said well you need to decide for yourself you know what is your use case but in many many cases our use case doesn't need a user a very rich user experience in many cases it is enough to have forms and tables about which I created a video course and also wrote a book um it's very e you know that's enough like you your user needs to be able to access the data to update it that's it and then your business use case your business case actually is is is happy like it settis fine in these situations yeah maybe just go for a server server rendered framework right but of course yes there are also applications which are Super complex um that need to have a front- end state that you know can um immediately react to the user input and have like uh optimistic updates for example you know because it needs to be super um Snappy the UI so to say now and what life you did in the last couple of years is to push the boundaries of what life you can give you in terms of a rich user experience because when when they started when life you first announced it was pretty basic I mean you know in comparison to what it is now it was already mind-blowing at the time but you know in comparison to what it is now it was pretty basic And even Chris said when you started in the The Life View framework you know he just rendered the whole page on every request and then he made these chunks smaller on small and smaller to optimize the the data that needs to be sent over the wire for every interaction and then eventually also um life you edit the JS module where now you can easily show and high drawers and modules and so on all using JS but you actually don't need to write JS you know you just have a Elixir code that you can use to execute JS command right so you know when when Lifey was first released maybe like this is the ceiling or the boundary of user experience that it could um support right so you have like if your user experience would fall on this side of the scale life you would be a good fit if it would fall on this side of the scale it wouldn't be you know and you should rather reach for an SBA over the years though like Chris and the whole team they have done really great work of changing this boundary like moving it slowly slowly slowly all the way to the right you know by by giving the JS command by optimizing the the um data that sent over the wire uh us also was a big part of this uh this work um yeah and so you know the boundary always moved further further to the right so more and more use cases would fall on the side where live VI is actually a very viable option and that is the great work here now this has all been you know about the fundamentals um there's one last thing that I wanted to mention which is kind of how these Frameworks now all seem to be trying to bridge this Gap here like to bridge the gap between um basically back end and front end like here the server side and the client side right because what you what you got with service side rendered Frameworks is they come with a client side rendered framework out of the box kind of like they render the HTML for you they um update it in the browser for you you know they they do the mutation um and so on so like they came with a very basic framework there and they have have been extending that client side framework off of themselves and so so the thing is here what they did is like they they tried to breach the gap of um the front and backend and I've also been seeing client side render Frameworks doing the same and I just wanted to say you know if you now pick a new framework you if if you pick either side it doesn't mean that you can that you have to stay on that side you know if you choose a client side render it doesn't mean that you can never update the position state from the same code base and the same goes for the service that Ren at once where it doesn't mean that you can never update the temporary state from that framework right so they have been doing a lot of work there the clients that RS also have been doing a lot of work there and uh I particularly like remix um because yeah they they have everything in one file basically where you render uh a form for example and then you also render or write the action that should be performed on the back end for it so they make it really easy to write really rich user experience in react format but then also to write you know backend code that you can run with nodejs on on your server um so you know a lot of these Frameworks that have been trying to to bridge this Gap you also see uh nextjs for example you know they they do the same now where um you also have clients that render it but Serv that render it and uh yeah basically where you also write the the backend code in the same code base as a front end so this is a you know this is where you see that like the the client side ones they always go further into the backend side side and the backend side they go always a bit further into the the client side part well and until now I've been talking quite positively about all these kind of things so I would like to take a couple of minutes to talk about the negative things that you know both these approaches have and because service that rendered Frameworks have been quite um yeah in the focus lately I would like to settle those now obviously the criticism that service side render Frameworks make user interaction slow it is true however it depends on how you build it right so if I you know make opening this um this drop down here if I make that an HTTP request to the back end to ask hey backend can I open the the drop down or not and the back end needs to respond to that yeah no that's that's not great you know and then if my internet connection is slow I will click here nothing will happen and then only like two seconds later maybe this thing opens it's terrible you know that's why I said earlier that a lot of these Frameworks now they also extend the client side rendered or the client side framework uh to allow that these interactions are super fast so that is that is one downside um you need to be like it's much easier to shoot yourself in the foot with a server side rendered framework if you only develop locally you know and and you make this an HTTP call or like a web so connection um and this is also what what Theo for example like he criticized because you know somebody opened a model here in in the hey calendar and then it took like two 4 seconds to open to show you know this is literally where you open a model and then the HTML needs to be fetched on the back end like this is not great this this is bad use experience um however it was fixed eventually using JavaScript you know so this is how how it went and um let me go back here right so this is the major criticism and it's true you know but it is being mitigated now the other criticism is of course that you can't write Super Rich use experiences with serice side random Frameworks and that is true as well this is what I I showed here right but you you need to be like you need to be conscious about where on this scale does your use case fall and you got to be honest about it right because not everything needs to be as interactive as a Google doc like most of the things we build are just forms and tables anyway all right this is serice side rendered another like personal experience I had with um service side rendered web Frameworks is that it's much higher harder to hire for them like proper front end people who do client side work with react or something they rarely want to take on jobs in life view for example and then only build Life View because first of all yeah it's not as exciting second of all it's not great for your career because you lose connection to react and and what's going on there um and you also don't really become a proper backend engineer because you only do the Life View part so it's hard to hire for these positions however you know the backend Engineers can take over that work and and you know if if they are handy enough with CSS to build some front ends um if you have a designer usually that also works out pretty well you know but you got to you got to hire a little bit differently if you want to use such a framework you got to higher more full stack oriented backend engineers and you can't just have this divide where you have a very professional frontend and a very professional backend engineer you rather need to have like full s Engineers so that's another problem here now let me yeah go to the server side render now because um one of the biggest issues of client side Ren Frameworks is that they kind of duplicate the persisted state in the front end so they have their own little version their own little um data set of the whole persisted State you know not all of it just part of it and they work based on this data and they update the data through the get you know through HTTP request with a back end but the problem here is that you know it can easily get out of sync with a position State you know if if another user Updates this date we need to update it also in every client that is currently running uh and so on and and also just handling it in um in the front end means that you also mostly need to duplicate business logic because for example if you have certain Logic for example for a calendar event that the start date can't be before the back the end date um well you know it's pretty basic but it is business logic that needs to be always correct in your database you can never persist an event that has the end date before the start date unless you know time zones and um and the the leap day whatever like there a lot of exceptions of course but like in general there's some validation here that you also need to apply in the front end so you need to duplicate it to the front end and then whenever the user inputs some data you need to to check that validation um immediately here and you need to duplicate the the logic also in the back end right so now you have two places where you have business logic one's in the front end one in the back end and yeah that already adds so much more complexity now the second part is that um you need to mostly um not always but often you need to have two different code bases one for the server so like this usually a backend language and then you have a front end that is you know in JavaScript mostly well actually only JavaScript or typescript um so out of a sudden you have two code bases you need usually need to hire two different Engineers you know backend engineer front engineer for those these two people or these group of people they need to coordinate their work the backend person needs to offer the API that the front end person needs um and so on so on you know if there's like business logic again that needs to be um like implemented both people need to imp mented in the same way which is also not diff like easy you know when it comes to like data um passing for example like in JavaScript you need to have a a daytime with a time zone and then in the back end you handle that differently and these two things don't match for whatever reason like there's a lot of a lot of detail here right and immediately yeah you need to have two people doing this job instead of one back in engineer again you could also have a front engineer that takes over the back end however what I showed you like like the the remix uh nextjs like their backend functionality is usually not enough for a proper backend application where you might need to pull in other um Technologies like whatever message cues caching um different database connections and so on so you know that that is the second part where you immediately have a codebase split um and then you need to have two Engineers working on each and they always need to synchronize their work it makes Mak everything slow as well you know you uh you don't have one person building the whole thing like from the model to the database query but you have two people and they need to coordinate in the middle and from personal experience I can also say that it is much harder for backend engineer to care about the product um if they don't build the front and themselves as well um I had that situation where for 2 years I was merily building API end points and it was fun work but you know if you don't if you never see the product like how it interacts with the apis or like you might only see it a week or two later when it hits production and then you actually need to go and you know test it yourself like you need need to make it a point to actually see the front end part to your backend work it makes it much harder to just care about the product to see the little nitty details that can go wrong you know maybe if you build the front end you immediately see that your data representation doesn't really fit your use case because users input the data differently than you expected but you wouldn't like know about this like the front end person doesn't know about your database schema and you don't know about the front-end schema right so that is also a thing where I realized ever since I've building fulls applications myself like Indie courses my video course platform and also client work um I realized that you just you just find these issues easily if you do fulls development uh I wanted to point out one extra thing here uh for the ex for the server side random things there's another negative that I forgot to mention earlier um it also depends on how the service had rendered framework does this data um transport because if you look at Hotwire in in rails for example they replace whole chunks of HTML when they update right so like you have a little form and it needs to be updated they replace the whole HTML again the optimizations that you can use but I think by default they will just replace the HTML so they need to send the whole HTML over the wire uh which is in much bigger in size um and also they use HTTP there are some websocket implementations you can use uh but what I've seen in in in the demos is you use HTTP calls and HTTP calls are almost always less performant than websocket messages because they have to go through the whole stack of authentication uh you know passing your whole your whole stack like all the the middleware that you need to execute uh when a request comes in all of that needs to be executed for every single request you know for every single button click navigation whatever um and then they send HTML back which is much bigger in and larger in size um than the raw data that you need to change is that is something that life view for example does much better so you see that nuances in the in the service that rendered Frameworks as well with life you you use websockets so you don't have the overhead of making HTTP calls for every change in your HTML and they don't send back the whole HTML they only send back the exual data that changed so if you have like a number on a page and the number changes they will literally only send the new number and not the HTML around it that is an advantage of Life VI um because it uses earling and it starts a new process for every single client that connects to your server and in that process they can also save like cach data you know that's another Advantage where you don't need to go to the database for every single request and fetch the same data um you can keep that in in memory and then work on on that cache so that is something that Lifey already I think does better than Hotwire so you see like you know there there can be cons to the service at render framework depending on how they designed their their approach so this video is already long enough and I hope you got my points and everything one last argument I wanted to make um which you know also like takes off the edge of the whole discussion a little bit is that even clients side rendered Frameworks nowadays do a lot of server side rendering and the reason for that is Google indexing if your website is on on the public internet so it's easily accessible and you don't need to log in Google will try to index it right and if you want to be indexed on Google you basically have to return the pure HTML to the crawler of Google so so they make a request to your website and then yeah maybe if you use react actually that's an issue I learned um so if you return just like if if Google ask your react website to return the HTML for the for the website yeah react doesn't like it builds the HTML only when it's fully loaded so it only returns a very empty HTML document and you know the the solution for that now is for example nextjs which is known for server side rendering and they also do static side gener ation where they generate the entire document uh and they just keep the HTML in in in memory which is great for blocks for example and any static um like uh any static content and even remix I I learned uh although it was a little like I need to to really read to the document that don't like fully say um they also do the same you know if you have a remix website actually I went to the uh to the Showcase here and I think I went to Shopify and if you look at the the website here and you look at the document that you receive it is also a fully generated HTML um document that then Google can use you know you see it down here that Google can use for indexing the website right actually oh I have a slow throttling on um yeah so even these frontend the client side rendered Frameworks they do an initial server side rendering for the HTML and then after after the HTML is sent to the browser then they hydrate it so they make a dynamic and they add all the JavaScript to it uh but yeah still like you know we're all kind of trying to solve the same problem in different ways in with different approaches but at the end of the day we all try to solve our users problems and you know make them happy so that should be our M main goal now I hope you enjoy this video I hope you got something out of this um just you know the main conclusion here is like if you need Super ux of course go for client that Rand out framework see whether you need a backend as well maybe you don't need a backend so you can use the the client side like extension uh into the back end for updating the position State uh if you don't need a super rux maybe get server side rended Frameworks to try you know life view is here to welcome you with uh open arms and I'm also here if you have any questions you can follow me on Twitter it's PJ or um I have a Blog on p.com and a startup at IND courses.com for setting your video courses I hope you enjoy this video I'm not very active on YouTube so you know you can subscribe to the channel but I probably won't upload anything in the next years months I don't know so better follow me on Twitter uh to stay updated all right I hope you enjoyed this thanks for watching have a great day bye-bye

Let's dive into client-side and server-side frameworks, how they work, their pros and cons, and which problem they try to solve.