You might not need a frontend framework | Afonso Cerejeira

Speaker 1: Hello, thank you for attending this talk. My name is Afonso. I work as a DevOps engineer at Colabra and I'm currently based in Portugal near Porto And this is the first time that I'm speaking here at DjangoCon. I've been using Django professionally for about two years, mainly developing internal time tracking tools and some financial tools. In just talk we are going to explore different lightweight front-end solutions that do not require building uh the whole a whole single-page application. project. We will see how they integrate with Django development and the advantages and disadvantages of each one of the approaches

Speaker 1: As you know, Django is a full-stack framework that follows the model view and template architecture. This means that traditionally a Django server is responsible for all the application layers. uh from the database models to the template rendering process. So this was the most common pattern in web development. The browser would simply send a request to the server, the router would call the appropriate view, and then the view would respond with an HTTP. uh response containing the rendered HTML. So this architecture delegates all of the work to the server. If we wanted to have a bit more of interactivity

Speaker 1: with the client, we would also send some pieces of JavaScript in the response and then the browser would execute them. This architecture pattern is fine for most websites that do not require high user interactivity and are mostly static. However, we've seen in recent years a shift towards single-page application architecture, where the front end is completely separated from the back end. So in this case the backend would be a normal Django service that exposes an API, can be a REST API or a GraphQL API. and uh is responsible for handling the the database, the services, the tasks, and uh

Speaker 1: it is within this API that the that to the front end uh will communicate and retrieve data so the front end will be usually built around a JavaScript framework like React or Vue or Angular and This front end is now responsible for rendering the templates and um fetching the data from the API so the browser will communicate we directly with this front end not with a server like previously and then is the front the front end is responsible for communicating with the back end retrieving the the data, the results, and exposing them to the user in in an HTML response This new kind of architecture brings many f

Speaker 1: benefits to the development. I think the biggest one is that there is now a clear separation between what is the front end and what is the back end and that can be developed independently uh between each other as long as uh they both agree on the same API. Um this this might be suitable for bigger teams uh with lots of people. It might make development easier and more quick. And also because the back end is now required to have an API for the front end to communicate. It requires an API to exist so this API can also be used by other clients like mobile apps which might be useful In the future end

Speaker 1: it it also decouples the front end from the back end so as long as the API remains the same it's i i it is okay to switch front-end technology, front-end frameworks, as long as uh we keep the same API. And uh now that the front-end is all all JavaScript, all based around a JavaScript framework. It provides a better usually it provides a better user experience. Because users do not need to wait for the page to reload because the JavaScript framework will include a router that will do all of this for us. And it's also usually a more modern user experience with this having this approach. And uh being that the front

Speaker 1: end is only a set of static JavaScript files, um It makes it also really easy to deploy the the front end because it's just a matter of hosting the static files. So there's no need of a server to actually run the front end. That's another another advantage. And uh at least there is the we by using uh JavaScript On the front end. We now have access to the whole Node. js ecosystem, which is quite big and contains solutions for almost all of the problems that One might encounter during developing projects. As usual, this architecture also brings some

Speaker 1: disadvantages and drawbacks that might be worth to consider before uh chasing it. Um the biggest one is the complexity that it brings to the project So until now we we only need to know Python, Django, uh and uh a bit of HTML, CSS and a bit of JavaScript and we would be able to develop a a full stack application from one one from the top to the bottom. But now with the single page applications we require We are required to learn another whole uh technology layer, um Node. js, npm, webpack, bubble, uh the the framework, uh React, View or Angular.

Speaker 1: Uh we need to be aware of the whole node ecosystem uh and context switching between Python and JavaScript during project development sometimes might uh might be difficult and uh tiresome. Sometimes working in JavaScript environments uh might feel a bit overwhelming, uh like you can see in this comic of this green dinosaur. uh found on Peter Young blog. It's there's a lot of different tools to learn and to to study and it it increases the complexity of project development always. When working with Django backends and JavaScript frontends, um we kind of lose some of the stuff that Django gives us for free.

