Elevating Drupal Experiences with Vanilla Javascript

This talk focuses on enhancing Drupal sites with vanilla JavaScript, allowing developers to create dynamic and modern web experiences. The speakers, Marz and Andres, emphasize the evolution of web technologies and user expectations over the past decade, highlighting the shift towards smooth, interactive experiences akin to mobile applications. They discuss the limitations of older frameworks like jQuery and how modern APIs such as Intersection Observer, the Fetch API, and various CSS capabilities empower developers to build responsive and performant websites. The presentation explores the advantages of using vanilla JavaScript to reduce dependency on large libraries, ultimately leading to smaller, more efficient codebases that enhance user engagement. Real-world examples illustrate effectively using these technologies to create immersive storytelling experiences and improve content accessibility on Drupal sites.

So good afternoon everybody. Uh thank you so much for being here. Um well today we are going to talk about how a little bit of vanilla JavaScript can eleate our Drupal site from something powerful to truly dynamic. But first we would like to introduce ourselves. Hi Marz. I'm from Costa Rica. I'm a front end engineer uh for kitchens. I have been working with Drupal on the front

end side for about five years and yeah I also have a UX design background which allows me to combine technical implementation and UX thinking uh for creating interfaces for our Drupal sites. Uh, a little bit about you. I'm a type person. Uh, I used to be a person, but since I adopted my two cats, I that's a new work. On my free time, I like to listen

to music and watch Korean dramas and yeah, that's me. Hi everyone, my name is Andres Andres Diaz and I'm also a front end engineer at for kitchens. I've been working with front end and Drupal for about 20 years now. So I'm really really into this web stuff and I've been for a long time and I'm also a cat person and uh yeah I love taking film photos.

I love film photography. That's what I do in my free time. So yep. >> So let's start with a simple question. Why are we talking about modern web experiences today? Well, the result is that the way that people use the web has changed a lot in the last decade. users nowadays expect the same kind of a smooth and engaging experience that they get that get from mobile

apps. So our goal as designers and developers is to meet those expectations while keeping our sites fast, accessible and easy to manage. When we talk about modern experiences, we are talking about interactivity that feels alive. That's when transitions and visual feedback comes in h to make the navigation feel continuous instead of abrupt. And the other key feature that we want to imp implement in our experience is

a storytelling using motion lo out and timing to guide attention and emotion. And all of this together makes the web feels more human, connected and more engaging. The web today isn't the same web that we were building 10 years ago. Uh browser back then were just document renderers and JavaScript existed. It was there but it was very limited. Um animation were clever CSS tricks and if you

wanted real interaction you probably will need a heavy library um yeah a heavy library just to make things work consistently. And in Drupal, let's be honest, jQuery was very involved. Um, it was it worked, but it wasn't that powerful. And today that's just different. Uh, today browsers are not just rendering documents. They are full application runtimes. And it must it is just not the browser that has

changed, but also the way that users access our sites has changed. Um now um we are building for different screen sizes, different interaction patterns, different network connections and different performance budgets. And as a reminder for yourself, not every user has the same resources. So h every kilobyte. So that means sorry that so that means that some connections are fast while some are not and some devices can

parse JavaScript instantly while others can struggle a little bit with large bundles and every kilobyte of JavaScript must be downloaded compiled pars and executed. And this means we are a language designer for a single ideal environment. We are design we are building for variability and but yeah so that change how we think about front end architecture and how we build from now on. And here's the most

important part. Uh the web evolved to handle all of this. Um and the browser isn't lacking anymore. So modern web technologies are not just new APIs, they are core capabilities that the browser provide us out of the box. So instead of listening to scroll events non-stop, we can now use observers like intersection observer which I'll be talking in a bit. Uh instead of having JavaScript for larger

hacks, we can now use CSS grid, container queries, flexbox. Um instead of building a full single application single page application just for transitions we can now use view transitions API. Um and when it compos in performance um we now have fine grain control where how and when the resources are loaded by native lazy loading a sync defer ES models and fits priority. All of these are not

just walkarounds, they are platform features. So with all of the next technologies, it is natural to ask why stay in lupal? Well, let's not forget that dupal solve many of the hardest problems in building digital experiences. So it give us a structure content modeling edit workflows permissions and governance things that are essential for for large sync and complex organizations. It also has a mature ecosystem with thousand

