season 1, episode 1: on Javascript with Martin Splitt

AMANDA: This is Amanda, your host for this podcast called Engage on Enterprise SEO, where we go where nobody has gone before and dive deep into the world of Enterprise SEO from as many different angles and viewpoints as we can tackle.

So what better place to start than with JavaScript? An ever-present and sometimes looming feature of modern Enterprise SEO. It seems all enterprise websites are built on or with some form of JavaScript. As SEOs, we know JavaScript isn’t great for your website. And yet we have to deal with it every day, and it’s probably not something you’re going to be able to entirely migrate away from.

So how do you deal with it? What can you do to manage it? Look, no further than Martin’s Splitt in Google’s developer relations team. You may know him from his brightly colored hair and many, many YouTube videos on JavaScript SEO. And I’m honored to say he’s our guest.

MARTIN:So I’m a developer relations engineer in the Google search relations team. So I work with people like John Miller and Gary Ilyish and [..] Cherry, as you know, and Daniel Weissburg and Alan Kent and I came to the team because SEO has been difficult for websites that employ a lot of JavaScript. I have been a web developer and SEO quite a while, so I got scooped up by John and team, and here I am today trying to make sure that everyone builds nice websites and that we have nice bunch of events.

So now we have this paradigm shift of going from pages. There were just like a piece of paper with text on it and images on it. It’s no longer just a page with information that I can consume and then a form that I can submit like I would do a mail in form. Like, oh, yeah, I fill in all the fields and then I put it in an envelope and then send it off and then sit there with my cup of tea waiting for the postman to come. And hey, there it is. All right, this is the result that I got back. No, now it feels like more of an interaction application.

So we are shifting away from pages towards applications. And the sheer fact that we are recording this very podcast episode in the browser shows that I’m right here. This is an app, this is not a website. This is not how is this a website? It’s not a website. This is an application. It just happens to live on the web, which is fine. However, for SEO, that poses interesting How would you represent what we are seeing here in terms of search? Do you have to represent it in terms of search? probably not. I think it has been like a continuous paradigm shift on the web that led to this.

I mean, node JS was useful because now you could use JavaScript in both the front and the back end. But before that, JavaScript has mostly already been in the front end side of things for small things such as interactions. If you wanted, let’s say like a pop-up or if you wanted something like snow on your website, you would do that. Remember the old websites whenever there was like winter times you would probably have like snow or something followed your mouse curves or like mouse trails in the 90s all this kind of stuff was already done with JavaScript so JavaScript was already there to make the website respond to interactions and but all of this has been pretty much decorational so none of this has fundamentally driven functionality or content on the website the website has been there looking like it would CSS and then JavaScript just added a little eye candy if you wish.

However, I think in 1999 or something a feature was introduced that would allow JavaScript to do network requests in the background and basically fetch things from the network. And what also happened is that in the early 2000s browsers were very different in what they would support and what they would not support. things like let’s stick to the example of like a little cat running after your mouse cursor as you move the mouse cursor around. Depending on which browser your user was on, you would have to do very different or you would have to write very different code for each of these browsers to make it happen.

That’s ridiculously annoying, right? It’s like, okay, so it’s very simple. I just get the coordinates of the mouse cursor and then I figure out where the cat currently is. Then I plotted trajectory and then actually the cat just moves and I just moved this little element. little cat gif around to the point where the mouse cursor is, that’s it done. Maybe I want to rotate the little gif or something like that. And you could do all of this with JavaScript. It’s just every browser required you to do this different, the internet explorer look different, the netscape look different, then Safari look different, then Opera look different, then Firefox. So that was annoying.

And so a bunch of libraries came out such as prototype or which you probably all have heard at some point in your life if you’ve ever worked with the web. And jQuery fundamentally was a library that allowed you to just write one piece of code and that would just magically work in all the browsers by abstracting away from all the browser differences. So it would figure out, oh, so I need to use this piece of code to make this function happen and this piece of code to make this function happen because you’re in Opera, let’s say. All right.