Speaker 1: For example, with a front-end framework it does not make sense to use Django forms, although although Django forms are really useful because they'll they provide automatic rendering and validation and model integration. And we also cannot use some of Django templates filters, which are also useful because everything front-end related is now handled by the JavaScript page. And because of this, this also makes the the page uh harder to test. So now to test the previously when doing server-side rendering, testing the front end is quite easy. We just fire up uh Django test client and do a bunch of requests uh to the server and we then compare the HTML response and check their structure if it is correct.

Speaker 1: Now that we use a JavaScript framework, to test the framework we need to either use some of the framework testing modules like Jest Or we might even need to create end-to-end testings with Selenium, for example, to be able to run the whole window with all of the JavaScript loaded And uh this also can affect uh accessibility and the search engine optimization. Um although recently it's been more easier to make this work with the recent changes in these frameworks Because previously the web pages were normal HTML files which are uh which are documents that contain metadata

Speaker 1: so crawlers can can download and understand what what is inside the documents. Server single-page applications return uh uh an empty, almost empty uh HTML document which just contains the the script tag um and uh they need code so um s search engines cannot understand very well uh what what information what kind of metadata is present there Another increase in complexity is that we are now required to build uh an API for the backend. Um sometimes a project might not be that big and it might not be worth it to

Speaker 1: take some time to develop a separate RIST API when we can uh directly use the templates and the the old Django views to to provide the functionality that the users want. And at last there's there's also there can be also some coordination and development um development challenges when working with multiple projects. So for example, let's assume that a team there to Th that there is one team working in the front end and then another team working in the back end and they decide that each one of them each one of them will run their own repository and they will communicate with the rest. It makes things a bit a bit difficult to to test and use as a whole.

Speaker 1: So we now need to keep track of two different repositories. We need to keep track of the versions between both of them. So that might make development uh a bit trickier. So we get to the question that gives the name to this talk. Do we really need a full JavaScript frontend? And the answer as usual in software engineering is it depends. It depends if the project is big or small, it depends on the size of the team, it depends on the skills available in the team. It depends on the client expectations on user reactivity and user experience. So it depends on a multiple factors. As a general rule of thumb I would say that

Speaker 1: uh traditional crude applications which do not require uh lots of reloading uh are fine to be built with traditional server-side rendering and traditional Django and that websites that behave more as applications, that we want instant instant reactivities, stuff like Google Maps for example, they are more suited to use a single page architecture. uh on that uh regard. For the rest of the talk we will be uh exploring a third way, a more hybrid approach between these two that we discussed previously, which is called progressive enhancement. This means that we will start with a traditional Django uh

Speaker 1: traditional Django website and we will improve the user experience, we will improve its reactivity uh by adding lightweight front end tools on that on top of that so that at the end uh the website will be will be usable even without JavaScript. So we keep the accessibility benefits and the search engine optimization benefits. But when JavaScript is enabled, the website will bring user experience improvements. We will now work on an example, a talks website that allows users to manage the talks submission for uh a given conference like this one I know not very creative

Speaker 1: um so this will basically be a a simple crude management app it will allow create, list , update and delete talks. The source code is available at GitHub uh on the on the address that shows up here on the screen and uh the the the application is also deployed is currently running live on Eroku so you can access there too on on the link on this slide Okay, to start we start defining uh the main model for this website after the the project is generating using Django, Django Admin Start Project And we start by defining the talk model

Speaker 1: which contains a title for the talk, a description, and a speaker. The speaker will be a foreign key for the user model Um yeah, so that that's only it. The talk will be composed by a title, a description, and a speaker. We now create the the views for uh for for doing these crude operations on the talks model. Um we will create a list view, a detailed view, a create, update and delete view I'm using here in this example the generic class base views so that I can keep the code short and smaller and they do what we need to do in this example.

Speaker 1: We also need to define the URL patterns for this application. Um this is uh A quite general Django URL patterns file here. We define the paths for the list, for the create, for the detail, for the edit, and for the delation views so that we can do all of the crude operations by accessing these URLs here This is how it will look like. I'm using Bootstrap 5. I'm not showing the templates here because I don't think it's worth it for what. we are trying to do. Yeah, but so far you can see the list view of the talks. You see we have a table with which displays the title, the description, the speaker

