JavaScript at Google | Search Off the Record

Key Takeaways

[Music] hello and welcome to another episode of surge off the record a podcast coming to you from the Google search team discussing all things search and having some fun along the way my name is Martin and I'm from the search relations team and today we have two very special guests Ito Pereira who's worked with Gary for over a decade and most recently has been working on search open sourcing together with Gary we've discussed this in the previous episode in this podcast if you're curious and Pascal who has been working a lot on Modern content formats such as web stories which we also discussed on this podcast in episode 10 with Pascal in fact so in today's episode we are going to talk about a little bit about JavaScript and typescript and you know everyone's famous love topic I think we should have Gary here because he loves JavaScript so so much but it always surprises me when people ask me like why is Javascript such a big topic and I I think there's a bunch of projects within and outside of Google that are using JavaScript heavily and I know that both of you are involved in some so would you like to introduce real quick what you are working on and what your JavaScript projects look like let's start with Pascal what do you work on so my day-to-day work is building a Visual Web stories editor um like a javascript-based editor runs in the browser or basically uh within a WordPress plugin and that is basically my daily battle with JavaScript working on that editor right and that sounds like a super interactive application and as you say like a visual editor which is pretty advanced stuff I would say that's not easy to do without JavaScript at all is it without JavaScript uh this editor wouldn't really be possible because it's what allows us to to make this web page interactive and dragging things around on a page and interacting with with browser apis it allows us to talk to your webcam basically so that we can allow you to record yourself with the webcam that's all JavaScript absolutely and what are you using it for edu hey so I've been building for a long time internal applications for debugging stuff I worked for a long time in search where we were building internal applications for debugging the different parts of search and then I switched to security a bit before the pandemic and then continue building basically web applications that internal users use tools let's say they're Tools in general without going to any specifics and we do use JavaScript because well typescript actually because it it's basically their their tools that you have to to make Dynamic tools in the browser interesting and both of you are working on tools so you're mostly working with applications rather than standard off the cuff websites I would say why do you think people have such a strong emotion towards JavaScript there's a bit of a hate love relationship thing happening out there I think any idea why that is I think I have a feeling of it like applications written in JavaScript if you're going to be using them to just show content the the loading of that content is going to take longer just because it needs to load this extra JavaScript but I'm guessing that it's there are so many good Frameworks today to make web applications with dynamically with JavaScript that for developers it's a natural way to start there because it makes it so easy to make very Dynamic and you can put whatever you want be content or any other functionality so I guess some developers love it because of that and then some users hate it because they cannot get away from the past or where everybody everything would load instantly I don't know that's my feeling I don't know Pascal what do you think it's actually a great point I think JavaScript definitely had a lot of negativity connected with it in the past because of like larger bundle sizes of web page sizes one part I do like about JavaScript and like you you can't really you know do without JavaScript it's like all the tooling involved with creating websites nowadays so just the other day I wanted to create a small landing page and I wanted to have like some some build step like minifying CSS and then making sure the fonts work etc it's really hard to to do that with like another programming language like all the tooling for creating websites is basically child support based that is true that's absolutely true and I like the angle of users are dissatisfied with things that take longer to load and JavaScript tends to be that and then developers are kind of like stuck to it because it's the way to pretty much build anything on the web today and also the tooling as you say the minification everything that you want in the modern website is very JavaScript focused and very JavaScript heavy and that's that's interesting the other thing that I personally find tricky is that with JavaScript you get very powerful possibilities but at the same time you also have to reinvent things that the browser already has for instance react has this virtual Dom that basically more or less reinvents what they say is a better version of the the document object model built into the browser a lot of accessibility concerns come into mind when it comes to making sure that screen readers and keyboard input still works as the browser would by default give us working input facilities there and I think that's that's something that might also contribute to this weird strained relationship I guess but I heard that some developers are also not super fond of JavaScript to begin with and I it's it sounded a little bit like that when you Pascal said like oh you know I just wanted to build this simple thing and I needed to deal with all this JavaScript tooling so I guess developing JavaScript comes with its own challenges let's put them that way but wait may I say something controversial first oh I think a lot of the the heat has to do with Google itself and the fact that it took a long time for Google to render the dynamic pages that were using heavily JavaScript it took a long time for Google to adapt to that yeah and then people were like oh should I do should I use JavaScript in my website that just showed content or should I not and then like how will Google do that how will Google render it so I think there is a lot of that as well yeah for for writers of applications I mean out there SEO is downright often fear JavaScript and without acknowledging that a lot of things are not even possible and and it's not that every JavaScript that you use actually destroys performance for the users or makes it harder for search engines an example of that would be service workers that actually allow websites to work offline or make better use of the network in a faster way where they basically load cached content pretty much instantly and then rely on the network to give them more up-to-date data so this the challenge that search engines and I wouldn't just say Google I would say in general every search engine faces the challenge that a lot of websites are using JavaScript to load content and search engines just need to go with the web or go where the web is going and just support that and it has taken us a tremendous amount of time that is true however we do have a modern chromium rendering things now so that's that has been pretty big undertaking so that's pretty cool JavaScript has improved a lot and it was super bad in the past a lot of people that are against it have not seen the modern JavaScript or like even typescript how different it is from how it was in the past but a few years ago it was horrible to work with JavaScript there was no tooling there was no types there was like the wild west out there because you could JavaScript itself is so flexible and you can do so many things that it was it is very very easy to shoot yourself in the foot and a lot of the modern tooling around typescript um and and all the development of the this ecmascript standards that have come through and then the typescript usually like adopts early those have helped a lot to make the language more readable more easy easy to maintain I think those things had made the language I used to hate JavaScript just to be clear and now I love it I like it I I cannot do without it that's that's interesting and I feel the same having been a JavaScript developer for a very long time it felt like you are basically riding a Kitty bike with training wheels uh until a bunch of language features have been added to the language that made it a lot more mature and and capable and powerful and it's quite fun we had this episode on the podcast I'm not sure what the episode number has been but where Gary and I talked about JavaScript and he was surprised to hear what can be done and is different now in JavaScript that he wasn't aware of so I think that is actually true for a lot of people and what I would like to go back to because you said a bunch of things like typescript and types and stuff like that before we get into the nitty-gritty details I'm actually interested and intrigued by the fact that I have two people who are working on very different kinds of applications I know that you edu are working um on internal facing applications which I feel has different requirements and different development priorities than what Pascal's working on which is an open source interactive application that may be deployed to millions or billions of users at some point so how does internal development and external facing development look like what what is the what are your requirements what are your challenges in the language and what are things that you do to address these challenges with the language let's start with internal applications because I feel like that's a good starting point that then we can build upon for internal applications there are a lot of things that you just don't need to focus your efforts on first you have a you will have a lot fewer users there are a lot of things that you will not care about because also they are internal users googlers basically and they all speak English so right from the start you don't need to care about the internationalization everybody you just write your application in one language everybody will be using these apps in in desktops or laptops so right from the start there you don't really need to care about mobile I mean there are sections right but but most of these internal applications is that true is that still mostly it is because for security constraints at least the apps that I work that I've been working on you cannot really access them from a phone like the policies from the phone will let you access public Google applications like Google Drive and docs and stuff like that but then for the internal ones there there are a lot of security restrictions and you can only access them if you have like a fully corporate phone with a lot more policies and constraints and whatnot and not everybody have those making sure an application works well everywhere takes time and then you don't always have the time so it's very frequent that we don't even focus on the mobile version of an app because it's not going to be used anyway or very very seldomly and then what we want is to be able to develop fast so so what we focus is on Fast development cycle um like basically you write you you touch your code and then you get it refreshed on the web page instantly or as more as fast as possible so that you can try new things and continue developing that's the biggest biggest thing that an app needs to have and then I know for external app you need them to be scalable you need them to load fast you they're going to be users accessing them with very bad connections and there is a ton of things that you need to think that you don't need to care when you're writing internal apps it also you get a lot more flexibility because you don't follow as many guidelines uh I don't know I I don't really know if it's true but I can imagine that if you want to change the font in Gmail there's going to be a lot of red tape that you'll have to cut there whereas in an internal app you just do it and then maybe somebody complains maybe somebody doesn't I don't know no but yeah that's my experience and then we have different Frameworks suited for different things I don't know if Pascal you want to say some beats before I continue because I can continue rambling forever well it makes me makes me want to work on internal applications actually because uh as you briefly mentioned like working on like an external application and an open source program like I'm working on we have so many more constraints uh users with different uh browsers weird setups edge cases that don't work uh it's even more complicated by the fact that this web stories editor that we're building we actually ship it as part of a WordPress plugin so it's not even like a standalone single page app or whatever but it's embedded within like a WordPress admin and so you have to deal with all sorts of conflicts from from other WordPress plugins or the site configuration uh you have to use for example the internationalization layer from WordPress you can't really roll your own so a lot of challenges come definitely from working on such a project interesting and I think that's generally like one of the bigger challenges for people getting into front-end web development with JavaScript that especially when you're coming from a more internal world or let's make it even more extreme a back-end world where you have control over everything you know what kind of server the thing is running on you know what kind of requests you're getting you can ignore a lot of things you can just say like I always have a fast connection to this piece and I always have this much CPU available whereas in front-end development especially when it's external you know pretty much nothing you can assume nothing and you have to defend against everything be it a2s too small of a screen be it a very slow network connection or a flaky network connection that might fail every couple of minutes or something um so it must be interesting to to be dealing with that but challenging at times as well and I imagine embedding as part of Wordpress is probably its own big set of challenges isn't it hey I think you're absolutely right yeah absolutely I think it also starts with just uh what kind of web apis or JavaScript apis are available in your browser because not every Barrow author supports the same set of apis or features or maybe only to some degree that makes it also difficult when you want to build some applications like oh this doesn't actually you know it's not supported in Chrome I have to use a polyfill or whatever and I feel that's that's really interesting um the entire node on how the front-end side of things especially with external applications is so has to be so defensive but the other thing with the availability or not availability of of apis is one thing the other thing really is that the language I feel to this day even with all the additions that have been made um to the language in the past couple of years as edu has pointed out I think like the biggest one was probably ecmascript 2015 and then like everything was added afterwards in in yearly steps so that fantastic language has been evolving greatly since the last couple of years but it hasn't been designed from the get-go for larger scale application it is a scripting language which means you have a website you have things in the Dom in the in the document it hasn't been designed to deal with applications with large applications from the get-go so it is meant for scripting which means you have a bit of content on the website and you want to respond to actions or events on it like clicking on a button or adding something when the user Scrolls or something like that it hasn't really necessarily been primarily built for a large scalar or middle scale applications that are fully interactive applications built in the browser so I'm guessing both of you are dealing with the Fallout from that as well don't you feel that the larger the application gets the more complex the application gets the harder it gets to actually make the different parts work together and how how do you deal with that Pascal probably with the very visual tool that might be even trickier because you're dealing with everything from like storing data loading data from the network and then also like the whole user interactions layer how do you structure your application how do you make sure that the different parts play together well that's an excellent question Martin um and you're definitely right like JavaScript has come a long way from scripting language to now having to support all these like Rich internet applications luckily I think the tooling has come a long long way as you say like es2015 but also like the bundlers the Frameworks um libraries like react Etc to make it relatively easy to make sure that your application is performant and doesn't like use too much memory for example browser apis have also come a long way in that perspective JavaScript engines have become much much faster as well but I think a lot is also you know due to improved documentation and like learnings from other people so that nowadays I think it's pretty obvious that you can write these applications in JavaScript in a performant way okay so then the performance angle is covered but how do you make sure that all the different bits and pieces because I know that for instance there's this Infamous media playback thing where you can ask the browser if you can play back a certain type of of audio file and it comes back with strings and the strings are probably maybe and I think empty string or something like that it's it's a really really weird way of of dealing with this and I can see so many potential problems from that if if that is used in one part of the application and then another part of the application needs to deal with it because if you are not 100 sure about the type of data that you're getting from it and what it means then you might run into these really weird problems I recently ordered something in a webshop that was using a client-side framework to render out its entire like shop system and in the card I saw the infamous not a number it was bananas like so you buy this for 20 bucks you buy this for 10 bucks which gives us a total of not a number and I was like Ah that's and that's the classical JavaScript problem where one part of the application didn't know what the data was that the other part expected and then gave it in the wrong way and and that it imploded is is there a better way to do this is there something that JavaScript allows you to do to avoid these kind of situations where the left hand doesn't know what the right hand's doing I think typesheet has made that thing a lot better because uh you can enforce that a lot of things don't go wrong at compile time so you need to wait for them I think if you use strictly all typescript with all the all possible checks which sometimes is very annoying to work with because you're like I know this is going to work why don't you let me compile it and then if instead of finding the right types you end up using this any type that type Series has that is basically an escape patch to say I'm gonna use JavaScript here for a bit and trust me so as long as you don't do that or if you like when you do you really know what you're doing I I think those those errors are part of the past I don't see them now if if you're using typescript correctly so maybe that this website that you saw is older or they don't use typescript or maybe don't they don't have any tests for the UI it could also be possible but Pascal said that he's using a mix of JavaScript and typescript so why would you do that then it sounds like it's a very clear need for just using typescript and all the problems will be solved um the reason why we have this mix of like JS and TS is because we started uh building the application in like purely JavaScript there was like a few years ago already it allowed us to iterate quickly because we didn't have to deal with any types um also I think like a big reason was that not every team member was familiar with typescript not all the tooling was at the level that it is today but uh I think last year's how we started migrating actually part of the code base to typescript step by step and that actually helped uncover a lot of bugs as Adam mentioned uh could even be silly boxed like not passing the right arguments to some function and not getting the results that you would expect so yeah the type safety with typescript definitely helped make our application safer and less buggy that is nice so you would say typescript is a natural Improvement for anyone building larger scale applications with JavaScript I would say yes absolutely and it just makes sense to use types with JavaScript as well because if you look at other programming languages for example I used to work a lot with PHP because of Wordpress and you have types there you have types in Java which is probably the language you learn most at University so why not use types with JavaScript as well true true you know what to me was a great sign that typescript was the right way of improving JavaScript when Google updated because it was created by Microsoft and Google went full on typescript so that it has to be good for for a company like Google to go with something built by one of the biggest competitors true true I mean it's a good sign because we are basically choosing the right tool and not avoiding it just because it comes from some other company I I love Thai food the moment I started reading about it because it was JavaScript done right I became a fine boy I think that's fine and I I really love that the power of Open Source means that one company uses stuff from another company without prejudice I think that's a that's a really beautiful aspect of Open Source and what has your journey been I mean both of you have been writing uh JavaScript beforehand and uh Pascal you also have experience with PHP probably from the time when types weren't a thing in PHP because I remember that so how did you feel the journey went where what were your big key moments was there like a big aha moment um in the journey from JavaScript to typescript and is there anything that you would like to tell developers out there who probably haven't touched typescript yet oh that's a good question um because I do remember that I looked at typescript and I tried it first of small projects a few years ago and it was not where it is today didn't have many of the features and you're like oh I wanna make types for this thing but actually like it couldn't do what you wanted so maybe you resorted to anywhere like uh why like why bother I go back to JavaScript so I would say if you have tried typescript as well in the past it might be worth trying it again if you've never tried typescript um I would probably start checking out the documentation like getting started guides because it's actually quite easy to to get going with typescript you can adopt it creatively for a project maybe on like a file by file basis if you're not sure what to type you can maybe use any even if it's dangerous no but I think that's the perfect usage for it for for like migrations um internally at Google we have we had I don't know we still have it there was this Alias type any for migration so that the lint would not complain because you're not actually using any but any for migration that's great oh I hope you have removed all the occurrences of that by now oh for yeah I was hunting them down like I avoid any like the like the plague I don't like it in my countries but so in my case I used to work with GWT Google web toolkit which was uh a way that somebody Google invented many many years ago to write Java and convert that into JavaScript so it was one big attempt to add ties to JavaScript anyway because you could write code in Java with some limitations and get that converted into JavaScript so and we were using that uh you know in the main internal application I worked when I started at Google for years and eventually that thing became deprecated because basically JavaScript became good and there was no need for for this conversion from java to JavaScript and I I when I learned about typescript there was this software engineer based in Munich called Martin brost that he brought he's I think he's the one that brought typescript to Google and he gave a talk in the Zurich office and it was like whoa this is I need to learn this and I started it was I fell in love with the language right away so whoever has not tried it and is using JavaScript today they should go ahead and give it a try because it's amazing and Gary if you're listening you should try it as well I'll report back if coerce or convince Google and Google I'll report back if we can convince Gary to actually try it I know sounds good so much I'm sure we can't coax him away from from that we can try though we can try it I'm with you on that excellent so cool and is there anything else exciting so I I get the vibe that typescript was a huge step forward from JavaScript being a bit of a bag of surprises towards something more predictable is there something else that you find exciting about developing for the web these days like what about webassembly oh webassembly I love it I'm not like super familiar like I have never written something like that compile it to webassembly but I'm a heavy user and air tool because webassembly allows us to bring I don't know let's say C plus plus code and run it in the browser uh it's pretty cool and in in our use case we use it for example for uh transcoding or like compressing videos that you upload to your site but in the browser you don't have to do it on the server maybe the server is not capable of doing that um again we're like in a WordPress PHP context so there's like no video library whatever installed on that server but we can do it all in the browser uh with JavaScript running this webassembly program we should probably explain what webassembly is so you already said like you're doing video compression but does that mean that you kind of do this a very specific kind of JavaScript or how how does webassembly work in very rough terms you don't have to go into the Super nitty-gritty details but what's webassembly so basically webassembly is like a low level Assembly Language that is supported by I think all major browsers nowadays so it allows you to compile binary programs like into webassembly that you can then talk to Via JavaScript nice so it allows you to basically compile code in languages that is are not supported in the browser like C plus or rust or whatever into a kind of code that run in the browser as well without having to go through JavaScript but you can call it from JavaScript I guess exactly yeah you can call it from JavaScript that's really nice that's really really cool so you can write parts of your program in a different language and then use that from JavaScript that's really interesting okay so I know nothing nothing except from like higher level what it is but it sounds like you can enhance what the browser apis and then call them from JavaScript I guess yeah to a certain degree I don't think you can break out of the sandbox but I know that I wrote like a c plus program that basically was a function that took two numbers and added them which you can totally do in JavaScript but the point was to see if I can I know that's that's groundbreaking stuff you can add them up without not a number I know but we could hypothetically take our C plus plus uh robots txt parser make that as a function compile that function into webassembly and then call that from a JavaScript interface so you could build a web interface that uses the same source code fundamentally as the C plus tool that we built and that works in the browser and I think that's really exciting so would it be like GWT Google but toolkit for C plus plus sort of kind of kind of I think even like in note or like you know whatever also supports webassembly nowadays so it's a really portable oh uh format very useful it's basically like a little app that you can call from whatever JavaScript runtime supports webassembly and I think that's pretty interesting and I think it's also saw some examples where people basically put a JavaScript runtime into webassembly so you can execute JavaScript in webassembly it's like mind-blowing okay that's Inception level stuff all right before you put more of a knot into my in other people's brains um thank you so so much for the conversation it has been really really exciting to hear about all the things and to also take a look into the future and I know that we don't necessarily do that very often but let's do one last look into our crystal wall do you guys think that webassembly will replace typescript then I have no idea but I don't think so because it from so let's let's introduce the caveat that I have no idea about wasm right but from the description we just gave it sounds like it serves a different purpose I don't know true true no that's true Pascal what's your take I know that there are still some performance limitations uh with webassembly because when you have to pass data back and forth between JavaScript and webassembly there's a lot of overhead and I think that some people would say that yes webassembly could take over once these limitations are resolved but I'm not sure like where that would lead us okay but if you could use just webassembly then you don't have that problem of passing the data between JavaScript and webassembly I don't know could you could you have like a in the same way as you included Javascript file from a web from an HTML could you include something in webassembly as well I think I think that's not how that works because as far as I understand webassembly kind of runs in its own virtual machine and you would still have to once you want to do something with the UI for instance uh you would have to pass out of that virtual machine into the browser and that's probably where the data transfer bottleneck comes in I'm guessing but maybe I'm wrong so I I think we can wrap that up as a definite maybe and let people see what the future holds if we have been right wrong or just in the middle but before I send everybody off uh Pascal and Edo where can people find you um I'm at home I mean like online so how can how can people give them their specific address so they can bring you chocolate yes nobody are you on Twitter are you on LinkedIn my Twitter handle is epide4 so a from edu Pere from perida and the number four there you can find me okay excellent uh Pascal how about you uh my Twitter handle is Swiss Spidey or swiss Speedy so it's like Swiss and then Spidey with like three s's in the middle excellent you two it has been such a great time I do hope that you enjoyed it as much as I did uh I I think this has been really interesting um and this could go on for hours but let's wrap it up here [Music] we've been having fun with these podcast episodes and we hope that you The Listener have found them both entertaining and insightful too feel free to drop us a note on Twitter at Google search C or chat with us at one of the next upcoming events that we go to if you have any thoughts and of course don't forget to like And subscribe thank you so much and goodbye bye bye thank you