- The (potential) overspecialisation of developers and what we can do to help course correct
- Where Single Page Applications (SPAs) came from
- The libraries Martin likes, and where he sees promise in new and existing frameworks
- His advice for enterprise-level SEOs
That’s not the web I want to build. The web I care for should be for everybody.
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 React developer,” “I’m a Vue 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.
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 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.
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 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.
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.
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 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.
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.
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: 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.