Speaker 1: And we also have uh quick actions uh shortcuts for editing and deleting the view. The talk, sorry This is how the detailed page looks like. So as you can see very simple stuff, again with the edit and delete buttons as shortcuts to those views. And here is the uh the ad talk uh ad talk template view This is where we we render the form, standard bootstraft stuff, and where we can create new talks in this website. The first lightweight front-end library that I'm introducing here is called HTMX.

Speaker 1: It was previously known as Intercooler. js And it allows to use data attributes inside HTML for performing Ajax requests, for performing CSS transactions accessing WebSockets and even server sent events. It is really small library, it's only 10 capabytes. with no dependencies so it's self-runnable we you just need to point out to the to to a cdn and we have this library ready to run It is quite useful because it extends the normal HTML syntax, allowing for a more declarative approach

Speaker 1: when building interactions. And it does not depend on on using a um a language like JSON for transmitting data. It's actually quite reliant on servers responding with HTML. Similar to how server-side writing pages work. So HTMX allows us to perform this asynchronous requests to the server. The server will respond will response with an HTML uh content and then HTMX can can swap um an HTML block with the server response So this is really useful for adding more interactivity to the web page

Speaker 1: without introducing without having to write custom JavaScript code and without having to create a new REST API because we can use the old uh HTML rendering as it wa like it was an API This is a really small example stolen from HDMX website. We can see how simple and and powerful uh this library is. So we start by loading it from the from the CDN, loading the JavaScript and uh this the this snippet will uh display a button That when we click on that button, it will perform an asynchronous JavaScript request to the server, to the slash clickav

Speaker 1: URL. And then we'll replace the the whole button with the HTML response from the server. So here we are already seeing some HTMX directives like HX post. uh which which defines the where real to perform the post so this is this is really nice because we can now perform post requests to to without requiring an HTML form, we can use any element to do this kind of request. And then we have the directive hx swap Which defines which element to swap with the server response Now going back to the talks

Speaker 1: website example that I talked about earlier, uh let's say we want to implement a new feature. We want to be able to search through the different talks, but we want to do it to do an active search. So this means there will be a search bar at the top And we want that when the user starts typing, the results start filtering automatically without needing to reload a page or opening another page like it was uh a single page application. So here we define a different view for that. We define a search view that is inheriting from the list view just for convenience And uh this search view will render uh an HTML table with a content and it will check for a queue parameter in the request

Speaker 1: request get parameters and based on this query string it will filter the talk list. Here we can see the the template for this So it's a regular table, uh we iterate through the different talks and vendor each row. Uh the most important thing to notice on on this on this template is that the table has an ID and this ID will be used in the next slide for selecting this table This is how this search page looks like. So it's it it looks quite similar to the to the talks list page uh but without the headers because it we are only interested in rendering

Speaker 1: uh in rendering the the tables. And now to actually perform the search on the talk list page, we need to create a new input. Um an input for that allows a user to type and search. And what will this input do? This input will perform a GET request to the view that we defined previously. So we can see in the directive hxget it will point to the to the search to the search page that we just created And we also need to define what what will trigger these these requests and the trigger will be whenever the user types something on the search bar.

Speaker 1: So we'll we will use the KUP event and we can even We can even define a delay for performing the request so that the users do not abuse the server And uh and and uh and at last we also need to define um where to substitute uh the the returned HTTP response. So uh we will We need to define uh w where this replacement occurs and it will happen in the table that we defined uh that we that we defined previously. So the so basically the the invoice list page uh will perform asynchronous requests to the search page whenever the user writes something on that text bar and then it will

Speaker 1: replace the the the current table with the results that um that the server responded to This is a small demonstration of how it how it is working at the moment. As you can see, it allows users to instantly search. And uh we didn't write any JavaScript code to achieve this, right? Um we relied on HTMX and simple data attributes to do so. So This is a progressive enhancement of the page. Previously we had the static page rendering the table. We added a static page for searching through the different talks and now combining

Speaker 1: HTMX we are able to dynamically do this filtering. Here we are kind of having the best of both worlds since we keep all of traditional Django uh benefits, but we're also uh improving the user experience uh by having this instantaneous search uh right here on this page Similar to HTMX, Alpine GS is a minimal small JavaScript library that does not require any build step when using it and it allows for composing JavaScript behavior directly in the markup with a syntax that is inspired by view template expressions. It is quite suitable for simple user interaction since it allows for an easy way to manipulate the DOM

