 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 could be a great intro, so let me break down each part of the title for you, so we know exactly what the presentation is going to be about. Let's start with the most simple thing, front-end projects. So, I'm a front-end engineer at TenUp, and I'm guessing that if you came to the stock, you were also a front-ender or dabble in writing HTML and CSS and JavaScript. How many here are front-enders, raise hands? Quite a few. That's nice. So, if you write HTML and CSS and 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, and 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 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. Means that we have to either use polyfills, transpilers, compilers. In other words, write more code. And that's why we also can put amount of code on the y-axis. One 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. What is comfort, 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 and 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, 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 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 and keep up with everything that's going on while moving my projects forward. So in a natural, this framework is 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 like too far, don't worry, I'll share the link to mirror 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 a 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 say it touches on many, many topics. We don't work in silo, usually we work most of the time in the context of a bigger system. We are at a work camp, so it's mostly WordPress. It could be a headless situation, so it could be WordPress on the back-end, Next.js on the front-end, WordPress on the back-end, Gatsby on the front-end. There could be multiple options. So what it does in a nutshell, like 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. 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. 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 goals 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. What it does, it also shows respect for your team and the project. 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 junior 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. 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 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. What's the better approach? 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. That's also not ideal, right? You can, creating color picker is a really, really 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. 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. So 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 are 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 be, 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 Big Mac. 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, that we can move this 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? Now, why is that important? Why it's important to ask this question, especially when we are building something complex, right? 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 apply 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 has 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 a 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 looks, matches the design and be done with it. But 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 anxiety is 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 wanted 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 the shortcoming of how viewport units were implemented initially. And I solved that issue 100 times 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 a new project and plug that script into a new project and move on. But now we can almost 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, 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 build it with HTML and CSS. Maybe we can build it and not yet. So 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, CSS, and just a touch of JavaScript a tiny bit? See, what's attached? Let's just first pause on that. And then I'll explain why that's cool and important. It touches, 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 impulse, because we can import like multiple libraries and they'll equal to like 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 attached 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 projects 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 write, we increase the options of what we can do with UIs. So again, keeps the project lean, 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. A few caveat, like 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, not 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 pen. And the link to the code pen 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 code 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 a library that's supported, where the library or framework that has community behind it that where the issues, the pull request ratio is good, meaning that there are almost the same amount of pull requests 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 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. But 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 like a good indicator that we are either onto something really cool that hasn't been done before, or either 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, so 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 reason, understand what's going on. Like, 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. But 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 this deserves the entire talk to itself, but I want to 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 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 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, oh, this doesn't follow the global color scheme. Let's change it. 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 intersection observer and mutation observer and all the classes and JavaScript and whatnot. It's our job to know those things so we can solve business goals faster. So again, simplifying that is important and presenting options through business value. So if you've done all that and hopefully 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 a 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 in the... 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 just struggles sometimes to think strategically or think method, 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 in 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 wordpen which I appreciate you sharing that. But then you said ultimately you went with another solution. I was curious what that other solution was. 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 UX, UI engineer trying to hide the fact they cannot place the information the right way. That might be true, might not be true. 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, a few libraries that we use at Tenup 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 and just find me in the hall and link it to the repositories. Thank you.