So that library also introduced another thing, which is an easy and less cumbersome way to interact with the content on the website. So you could add things that weren’t there before. So now you could do things like, oh, what if I just wanted to have like an image car or so? So I have 10 images that I know of. And I just want to load the next image whenever someone clicks on the button. You could do that now. You could actually, you could do that beforehand. You don’t need jQuery for any of that, but it’s cumbersome. cumbersome because every browser has a slightly different way of doing things. So again, it was just cumbersome, so no one did it.

But now that you have this stumbling stone taken away from you, like, oh, I don’t actually need to write 10 pieces of code to just do like one thing and then need to decide on the browser based on the browser, which one I would be running. So now people started to be more creative and then eventually they figured out, hold on, actually, you know what, write my web applications more like I write my desktop applications. As in like you would have sort of a window and in this window you would have all sorts of things that you didn’t see before on the web like dialogue windows or pop-ups that you could drag around or well actually drag and drop.

So the the ability to just casually drag and drop something into a website and then appearing on the place where you dragged it. That was wild. Or just I need to sort these 10 things. Yeah. JavaScript, well, you would have a form and then you could probably have like an input where you can select it would be very, very weird interface. But what if it’s just the 10 things as bubbles underneath each other and you can just drag them around and they just reorder themselves?

Hey, that’s nice, that’s an interface that I would actually want to use. You can build these things now because there’s libraries such as jQuery and others that make it easier to do this across browsers. So, and building stuff, and eventually they figured, you know what, we can’t just make simple websites anymore, because the maximum interaction that you get with HTML and JavaScript, so sorry, with HTML and CSS alone, is like you can have a form. But if I click submit to have the server do whatever the server needs to do, the page goes blank for a while until the server comes back with a response, and then I see the next page. So that’s not a great experience either.

So in an application, you would expect me I don’t know, put something into the form, then you would see like a little loading spinner or loading by a progress bar, something that fills the time until whatever action you just perform is done. And then you would see the outcome of that action. I don’t know, like you want to resize an image. Sure, you just do that. You put it in your application. If it’s a really slow computer, then maybe it takes a few seconds until the image is resized. So you just drag until you have the size that you want. Then you see like a little loading spinner.

And then bam, there is your resized image. that on the web, but now you can with JavaScript. Because you no longer have to just submit the form of the image, wait a couple of seconds until the network comes back with data in front of a blank screen, and now bam, there’s your image. No, you can actually have a little spinner and JavaScript in the background, sense it to the server. And in the background, it comes back. And then once it is back, in the background, JavaScript can add this image and then remove the logo in graphic.

AMANDA: At this point here, after reminding us about the history of JavaScript and how it came to be, what it is, and the capabilities that we now have, I’ve has the question to Martin, just because we can, does that mean we should? And this was his response.

MARTIN: And that is a really interesting point. And I think it’s one that is underappreciate, especially by developers and by technical decision makers. You are absolutely right. And this is the thing that I think will eventually change for the better again, probably. But at this point, is that developers now have this shiny fancy tool that allows you to build whatever application you want to build in. And again, they have to write just one kind of code to actually make this application happen. But now, now comes people from marketing and sales and saying, we need a blog or we need a website.

So there is a bit of a tendency within developers or within development teams to say, I don’t want to like deal with two systems because admittedly, there is additional complexity in that as well, absolutely correct. So they are trying to do everything with the tool that they have on hand and the problem there is it can be done. I’m not saying it can’t be done, it’s just, it’s the wrong you can do a lot of incredible things with just a hammer.

You can probably clear your driveway from snow with a hammer. It’s just gonna take you a really long time and it’s gonna be really, really tedious. But you can, I don’t think you can not. Even if it’s icy, you just smash it with a hammer until it’s no longer icy, it’s like crushed ice and then you just use the hammer to swoop it away. That works, it works. It’s not…the thing is like it works, right? It’s, you get the results you wanna get probably and it’s probably not going to be as clean and nice and quickly done as it is if you would just use a fricking shovel, but you can use it.

So that’s there’s a tendency within developer circles to just be like, well, we already have this React application that does all these fancy things or maybe like it’s a backend that is written in React. So why not just write our customer facing front end the same way because we can reuse a bunch of stuff and we can reuse a bunch of the same development tools and we know what we are doing. Yeah, sure. But on the other hand, you’re just having to do a lot more work than just integrating something that exists already. And that probably isn’t as painful to use this as well. And a lot of people don’t understand or don’t care enough.