of contributor mod and a large open source community that keeps improving the platform. So organizations benefit from stability, security and solution that have already been tested at the scale. Drupal also provides a strong foundation for experiences that over time. Recent versions have improved the experiences for content creators and editors uh with tools like leger builder that allows teams to check the pages without having to rely on

a developer for every change. At the same time, h Drupal is built to scale. Uh it flexible architecture, APIs and caching system allow sites to handle large volume of content and traffic. And because Drupaler is model and composible, it also integrates well with other systems and other web technologies. So, and that's the really the key idea. Instead of replacing Drupal with a heavy from a stack, we

can build on top of it. Letting Druper managing the content and structure while modern browser APIs and vanilla JavaScript can enhance the user experience. But what about a couple of problems? Everybody uh whenever we talk about mobile web experiences someone always thinks up that the capula option and for good reason at the capo set means to separate the rupal's back end from the front end uh and

yeah the coupling has bonafics but it comes with some real challenges that we need to take in count before going for that route. First uh things gets a little bit more complicated. Now you will have multiple code base which can increase development time and also the tens of box. Second, it requires more infrastructure which can add extra cost and also more in maintainers. And finally, the editorial

experience can suffer a little bit because the final page will live in another app. So that can be a little bit confuser for content creators and yeah. So what the cap has benefits we are not saying that we are against you need to take really encounter the challenges that I already mentioned and instead of going full headless we can go with a progressive approach using just vanilla

JavaScript uh but there's a library for it well using third party libraries is a common and polish and a valid option in the JavaScript world there are thousands library that helps us as developers to provide interactivity and enhance the user experience in our sites. But that's not the sol that the best solution for all cases. First, most slideways are generic and they are not always tailored to

our needs. So that means uh sometimes we can have a big library with a lot of code and you don't just need it for just one single thing and which can lead to compromises in performance in design. Second introducing external can potential security cons concerns uh there have been multiple cases where site have been affected when a single library when the library that they are using gets

compromised. So yeah, that's another thing and finally there's an if we add an another loader that means that we have another dependency that we need to keep track update and test and that can include those maintenance over time. H all of the doesn't mean that we are against using libraries but the key is that we need to be really careful and use them strategically. So why choose

vanilla JavaScript for enhancing a Drupal site? Well, vanilla JavaScript today isn't just plain JS. It is built on the standardized APIs that well supported for modern browsers. So we are work that means that we are working directly with what the platform give us. This means that we can often build lightweight tailor solution without adding an extra library or a framework. And fewer dependency also means that we'll

be having less maintainance and fewer potential breaking changes over time. So for example at this score the don API provides clean and predictor ways to interact with a document using methods like qu selector classly closest um where we need to talk to the server. The fetch API pro let us write a synchronous code that is CSS to maintain and also easier to read. So instead of relying

on nested callbacks or library specific abstractions uh as our interface becomes more dynamic the browser continues meaning there for example we have intersection of server that take cares for us uh for scroll base behaviors and also lazy loation observer let us react when the dome changes and when led changes And that is an obser give us a solid way to respond without hacks or constant polling. Navigation

and interaction are not framework exclusive features anymore. Uh with history pushes story the browser already provide us the the building blocks for client side navigation and for motion and reure interactions. We have the web animations API that allowed us to create expressive experiences without pulling a heavy library, a heavy animation library. And why this matter? Because when we build director on the platform, our code gets more

lighter and more intentional. Smaller bundles means faster time to interaction and just better performance overall. This isn't about going backward. This is this is about realizing how much the browser has grown and taking advantage of those things and instead of adding extra layer that we don't really need all of these APIs are not just interesting platform features these are things that we have used for real client

projects um for kitchens. So what we want to do next is to walk you through a few example where we use these core capabilities and solve common interface challenges in Drupal. For the next example uh that like I would like to show you first the client's goals. They wanted to create an immersive and visual storytelling with minimal text uh support vertical scrolling with image dragon narrative. The

slice could can be an image or a blank background. Look for negative poses. Then we have flexible test alignments and caption for readability and keep the performance fast by limiting the slides loading only to images and optimizing file size. here's a video of that example that I was talking about. Notice how the image and animations only trigger as we scroll. There are no more glitches, no heavy

