 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. Like 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 is going to be about. Let's start with most simple thing, front-end projects. So I'm a front-end engineer at TenUp, and I'm guessing that you came to the, 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 our 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, 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 on 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, transpilers, 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 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 that you follow. You read books on development, you follow ADS money on Twitter, you go to meet-ups and conferences, WordPress, WordPress meet-ups, 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've 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 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 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? Like, 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 in most of the time in the context of a bigger system. We are at a work camp, so it's most likely 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, like specifically asking yourself this question, allows you to be more efficient and get to the business goals faster. What it also, what this question also helps with, it pushes you to study that system that 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 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 the 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 the 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 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? You can creating color picker 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 very great user case scenario because there is color support baked into WordPress now, and you can use global color schemes through theme 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 theme 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 asked ourselves this question. Can we build 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, we can, we can, maybe, maybe we can do that if we support global colors instead of creating, 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 junior engineers from, sorry, 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 like that. Yeah, obviously that we can move this thing around a little bit. If they said yes, then we 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 the different tools. 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 with library? I usually try to like 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 like 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 you clearing that floats that was painful. Now we can do flexbox and CSS grid. So the trend is that HTML and CSS usually find like 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 it 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 like 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 learn 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 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 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 some 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, plug that script into a new project and move on. But now we can just 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. So, but we're getting there. So in this case we have fourth answer in our framework. Like we can either, we can build it with HTML and CSS, we can build it, maybe we can build it and not yet. So this is not, 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, the next question is, can I build it with HTML, CSS and just the touch of JavaScript a tiny bit? See, like, what's the touch? Let's just first pause on that and then I'll explain why that's cool and important. It touches, to me, is like a simple DOM manipulation or class manipulation. If it, 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 like multiple libraries and 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 a touch to me. Now, why why it's important? Same, 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 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 in 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 get to the goal, like our business, reach our business goal faster. So the next question is if it's a no, if it's a no for a 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 lean. But if we want to use library here are a few tips on how to evaluate which one is to pick. Obviously, you want library that's supported that they're where the library or framework that has community behind it that where the issues to pull request ratio is 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, needs of your project and last but not least, what's the bundle size? That's that's crucial because we want to keep project lean. So we evaluated a bunch of libraries. We we have our task. We went through all these questions. We 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 on 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 from from the other. Usually when your initial reaction to so like you are about to build this thing and your initial reaction is, huh? That's cool. That's that's usually a good sign. But if your reaction is oh, I need to build this. That's 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 maybe step and try to like reason understand what's what's going on like do we actually need to build it or not? So I keep I keep saying go and talk to the client go and talk to designer go and talk to your project manager But how like how do we approach that? How do we approach that the conversation? I'm a firm believer that keeping projects lean on the cutting edge like development is just one part the the bigger part is is communication and Like this deserves the entire talk to itself, but I want to like highlight that it's it's not just about the code it's not just about HTML and CSS so a few 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 Like concept to keep in mind is that We should not assume anything so like going back to the example with custom colors From from custom block. Maybe there's a legal reason that that block that the car has to be that that way Maybe there's another reason that we are not aware of maybe it falls outside of the design system But there's 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 Suggestion for suggestions for me or suggestion in form of questions. So going back to that same example instead of saying Oh, this this doesn't follow the 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 the reasons behind that so reframing that question and asking Why is that link different color? Is there a reason behind that as is a better better approach to to handle Conversations like this another key thing is to not drown clients in technicalities because It's not their job. They're they don't know they don't need to know APIs and Intersection observer and mutation observer and all the classes and JavaScript and whatnot. It's 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 and 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 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 hole. There is a question It's not a question so much as is it is a comment. This is just a 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 this decision framework is actually the answer to a question I had earlier So thank you for presenting this and in a very helpful way that I think he's gonna 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 Yes, that's 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 that But then you said ultimately you went with another solution. I was curious what that other solution was Sorry the 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 I heard a saying that Using carousel is just You like UX UI engineer trying to hide the fact they cannot place the information that the right way That might be true might not be true I so like if you I Guess that the point is if you can avoid using carousels altogether. That's that's better because there are a lot of challenges doing them right and libraries exist We have a library that we use Few libraries that we use it to not that we reach out to But again Trying to avoid using carousel. I think it's it's still a better approach. I can I can point you to those solutions Just find me in the hole. I'll link it to the repositories. Thank you