 Thanks for your patience with the room change and everything today. Welcome to Saturday afternoon at WordCamp. This is WordPress Playground, Present, and Future Applications. Antonio Cejas is a software engineer from Madrid, now residing in the Canary Islands. He completed the Masters of Science in Artificial Intelligence in 2020 and has made significant contributions to the development of the Vimeo plugin and the Harvard University website while working for Modern Tribe. Antonio is proficient in React. He helped to create React Boot Camps for Reboot Academy and worked as a mentor at Udacity. Currently, he is working remotely for Automatic WordPress.com where he is involved in developing cutting-edge tools for WordPress.com to help developers in shipping products faster. Antonio is also an active contributor to open-source projects such as WordPress Playground. Let's please give a warm welcome. Thank you. Sometimes, all you need is a little nudge from a colleague to achieve amazing things that you've never dreamed about and then a lot of support from your family. Because unexpected things happen, and we just changed the room from Triloblasm to this big stage. And this is how I get involved with WordPress Playground. I started working, developing a little application and then started contributing to WordPress Playground from time to time. So, in this talk, I will talk about WordPress Playground, what it is, what you can do with it, and the learnings that I got from Adam, who is leading this open-source project. So, let's see what WordPress Playground is, and people will understand better seeing this video. I have a lot of screencasts, so it's one click, and you can spin up a WordPress instance running in your browser without servers, no database, everything in your browser. This is possible thanks to WebAssembly and JavaScript, so PHP is running in JavaScript. It's a normal WordPress that we already know, but you can see how much time we saved. You didn't need to set up a local environment. You didn't need to register anywhere. You just open the website and it starts running. You are already logged in, so you can start typing. The cool thing is that, as I said, WordPress Playground runs directly in your browser. It doesn't matter which one you prefer, but we can improve this description to make it more general, and actually, WordPress Playground runs on any device with JavaScript, which is maybe Node.js in a server or your laptop or your mobile phone tablet. So, as I said, you can try it now. It's Playground.wordpress.net, and it will spin up the WordPress instance. But this is just one of the applications. We have more. It's kind of an ecosystem of applications that people is developing on top of it. The key part is PHP WebAssembly, and that's kind of the core that runs the Playground. Around that, we have Web API written in JavaScript and Node, and even Ella created a mobile application. So, I will showcase all these applications and some of those use cases, because Playground is not just for developers. Yes, normal users can learn, showcase, or test, and you can develop WordPress sites with the Playground and also build and extend the Playground itself. At the end, we will close the talk, talking about some future possible applications that we could do. So, for the use case of learning WordPress, I would like that you go back on time and remind what was the steps you took, how excited you were about learning new technology, and then maybe the hassle to set up the local environment, installing Docker or MySQL, or whatever application you are using. So, with the Playground, learn its instant, and you can explore all the ecosystem, the plugins and themes. We have the query API in that URL. You can type theme and the name of a theme, and it will out-install in that instance. The same for other variables, like plugin, and you can put it multiple plugins. So, at the end, you will have a long URL that will set up a custom WordPress site with those plugins and themes. Here, you can see also, we have a settings button where you can change the PHP and WordPress version. By default, the Playground runs in a temporary state. So, if you refresh all the post and pages you created or plugins if you installed someone manually, it will be gone. But you can set up permanently the option on the settings to keep it there, or even you can run your WordPress from your computer. Also, you can export the site and import it to continue later. So, a little bit how it works under the hood. This is a source code of C program, and it's compiled with GCC. At the end, we have been binary, and we can run it in our computer, right? So, with WebAssembly, it's the same thing, but it will run in JavaScript, and the compiler is MScripten. So, to change the PHP versions, we have a Docker image that compiles the source code of PHP generating all the WebAssembly files needed, each one for each PHP version to accept. As I said, we don't need a database, because if we are using MySQL, we would need to compile it to WebAssembly to use it. So, Adam decided to use SQLite and run it directly in PHP. So, another use case for learning is learn through writing code directly in the browser and executing PHP in the browser. Here is this plugin that creates a block where you can embed in your website and make a tutorial with a predefined PHP that the user can play and change and execute it and see how it changes the result. Here is a small demo. So, this is the block, and the users can run that PHP code. Currently, it runs only PHP, plain PHP, and if you need to run WordPress functions, you need to import it to the library. So, the users can change and see the output of it. So, it helps people learning from any device, tablets, iPhones, whatever. For showcase, imagine you have a plugin and you can embed it in your website so the users can try your plugin directly, and you are not afraid that they will get into the server because there is no server. It's executing in their laptops, so its user has a different instance. Here is another demo. This is a real use case that people is using. So, you can try just from this, from used and see how it works. For testing, we have this website where you can put a link or the number of the pull request and try the code executing in your browser. No need to download the repository or compile it, anything. So, it would be handy that it's automatically generated in, like, about, but currently we need to write it in the description. But for testing, people will click it and test your PR. This is another cool application that Alex Kirk created and it's working in Core to help translators to get context. So, they will run the plugin that needs to be translated. It will be installed. It will be localized for that language. And then in the website, you can see what's already translated and what's not. And commit all the translations that currently is in yellow and then push it and synchronize it to Core. So, translators will have all the context because they are seeing the real web page. Yeah, here is synchronizing to Core. Another use case is WordPress development. So, this is WP now. This is the tiny tool that we've created from my team in WordPress.com. And it was a six-week project and it runs in the command line interface. So, you can install it globally in your machine and then you can spin up, go to a blog theme or plugin and then run WP now start and it will run a WordPress instance with that plugin or theme installed. Under the hood, in a home directory, we have all the WP content folder in a custom directory. So, it's persistent in your laptop. And a cool application of this same tool is that you can run it in code spaces and you don't need to set up anything, any file. Like, you can go any... you'd have repository that it's a plugin or theme and then run WP now start. Like, install it and run it. WP now start and you will test that repository and play with it. You'd have code spaces. And we've created this to improve the experience for developers and avoiding installing third-party tools like Docker that you need some license. And the funny thing is that, for example, Luis Saranth took that application and used it in a different way that we've never thought about. So, in a workshop in World Camp Europe this year, he showed how to create interactive blocks and define it in the package JSON how we'll run WordPress scripts and also WP now at the same command and start. Developers just need to jump start and that's it. They don't even need to install it globally. WP now. Making it much easier and in development. Daniel, he's around here, participated in... Hackathon this year and created with Adam and more people the extension of Visual Studio Code. It was the first development to run it locally and now it's the user interface of WP now. So, it runs under the same code. You can install it. If you're using Visual Studio Code, go to Extensions, search for WordPress Playground, install it, and you'll have an icon on the left and if you open a plugin theme or a whole WordPress site, you can click on the WordPress icon and then click Start Server and it will automatically start the WordPress instance. So, as I said, it's equivalent to running WP Now start but it's the user interface and you can change the PHP version and WordPress version so you can test your client theme in different environments. For building, I mean, it's extending the playground itself in different ways. So, because you can run it in any JavaScript device, in any device that runs JavaScript, you can use Playground as a mobile app framework, like it would be, for example, React Native or Ionic. So, Ella created this application, its block nodes, and it's running a WordPress instance in your mobile phone as a native application. The thing is it saves every page or every node as a local file and it synchronizes with the iCloud. So, it's just kind of an iFrame that loads HTML and JavaScript locally and then out installs some plugins. That's what I imagine, like I don't have the details but out installs a plugin that changes the UI of WordPress to hide all the options, the user options and the front end, showing only the admin side. You can experience all the blocks and you can move those nodes to different folders. Here we can see that the nodes are saved in your local phone and synchronized with iCloud. So, we can extend it in different ways. One of those are using the JavaScript API and it would be like all the playground logic lives in NPM packages and you can install it in your project, import it, but this is like really a complicated way to extend but you have all the freedom, right? So, a better way is using blueprints and this avoids the hassle to code in like line by line, all the logic and define it as a JSON object. We have steps where you can define installing a plugin, installing a theme and run some PHP logic if you need and even you can access the virtual file system. These blueprints, you can run it using the JavaScript API or in the same website, PlaygroundWarpest.net you can add the hash and the JSON of the blueprint in the same URL and it will get it and run step by step. So, the three ways to extend WordPress Playground is using the query API, just adding the theme and the plugin in the URL and it will outload that. So, it's really easy. The blueprints, that is the JSON object defining step by step, some predefined logic or the JavaScript API. So, WordPress Playground is powered by WebAssembly but you don't need to code in WebAssembly. We've seen that you just need a little or maybe changing the URL or creating some blueprint or using JavaScript. So, don't be afraid that, oh, I'm not a WebAssembly developer I will not be able to extend it, not at all. So, the last section is the future and the Playground has vision and road maps but some of the vision points that I talked before this is my personal view, like my experience and what I can see that it's missing or I would like if I would have a magic wand. And this is in the future but already exists because one person developed a Chrome extension that changed the URL, allowing people to try any plugin on theme. So, if you install this Chrome extension you can go to the plugins or theme directory and try anything. So, because I wonder how you try plugins. Maybe you install it in production or maybe you create a staging site but now you can go to the directory and run it. I guess that maybe this will be incorporated in core and you will not need a Chrome extension to do it. So, for themes, the same. You pick one and the button appears, click there and that's it. Try the theme. So, everybody is welcome to develop but you can share your feedback and add new ideas or report some bugs. So, here Elliot added an idea and this week I started to create a prototype to make it easier to write blueprints. So, I created a text editor where you can run the JSON object and it will reload the iframe automatically to represent all units. So, we can see that we have a login step here, for example, and if you change the username, then the iframe is not logged and if you put the right username you are logged in automatically. So, it's really easy to do. This is like three lines of clean HTML and JavaScript. That's it. I would like to keep working on this and I imagine this being kind of a scratch thing that you can drag and drop blocks so people that are afraid of writing JSON can play it and create things with WordPress Playground. Another vision that I have is probably we will have a kind of complete ID in the browser where you can write the code, access the virtual file system of WebAssembly and change the PHP code and that will be your local environment but it will be running in your local but kind of remote in the browser. Another would be like we have the pull request everywhere for Gutenberg but I imagine that we will create a bot that you will preview any pull request or any repository from WordPress in your project or one last application, possible application would be running end-to-end testing in GitHub Actions, for example, because it's easy and you will not need to run a docker with a database. It's just kind of a command and that's it. So, I see that WordPress Playground is an emerging ecosystem of new tools and applications and there are a ton of opportunities to create new things. So, I explained all these different applications that currently exist but these are just pieces that you can use and I hope that we will have fun building the future playground together. If you are interested, you can join the Slack channel, Meta Playground in the Make Slack and here are the repositories of WordPress Playground and Playground Tools. Thank you. If anybody have a question, happy to answer here or later in the home. So, looking at this, one of the use cases that jumps out to me most, apart from the ease of onboarding post-it contributor days with this project is also there's a lot of schools with middle school students, high school students that use Chromebooks that up to this point have been able to do any sort of local WordPress development without installing Linux in Chrome OS and all of a sudden this is going to open up a lot more possibility of learning WordPress and software development earlier in the cycle instead of other platforms. So, I'm just really excited to see how this is going to grow and mature and how it's going to integrate with the core training team working up lesson plans for this in the educational system. No real question, just a comment and that sounds super cool. Yeah, I totally agree. And thank you for your question and comment. Yeah, this enables anybody to run WordPress and you don't need a machine that is powerful enough to run Docker or any other local environment. You can try it instantly just accessing a website. So, yeah, like you cannot develop right now from your phone or your iPad, but with Playground you can. And that's what's changing and making WordPress more accessible to more people. Thanks for all this work. This is awesome. The Blueprints API in particular looks really cool and really powerful. I'm curious if you could talk a little bit more about what sort of things you can control through that and how is that actually implemented? Is that something that we could use those same Blueprints on full standard provisioned WordPress instances as a standard format for creating new WordPress sites? So, the question is about Blueprints and, yeah, the idea of Blueprints is defining a logic that will be executed before starting the WordPress site. So, you can make it reproduce the same behavior each time, right? But the possibilities are endless. Like, for example, the mobile application that Ella created probably is running a blueprint saying, hey, install this plugin that it's in this directory and that plugin actually transforms all the WordPress to make it look like a mobile application. I can see, like, it's writing a docker file definition. But easier, right? Because it's just JSON. And the thing is that each step is defined. So, you can add new steps and create a pull request to WordPress plugin. Like, I need to change something but it's not, already doesn't exist. So, feel free to create that step and the rest of the community will enjoy it. Hi. That's pretty awesome. You talked about with the mobile app framework type thing and you compared it to Ionic. How does that work? Is it like a web view with WordPress running in, like, a browser type instance or how does that compare to, like, Ionic for that? And so, you mentioned Ionic, which, like, the mobile app framework. So, how does, and you showed the example of the app that Ella built, how does that work? Is that, like, a web view that's running or is it something else more native? Yep. So, I talked this week with Ella about the mobile application and thank you for the question. And from my understanding, the application runs offline. So, it means it's loading the HTML. Like, it's loading an iFrame. And that iFrame has HTML and JavaScript to run the WordPress playground like you would be accessing Internet but it's just in the phone. And that's the way she loads it and I guess, yeah, that she's using the Blueprints to run the plugin. But, yeah, mainly it loads an HTML. It's an iFrame that loads an HTML that lives inside the phone. So, you can access it offline. I answered the question? Yeah. Thank you. Okay. There are no more questions. Thank you, everyone, for coming and your time. Hello, everybody. Thank you for your patience as we were figuring out some technical difficulties. I have a quick announcement before we get started. The sponsors today will be packing up their booths at 3.30. So, if you were thinking about grabbing another shirt, stickers or water bottles or I think someone has a toy card on there, too, make sure you go before 3.30 to pick everything up. You'll still have some time after this session to make it to the swag area for Josepha's keynote speech at 3.30. So, just so you know. All right. Welcome to From Cutting Zone to Cutting Edge. Dimitri is a lead front-end engineer at 10-up. He excels in crafting efficient and minimalist solutions. Healing from Toronto, he takes inspiration from the beauty of simplicity, just like Torontonians often skip pronouncing the last T in Toronto. Dimitri's approach to work reflects his distaste for overcomplication, always striving to build lean and elegant solutions. And with his expertise in front-end engineering, he ensures that every line of code serves a purpose resulting in clean and streamlined user experiences. So, please give a warm welcome to Dimitri. Thank you. So, when I was putting together a draft for this presentation, one thing I particularly struggled with is putting a title on it. Because the presentation itself touches on various different topics, and it's not just one thing. So, this one describes it well, but from Comfort Zone to Cutting Edge, I am already tired. It's a mouthful. But then I thought this is actually a great, could be a great intro. So, let me break down each part of the title for you so we know exactly what the presentation's going to be about. Let's start with the most simple thing, front-end projects. So, I'm a front-end engineer at TANUP, and I'm guessing that if you came to the stock, you were also a front-ender, or dabble in writing HTML and CSS in JavaScript. How many here are front-enders? Raise your hands. Thank you. That's nice. So, if you write HTML and CSS in JavaScript, you probably have your favorite tools, libraries, go-to approaches for solving common challenges with these languages, and that I call Comfort Zone. You don't think twice to build something because you've done it multiple times. So, what is cutting edge then? For the purpose of this talk, I will be calling cutting edge all the tools, techniques, recent additions to HTML, CSS, JavaScript languages that just become available in all major browsers, not five years ago, not a year ago recently, and what I'm not going to be calling cutting edge is tools that are only supported in, let's say, one version of Chrome, the latest version of Chrome. That would be future technologies, future techniques. And why I think it's important to stay on the cutting edge, that's another topic that we'll be discussing today. I want to illustrate it with this simple graph. On the x-axis, we have the evolution of front-end tools. That's not time, that's a very important distinction. Evolution of front-end tools where at the zero, we have tools of today. On the right, we have tools of the future, and on the left, we have tools of the past. And on the y-axis, we have challenges associated with working with tools of those moments in time. So the common pattern goes something like this. Imagine a project that no one has touched in, let's say, five years, you inherited that project, and your task is to update something on it. It could be relying on an NPM package that no longer supported. It could be that that specific package requires very specific version of Node or something else. Updating something in that project would be a huge pain. That's not efficient. That doesn't help us reach business goals faster. At the same time, if we think about the most recent additions to, let's say, CSS, if we use some feature that's only supported in one version of Chrome, we need to make extra effort to make that production ready. It means that we have to either use polyfills, and spilers, compilers. In other words, write more code. And that's why we also can put amount of code on the y-axis. Same goes for tools of the past. Think of jQuery that was created to address shortcomings of JavaScript language. Extra library to make things happen. Extra code, extra package to maintain. So see at this sweet spot of today where we have the least amount of code and the least amount of challenges, I call that cutting edge for the purpose of this presentation. And what is comfort? Like, where comfort zone sits in that? Usually, it lags behind a little bit. For some people, it lags more. For some people, it lags less. But it's a natural pattern that tools become available. Then we learn them and introduce them to our comfort zone. So what we'll be talking about today is how do we bridge that gap? How do we make sure that our comfort zone as engineers overlaps with the cutting edge of front-end technology as much as possible? And that's why we have lean principles in the title of this presentation. So how do we stay on the cutting edge of front-end technology? The standard approach that first comes to mind looks something like this. You subscribe to newsletters. You read blog posts by your favorite engineers that you follow. You read books on development. You follow Eddie Asmani on Twitter. You go to meetups and conferences, WordPress meetups, buy courses. Completing those courses is really important because otherwise, why even bother buying them? And all that is great. All these practices are worth doing. I think we all should do them. The only problem with relying solely on that approach is that it can get really overwhelming. You might... because the industry is moving so fast and I don't think it's technically possible to follow on every single trend. And I don't think we should because what happens when, let's say, you wake up in the morning, open your inbox, and there are 20 new emails from, I don't know, announcements from your favorite online magazines, notifications from Twitter, new YouTube videos. If you don't have a very specific routine on how you consume that information, that could create more stress than it helps you because it feels like the information attacks us from different angles and your projects, the very thing that puts food on your table, they don't move forward because while you're consuming that information. So I grappled with this concept of how you can sort of do both and don't stress too much about it. How you can get the level of anxiety to a lower level. And I developed a framework for myself. It's sort of like a decision-making matrix that consists of four questions that I ask myself when I work on something that helps me stay on, like, keep up with everything that's going on while moving my projects forward. So in a naturalist framework, it's about dialing down the external information and tuning in to your project, the very specific project you're working on at the moment. So this is how it looks. I know it's too far. I'll share the link to Mira board after this, but it has very specific steps to go from a simple task to a success. So this framework tries to lead the project to the cutting edge and very specifically front-end project. So let's get to the actual project. So let's say you work on something. Usually we break projects into smaller, actionable tasks. Build a navigation, build a component, fix a bug. You name it. So you have this task at hand, and the first question I ask myself is, can I build it with existing tools? Now you might be asking, like, existing tools, cutting edge, what's the deal here? Why is that connected? Because existing tools, they have existed for a while. That's why I said it touches on many, many topics. We don't work in silo. Usually we work in most of the time in the context of a bigger system. We are at a work camp, so it's mostly at the WordPress. It could be a headless situation, so it could be WordPress on the back end, Next.js on the front end, WordPress at the back end, Gatsby on the front end. There could be multiple options. So what it does in a nutshell, specifically asking yourself this question, allows you to be more efficient and get to the business goals faster. What this question also helps with, it pushes you to study that system, the context that you work with then, deeply. And I would argue that a lot of tools that exist today also develop very quickly and are cutting edge. If you think about WordPress, it moves with, like, think how far we went from classic editor to where we are today with block editor, with full-site editing. That pushes the boundaries of what we can do with our websites. And learning that helps you get closer to that cutting edge of technology. Also, you can contribute back to those existing tools, making them more cutting edge. And that happens when you start building something, you study the system, and you find something that could be improved. That's a great way to learn. That's a great way to contribute back because the entire ecosystem of open source thrives on people contributing back. It also shows respect to the team and your project. A quick example of that. Nobody likes an engineer who joins the project and starts doing everything differently just because that's how they are comfortable doing that. If there's no reason to change common patterns, if that doesn't help reach business go faster, that's not helpful. Also, do you like plugins, for example, that create user interfaces that are astonishingly different from WordPress UI? That's also not helpful. It doesn't help users navigate the backend because it's unfamiliar. So what it does, it also helps show respect for your team and the project. Now, a quick example with how we can go from an initial idea of building custom block with, let's say, custom color support for text because this is a very common mistake I see engineer-engineers make when you start working on something for WordPress and you don't have much WordPress experience, there's a chance that you don't know all the possibilities that are available to you. So let's imagine that block that has an option to change text color. The inclination, one of the first inclination that that engineer could have is to build, add an attribute to the block, create a select box with color variations and do handle the front end based on what user selects in that select box. That's all right, that's probably going to close the ticket, but does it follow the pattern of how WordPress does things? No, that's not the best approach to do that. So what's a better approach? Well, if you don't know WordPress too much, you might think, oh, I'll just write a color picker because it's easier to pick colors. But that's also not ideal, right? Creating color pickers is a very complicated task. There are so many edge cases, accessibility concerns and other challenges. So, okay, if that's not an option, what else could we do? Ideally, we would use color picker component from core, right? I would argue that that's also not a very great user case scenario because there is color support baked into WordPress now and you can use global color schemes through Team JSON. So instead of reinventing the wheel, if we study the WordPress deeper, we'll figure out that, oh, if we want to support custom colors, we can just declare support for this block in Team JSON and Block JSON and that will be done with just one line of code. So we went from a very clunky solution that's not ideal to a very lean solution that respects the project, respects the team and gets from point A to point B in 15 minutes. Obviously, there could be edge cases with this. There could be times when you actually need to use custom color picker, but thinking outside of the box, studying the system, the context that you work with then, is really important. But is this ideal? I would argue that with all the tools and techniques and APIs that are available to us in WordPress, we could even go further and say, do we need the custom block in the first place because there's so many things we can do with core blocks now. So that's the kind of thinking I try to do with every project that I work on, not just closing tickets because that's taking us away from cutting edge, taking us away from efficiency. Okay, getting back to our question, can we build it with existing tools? We have a task, we ask ourselves this question, can we build it with existing tools? If the answer is yes, we're in luck. We just use existing tools, we are efficient, we move to the next task, or if it's Friday, we can get some ice cream or whatever you like. If it's a no, we move to the next question in the framework and we get there in a second, but it could also be maybe, wait a second, maybe what does that even mean? So you might get a task, or you initiate a task, and see that you could get 80% of the way there by tweaking the task itself, by changing the requirements. And if you start renouncing your questions like, oh, maybe we can do that if we support global colors instead of supporting colors from Vigma, or we can get 80% there if we move the button from this column to that column. So if you find yourself asking yourselves these questions, it's very important because this is your project trying to tell you something. It is trying to tell you something to be more efficient and go and talk to your client or go and talk to your designer and go and talk to your project lead. Because usually that's what separates senior engineers from the rest, ability to zoom out, see the big picture, see the business goal, and see how we can get there quicker, faster, more efficiently. So you want to talk to the client, designer, your team lead. If they said, yeah, sure, we can tweak, obviously, we can move things around a little bit. If they said yes, then we're also in luck. We build the thing using existing tools and move on to the next task or ice cream. If the answer is no, we move to the next question. If the answer is maybe we'll just discuss that. So let's say it's a no. Let's say we cannot use existing tools. The next question I ask myself is can I build it with just HTML and CSS? Why is that important? Why it's important to ask this question, especially when we are building something complex, you get a task to build a component, and the initial reaction is to reach out for your favorite tool or favorite library or just go and search what's available out there, what solves this problem, like what NPM package, what library. I usually try to slow down a little bit because that's exactly the point. What was impossible to build with just HTML and CSS yesterday or a few years ago might be possible to build with just HTML and CSS today, and you won't know that unless you actually go and research that and see how that's different from how the pattern is different before with newsletters, magazines and everything, you let information attack you and be bombarded by nuggets of wisdom, which are all great. Instead of that, you focus on the project and reach out specifically for what you need, and you reply that immediately, and that helps retain information much better, and it also keeps the project lean and efficient because less code usually means less challenges maintaining it, and I think it's hard to argue that low maintenance is bad, right? So also what's really cool is that new additions to HTML and CSS usually address common pain points. Think we are at CSS hacks that we had to do with aspect ratio with padding that was calculated and hide zero and columns that were created with floats and clearing that floats that was painful. Now we can do flexbox and CSS grid. So the trend is that HTML and CSS usually find those pain points and fix that natively. Okay, so quick example. Let's say you worked on a project in 2018 and you built an accordion for that project and you have a new project now that also has an accordion. So the comfortable, the easy path is to reach out for that accordion that you wrote a few years ago, plug it into your current project style so it matches the design and be done with it. When we do that, without intentionally asking ourselves can we build it with HTML and CSS, if it's possible our comfort zone goes, like the gap between comfort zone and cutting edge increases and we want to avoid that, we want to do the opposite. So if we research today can we do accordion with HTML and CSS, we find out that, yeah, there's details in summary now that we can use. Does that replace all the libraries that do accordions? Not necessarily because there are still some accessibility challenges with this HTML, CSS approach. But is that a deal breaker for your specific project? I don't know. Could be, could be not. So it's for you to decide. But now, see how, again, we learned something new while working on the project and the level of anxieties a little lower. Another cool example of what's almost possible with HTML and CSS now is viewport units approach. So I want you to scan this code because I created a quick code pen that illustrates that example. We've all probably built navigation trays that work something like this in mobile. You click the hamburger icon and the navigation tray takes the entire height of the screen. And you set the height of the screen to 100% VH, viewport height, because that's exactly what you want it to be, 100% viewport height. But only to realize, let me play that again, that when you scroll to the bottom of the navigation, you cannot reach bottom items because it's a shortcoming of how viewport units were implemented initially. And I solved that issue 100 times while I'm exaggerationally, a lot of times. Usually I did something like this, like you write some CSS JavaScript magic to track the actual height of the viewport and you set a CSS property on the body that you can later use in this fashion. And that variable with the fallback to actual viewport height will contain the actual height of the viewport regardless of whether those trays are on the screen or not. And this is very comfortable to me. I've done that a lot of times. So it's very easy to just plug it into your new project, plug that script into your new project, and move on. You can use dynamic viewport height units because they were released recently and address that specific shortcoming. So in that example, you can switch between 100% viewport height using JavaScript approach and this approach, which is only HTML and CSS, that does the same thing. So we can ditch that script and make the project leaner and rely on newer units. The only caveat with that is it's not supported in Firefox yet. But we're getting there. So in this case, we have fourth answer in our framework. We can either... We can build it with HTML and CSS. We can build it. Maybe we can build it and not yet. This is not yet as of today, but I hope Firefox catches up sooner rather than later. All right. So moving on to the next question. If it's a no for HTML and CSS. Next question is, can I build it with HTML and CSS and just a touch of JavaScript a tiny bit? See, what's a touch? Let's just first pause on that. And then I'll explain why that's cool and important. A touch is, to me, it's like a simple DOM manipulation or class manipulation. If the logic fits in a few JavaScript functions, that's also a touch. If the entire script fits on one screen, no cheating, no imports, because we can import multiple libraries and they'll equal to three megabytes. I'm kidding, but not really of a compiled bundle size. So no imports entire screen that's still a touch. If the logic is easy to follow and the three previous bullets are respected, that's also a touch to me. Now, why it's important? Same concept. We're not relying on libraries yet. That means less code to maintain. That means that project stays. It's easier to support it in the future. You don't have to update NPM packages frequently. It pushes you to study, again, HTML, CSS and JavaScript, native browsers API and the combination of those. Because, yeah, with HTML and CSS, our options are limited to what's available. With JavaScript, if we are mindful of how much JavaScript we're right, we increase the options of what we can do with UIs. So, again, keeps the project clean, forces us to intentionally learn things that are applicable right now to this very project and pushes you to think outside the box and to illustrate that, I want to show you a Carousel example. We have a few disclaimers. If you, by all means, can avoid Carousels, that's great because they are challenging to implement. Clients love them. But it's not easy to build a good Carousel. So, I went through the entire exercise for this one and tried to build a Carousel. This was a first specific project. We actually went with a different solution at the end, but it was a very interesting experience to try and build it with as few tools as possible. Again, I created a little demo for the Carousel. It turns out that you can do a lot if you use these three properties in CSS. Scroll behavior is smooth, scroll snap type and scroll snap line. You apply first two on the parent element and the bottom one on the child element. And what it allows you to do if you use horizontal parent element and clip it, it allows you to slide through items and they will snap to the position as with most Carousel libraries. And that's done entirely with HTML and CSS. The only issue, one of the issues that I ran into is when you create bullets for navigating to each specific slide. Those bullets are simple anchors to an element on the page and it's fascinating how it not only works vertically, but also horizontally. The only issue is that if you are at the middle of the page and you click a dot that takes you to a slide in the middle of the Carousel it not only slides you to the middle of the Carousel, but also to the top of the page and that's I haven't figured out a way to address that so that's where Touch of JavaScript comes in. This is the demo of me playing with the Carousel, but you can access that same way from this code and the link to the code pan is on that same page as well. So you can see how JavaScript is only there for highlighting the active dot and preventing the jumping behavior. Okay, so we are at this question we ask ourselves can we build HTML, CSS, and just JavaScript? We know the answers if it's a yes we go and build it, if it's a no we move on to the next question we'll just get in a second. Maybe again we talk to the client, our project manager, designer to see if we can adjust the task to reach our business goal faster. So the next question is if it's a no for Touch of JavaScript. We try to use libraries. So again I'd like to point out that we get to the libraries just towards the end because we try to keep the project clean. But if we want to use a library here are a few tips on how to evaluate which one is to pick. Obviously you want library that's supported where the library or framework that has community behind it that where the issues to pull request ratio is good meaning that there are almost the same amount of pull request that closes issues that there are issues. How good is the documentation? What's the like how responsive is the maintainer? How can you get support for this library? What's the license and does that license fits your needs needs of your project? And last but not least what's the bundle size? That's crucial because we want to keep project clean. So we evaluated a bunch of libraries. We have our task. We went through all these questions. This is the last question of the framework. We try to solve the task with the library and we have the same answers. What if it's still a no? What if we get to a point where we understand that we're probably about to build something from scratch? At this point I think there's a good indicator that we are either onto something really cool that hasn't been done before or onto something that hasn't been done before for a good reason. And I think I have a good idea of how to tell one from the other. Usually when your initial reaction to like you're about to build this thing and your initial reaction is huh that's cool. That's usually a good sign. But if your reaction is oh I need to build this that's again your project is trying to tell you something. It's trying to tell you to be more efficient and go and talk to the client again because we already talked with them on the maybe step. And try to like reason understand what's going on. Do we actually need to build it or not? So I keep saying go and talk to the client. Go and talk to the designer. Go and talk to your project manager. How do we approach that? How do we approach the conversation? I'm a firm believer that keeping projects lean on the cutting edge like development is just one part. The bigger part is communication. And like this deserves the entire talk to itself. But I want to like highlight that it's not just about the code. It's not just about HTML and CSS. So a few bullet points to approach conversation like this. I think the ideal case scenario is that when you reach a point where you need to talk to the client or you need to talk to your designer you have already established trust in your relationship. You have already like on good terms with them and have had multiple conversations before. Another really good concept to keep in mind is that we should not assume anything. So like going back to the example with custom colors from custom block maybe there's a legal reason that block, the color has to be that way. Maybe there's another reason that we're not aware of. Maybe it falls outside of the design system but there's a good why behind that. So being empathetic and actually listening why that is that way is key. So that means understanding the goal of what we're trying to build deeply. Another suggestion is to form your suggestion in form of questions. So going back to that same example instead of saying this doesn't follow the global color scheme let's change it it's better to like saying that can put you in a very difficult position and could make you sound very silly and not caring because you don't know the reasons behind that. So reframing that question and asking why is that link different color is there a reason behind that is a better approach to handle conversations like this. Another key thing is to not drown clients in technicalities because it's not their job. They don't need to know APIs and intersectional server and mutation observer and all the classes and JavaScript and what not. It's our job to know those things so we can solve business goals faster. So again, simplifying that is important in presenting options through business value. So if you've done all that on good terms with your clients, your designers, your team leads it will help you to handle these conversations easier get your projects to the state of the cutting edge and learn while you do that. So quick summary of the questions and this is where you can find the framework online and thank you for your time. We have time for questions. If no questions, we can just wrap it up and you can find me Oh, there is a question. It's not a question so much as it is a comment. This is just an immensely helpful way to think about this. I manage a team and I have a developer that struggles sometimes to think strategically or think through how to actually do his job and I wish he was sitting in this talk because this decision framework is actually the answer to a question I had earlier. So thank you for presenting this to me. It's been a very helpful way that I think he's going to get a lot of value at and honestly just be a little even more fulfilled in his job. He really struggles with this and I'm just really grateful. Thank you so much. That means a lot. Hi, thanks for your talk. Quick question. You mentioned about the carousel and your word pen which I appreciate you sharing with us. Sorry. The audio here is really like the echo is crazy. So you're asking better solutions for what are better solutions for carousels? Yeah, exactly. You said you went to another solution ultimately. What was that? It really depends. I heard a saying that using carousel is just like a DIY engineer trying to hide the fact that they cannot place the information the right way. That might be true. It might not be true. So like if you I guess the point is if you can avoid using carousels altogether, that's better because there are a lot of challenges doing them right and libraries exist. We have a library that we use that we reach out to but again trying to avoid using carousels I think it's still a better approach. I can point you to those solutions just find me in the hole I'll link it to the repositories. Thank you.