initial load and the pages feels smooth and applike. This isn't just a net effect. It is designed to support immersive visual storytelling and as I mentioned before where images let the narrative and captions provide context while keeping performance fast and readable across devices. This is how it will look on desktop and this is the mobile version. So how does it actually work under the hood? Well, for

this we use intersection observer. Think of it like a sensor on a slide where it detects when a slide enters the build form. Uh so we don't have to constantly um check positions while scrolling. You can also think of it like a mo motion sensor in a museum TV show when the animations or lights turn on only when a person enters the room. The this let us

trigger animations allow images exactly when needed keeping the experiences in more as fast even with lot of images. This makes it easy to build things like parallax effects uh fadings and other scroll based by only loading what the user actually sees. H we reduce unnecessary work keep the page fast and deliver the fluid app like applike experience that we have been talking about. So this is why

the loud show cinematic and responsive even though there's a lot of happening in the page. So this is a way for the user to digest the content in an easier way and not get overwhelmed. And let we take a look at another example where we use the same inter idea but in a different context. So for this one the clarian goal was to uh were sorry to

provide more context around their work. Uh they wanted to improve that how user discover images content and make complex research driving material more approachable to non experts and at the same time they were looking for to improve the mobile experience. So the new site designs introduce more dynamic guide interactions to help users move through the content and this is where intersection of fware help us and this

is the example. So look at how the cards and the information only loads where as we scroll down and this is how it will look on the vial. Okay. And now I'm going to pass the microphone to Andres. >> Thank you, Marie. >> All right. The main focus of this presentation is JavaScript, but JavaScript is not the only piece in the puzzle that web development is. We

know that we have other tools and without those tools, we wouldn't be able to to create this kind of stuff. So we'll start talking a bit about HTML. Something that sometimes we forget because it's only the foundation and we focus on the more flashy technologies. But HTML has also evolved and also leave us allow us to do a lot of cool things now without a lot of

extra things. For example, we have the dialogue component, which is not exactly new, but haven't been around for for a long time. And it's an element that allows to create dialogues which we see in a lot of sites but without the need of writing a lot of extra JavaScript for doing things like handling the closing with the keyboard with the escape key or um creating the backdrop

with we don't need to create a lot of of extra dips and add a lot of code to handle how it works. It allows to create a accessible sites without a lot of extra JavaScript. We also have things like like template which is used mostly for web components and basically it's a way to create blocks of reusable markup that we can manipulate and interact with JavaScript to

create dynamic elements. For example, if we have a dialogues and we will have different element elements on each dialogue depending on where we what we are where where are we opening from. So we can add that content dynamically using a template for for for the base and then populating it with with We also have CSS clearly and as Mari mentioned earlier we now have a lot of

options for layout. We don't have if we if we all want to build a complex layouts we don't have want we don't need to use JavaScript for calculating positions and and determining with to place everything is absolute position. We now have grids we have sub grids. We have flex. We have container queries. We have a lot a lot of things that weren't that that weren't around 10

years ago. We have a lot of ways to create animations and transitions with between elements. And the nice thing that can be a bit overwhelming, but a lot of a lot of things are being added to browsers every day. In my case, I usually go to to YouTube or to read articles and I found found out find out new things like that I didn't know existed or

when I talk to colleagues while working I realized that we now have this isolation property for example for controlling how the stacking works or we have this new layout technique or things like that and actually the the hard thing right now is to keep up with all the things that have been added to browsers and that can be used in our day-to-day work. One of those things

are the transitions. It's something that that has been there has been a lot of talk about it because it has been added to frameworks like Astro and Nex.js. Uh but we can use it without using a framework like this. And the transitions is mostly CSS but we also have a JavaScript API for interacting with it. And it's great for animating a property when properties are being transferred

from one element to the other. For example, changing which element is active. We can animate the transition without needing to do a lot of custom code and movement with with JavaScript. We can do that with CSS only. And also when things enter and exit the the screen or the viewport, build transition is a great way to animate that. So we have two types of uh view transitions.

We have in page view transitions where we are animating elements in inside a single page. For example, here we're animating the active state of the tabs and we are doing some motion to move the the background for from one element to the other. That's something that can be done with regular transitions with regular CSS transitions. In the past, it had to be done with JavaScript for moving