Speaker 1: in a declarative way. Um the the only downside is that it does not use virtual DOM, so it's uh regular node uh regular node manipulation. Uh so if there it is not it is not advisable to use it for bigger applications. for bigger pages that use a lot that process a lot of data. So similar to Vue , we can define a model there, we can define the transformations and all by using template expressions. Here is a quick example on how to use Alpine GS. We are going to model a tab behavior here. So similarly to the other tools we

Speaker 1: presented here, we start by loading the the the library from CDN. And similar to view templates, we are defining here the data model for this component. In this case, we want to store in the model the name of the tab that is currently active. Okay, so next we have two buttons which will trigger uh a change on this model so we use the the property on click to say that to update the model whenever these buttons are clicked And then we have the actual content of each tab. And here we are using the attribute XChow that

Speaker 1: allows us to specify a condition. for whether or not the the current element should be displayed or not. In this case we will display the tab foo if the current tab defining the model is foo and the same applies for 4 bar, so as you can see uh it's really similar to view templates but much much more lightweight Now going back again to our our example of the talks website We are going to use Alpine GS to create an interactive text input similar to the ones you find on blogs or postings. So the idea is that we we want to

Speaker 1: add a field called tags, like you can see here on this slide. and we want to dynamically type them and have the ability to to add multiple tags to a talk. So for example, a talk can have a tag like Django, HTML, etc. standard tag models. So we start by adding the text field to the talk model. Okay, so here I'm using a JSON field. Because I find it quite flexible and since Django 3. 2 it's been a great addition there and I'm saying that by default it will be an empty list. So it's Not entirely relational, but for the purpose what of what we are building here

Speaker 1: is more than enough We're now going to update the Talks form template. This is the template that is used by the edit and by the create pages. and uh we want to display the tags and being able to add new text as you type. So we will create a new div block. and we need to define the the Alpine model for this for this component and this this model will contain uh basically the list of tags uh that were inserted and the name of the new tag that we want to append to this list. to to initialize this this module we also want to um to initialize it with the tags that come from

Speaker 1: uh the model. So for example if a talk already has uh two three tags we want them to to appear as well and retrieve them from the model we can do it fairly easily by using Django uh by accessing the text field in in the template, uh because tech Text field is a JSON field. We can use it directly here when defining, so that makes this part much simpler. And of course, if there are no text, we define it as an empty list. And then we define the input, which will be the actual input that is sent to the server that contains a JSON value with a list of of the different tags. In this case, we are using the X

Speaker 1: bind attribute to define that the the value attribute of this input Will depend on the tags defined in the in the Alpine model. So this will be an either input, it will not be shown in the UI, just to be sent to the server and stored there And next we will actually create the text box for for for introducing the tags Okay, we will we will bind this one with the model and uh basically what we are saying here with the x model equals new tag is that um The values that we introduce here will be starting the new tag variable in the model

Speaker 1: And then we also we also add um add an attribute k down enter prevent uh to to prevent it for send for always updating the model if the if the the string if there is an empty string entered so that it is not it only it it only triggers when there is uh when there is a new push from the user after writing the tag And the next block consists of a regular HTML5 template block. This is the one that contains the properties for displaying each tag So we use the property X4 to iterate through the through the tags in the model. And for for each one of these

Speaker 1: we will display a spun element That contains the tag name. We also can define the class as a bootstrap badge, for example And then next to each tag we will have a button that when we click it will remove this tag from the model. So this button is a button to remove the tag So it will update the model when we click it. At the end this is how it looks like So this is the same page as previous as previously shown, and you are able to write a list of tags.

Speaker 1: They are stored in the in the database as a JSON list and you can edit them and delete them directly with this input Again, all of these just leveraging the capabilities of the of the of the framework. So we didn't write any custom JavaScript code again We are using declarative data attributes. We are using regular Django forms. So again it has been a progressive enhancement of what we already have here um just improving the the user experience here with this new text input and Later we could refactor it and uh create a custom Django Web

