JS Monthly #16 / Node & Visual Viewport / July 2021

[Music] [Music] so [Music] [Music] [Applause] [Music] one [Music] foreign [Music] [Music] do [Music] [Applause] [Music] done [Music] [Music] so [Music] [Music] do [Music] so [Music] [Applause] [Music] so [Music] then [Music] [Music] foreign [Music] [Music] so [Music] [Applause] [Music] [Music] foreign [Music] foreign [Music] [Music] [Applause] [Music] my [Music] oh [Music] so [Music] [Music] so [Music] [Applause] [Music] hey folks thanks so much for joining and apologies for the mix-up there um thankfully you weren't sent to uh any completely relevant or offensive content you sent a video which will feature in tonight's js monthly but uh yes hopefully uh those of you that have joined uh are um forgiving and uh yeah um understand that we've changed the format and there was a little uh glitch in our organization uh which i take real responsibility for but um yeah good to have you on board um yeah just hopefully uh uh yeah hopefully we'll have a few more people join over the next five minutes or so as uh yeah as people get the correct link um yeah it's our plan from from this one going forward to do them purely on youtube and not to use zoom anymore um it has been fun over the last whatever 18 months or so doing them uh using both and it's been great to have yeah some really fun and engaging conversations in zoom um you know i i've cherished the memory of the uh christmas event in particular that was super fun um yeah the quiz was um was definitely very funny uh and the right thing to do on zoom but yeah i think we're good we're gonna focus purely on quality content and possibly um also slightly shorten the the length of the event too um so yeah this evening we have uh steve hopkinson uh who has spoken at js monthly before unfortunately he's not live um as you probably gathered if you went to the wrong link because you'll have seen a video of him which is pre-recorded uh yeah he couldn't make this evening's event so he he made that for us over the last few days um so he's going to be talking about data in node and the problem with leaked code and we also have pauline nemcha who is with us live hopefully you can see and uh yeah she'll be talking about the visual viewport api so uh alex if you're still there do we have uh yeah a sensible number of people watching i can actually there we go i can see that there's uh there's eight out of the 35 odd rs vps so yeah people are starting to join which is great uh in which case yeah i think it's a good time to um yeah talk about yeah absolutely fine to continue if you want yeah yeah great okay um let's go for it yeah so i'll um just briefly talk about pusher who uh who alex who you just heard uh works for and who have supported js monthly for many years now have been a really great sponsor and um yeah alex uh and his colleagues have given a lot of their time to us to to produce these events and make them happen when they were physically in people's offices and now online um so yeah many thanks to them uh and pusher if you don't know what it is um basically a set of uh real time um events and real-time data services uh here's just a little bit more info so these are the kind of features you get when you use pusher real-time location charts uh chat um chat applications gaming you know all the kind of typical things you'd expect with real-time data um and there is their web address please do support them check them out uh if you're interested get in touch um and yeah uh again thanks pusher for supporting us so i normally begin with some industry news i'm going to keep it reasonably brief this time i've just got one topic for you that really caught my eye the last week or the last month and it was an article in smashing magazine which i don't come across so much anymore but i was pleased to see that they had quite a comprehensive article on the state of web workers it seems to be quite trendy right now to to start your article with the title the state of that seems to get everyone's attention the state of javascript the state of typescript and here we are with the state of web workers which as you can see at the moment has a lot of green so if we do a can i use search you can see that all the major browsers have supported web workers for some time for those of you that don't know what web workers are they are a way of running javascript and another thread so javascript is single threaded and therefore can sometimes uh be a victim of bottlenecks um which slow your application down slow down the user experience and web work is a way of allocating tasks to uh another um part of your hardware basically and processing it separately um and what i thought was really interesting was um yeah they were talking about uh the support for web workers um in the major bundling tools so webpack roll up and parcel they all support it um from webpack four you've got the worker loader plug-in which i think i used a while ago and was pretty good roll up i haven't tried roll up with it but um yeah you can see that uh there's um an article about making it work out of the box which is great and um parcel deserves a special shout out as both v1 and v2 support workers out of the box with no config uh personally i just love parcel if you want to get started on a project quickly and not have to do lots of painful wiring um yeah it does cover with lots of really useful features of which this is one and the kind of things that you can do with web workers this should be really this should be a really nice fancy slide with lots of really awesome looking things but i'm afraid it's just a list but i would definitely recommend checking out um the smashing magazine article and checking out some of the examples that you can find online where people have used it for decompressing large files for ray tracing in 3d for movement tracking media processing data manipulation anything that's going to be really expensive and anything that's going to slow down your application um yeah is a candidate i would say and then finally um using it with um es modules native es modules which is a topic that i come back to a lot because i'm really really you know keen to see this future be realized um you know a future where we can use um es modules in node and in the browser um you know and configure them in which way we want unfortunately when you use web workers with es modules there are still some limitations uh if we set aside ie which is obviously deprecated now it's a bit frustrating that safari on ios and firefox don't support it yet it's kind of surprising about firefox actually so just something to be aware of but yeah i imagine in most cases you're still using uh common js or compiling to common js and therefore you can use workers very happily so um yeah i have one message for you don't block the main thread there you go you have to remember one thing i said that's it so um yeah please follow us on js monthly london on twitter um yeah you can see that i recently deleted a tweet and then tweeted again with the correct link um so you can you know make jokes and give me a hard time about that if you like um but yeah we'd love to hear from you so yes it's time for our first talk um which has a fantastic title i think if all you have is pathfinding algorithms everything looks like a graph so this is the pre-recorded talk that steve hopkinson kindly gave to us so alex i will hand over to you to play the video hi everyone thanks for tuning in um so first of all thank you very much to rich for the opportunity to present um and thanks to alex for the support particularly on the technical side very sad that i can't be there in person today but hopefully i'll be able to cover most of my points in this video and at the end i'll be leaving contact information for anybody who wants to reach out to me about any of the topics that i've discussed today and i really encourage you know anyone who has any questions to just get in touch and give me a call starting the presentation with this slightly long-winded title um if all you have is pathfinding algorithms everything looks like a graph or how engineers focus on logic leads to worse software which is a lot to get your head around i'll i'll get to the explanation of the title soon but given that we've all been locked down and i've had far too long to think about this uh there's a second title which is creating a better schema for software engineers now my name is steve hopkinson i'm a full stack javascript engineering lead i'm currently working as the front end lead of an engineering team delivering a thick client fintech application for jpmorgan chase prior to that i was back in lead of a team delivering node micro services for lloyd's banking group but coding is actually my second career my first career was as an arts and science journalist and writer so if at any point in this talk you think that things are getting a little bit soft a little bit philosophical there's your explanation it's because i spent years uh on the arty side of the divide uh before coming over to tech so why am i giving this talk what is my motivation through my career i've worked with a wide range of engineers in a lot of contexts both on the front end and the back end as a peer of theirs as a manager and also in my first career as a client i suppose somebody who was not on the engineering side but who worked with engineers to develop a product and across these experiences i noticed a pattern of a lot of engineers who focused their efforts quite narrowly on writing logic you know the sort of nitty-gritty of the code sometimes at the expense of other important skills for delivering what we needed to deliver now in contrast i tended to find that high high performing engineers generally took a much more holistic view of their work uh seeing their role as being about a lot more than just writing if statements and for loops and so i wanted to explore some of the causes of this kind of divide um and search for some solutions so in my second title i mentioned creating a better schema for software engineers which begs the question what is a schema now it's a familiar term for many engineers but it's also a key term within psychology now a psychological schema is essentially an individual's mental model or a pattern of thinking that allows them to organize categories and the relationships between them it's a framework for making sense of the world around them shaped by their experiences now schemers are how we make sense of the world and we use them as shortcuts for thinking about things the world is extremely complex if we were constantly dealing with it in its kind of raw form it would be quite overwhelming and so instead we have heuristics you know we ask ourselves simplified questions and often that means relating things back to our schemas which means that we're more likely to accept information that reinforces our schemas and to reject information that contradicts them we have schemas for how we think about everything um from kind of human elements like friendships and parenting even through to how we think about ourselves and these are called self schemas the kind of mental model for how we think about ourselves in life and these are extremely important so if a self schemer becomes self-defeating if we have a model of ourselves that has a mainly negative impact on our lives we can say that that schema is maladaptive it's kind of an adaptation that has had a negative impact on our ability um to deal with the world so that might be things like perfectionism or or a sense of inferiority you know any of those things now kind of extending that um a way i think about it is that individuals will play many roles throughout our lives you know our self isn't just in a single role constantly we move through many roles um and for each of those roles we will have an internal model of what we should be doing in that role whether it's a kind of romantic role a family role or a professional role and so we have a series of role schemers if you will which are our mental models for those roles that we inhabit now why does this matter to a software engineer so maybe a bold statement but from my experience i would say that many software engineers have what you might call a maladaptive role schemer a mental model of their own roles professionally that have a negative impact on their working lives so how does this happen i thought to explore that we might look at something i've seen in an area very different from software engineering which is football here is a clip of the famous player maradona who died last year and this is kind of a highlight reel of some of his top moments most individually talented players their abilities um and kind of really demonstrating the the peak of their technique and skill so these highlight reels as i say they're compilations of individual footballers greatest moments um commonly profiling the most technically gifted players so so your maradona's your honoral dinos your messies they almost exclusively tend to focus on what players are doing when they have the ball and there's often a focus on dribbling which is as many of you will know kind of an individual skill that demonstrates technique ball control speed physical strength and intelligence and because of sort of issues with broadcasting rights these highlight reels are often a more accessible way of watching football than actually being able to watch actual football matches now from watching these highlight reels that you know have this very individual kind of technique-focused few of footballers you could develop a a role schemer of what a footballer should be doing which is that a footballer is someone who uses their individual skill to outwit opposing players through their personal technique and strength and you know on the basis of things like that maradona highlight reel you know that certainly seems accurate but to see the other side of things um it often goes wrong so here is cristiano ronaldo not meaning to pick out anyone in particular but this is the other side of dribbling and the application of individual skill it goes wrong quite a lot and when it goes wrong it tends to have a very high cost for the team it looks pretty stupid and it's not really helping anyone in terms of what you're actually trying to achieve in football so this to me highlights that this highlight reel roll schema is maladaptive it's it's a model of how to play football that is actually having a negative impact on how many people approach it because football itself is not an individual sport of course um success isn't measured by what you do as an individual but by collectively achieving goals as a team so high skill individual plays like dribbling they're inherently high risk and failure often has a high cost to the team there are usually safer options available as a footballer that are more likely to result in a good team result passing to another teammate who's available or going for goal or just moving the space around in a way that you know opens up the opponents rather than trying to you know take all the responsibility on yourself these clips also overlook more important skills such as movement off the ball you know how you're moving when we don't have possession and so in the place of what you might call the highlight reel roll schemer of a footballer we need to create a healthier self-image of what's required to create a more kind of heuristic model of what a footballer should be doing in order to achieve the best results and that role schemer might look something like this you know a footballer is someone who uses their abilities to maximize their team's chance of achieving the best result and you know this isn't just something that's limited to football if you're a musician you know you can imagine that guitarists who grew up listening to van halen might come out of it imagining that the role of a guitarist is to play a lot of notes as quickly as possible which ultimately leads to some pretty terrible musicians um you know a more heuristic view of what being a musician would mean would avoid some of those you know missteps in terms of how we conceive of our own roles now how is this relevant to software engineering so software engineering my experience is preoccupied with logic learning to be a software engineer is often synonymous with learning programming languages and that learning often focuses on logical constructs so if else statements loops switches all of these different things that we have available to us and equally online resources for improving development skills such as leak code and code wars often focus on improving individual logic writing skills but rarely explore other domains such as data modeling or requirement gathering interviews for engineering roles especially for quote-unquote aspirational roles like fang so facebook google et cetera um often focus on solving complex algorithmic problems so things like path finding algorithms and also many software engineers are entering the field through studying computer science which has a strong focus and algorithm design and optimization but of course computer science is not software engineering they're overlapping but quite distinct fields even the language that we use to talk about software engineers reinforces this bias you know we talk about ourselves as coders we talk about ourselves as programmers even though often the majority of our role doesn't involve writing code or or programming it's a much more wide-ranging skill set and my view is that this focus on logic much in the way that watching highlight reels of footballers create a very limited view of what a footballer should be this focus on logic within software engineering creates quite a limited view of our roles as software engineers which is that engineers are people who use their individual skill to solve problems by writing logic but now here's a screenshot from a project i worked on a long time ago and what i'm trying to show here is that this focus on logic often overlooks the fact that logic can be software's worst enemy and an excessive logic in particular can make software very very difficult to work with both as a user and as a programmer so this was a code base that i picked up from from another team and you'll see the second line here says that the one particular function has an n path complexity that's the number of paths through the function uh of 20 trillion which is quite a few the limit that we configured for complexity was 200 so we've overshot the mark quite a bit there and this was really a project where you know just mindlessly adding logic on top of logic really caused us a lot of issues so kind of what is the issue with this kind of logic first role schema well first of all engineers who focus on logic as the main responsibility of their role a much less much less likely to pay attention to non-logic tasks you know as we discussed earlier we use these schemas to kind of shortcut how we process things and so if we focus on logic first where we're much more likely not to pay attention to kind of non-logic tasks and responsibilities such as styling data modeling documentation and shaping requirements engineers are more likely to prioritize logic focus tasks or to try to resolve issues upstream of implementation by adding additional logic so for example finding out at the implementation stage that the data model was wrong and so bunging in a load of code to kind of fix that at runtime and this additional logic that we add to fix upstream problems uh implementation creates what we might call accidental complexity which is logical complexity that isn't fundamental to the problem we're trying to solve it's incidental and it's introduced at the implementation stage i've also seen the engineers who see them their role as being to write logic i'm much more likely to choose to solve problems by implementing solutions from scratch even if problems have already been solved elsewhere which when which can lead to not invented here syndrome as it's occasionally known and i think the reason for that is you know often problems like pathfinding or things like calculating that the difference between two strings these are solved problems but they're also quite enjoyable tasks to solve from a logical perspective and so if we see our job as being to write logic rather than to build software we will often tend to prioritize fixing the problem ourselves rather than looking to see if the problem has already been fixed now why is this excessive logic bad in my experience very few requirements are fundamentally logic problems you know there are very few requirements that come in that a fundamentally pathfinding issues or you know about calculating levenshtein distances or other kind of classic examples of algorithmic issues and particularly in the front end those issues are quite unusual to come across which means that most of the logic we put in our applications is incidental to the task at hand it's not kind of fundamental to the problem we're solving and even our kind of front door process as we're bringing in requirements complex logic in requirements so you know requirement where a single feature might have a lot of different branching paths that have very different outcomes depending on whether you know flags or thresholds go one way or another radical changes above or below those thresholds etcetera are often a sign that the requirements themselves need to be refined because these kind of very complex outcomes are very hard for the user to make sense of often the more logic that exists in an application the more that has to be communicated to the user or even worse hidden from the user and this often results in a worse user experience and on top of that logic probably more than any other element of our jobs is very difficult to reason with expensive to create and maintain and the source of bugs errors and edge cases i think it's often said that it's twice as hard to read a piece of code as it is to write it um and so if we're writing complex logic that that's the limit of our ability to reason then it'll be almost impossible for people to actually make sense of that reading it back fixing these issues that are created often results in piling additional logic on top of the logic that already exists which only exacerbates these issues as a rule of thumb i would say as an engineer a well-designed application should contain the least amount of logic necessary to deliver the required functionality and obviously if we do have a lot of engineers who believe their role is just to write logic then these rules of thumb are kind of pulling in opposite directions which kind of creates tension within teams so what can we do about this and kind of divide this into two areas what can we do as organizations and team leads versus what can we do as individuals ourselves now as organizations and team leads i think the most important thing is always to create culture and certainly i've worked in teams before that plates kind of complex logic on a podium you know team leads would really praise the engineers that write you know these extremely complex multi-layered algorithmic solutions whereas the engineers who are kind of diligently pushing back on introducing that complexity at the requirements gathering stage are often much more under-appreciated so organizationally and as team leads we can work to create a culture that doesn't place complex logic on a podium but instead praises decisions and engineers who choose to simplify and improve the application throughout the process also in terms of team building obviously recruitment is a huge part of that so we can try to ensure that application and interviewing processes do not unduly focus on solving logical problems so that's essentially you know grilling candidates getting them to write breadth first search algorithms or restart a star path finding algorithms uh interview often for roles where those abilities will never be used so trying to consciously avoid placing a focus on solving these logical problems particularly when recruiting for roles where the majority of the work will not be kind of intense algorithmic work particularly in the front end field in my experience and equally encouraging processes and behaviors that push back on the introduction of unnecessary logical complexity and that's in two stages really both as we're refining requirements ensuring that we are pushing back on requirements that seem unduly complex in how they formulate an issue and also at the peer review stage encouraging code reviews among peers that you know highlight complex logic that's difficult to reason with um and encourage developers to kind of go back and find simpler ways to deal with these issues potentially by moving some of that into a different domain by simplifying the data model or just by expressing that logic in a way that's simpler to understand maybe with more uh declarative code or in a way that makes things easier to reason with there are actually some linting tools out there that can automatically check for complex logic tslint has a cyclomatic complexity rule which allows you to essentially set a limit above which you will not pass a linting test for code complexity but that's a fairly blunt tool and i don't think it gets to the root cause of the issue as individuals we can invest more time in strengthening areas of our skill sets that are often overlooked really drilling down into data modeling looking into core concepts like data normalization looking a bit more into how we handle styling i see a lot of particularly with the rise of kind of css in in javascript i see a lot of complex logic employed to kind of generate styles at runtime which can be very difficult to reason with as engineers so again finding a more declarative approach to how we declare our styling and also investing time in understanding how we refine requirements i think too often as engineers we put less effort into refining the requirements that are coming in because we're confident that we can fix whatever happens at implementation but again that only results in more accidental complexity but also as engineers we can seek to consciously embrace a more holistic self-image of our roles as engineers and to continually evaluate our own decision making against that schema so we're constantly evaluating our own behaviors against an idea of our role that is more kind of all-encompassing in terms of the results that we're looking to achieve and as i wrap things up i'll leave us with an idea of what a healthy role schemer for a software engineer might look like and in my mind that's something along these lines a software engineer is someone who uses their abilities to create software that fulfills the needs of its users and is easy to scale and maintain and often that is something that we can achieve while writing the minimal amount of logic which for many of us who've learned software engineering through doing algorithmic challenges or from computer science that can seem quite contradictory to how we think about our roles but as touched on before you know this excessive logic is quite contradictory to these i think hopefully quite global standards of what writing good software looks like so thank you for listening um i appreciate that might have been a little bit more abstract than some of the talks that are often given at js monthly so i appreciate uh your patience and understanding and listening to this i'm very sorry i can't be there to answer your questions but please do reach out to me on twitter i can be contacted at steve underscore hopkinson uh or by email steve at stevehopkins.com.uk i'd always love uh to hear from your insights both in terms of your individual experiences or maybe if you've encountered this at an organizational level or even if this is something that you've just encountered as an individual and maybe any steps that you've taken to try and resolve similar issues so thanks again for listening i hope you've had a great evening and i hope to see you in person at js monthly event soon thank you very much fantastic um yeah steve you're not here but thank you so much for fantastic putting that together oops i've got a terrible echo let me just turn the video off that would be better wouldn't it um yeah i thought that was really really interesting and and wasn't actually necessarily quite what i expected from him um and i'm delighted that he's um yeah that he's presented something that i think can help everyone um who attends this event or everyone who sees this video and sees his talk um yeah be better at their job and to understand what they do perhaps in a different way or to see what they do in a different way uh rather than being a technical deep dive um which is you know probably the most common kind of talk that we have um okay i can see we've got some some questions coming in what is a thick client um that's a good question i'm not sure unfortunately because steve's not here he can't answer i wonder whether a thick client is something um [Music] yeah that receives content or data from a server that is more sophisticated than a server um so not service to server communications perhaps oh i don't know perhaps someone can google it while uh while we're talking because um yeah that's not a term i've come across um but good question and um yeah and looking at the icon um it looks like it was one of our previous speakers so uh yeah hello okay so we have another one heavyweight client-side application okay that's what came um yeah responding to the previous question about the thick client um yeah i guess maybe a thick client is something like a single page app or something like that um given that the talk was about having possibly excessive logic in applications um yeah pauline thinks uh thinks the same yeah i wonder whether it's that um i thought it was interesting what he was saying about um using linting tools to um essentially kind of find an objective way to um yeah to identify complexity into and to deal with it and to avoid technical debt um which is obviously what will accumulate if you have too much logic too much code uh i'm a big fan of um using tools like codeucy and sonar they tend to run libraries um like um es lint which he mentioned but yeah they just make it very easy to configure rules around yeah complexity and you know number of lines per module duplication uh all of those things so i'm a big fan of using metrics to to measure those things okay we've got some more comments which is great it's good to see you all chatting away uh thick client is where there's a lot of processing happening on the client not the server yeah so whatever the client is um to the application yeah uh i i guess it sounds like we're all agreed it's something uh yeah maybe like a single-page app which has a lot of processing that needs to happen uh i missed the start of the presentation so i don't know the full context yes so um the good thing about this youtube um channel is that yeah you can watch uh everything back at any time so yeah if you missed the beginning um then yeah please do come back and if you missed the beginning because i gave you the wrong link then uh again apologies everyone for that yeah it was uh it was my bad um i think it's mostly about business logic yeah this is a lot of logic around data yeah i mean i imagine also that the applications that um that steve works on uh uh because he's worked with a lot of um large financial institutions yeah they probably have very um very heavy client-side applications uh and i imagine yeah he's he's you know over the years he's seen a lot of great examples of probably over engineering so i think this is a really great topic i think he's introduced a topic um that we haven't really had much at all before at js monthly so i encourage you to uh yeah everyone who's watching um to yeah to either um put forward a talk yourselves because we're always looking for new presenters um or to ask one of your colleagues or you know if you if you know someone who's got a talk and wants to be involved to get in touch with us via the meetup page is the easiest place or dm us on twitter um but yeah in particular if you've got um any thoughts on how to make applications slimmer and fitter and more you know user-centric that would be great okay well i can't see any more questions coming in in the comments um but yeah good to see some chat there um and um yeah now that we have uh a talk um that's not pre-recorded coming up we can't actually have a proper q a at the end um so um i'm going to hand over or at least i'm going to introduce first uh pauline hi pauline hello hey welcome so are you calling in from from moscow is that right or are you in london i know i'm uh i was in moscow and i'm currently in saint petersburg i moved to another city now oh wow yeah and harrison petersburg is absolutely beautiful stunning a friend of them might live yeah that's that's i think so fantastic yeah well congrats on the move um yeah so if if uh yeah if you're ready to go then um yeah i'll hand over to you um and uh yeah we'll um yeah we'll uh definitely enjoy your talk because it's going to be very different from steve's which was obviously more i guess a little bit more philosophical and so yours is about um a kind of underused um api right a viewport api yes yes i i guess you can you can say uh well it's it's kind of it's kind of a new one so that's why it's not like it's widely popular yet right fantastic well we love new shiny things so yeah i'll hand over to you thanks a lot for joining us all right um right um hello my name is pauline this is my like very first talk ever so i'm really really nervous and today i'll just i'll be speaking about visual viewport api uh and not something about visual input api about some stuff about viewports as well so uh as i mentioned it's like a very new api uh it's only like a community draft report yet but if you look at the support uh it's kind of widely supported now i think you can at least you could just try it just play with it just look at it if you can use it in some of your cases uh and also yes about new shiny things yes uh it's front-end things change quite often you can't like catch on everything um so yeah what is it in general is just some api that can be used for querying and modifying the properties of the windows visual viewport and that's how it looks like but i would like to try it just in the console let's see uh so uh you can see a few properties uh i would like to to change something a bit so you will see if something has changed so we can see that page stop has changed and also we can notice that there's some like kind of pairs of properties that looks a bit similar but they're not the same i mean about i mean offset left page left and offset top page top like what does it mean what's the difference between them as i said yeah so and now we just opened uh our console we haven't zoom in we just code a visual viewport and our offset is equal to zero both offset left offset left and offset top uh what has changed is page still because we scrolled a bit down so it remains zero until we zoom in so let's let's go it again we can see that scale has changed because we zoomed in a bit and also offset off the top and offset left has changed um and if you'll be and if you like make some calculations here uh oh also i wanted to say that without swimming summoning this page top is the same as a window hy offset because it's just some uh it's the amount of pixel we scrolled from the top let's see uh and if we zoom in we also see offset top of end of that left has changed and if you notice uh uh the difference between wait till code the difference between page y of offset and which dope will equal to offset top and i want to explain why and what exactly means page top what is offset top so if you just read the spec it might be a bit complicated uh it says like it's the white coding page top is the y code in it relative to the initial containing block origin of the top edge of the visual viewport in css pixels and setup uh return the offset of the top edge of the visual you put from the top page of the layout you put in css pixels and well i don't know what about you but for me it was like what is it what is likely out report what is uh usually you put what's the difference uh i had no clue like uh how to understand a lid so i just started figuring it out and the first about initial containment block if you open specification again it says it's the container block of the root element so if you want to uh give an html some router size and position it will be calculated relative to the initial containing block and on desktop it matches the browser's window size and on mobile as you can see further it's a bit more complicated um about viewports um viewport is the is equal to the browse window desktop and on the mobile as i said it's a bit more complicated how to measure it we just use document.document.clientwith in the same height but there is a thing um if you know document document dot element returns the root element of the document so if you try calling it in the browser it will give us html element sorry but um there is a thing if you try changing uh width of html tag and try uh calling document.documentelement.clientwith it will not give you width of html tag it will still give you the size of your viewport on on the desktop so it's kind of tricky and uh if you wonder how can we find the dimensions of the html itself instead uh it's stored in document.document element offset width it's kinda tricky and about layout you put when i figure things out i found this answer on stack overflow and i put a link in the end if you uh my presentation if you want to check it yourself um so basically the difference between between our layout viewport and visual viewport roughly speaking what we see on the screen at this moment is visual viewport but you can zoom in and everything that contained like in in page will not be recalculated because because css layout calc uh calculated relative to the layout you bought so the yellow 2 port is some bigger thing like everything that you have on the website uh and if you zoom in the part that you see uh is visual viewport so if if you haven't zoomed in if like your scale is equal to one uh let's say the layout you put us that like is the same as visual viewport roughly speaking um but if you zoom in they become different uh sorry and i also wanted to say about how can we measure failure to put in the visual viewport uh first as i said before document document dot document element dot client within hide its viewports layout you put dimensions and visual viewports window dot inner width and height and if you i also wanted to come back for a second to this slide because i hope now it's less complicated if it was uh complicated for you in the first place as for me i don't know like now um it's more um understandable like page top is just the some uh code code in it from the very top of your page and and of set top is kind of the difference between visual viewport and layout your port that's why when we did some calculations before like it worked and also if you noticed before uh [Music] visually port has two methods on resize and on scroll i wrote just a few lines of code can i just ask would you be able to just uh increase the scale on the text in the console a little bit more just for some of the other viewers sorry to interrupt you i'm not i'm not sure if you can no um if you press some are you on a mac pauline yeah yeah if you uh if you do command plus same as you would in the in the viewport it should do the same in the console yeah cool all right perfect thank you better so um you can you can notice that there's two methods on resize and in scroll and i just wrote a few lines of code just to to make everyone understand how does it work let's open it in the new window so the default like is one as you can see it's we console in the scale so let's try zooming in and now you can see we consume this and also when we scroll something we'll also console it so basically that's that's it it's quite easy to use and um uh why do i need visual you put api like we took a look how how how to use it in general what it can do um the point is that um as i said before usually you put api allows it to position elements relative to the visual viewport instead of a layout viewport it's not that easy to find some cases that like really i found like very important to to to use it but still i wanted to show an example from the spec like if you zoom in you can see that this no not like this like if you zoom in and zoom out you can see that this this scene in the in the bottom remains the same it has the same size and for example if you have some blog with ads on your website and you'd want people to maintain with the rest of your content it can be useful so um first uh i thought that it could be just some small improvements in user experience uh second it probably could be useful in some gaming stuff in some html games so that's it thanks for watching i hope you enjoyed it and also i put all the links uh in the end my twitter my github all things that i write to make this presentation or just stuff you can read to darwin so and i will i will put this link in the comments on mid website to our current meeting so you can you can like watch it and ask questions and contact me if you want funny thank you yeah that was so good yeah thank you yeah i don't i don't think anyone would have known it was your first talk if you hadn't said so um but congratulations on your first talk thank you and yeah you definitely get some yeah you're definitely oh he's still there not good yeah uh i thought i'd lost everyone then another window just randomly closed uh yeah i was just gonna say you definitely get um get the prize for best looking studio that that violet light um in the background makes it look super cool yeah i have to say like nearly all the speakers that join us these days have got more and more sophisticated studios maybe i really need to up my game um but that was a really great talk um i think it was um yes super helpful for lots of people to really understand some of the fundamentals around you know about um viewport properties um because it's really easy to misunderstand which ones um do what uh i've certainly been uh in that that term situation a few times and also yeah to obviously understand this this new api which is going to be um super useful i think the the the examples you gave are really good ones um i've asked in the yeah in the chat if anyone's got any questions i can see some high fives and some collapse which is which is awesome so uh yeah people really enjoyed it yeah that's great um i can't see any questions yet but i have a couple um considerably pretty api being a lifesaver oh so uh i wonder how which cases so can you can you like name oliver if you don't mind me asking no that's yeah it's good i mean yeah if we were doing this on the zoom obviously he would just be able to chat um to answer uh verbally but um yeah oliver if you want to post it in the comp you're answering the comments uh um's question which is yeah how do you think it will be a lifesaver i could see there was a few examples above people were talking about headers on mobile and things i think toasts or anything you know things that are sticky or fixed um that you don't necessarily want to also zoom um could be great cases so i mean i have some questions about compatibility though because while you were talking i had a quick look at the um visual viewport api on can i use and i could see actually the support was pretty good i was really impressed so you know edge chrome safari operas yeah so that's really really good the only thing i was surprised about is firefox some reasons yeah yeah you know the paint uh already because i guess what you've tried to use this in production have you and that was a problem yes so that's true it might be but uh is that is there a polyfill that you know of um i'm not too sure because i look to like just in the uh in in the shoes and stuff and i haven't seen anything like that yet because it's it's just really a new thing and people just keep discussing it yet but i hope i hope it will i hope yeah sure yeah on mdn it says it's still an experimental technology but actually yes yeah the support is pretty good sometimes they post a polyfill uh in the document don't they but they haven't done you yet so i guess we need to wait for it to stabilize but um so how did you how did you discover it it was like really random i saw a question on stack overflow about it like about difference between a set top and like page top and so i started like digging digging deeper started reading the communication and the uh some stuff about few puts viewports in channel because as i said i didn't know about like leopard and visual europa that there's a difference and they called like that that's how i came to this topic and i realized to the subject and i realized that it might be useful for some developers like myself because i i've never heard about it before and i found out like randomly so i decided to speak about it so more people will know it and maybe they will use it in the future for sure well based on the comments uh it looks like it's going to be really popular for sure um and yeah we love um talking about new tech at js monthly and it's it's great when people share um yeah topics on new technology and sometimes topics like this where it's it's really focused on just one api you know and and um and people will really get a good grasp of it um so yeah we need to we obviously need to wait for firefox to um to stop spoiling the party um yeah it's just gonna yeah it's a shame isn't it but i mean it's often the case that there's there's one browser or another that causes a problem i suppose um yeah you could still implement it and if your browser stats are mainly you know chrome and safari and so on and yeah and as long as it didn't cause firefox users issues i can see that um oliver answered your question about what what it was you think will be um a lifesaver um so he says i can see it making responsive layouts much more simple uh scaling assets better to the view animations um actually that is some an interesting point actually yeah i mean it'd be really interesting to use it in animations um so you know making animations accessible especially if they're manipulating actual dom elements or svgs and so on it'd be interesting to know yeah how it can be used for that uh oh and um yeah there's a few questions yeah do you want to do you want to hunt do you want to read them out yourself yeah why not yeah uh like uh salmon asked have you written this stock up as a blog post uh no i just made some notes while like preparing it but uh i like i haven't made it as a blog post but i could if it if people want me to like quite hot i could do it and i'll ask any css compatibility uh i'm not a frontend deaf so maybe a silly question i'm not too sure about um which like compatibility to say because it's like yo um using javascript to measure uh things uh and uh like it it doesn't really affect css i suppose because you just measure scaling and your position from the top of the document and like this offset uh like between layout and layout viewport and visual viewport yeah it's computed values isn't it i guess so your css will will do its job and lay out the page but any but yeah you want to to compute something uh using javascript then yeah then this um this will yeah this will do whatever you need it to i guess um but yeah it's a good it's a good question though because um yeah we do have quite a few developers that join these um events that aren't necessarily front end or more familiar with node and and such like yeah um do we have any others no uh i mean on the um on salma's point about the blog post um yeah i think i think it can make a good one i'd be i've not come across anything about this so uh yeah maybe you could um if you were to write or not we might see you in the next javascript weekly or something right i'll think about it and also said that he was thinking in relation to css transform um i'm not too sure here so i i'm like i don't want to answer because i'm not sure like about about it i think i need to check it and to see what happens yeah that would be a good um little uh proof of concept to make wouldn't it i imagine that yeah if you've transformed something and it's moved off the screen or if you use transform to modify something that that will that the javascript will still know the final computed value so it still it won't matter it'll it will it will be an absolute value that it's got from whatever the css did um but yeah in animations it can be hard because the yeah you have timing discrepancies between javascript and css which is hey maybe that's improved i haven't done for a any while the world is a better place when it comes to animation i don't know um cool well i mean i i think if anyone's got any more questions that they've got your contact details right i'll have one more question oh that would be great i do think visual output will mostly be used by frameworks or libraries then directly by apps um i'm not too sure i think visual viewport api is quite easy one i mean it's easy to use it just by itself and it's probably can be used by libraries of course but i think it's also can be used just by developers directly because uh you don't need to read a huge specification and to figure out a lot of things just to use one api like with some other future apis when libraries are like really really really useful uh because the api itself is a bit is a bit maybe difficult just to work with uh directly so i think it's it depends like if if someone needs uh just to use a visual api i think probably people just will use it and if they want some more something more complicated they will use libraries i suppose [Music] fantastic okay so i think that looks like all the questions for now um it's great to see so many questions um yeah clearly everyone found the talk um yeah really really interesting and i guess there's still some questions to be answered so yeah this was the uh you know quite a new technology and um yes there's still some homework to do which is fun so uh yeah i'm gonna you know we're gonna nominate you um or you've nominated yourself as the uh the source of knowledge here so i guess anyone anyone who has got any questions for you can dm you on twitter was it yes at the end of your talk and uh yeah and and follow you and uh yeah we hope to see you back at js monthly another time uh or another venture i don't mind yeah fantastic yeah yeah we'll definitely have to be back sometime but um yeah thank you so much for the talk round of applause again thank you for inviting me pleasure great okay well uh yeah for those of you that are still with us uh yeah thanks so much for joining and um yeah please do share the link um with yeah anyone uh yeah anyone you know who will be interested with your colleagues please share it on social media um and yeah we will see you again in one month um people have asked me about whether we're gonna do events back in physical venues again in in london um and i'm not sure we are yet we were planning to do it around this time of the year and there just aren't enough offices open with people in them is it the same for you and some petersburg pauline uh it depends uh i currently work like from home from home office but i'm free to walk uh from from like real office as well right okay yeah so it depends but um i'm glad that many people walk like remotely now uh it's uh because it's way more comfortable for many people not to spend the time just going to the walk in some buses underground and stuff like that exactly yeah i don't miss my commute for sure yeah yeah well i'll yeah if we do do any physical events then we'll let you know i believe yeah i believe we have another city js which is our conference planned um which is online and uh physically in london um but for now yeah we're going to stay online so yeah look out for more updates and many thanks again to both of our speakers and thanks for everyone uh for joining okay [Music] so [Music] [Music] [Applause] [Music] [Applause] [Music] [Music] so [Music] [Music] [Applause] [Music] is [Music] [Applause] [Music] [Music] [Music] [Applause] [Music] [Applause] me [Music] [Music] [Applause] [Music] me [Music] [Applause] you

Channel: Pusher

Views: 249

Keywords: developer language, language code, libraries, help, tips, forum, meet-up, meet up, learn code, coding education, coding hints and tips, lecture, coding lecture, learn about code, learn a developer language, amazon alexa skills, developer conference, node.js, javascript, backend

Id: KjRIJiRuZjE

Length: 87min 39sec (5259 seconds)

Published: Wed Jul 28 2021