an element. But now we just need to use um view transitions for that. We still need so we still need some In this case, the JavaScript control switch tab is active. Basically setting a class for example needs to be wrapped in this document the start view transition function that will trigger the the transition from one element to the other and we need to some CSS we the

main part here is this view transition name that we add to the element in this case it's an after that the element that we are moving between the different tabs and it's the after that is in the active tab And then we have some uh special elements that where we can add all the transition properties. In this case we can define a an interesting timing functions to

have the the the balancing effect here. But basically all the things that we can use in in regular transitions and a regular CSS animation can be applied for for for the view And and the cool thing is that we can use it right now. It's supported by all modern browsers. So we have a a great coverage for this. We also have cross document view transitions. These are

a bit more interesting because we can use this for animating transitions from one page to a different page. And we don't need to do a single page application for this. We don't need to use Ajax. For example, here this is a page we created for a demo we are doing in our booths. You can go and visit if you want. It's a a finder a program finder

using AI for for programs in a fictional university that that we created. And this is a regular Drupal site. It uses JavaScript of course for the chatbot, but this is basically a view. And these are regular notes. We're not using Ajax. We are not doing anything weird. It's just a regular navigation inside the inside the browser from one page to another. But it's possible to animate that

that transition without using like a single page application and a lot of extra code. Just some CSS. Basically, we don't need we don't even need JavaScript for this one. on top of the other things I already showed, we need to enable the transitions between pages with with this directive in the CSS. And optionally, we have some events that we can listen to. We can listen to PL

the page swap event where that triggers from when I'm leaving a page, navigating from one page to the other. And we also have the page reveal effect that triggers on the patient navigating to. So there we can do some extra things. We can assign the view transition to a specific element for example or do things like that. But a lot of things can be done with with

just CSS. The bad thing is that this one is not supported in all browsers. uh for now I think only Chrome and Safari with some experimental supporting Firefox but I'm pretty sure they will catch up so soon uh because everything is evolving really fast so probably in some months we will be able to use it in basically every browser out there so so that's that's cool we

we don't have to wait a lot to start testing this and just like the like this one we have a lot of APIs available to to try. And every time I visit this page in Damosil developer network page, I I I basically get amazed of the amount of things that we can use from a browser using regular JavaScript. For example, I I have a mechanical keyword and

it can be configured using a web tool that the manufacturer provides and it can be flashed from that that same tool without any extra thing. Uh and they used a an standard web API that's called web hid which is an API for interacting with with in input devices on a low level. only works in Chrome, but it's standard and probably will be implemented on my browsers in

the future. So, so it's really interesting that something like that that that's in so low level can be done from from a browser and just like this there are hundreds and or tents at least of of different APIs that can be used with with regular JavaScript. One of these is the web sharing API. I discovered recently for a project with we did and this allows to share

text or files um using the the sharing functionality that that most operating operating system provides especially on mobile uh for now again only available in Chrome and Safari but I'm pretty sure there will be more browsers supporting it later and um basically we just need call to this function here navigator.share pass the things that we want to share. It can be text and can be a file

for example an image and that will plug into the OS functionality to do the sharing. So here for example I'm sharing this image and it will open that sharing dialogue for that iOS has and I can post it for example to to Instagram in Android it looks different because it uses a different technology and I think Mac also supports it. I don't know if other OS oss

do, but at least it's available in mobile in mobile where it might make makes the most sense because people would probably want to share to Instagram or Facebook or any social app they they have installed in their phones. Okay, I mentioned a lot that this is only supported on this browser. It's not supported by everyone and that's a reality. We are working with things that are evolved

really fast and and some of those things are experimental. Some of of those things are not fully extended across our browsers. And here's where progressing enhancement comes in. That's a term that has been around for for a long time and we sometimes forget about it especially with all these frameworks and things that that promise some sort of standardization that we can do. But it doesn't mean that

we need to to stick with the things that work everywhere. We we must make sure that everyone is able to access our content, but not everyone has to see the content in the same way. We can provide different experiences to different people. So for example, we can provide different animations and different transitions depending on on what are the capabilities of the device or the browser that the

person is using or even we can disable animations at all in case the person chooses to do that based on on for example an accessibility thing. If they want to to to activate the reduce motion, we can just disable animations to provide a better experience tailor for that user. Uh we can definitely have different interactions for different devices. We can have some things work on a way