Speaker 1: widget for having this kind of special input by calling Alpine, but it's uh a bit out of scope of this talk The last tool that I want to show today is called Otwire, which is a short for HTML over the wire. And it's uh it's a recent uh recent technology. Uh it's still currently in in beta and was developed by Basecamp and day. com. And it's the kind of the successor of Turbolinks, which existed for Rails , and I think for Django too. So it basically call it basically gives the single-page application experience to traditional server-side rendered pages. So

Speaker 1: like I said previously in single page applications there is a JavaScript router that is responsible for actually loading the pages and displaying them in the browser window. So it seems from the user point point of view that the pages are loaded instantly because they are done asynchronously through JavaScript. um and that makes us uh that that makes that much faster and uh this is what that library does without requiring a full JavaScript front-end framework. So basically we load this library at the top of the HTML file and then this library will automatically um parse the document and intercept all of the the anchors all of the links

Speaker 1: and then we'll overwrite the default browser uh behavior for for for for that page and we'll uh take charge of the navigation so um even regular old pages uh will seem much faster to load because this page will will handle that uh will handle that instead of the browser so uh the pages will appear to be loading uh instantly like they would on a on a single page application. Um I didn't create an example with this because uh it's still hardly It's still uh it's still in early development and uh there is a non-official Django package to integrate with with Django but

Speaker 1: I didn't check it out, but I'm pretty sure in the f future this will be a pretty great technology to build on top of To conclude, I would like to share with you this quote from Leonardo da Vinci. Simplicity is the ultimate sophistication, and I think this really applies to software engineering because As engineers we have a tendency to over-complicate things and over-engineer things. And sometimes there are simpler solutions that we do not even take into account because We are not aware of them. So yeah, that's what I wanted to discuss with you today. I'm really thankful for you to for assisting to this talk and I'm happy to answer any questions that you have.

Speaker 1: I hope you have a great day and goodbye.

Speaker 2: Yes, yeah. Thank you for your talk. Um does it I I I I presume that um You didn't use Alpine because HDMX can't do what you did with Alpine. You can do you can do uh any of these actions or both these actions in in in either framework or either library.

Speaker 3: Yeah, I wanted to show both both of them here in this talk. But I think they fit kind of different use cases. Um HTMX uh requires more on the server to respond with uh with fragments of HTML to inject inject into the the DOM And uh I think Alpine is more like a lightweight alternative to Vue. js where you can directly manipulate uh the DOM there using the data attributes. So I would say that's the biggest difference uh between them. Um like if if it doesn't require anything from the server side, uh I think Alpine might be more suitable.

Speaker 2: Okay, thank you.

Speaker 3: Thank you.

Speaker 2: Have you have you used these in in um in projects for for customers yet or

Speaker 3: uh no not yet. Uh just obvious stuff.

Speaker 2: Okay.

Speaker 3: Uh but I I want to use it when I have the opportunity.

Speaker 2: Thank you.

Speaker 4: Hi Afonso. First of all, uh great talk. Thank you. And you mentioned it in the beginning about progressive enhancement and the ability of uh making the the application continue to work even in a scenario without JavaScript. Have you uh Make some experiment about that with these three frameworks?

Speaker 3: Um Not an experiment per se, but uh it was more like uh trying to use the page without uh JavaScript, like using no script extension in Firefox, for example. Um and uh at the moment if you try to navigate the web without JavaScript enabled, uh almost nothing works uh in almost every site because they somehow require for uh for something but that's one thing that I wanted to approach with these uh with these small solutions is because um for example if even if a user cannot uh does not have JavaScript uh enable on its browser. Um in the the small example that I gave, uh you can still search the page. If you opened up

Speaker 3: the that page without JavaScript, you can still go there and search and type enter and it will return. um the list of results. So like like you were saying about progressive enhancement, it's it's about that, right? We uh we start by trying to we we try to We we start by having a regular uh old-fashioned uh page and view and then use JavaScript here and there to to improve the the user experience and with without the other uh going uh going against the the current trend perhaps of having needing uh if we try to open a page without JavaScript enable all we see is spinners loading in uh and uh sometimes nothing happens but yeah this this kind of libraries are great for that

Speaker 3: for just um improving a bit smaller pages that need more interactivity um that normal HTML cannot do uh for obvious reasons. So yeah that's why