And there isn’t as much understanding on the other side of things. So like I have the feeling a lot of the SEOs and the business people don’t know enough about about what they are dealing with to actually give pushback. Because I’ve seen in organizations where everyone was technical enough to understand what was going on to be like, yeah, sure, we could do that. Or we don’t, yeah, or we don’t, and actually get quicker results easier and with better performance for the users.

I’m not saying that that’s necessarily always the case. So I would argue a well-integrated react front end for a landing page or a blog is still better very badly integrated WordPress. So, you know, on the other hand, WordPress is amazing for a blog or a simple website or let’s use like a shop system, whatever magento or Shopify or whatever to do a shop to build a shop. But again, if you do that badly, it’s better to actually build it yourself well. But each of that comes with its own challenges and you probably need the right skill set to do each of these things. Well, Yeah, so it’s a, yeah, it’s a tricky situation. I think they’re all pretty much the same. It’s just a difference in philosophy and tooling and what do you value? So I really like the U.J.S. but I also like to React.

Angular, I worked with the old Angular and the newer Angular. So like there’s pre 2.0 Angular and then this Angular after that. It’s also pretty good. I just haven’t touched this much after that the Angular switch, like they had backwards compatibility, breaking change, and that has lost the community a lot of momentum, unfortunately. And I don’t have that much interaction with that community too much, I’d be more honest. But pretty much all the frameworks are great. There’s new ones coming out pretty much daily. Svelte looks pretty damn good. Lit HTML is pretty damn good. But they all care about building good web experiences, so we are all aligned on that one.

Things that are like stumbling box blocks or issues that I see is often that People tend to buy into whatever their framework does, and then just use that framework for everything. So I’ve seen a weird trend of specialization. Instead of being like a web developer, a lot of people are, I’m a reactive developer, I’m a view developer, and I find that very, very strange because that’s like I’m a second floor painter. I only paint second floors. I’m like, what does that mean? What? That’s very, very strange to me.

I mean, sure, you can be an expert in one thing and be reasonably good in other things. You can’t be an expert in everything. I would never call myself an expert in everything. I know a lot of stuff exists in Angular that I’ve never touched. A lot of stuff exists in View that I’ve never touched. But you should still understand the basics and you should still be able to understand what your framework, because the framework, what frameworks do is they take decisions for you. make the decisions for you so that you don’t have to. And that is fine as long as you roughly align with the decisions made.

But I would argue having seen so many projects over decades at this point, that you want to make decisions differently for different projects. So sticking to one framework, because that’s all you really know, without understanding the decisions and trade-offs that this framework makes for you, is probably I’ve seen that there are tools that are like, okay, so we solve this problem here with JavaScript. And I’m like, yeah, but you can also do it like this in the browser without JavaScript. They’re like, yeah, but we do it with JavaScript. I’m like, but don’t you then have this other problem? And they’re like, yeah, we have this other problem. That’s true. So what do you do about that? Why don’t you just step back one step and just not use JavaScript for this specific problem? No, no, no, you don’t understand. We just use more JavaScript to solve this follow-up problem as well. I’m like, okay, how do you do that? And then they explain it to me. And I’m like, okay. create these two new problems here. Again, you don’t have if you just didn’t use JavaScript in the first place. But that’s not really an issue. You see Martin, we just use more JavaScript to solve these problems. But that creates these five new problems then. Martin, don’t you understand? We just use more JavaScript to solve these problems. And I’m like, okay, that at least does not create new problems anymore. But now it’s really slow. But only on your computer, my computer is fine. That’s not the web I want to build. The web I care for should be for everybody.

