 Okay, so, hi everyone, this is my first time speaking, I'm Jacob, so I'm going to talk about how fun and development is hard, can you hear me, it's okay? So, my alternative topics to this talk were actually like, should I do something about grid, CSS grid, something related to CSS or fun and if not, what even I agree to talk, talk CSS, so what happens was, I was supposed to speak at the previous one, but I pulled out last minute because of work. So, yeah, a bit about myself, I'm a fun and developer at MiniTRE, I tweet on Twitter and I write on Medium, so I have some quite interesting posts there, so do check it out. Okay, so topic for today, fun and development is hard. It is time to actually address the elephant in the room, that fun and development is actually indeed hard. Why is it hard? For something that you can actually learn at like a coding bootcamp in like maybe six weeks and with such low barrier to entry, why is it hard? So I've been a fun and developer for close to about four years, so I have a bit of experience, yeah. So let's look at the three co-pillars in front end, we have HTML, you have CSS, and you have JS, and these three co-pillars are actually the three important tools that any fun and developer would need to start their fun and journey. So why is it hard? Often we get asked these questions, isn't it just CSS, HTML and JavaScript? Can you change this checkbox into a reader button, or can you give me an estimate on how long can this will take, and often the answer is nope. So let's have a look at HTML, so HTML it's here to make life difficult, the D is silent. So no, no, HTML is actually a hypertext markup language, which is the markup used to creating websites and web pages. So within HTML we often have to choose between two sort of structures, one being on the left where you can see it's the ambiguous structure, aka the diff soup, and on the right you have slightly more identical sections, you have a header, you have an article and a footer. And so on the right it's what's known as a semantic HTML, and why do we choose the one on the right? That's because for accessibility purposes really. So for screen readers, they often need to, so screen readers work by reading out the content, and if you build your HTML on the left, it's going to be like diff, diff, diff, diff, whereas on the right it will be like header. So at least a person using a screen reader would know how these sections are divided. And also for your general sanity, when you come back to review a project maybe like three to six months later, you sort of at least understand how your project's broken up into. Okay, and now for CSS, which I like to call cascading shit storm. If it works right, it is actually cascading style shit, but if it's wrong then it's a shit storm. So CSS is basically how your elements actually appear on paper, on screen and on other media. So I think the difficult thing in CSS is actually the different frameworks and architectures you meet. Should I use OECSS, should I use BAM, should I use a mix of both? What framework should I use? What architecture should I use? And oftentimes if you inherit a project, you need to fight with the important monsters, so that you have loads of important written within a CSS. There's also compatibility. If you have to deal with IE, it's a pain, especially 10 and 11. I know some people are still fighting to use it. And cross-browser compatibility is actually a huge developmental task, because you need to understand what browser supports can support what. For example, like Flex, even though it's supported on IE, it is an old version. Grid as well, but Grid doesn't work as well. And UI testing in general, if you want to do CSS, it's actually very difficult, because there's no unit testing for UI. And visually small things that take a lot of time to get right, it's actually very difficult to do in CSS. So continuing on, naming things are also very difficult, because how do you name a card or how do you name things? And I think maintainable efficiency in CSS is even harder. So final developers actually need to have a very strong understanding of how your entire website works. And it's like a huge mental map that you need to know in order to build your site efficiently and effectively. And the next JavaScript, which is everyone's favourite language. So with JavaScript, there is so much frameworks coming in every month, there's actually even a website that tells you the days since the last JavaScript framework. So with JavaScript, you need to know, do I need a framework? Do I need a shared use view? Do I even need jQuery? So for me, when I started Frontend, I actually started with jQuery, but I think after doing it for a long time, we realised that do I actually need to import this library just to use a particular function where actually I can read it just with pure JavaScript? And there's actually a website, you might not need jQuery.com, which tells you how the functions are in jQuery and in JavaScript. And graceful declaration, so what if a user can't use JavaScript at all? How do you, what do you do in that case? And also managing state with all the framework is hard. So if you ever tried to, say, show or hide a particular element and you do that for like, say, 10 pages, that's a real nightmare. So that's just it, right? No. So I work in the agency and unfortunately there's always so-crashing UI changes where the client tells me, can you adjust this input box 8 pixels more to the right or we like to script the previous design and we have to redo everything and let's have it done in two weeks. There's also optimisation and performance we need to consider. How come it's loading so slow in a particular browser? How come it's rendering it differently in IE? And the question that my project manager likes to ask, can you give me an estimate on how long this will take? And that's just it, right? There are other things like frameworks, libraries. Processing dependencies, plugins, understanding user experience and again the same dreaded question, can you give me an estimate of how long this will take? So what can we do about it? I mean the brutal answer is to not be a friend and developer because I think we chose this career to solve problems. We are the bridge between designers back end and people with different disciplines. The main website is about marrying the three languages which is HTML, CSS and JavaScript together and educating people on why friend and development is hard because it is development and also it's good to know that friend and development is often a process of discovery. So a developer only learns what he needs to develop when as the product evolves Initially when it starts, say you have a task to do a project, you won't know the entire of the product until you start building it. So this is a road map, it's quite a popular road map that you can go online and see which tells you sort of what you need to learn to be a friend and developer, which is actually quite a lot of stuff there. So with that I leave you with this. And that's it, thank you. Any questions? If you have any advice to make it easier? Sorry? To what? If you have any advice, how do you make it easier? I mean, I can answer that after everything else, yeah. Why don't you quit? Because I love complex problems. I think it's challenging and yet rewarding when you figure out how to solve a particular issue. So how do you feel about service workers? As soon as they came along I was just like, what the hell? How do you feel about them? Like you said you work in agencies, you're doing lots of service workers, and how has that changed your feeling about friend and developer? In terms of, well, I mean clients can be a pain because they don't know what they want. And oftentimes you can only go in to sort of say, I think this is what you want. And when you start building a product and then they'll be like, oh, actually you want something else and actually explore that, and it turns out that they want something else. So I think you have to take in mind that what you built initially would not be what's the final product. How much customization do you do per client? I would have mentioned you have a lot of commonality between different things to keep you sanity or do you not? Which is why you don't have any sanity. The latter is good. Any other questions? All right, thank you very much Dirkup for sharing your pain.