Speaker 4: Yeah, I'm totally with you on that. Actually we are trying this kind of approaching in production. But I I didn't know until this conference about uh ATMX So we were implementing some small layer of JavaScript ourselves because And and in this documentation, in the ATML, ATMX documentation, uh look at for me that there's no that uh intention to make the the the framework actually the site still works without the the users of JavaScript

Speaker 4: and what's important for me about that it's I mean there's a lot of initiatives, for example, API first and mobile first and all that it's aligned to uh progressive enhancement and we have a lot of good collateral effects when you do that. For example, the code is usually simpler. So that's my uh that's the why behind my question. So if you have some uh thoughts about that, it'll be great to hear from you

Speaker 3: Yeah, I agree what you said in in in general. It might be helpful for for these cases. Um I think I think an advantage is that you're you're writing normal HTML. So you even if you're not using HTMX you can just serve this uh HTML fragments as a backup plan in case uh the user does not uh cannot use javascript for s for for example so you can always have this kind of fallback um and b because it's all sharing the the same uh Django uh stack that we that we we are reusing the views. uh for for that you can you can use that to leverage this this kind of enhancement.

Speaker 4: Cool. Thank you.

Speaker 3: I hope it answers your question.

Speaker 4: Okay and uh I I'm really uh I I I I'm glad to hear. uh this this talk and I really want to reach you out to talk more about this approach. I'm really interested on that. Thank you.

Speaker 3: Thank you.

Speaker 5: Yeah, if your guys are like free during the sprints, um like we we were talking on the during the previous talk. uh we could totally do a sprint to to try to match your um REST framework renderer uh strategies that want to that um can either respond JSON or HTML or something else. uh with the HTMX approach, that would be super cool to try to bring that all together.

Speaker 3: Yeah, that's a good idea. You can uh did somebody type it type it out in the in the sprint channel? Uh I think we can propose ideas there.

Speaker 5: Yeah. But that was in the the main room uh channel, but we should totally uh put that there and everyone that wants to join could like try to make that yeah

Speaker 3: Yeah, looks like a great idea. I'm trying to find it out in the in the chat.

Speaker 5: Oh, it was during the previous talk, so yeah, that's way behind it. But I'll I'll I'll ping you uh I'll ping everyone in the sprints channel.

Speaker 3: Yeah, thank you

Speaker 6: Um I don't know if we have time because I think that the presentation has already started, but uh it's about PostgreSQL, I think. But uh if uh you want to stay a little bit more I have one thing to ask you. Yes uh but it will really be easier if I share my screen. Uh because it's a real example. Uh and that is okay, let me try this Okay, can you see that? Okay, so I have uh let's say a piece of land here and I uh this is a Django application okay

Speaker 6: uh and it's a traditional one request response So these are the irrigations I have made to my field, and I want to add uh I want to add an irrigation So uh let's say that uh yesterday I watered the the piece of land with uh 200 cubic meters of water, and I click submit. So now the problem is that if I submit this form, then the list of irrigations must also change So if I do it this the traditional way, you it reloads all the page again, okay, which is not what what we want. And it added the irrigation here

Speaker 6: But if this part is a different, I don't know how to call it, component, a form, uh reactive form, and I click submit. It communicates with the server, it gets a piece of HTML back with let's say HTMX or something, and then would it be possible to update that part? Would I need a Some JavaScript, maybe a little JavaScript?

Speaker 3: Yeah, I think you can I think that's a a pretty good use case for HTMX. uh actually uh you can bind that submit button that you have on the form on the left to perform a post request. um normally like you do for a form um and then uh and then uh using uh uh using the htmx directives I think there is one that you you can bind other elements to to this action. So basically what you would need to do is to on the On the list that you were showing up on the right side, the one that needed to be updated, um, the submit button on the left would need to Or or better, uh the list that you were displaying on on the on the right side, it would there would need to be like a an

Speaker 3: endpoint that always retrieves the list. And when we you click at the submit button, it would trigger a GET request there

Speaker 6: too, which

Speaker 3: HTML fragment for the list. Yeah, I think that that could work there in that case.

Speaker 6: Yeah, it would work, I think, yes. Okay. Okay, thanks a lot.

Speaker 3: Thank you. Um I think everyone is going to yeah to go to the next talk too. You buy if you need anything just ping me on Slack then