It is often, I don’t know how often I have been in projects or companies, Google being the exception luckily. So here at Google we have user experience researchers. So whenever you build something, it’s going to be put in front of potential users as soon as possible. And as soon as possible, it doesn’t mean that it’s ready. We have this thing that is a mockup. It behaves similar to what the actual product would behave like, but it’s not actually functional, but we want to have someone in, like some real user, not someone from your organization, not your boss, not your CEO. Someone who is supposed to be using what you’re building needs to be touching it and going, ugh, this is slow, or, this doesn’t behave the way I expect it to behave. And it’s necessary. It is absolutely just necessary because if you are just having arguments based on technicalities You get really really shitty results.

It’s like oh, but but you know this works fine on on most devices like Where do you get this data from? Yeah, but we get it from our analytics great Your analytics show that everyone that you have on your website uses a modern iPhone because everyone else opens it on their phones And goes like wow, this is slow. This is shit and goes through your competitors And that’s why your data doesn’t reflect what is potentially happening out there if you would make different decisions. So get real users, get a user experience expert. And if, to be honest, if the developers build the thing that works great for users, you should not care. Then sorry, then it’s your job to figure it out. If it’s good for your users, then the goal is achieved. Then it’s your problem to deal with whatever issues you’re seeing and not the developer’s issues. If the users are having a problem with or experiencing performance issues with, then that’s their job to fix. Because oftentimes we are biased ourselves.

So get externals and this shift to applications is crucial and important, and we will see more applications coming to the web because it’s a fantastic application platform. I can use this application that we’re using here for the podcast on my phone, on my laptop, on my desktop, on probably on my TV I think we have seen that there is a need for page-like content because for people researching things or for people learning or looking up information, this kind of stuff is as important to the web as applications are. So it’s like all sorts of different intentions, right? You have like information retrieval, you have research, you have exchange of information, and then you have the entire like whatever applications do like fulfilling a task, whatever that task might be. But for instance, a restaurant doesn’t need a web application.

What it needs is a website that shows me what is on their menu, how much does it cost when are they open and where are they? That’s it. So no need to have like a react thing there. However, however, they might wanna have fancy things like a chat that is integrated into it and they might wanna be able to change the content themselves. So then you are easily stuck in the CMS world or the site builder world. And then if you have someone who’s like a developer that you employ, maybe not the website of a restaurant. That’s probably not the best example, but like a larger company that has, let’s say like this company that runs this web podcast recording thing, they probably have a blog, they probably have informational websites that explain the product to them.

So their application might be written in a JavaScript framework. But then you have the content side of things that probably needs to integrate because there’s probably documentation and features in the documentation like feedback or contact support about this that need to be accessing your login information, your account information, and you want to reuse code fine. of content management system for them to access and change the content of the website or create new pages. You don’t want to have to run to your development team to create a new page for a new limited sales thing that you’re doing for the next two months. But you can’t really use like a page builder like Wix or Squarespace for that because they limit you too much to integrate You don’t really want to bolt on a WordPress or something because that also, it’s not what it’s meant for really.

So maybe you want to use something like a headless CMS instead. The headless CMS gives the people who edit and create the content a separate interface than the developers. And then the developers build basically more or less a traditional website, but they can integrate it nicely with what they have in the application side. These two worlds probably, rather than having a full-blown web application abused to do the non-application things, because that’s what has been happening. And I think developers realize this, because page performance has become a bigger concern and accessibility has become a bigger concern. And developers realize that holy moly this is tricky, because the decisions that the frameworks for applications made and have baked in, coded in are not the right decisions and trade-offs for page like informational content. So how do we bridge this gap? I don’t know, but I do see that a lot of people like, yeah, no, I don’t have an answer for that, but I see that next JS was a step in the right direction.

I see that there’s like a lot of, there’s like Graph QLs being used for Graph CMS that you can all sorts of like, I think, what’s it called? Can’t remember all of them, but as plenty of headless CMSs, I think you can run WordPress headlessly now. So that gives developers more tooling and more abilities to do things without being encumbered by either two rigid frontends from content management systems traditionally and two rigid application frameworks that are not meant for page content. So I think we’re gonna see more in that direction and the server side rendering has been like a thing that hasn’t been looked at for years. And now everyone is like, but does this framework support server side rendering? And the no is often not well received. So pretty much all the framework communities are looking into figuring that out or having a better story for server side rendering as well. And that brings us back to pages that are more in the or websites that are more in the page like world than in the application world.