in desktop and some things work on a different wake up in model because the way the user interacts is different. And we can also provide alter alternative ways to do things. For example, for the sharing API, if the user is using a device or a or a browser that doesn't support it, we can still provide the option to download allow the image, for example, or do something

else different. So, there are ways to do this even when when the technologies might not be available on everything. And the key here is to always consider the target audience. It's most most likely we will have a statistics. So what are our users using to access our our our platform? We can take that into account definitely. Obviously if we want to use something very experimental that may

not be the best idea if we wanted to get a wider audience but but we can still do some testing and and provide different things for different users. And the key is always know your users and keep in mind what are they using and and and if this thing that we're going to try is is is available there. Performance is really important when we talk about a

fluid and uh rich web Um and with these techniques that we've talked about today, we are already we already started doing the things in the right the right way because we are reducing the size of the bundles. We are reducing the amount of JavaScript that the browser has to execute uh because we are removing most of the extra things that frameworks and libraries provide. That doesn't mean

we can do use slivers. If we choose carefully what the levers are using, we can still provide a very lean and and fast experience. But that's not the only thing. We need to make sure that we use a clean and semantic HTML to reduce the amount of elements that that we have in the page to make processing faster and to make download faster too. And when we

talk of rich experiences and storytelling, we usually will have a lot of media. So using modern formats like webp for the images for example and and and motor formats for videos too. It's really important. Always optimize our assets to make sure that the download will be as fast as possible. And cache is really important both on browsers and on a CDN or something like varnish especially when

we talk about Drupal because um we want to reduce the size of the douts. We want to put the assets as close as possible to the user and we avoid having to reload and redon a lot of things. If we cache things locally, we won't need to to to download a lot of things like the specific libraries or or as CSS or things like that. So, it's

always important to keep performance on a on a good spot and make sure that that optimis to optimize for for for performance. And as a conclusion, there's a world of possibilities out there, not only with vanilla JavaScript with which was the main topic, but with all the technologies we talked about. Um, I think the hard thing here is to break the barrier of using what's common and

what everybody's using. Um, I've been doing the web development for a long time and I've been I've used practically everything jQuery, Backbone, React, Angular, Vue and everything looks really good at the moment. Everything looks looks like the thing that will solve all your problems. But at the end, every platform has it. It's it's good and and bad things. And while most of the tools are really good

and and and are really good for specific things, um at the end everything uses these technologies and as the underlying that underlying foundation. So getting to know these tools and and understanding how they work and maybe reduce all the extra layers that we add can really open open at the door for for creating really fast and really performance sites that that can provide a great experience for

for final users. So so that's something that that it's worth keeping in mind. And that's it. Thank you very much. Please Please let us know if you have any feedback and I don't know if you have any questions. >> Yeah. >> That's very like OE. >> Can you please repeat? View transition >> view transitions accessible. Uh yeah the question is if view transitions what we show accessible

for Okay. Excellent. Yes they are. Um in general what that we are animating is on the visual layer. We still need to make sure to for example for the tab example that I showed to set the right area labels and area properties and rows and everything. But the only thing that we're animating is a change on the visual layer in this case. And it's always a good

idea to provide options for disabling animation in case the user selects the reduce motion option in their the operating system. But in general, the technology itself is agnostic to accessibility. We we need to make sure using the rest of accessibility tools as we know to to provide a a full experience. Anything else? Yeah, I have a a question about service workers. >> Um yeah, I came across

a project where it it looked like the service worker was and I don't understand service workers super well, but it looked like it was being used to cache like theme images. [clears throat] >> Uh is that is that a good a good approach or is that kind of a misuse of the service worker? That depends on the specific implementation but for caching images the browser already does

that and I've seen service workers mostly in the context of progressible applications and it's like this extra layer for handling mostly requests like I don't know fetch codes or things like that and usually intercept them and do things based on on that and detect it if the user is for example out of offline >> would you still need that if you you're doing a a progressive web

still need to put the images into the service worker >> or would the browser already cach it? >> That's what I didn't understand. >> I haven't done web progressive web apps in a while. I've done that but but like 10 years ago and I think you still have to let the browser know that you offline and that you can access the data somehow. So I think that's

where the service service worker comes comes in but yeah I don't remember if you can use regular caching in that context specifically. Sure. Any other questions? All right, that case. Thank you very [cheering] [applause]