AMANDA: Before we got to starry eyed about JavaScript and its future and where it could be going, I asked Martin about one of my personal pet peeves in JavaScript, SPAs or single page apps.

MARTIN: Single page applications are a consequence of a very different trend and that was proclaiming the web is dead and it’s all going to be apps now. working in agencies has often been that we pitched, we would have both an on offer, like a website or a mobile application, we could do both. And then people were like, we want the mobile app. And then you say, like, but why? Because what this is is fundamentally, let’s actually say, like, this is a website for a restaurant chain. So it’s a website. It’s not an, this is not an app. Yeah, but I want to see the restaurants near me. Yeah, we can, we can do that on the website. Like that is, yeah, Yeah, yeah, no, we can do that. We can like show a list ordered by closest to farthest away. We can show a map with like markers on it. Yeah, but then if I press on menu, it reloads the page and like it’s a flash of white and then in the app, it just like droops in from the side and whoo, which is utterly pointless.

Like I don’t give a shit about things like moving in from this, I want to know what’s on the menu now and not I don’t want to download especially if I’m visiting a different country like I don’t want to download your your shitty restaurant chains app just to install it on my device for it to be removed five days later because I’m leaving the country and there are none of your restaurants in my country Eh Like what’s the what’s the benefit here? Yeah, but we can offer you coupons you can’t do that on a web like what? What and you could have all these animations and woo! And we didn’t have that on the web. It didn’t exist, like there’s a page, then there’s nothing, and then there’s another page. That’s how traditional websites work. But I said earlier, now we have web applications where the things can happen in the background, and then you can do JavaScript magic.

So what you can do instead is you basically have one page, and then the JavaScript does magic in the background, and then, woo! like all sorts of funky animations because the JavaScript can actually intercept this navigation event. And that’s how you get an app like experience. It is pointless. It is utter, fucking pointless, but it’s what people wanted. Because now it’s like, I get the benefits of an app which is like shiny, shiny, shiny, without the cost of an app. Hmm, interesting. All right, you convinced me. I’ll buy that. And that’s how you end up with single-page applications. And I don’t think those are a particularly good use of anyone’s time and resources. And you should just have normal pages.

I understand the need and the one for like these transitions, but there’s now I think it’s actually called the page transition API. It’s actually literally called the page transition API. And it allows you to do exactly that, but with a normal website where it’s different pages. You don’t have applications anymore. However, it’s an experimental feature. It’s going to take a few years until it lands and all the browsers, probably. So, you know, keep your horses calm. But eventually, that’s going to probably replace that pattern that we’ve seen for those websites.

However, if it’s a web application with an integrated documentation or blog or something where you want to smoothly transition between the app application and page-like content. Then it makes sense to have a single page application and kind of have like a hybrid thing where it is individual pages, but in the app or in the application version of the website, it actually works as a single page application, which I think is fair. So it’s probably never going to go away fully, but I think it came from a weird perceived concurrency or like a competition from apps that has mostly died down because people have realized that pumping a lot of money into apps development and then having no one download that app is not a great strategy. But the nice transitions and the eye candy for from single page apps that has stuck unfortunately. So we’re going to see that a little more in the future.

AMANDA: Any final advice for anyone working in enterprise SEO with JavaScript?

MARTIN: Test, test, test, build a good report with your developers. Also don’t be like, oh, JavaScript, that’s a problem. No, JavaScript per se is not a problem if applied correctly and done well. Do try to understand and talk to your developers. Just ask them what choices are they making? Are they taking into account all the SEO relevant things does content show up? Is the website fast for users? Does it does it all work well enough in Googlebot? You can test these things. They don’t have to test it for you. You can test that for them, but just make them aware that there’s more requirements than they might have on their radar. And that will help them make better decisions. Thanks so much for having me. And I hope that was useful to our listeners as well.

AMANDA: Now, thank you for joining me in this podcast episode from Engage. on Enterprise SEO and I hope that you’ll continue listening on or get in touch with me @amandaecking or Amanda at floq.co if you’d like to continue the conversation or if you’d like to discuss SEO consultation.