Working with 50% of code in the browser

Podcast transcript

Mike Mason:

Hello and welcome to the Thoughtworks Technology podcast. I'm your host, Mike Mason, and I'm joined by my regular co-host and Thoughtworks Chief Technology Officer Rebecca Parsons. Hello, Rebecca.

Rebecca Parsons:

Hello, Mike. Good to see you again.

Mike Mason:

And Rebecca will be doing a kind of split role, hosting and guesting on today's podcast. And we're also joined today by Erik Dörnenburg. Who's the head of technology for Thoughtworks Germany, and a long time collaborator of ours. He works with us on the Technology Radar and in running the tech organization at Thoughtworks. Hello, Erik.

Erik Dörnenburg:

Hello Mike and hello Rebecca.

Mike Mason:

Today's topic is one that came up during a Radar meeting, and that was the realization that 50% of code today is running in the browser. This seem like an important topic to dive into and especially the implications of that fact. So Erik, let's start with, what do we mean when we say 50% of code is running in the browser?

Erik Dörnenburg:

I think I made the statement in a discussion, where I don't exactly remember the context, but it was referring back to an engagement with a client that I had been working with, where we're writing a large application, in fact, I can be open about it. We have the clearance from the clients to talk about it. It is the application that Mercedes Benz is using for selling all their cars in the German market.

Erik Dörnenburg:

This isn't a business application, obviously it is not B2C application, it will be used by the sales representatives. While working on that, we recognized that the application was of course split into a part that runs in the web browser, a part that runs on the servers and then some backend systems in the large enterprise that Daimler has.

Erik Dörnenburg:

But what we realized is, as the team that was writing this application, we were spending more and more time on... The majority of the time actually writing JavaScript code and not code that was running on the backend. You may argue, and we might come back to that point later that it takes a little bit longer maybe to write code in JavaScript and in other languages, but I don't really think that is the case. So, if we think we spent more time writing that code, we probably writing more off that code. And then easily you can say 50%, because if you write more of it the other one must be smaller.

Mike Mason:

I think what we wanted to do today, was to talk about how we got here? Because I think a lot of people that story would resonate with them. They would probably agree that they spend quite a lot of time writing JavaScript or getting the browser to do things, with more and more code being in the browser. So, let's talk about the historical arc, I think when we were preparing this, we said maybe we'll start with thick client or fat client or desktop app, or however you want to describe that. So starting there, let's think about the historical, how we got to where we are today?

Erik Dörnenburg:

The thick clients of course we're there to help people be productive in enterprises, in large organizations, we are writing applications for internal use and it was just the thing to do, I guess. There were websites already, I guess if we're going back to this time, when the term was really popular at that time there was web technology people had .com websites and the technology was there.

Erik Dörnenburg:

Yet there was this understanding that the internal applications would be written as desktop applications. There were technologies like VB6, if you remember those and then of course, the whole modernization that Microsoft brought along with the .NET Framework at the time. And this worked I would say reasonably well and we wrote some beautiful applications with it. There were issues though, there were real issues with deploying those applications and making sure that all the libraries were on the laptops, rolling them out.

Erik Dörnenburg:

There were some really clever engineering solutions, but it's still, never felt great, I would say. Then somehow, at some point, not in the field where we were writing these rich client applications, but somewhere else, other organizations wanted to bring applications to more end users. And they were running I guess, into similar problems with distribution.

Erik Dörnenburg:

One of the companies was Microsoft. Microsoft wanted to have, a web version of outlook. Remember, this is really quite long time ago, it wasn't anywhere near as sophisticated as today. The webpages were still, request response, they would reload. The browser for getting smarter, they weren't repainting the whole page, but still it wasn't anywhere, what we would expect from this today. And yet Microsoft really wanted to have a web based client for outlook and they invented, I think it is fair to say this, we probably should fact check this before, but they invented this idea of Ajax.

Erik Dörnenburg:

The idea that you could do an asynchronous JavaScript call to retrieve some XML, because they wanted to avoid this whole reload problem. And then the JavaScript would run in the browser, it would retrieve some information coming back as XML of course, in that day and age, and would then be dynamically rendered in the browser to display something. At that point, of course, developers took notice. They said, if that can actually work, maybe we can also use this for these enterprise applications, because then we avoid all the distribution issues and we can use a broader set of technologies.

Erik Dörnenburg:

That I guess, is the historical beginning that sets into movement this whole arc, this narrative that we were talking about, how more and more code moved into the browser.

Rebecca Parsons:

I would also say, if you think about it, again at the historical context, the way of interacting with an application pre-Ajax on a web browser, you were very, very limited. It was almost as limited as the green screen technology, and I think a lot of the drive towards the desktop applications at that time was to get that greater level of interactivity, the richer user interfaces.

Rebecca Parsons:

The ability to just make things easier to work with was a big driver. As you said, the browser at that time and how we were coding webpages at that time, you simply could not have that richness until Ajax came along. I do think that technology shift then got people to also say, all of those other wonderful things that we want to do with desktop app, how can we do that in the browser? And of course, we went through the horrors of Flash and some of those other things.

Rebecca Parsons:

I do think a lot of it was the increased flexibility that could be given to the level of interactivity with those applications. And for a time it was actually worth that configuration management headache, to get the productivity gains that were coming from being able to have this richer user interface.

Erik Dörnenburg:

That really mirrors my experience too, because people were absolutely trying, and in certain cases also succeeding in building enterprise applications, internal applications using purely web technologies, simply with form fields, submit buttons, page reloads, and so on. There were lots of frameworks for that, and this whole thing, it's a bit difficult to use the terminology consistently today, because it's overloaded.

Erik Dörnenburg:

But what we called server are rendering at the time, where you had application server often written in Java. There certainly was also Microsoft variant, rendering HTML on the server and just sending it down to a browser, like B2C websites used to work. That was definitely done, not only tried it was done and it was successful in certain cases, but it really wasn't rich enough to replace many of the applications that we talked about before.

Mike Mason:

I remember one of my first Thoughtworks projects actually, worked on it with Rebecca in London and we were writing a Java Swing Application for a retail store to run on the cash registers. And so, it was a thick client app, very rich and interactive touchscreen great stuff. But, we had an entire team who worked on something we called software distribution, which was the process of getting that to all of those many thousands of machines across the country.

Mike Mason:

I think it's worth remembering, that a significant part of the motivation here for putting things into the browser was the notion of not needing to install software anymore. Suddenly I think that was the primary one, was once you had the browser the IT folks at an organization could ensure that a particular browser was on the desktop. And then you could write your application for the web browser, that you knew was going to be there.

Mike Mason:

And of course, over the years we've had many promises of standardization around what the browser actually does, so that you would only actually have to write one version of your website rather than one that had a million tweaks in it for each browser. But, we know that certainly never panned out for me. Whenever I was writing software, I would always have to understand whether you needed it in an Internet Explorer tweak or this or that, on that.

Erik Dörnenburg:

That's a good point. It is probably worthwhile at this stage to place this into historical context, to look at the time we're talking about here. Certainly for me and I also happened to work in London. The first time I was working with a client, where we made a decision against the desktop application and for browser-based internal application, was The Guardian, The Guardian newspaper. Where we needed to write tools for the editors and journalists to enter and to write the articles. Actually, most of the articles were written in a different system, but there was definitely an admin backend if you will, for the website. And this is 2005, 2006, it's the first time when I remember having a discussion and making a conscious decision of going with an application that ran in the web browser.

Erik Dörnenburg:

The technologies were quite different than they are today, if I remember correctly, it was a Yahoo UI toolkit, I think called YUI, that we used at the time and it really felt limited. There were longer discussions later, it's probably fair to say, wondering whether it might make sense to actually do after all write a Swing application, a rich desktop application. But to my knowledge, as far as I was involved in that engagement with the client, this wasn't done. And I'm pretty sure that today, of course, it will be a browser based application that is run on the backend.

Mike Mason:

That's an interesting timeframe because I remember doing an application, probably a similar kind of timeframe for you, that was again delivered via the browser. It was a corporate application, so we knew exactly which browser, it was always going to be Internet Explorer. But what was interesting was, we were building an energy management system that was basically complex in browser spreadsheeting mechanisms.

Mike Mason:

And at one point the stuff was just running so slowly via JavaScript that we ended up having to use a Silverlight component, which was the not very long lived Microsoft attempt at beating Flash, as part of the page. But because we were building the app largely in .NET, Silverlight made a lot of sense because it was Microsoft technology as well. So for a little while in order to get the browser to perform at speed, with many thousands of rows in a table, we actually needed to jump into Silverlight for a bit, but again, it was still code running in the browser.

Erik Dörnenburg:

I guess that brings us to another major breakthrough, which was Google, really looking at improving the speed and making this kind of application really viable at a large scale, by having a better browser. By making JavaScript performance something that the browser vendors would optimize for and by being able to run large applications, in a somewhat efficient way in a web browser, at least something that allowed you to do this.

Erik Dörnenburg:

I think this then result really in a major breakthrough, of course for applications in the B2C space, for end users but also in internal applications. I think this is then the point where we're seeing a lot of this development, we're still seeing a lot of people who distinguished between I'm a front end developer and I'm a, in air quote, which you can't see, a real developer meaning I write code that runs on servers.

Erik Dörnenburg:

So we received that distinction here because there was still this understanding that somehow JavaScript was again in air quotes, just a web technology that people who were writing JavaScript had an HTML background, which of course isn't a programming language. There was this implicit assumption that JavaScript somehow wasn't real.

Erik Dörnenburg:

I remember one of our colleagues, Sam Newman at some point said, just because it's JavaScript, it doesn't mean we shouldn't test it. Apart from the double negative in there, but the point was there was this assumption that we were writing... We were doing TDD, we're writing lots of unit tests. We had lots of good coding practices and suddenly the same developers writing code that ran in the web browser, threw this all overboard because it was just JavaScript.

Erik Dörnenburg:

Maybe in the beginning, when you were just doing a little bit of validation to improve the responsiveness, to improve the user experience in JavaScript, maybe that was acceptable. But certainly as we were seeing this class of applications, that we're talking about here, we really needed to apply all these... I think we called it engineering practices to JavaScript as well because there was, and that is the topic of the podcast obviously, an ever increasing amount of JavaScript in the web browsers.

Rebecca Parsons:

Yeah, in fact, we put on our Technology Radar, JavaScript as a first-class programming language, to reinforce the fact that we needed to view JavaScript in the same way, from an engineering perspective that we looked at C# and Java and all of the other air quotes, real languages.

Mike Mason:

Maybe we should recap, Erik, we've been talking about the, how we got here, where is here today? If we talked about, the average modern application delivered via the web, just roughly, what does that look like to you? Just so that, we're all on the same page about where we think we are today, when we say 50% the code is in the browser.

Erik Dörnenburg:

In the simplest sense, it is an application that is written in one of the large JavaScript Frameworks either React or Angular or Vue.js that is downloaded into the user's web browser and is running there, provides a user interface that is at least a rich as user interfaces we were used to from the rich client applications. Sometimes I think the bar has been raised, the rich client applications often used UI toolkits that made everything gray. Everything looked uniform and everything looked gray and today I think there's an aspiration to make them look good.

Erik Dörnenburg:

I think this is the influence that we are seeing from the general web, from the ability with HTML to style things, in a much more sophisticated way than these older toolkits, for rich clients allowed us to do. Today we see an application that is functionally completely equivalent with everything that was possible with normal desktop applications, 15, 20 years ago, and at the same time, it probably looks better.

Mike Mason:

That JavaScript application in the browser is typically making server requests at a lower level than the full page refresh. So, we're specifically asking the server to do things based on the user's interaction with that application in the browser. So, are we effectively back to client server just delivered via the browser?

Erik Dörnenburg:

I think you could say that. If I think back to the application that I mentioned at the beginning of this podcast, the sales application for Mercedes Benz, that is clearly the case. We are loading JavaScript and the JavaScript makes requests to the backends, to the server systems and which reads data in the form of JSON. Luckily we left XML behind also in the process in all of this. But yeah, you're absolutely right.

Erik Dörnenburg:

What we're seeing is an application that is running in an execution environment and that just happens to be a web browser making requests for data to some backends and the code is delivered... And this is an interesting nuance we can probably talk about in a minute, the code is delivered mostly upfront and then the data is loaded as needed.

Mike Mason:

People come into the software engineering industry every year, new people get involved and maybe haven't seen some of the older styles of building applications. Do you feel there are things that we have learnt or that people should have learnt in building client server apps, that are either being missed or being forcibly rediscovered. Now that we're building kind of these rich JavaScript powered apps.

Erik Dörnenburg:

It's not quite the same. I think they have even learned things that we couldn't do back then. One of the interesting things is of course, what we've seen on the service side, is the idea of microservices, of splitting a large scale application into individual services.

Erik Dörnenburg:

Actually we talk of, for portfolio of services rather than having these big line of business applications. I think what we're seeing today, what we didn't see in client server applications earlier, at least not to my knowledge, is the splitting of the code. We sometimes in Thoughtworks we called it micro front-ends, this idea that you can load an application, but you can... That's what I meant earlier, when I said, it's not the whole application that is loaded, that actually you can deploy individual parts of the front-end separately, and they are loaded from separate resources on the server unknown to the user but that gives you of course, the benefits of microservices in an architecture, with a rich user interface.

Erik Dörnenburg:

When it comes to other lessons learned, I think there are some underlying lessons of how you should structure data, of how much you should trust the server. How much the server should trust the client, at the same time I'm relatively happy to see that we've given up, at least I hope so. Some of these things come around, but it seems we've given up on the idea of transparent method invocations.

Erik Dörnenburg:

I think this plagued the industry for 20 years, this idea of distributed objects. And then we started this in the '90s and callback came along and Java came along and other paradigms came along and it was always saying, oh, you only need to understand object oriented programming and some magic in the middle will hide the boundary between the client and the server.

Erik Dörnenburg:

You can treat an object, whether it's local or remote in the same way. And that has cost us, I don't know how many person hours in development time in debugging time, but also inefficiencies at runtime.

Erik Dörnenburg:

The thing with the current model, this is one of the learnings, if you will, that these distributed objects don't work. There were talks in the early '90s that said this, but it took us a long time. But with the new one, we have really learned this and I think nobody's trying to do that anymore. At least again, not to my knowledge. So this is a good thing for me to see.

Mike Mason:

Well and hopefully not in a mainstream library, that has traction because I'm a hundred percent sure I've seen people still thinking that you can do, treat local objects as though they were remote and vice versa.

Erik Dörnenburg:

Yeah, I guess something that we are also seeing is different now, is that there's a realization that you cannot trust the client. I think we could never really trust the client, but nowadays it is... Despite the minimization of the JavaScript code and so on, we are shipping more or less, basically not only more or less, we're shipping the source code into the browser. Something that could be much more easily re-engineered.

Erik Dörnenburg:

And of course all the underlying communication is also in the clear and everything... The transport is secured with HTTPs hopefully, but once you're in the browser, it is in the clear. So realizing very, very strongly without too much pushing from security people that the client cannot be trusted. And we need to do not only authentication, but also validation on the server side.

Mike Mason:

And one of the things that we talked about is this notion of the application. One of the other storylines over the last 10 or 15 years has been the rise of smartphones and the App Store for those. One of the reasons that we like to ship things via the browser is that, you don't need to update an app. It's always up-to-date because you go to the web server. If things have changed, you get the latest version of the JavaScript and then you're all up to date and you can go from there.

Mike Mason:

But now we're also seeing automatic updates on people's phones and iPads and all that kind of thing. So, I can't actually remember the last time I manually updated an application, things just seem to... I've got WiFi or good cell connectivity, everything just kind of auto updates.

Mike Mason:

Is there a pendulum-ing back and forth that we see here? Are there cases for continuing to have rich client native applications?

Erik Dörnenburg:

I think the case can certainly be made on the mobile phones because... I don't have scientific evidence, I will admit that, but I'm reasonably sure that running a JavaScript application on a mobile phone is not as energy efficient as running something that is written natively in Swift or potentially also written in Kotlin running on Android. I think what we're seeing here is a trade off that is made for the user, for the increased life of the phone as in like the battery life. The battery lasts longer on a single charge, when using applications. That is what I'm relatively certain about.

Erik Dörnenburg:

I completely agree with you that the distribution problem is being solved. We've seen this in other areas, where you really could not deal with web based application. Although we might come back to that again too, is video gaming and we saw a big distribution, I don't know, I don't like the word war, but there's a big distribution discussion happening between a couple of platforms that are solely there to distribute bits and bytes to the computers of people want to play video games.

Erik Dörnenburg:

You mentioned the App Stores, we're certainly seeing that also on the mainstream operating systems. If you look at the Windows applications, we have an App Store now and on the Mac OS of course you have an App Store. So, it is the barrier to updating applications and software has been lowered.

Erik Dörnenburg:

This could be the herald of a renaissance of native applications, at the same time we shouldn't forget that we are... Because there's so many people in the market who know JavaScript and there’s such rich tooling now, that choose to write JavaScript even when they don't have to, for example, when we look at the Spotify application on Mac OS and Windows, the same holds true for Tidal and a number of other systems, they are actually JavaScript applications that run as far as I know on top of Electron. So we're seeing here, is if these applications are being distributed, we are distributing a web based application in the end, anywhere.

Mike Mason:

Erik it's interesting, you mentioned video gaming, because one of our colleagues sent me a note asking about a WebAssembly, which is a new specification, for running native code in the browser. And he actually sent me a website that runs the Doom 3 video game engine in the browser. So I cranked it open on my laptop, just a random Mac laptop, and it's Doom 3 video game running at 60 frames a second, no problem, that's all built on WebAssembly. Does that show some promise? And of course that's very much code running in the browser.

Erik Dörnenburg:

Yeah. It's funny that if you mentioned it, this is exactly what I had in mind with the previous remark. I think it does show some promise. I think the verdict is out. Personally, I've not been a great fan of JavaScript. I do not think it is one of the most refined programming languages out there.

Erik Dörnenburg:

I think even if you look at the people who designed JavaScript, they will be quite open in saying, it was a bit of a rush job and there are certain things that I would have preferred to do differently had they had more time. If they hadn't been building a platform that got widespread use so quickly, and then having to worry about breaking applications in the early web days.

Erik Dörnenburg:

I think this is probably true for many, many people. When we're writing applications running in the web browser in JavaScript, we're not writing it because we love JavaScript. We're not flocking there because we think this is the most productive programming language, we're doing it because it is the given programming language in an environment that has proven to be super successful.

Erik Dörnenburg:

The execution environment of the web browser is capable as a runtime now, is very simple and very streamlined distribution process, this is why we're doing it. We have learned a lot of lessons in writing software that are now being transferred into the world of JavaScript.

Erik Dörnenburg:

It was interesting to see, I guess we all three know this, that Martin Fowler when he wrote the second edition of the Refactoring book, he chose JavaScript just to say, these technologies all apply to JavaScript equally. There is no distinction, really. There shouldn't be a distinction between something that is running in the web browser and something that's running on the server.

Erik Dörnenburg:

This is all valuable software. These are business critical, or these are valuable applications. So, yet we are choosing JavaScript or we are using JavaScript because it is the language of the browser. WebAssembly now has the potential to open up the web browser as an execution platform for different programming languages, for a multitude of different programming languages.

Erik Dörnenburg:

I'm super curious to see how this will pan out. I already mentioned that nowadays, sometimes when teams have the choice of different programming languages, like the team writing the Spotify application for Mac iOS and Windows, they could have chosen something different and yet they chose JavaScript. Maybe there's such momentum, there's such knowledge, they're such a richness of frameworks that people will continue to use JavaScript for the foreseeable future, but maybe also for certain areas, people will choose a different programming language, when the programming language matters, when it provides them a competitive advantage.

Erik Dörnenburg:

It's going to be interesting to see which programming language that will be. I think there are certain languages which are better suited than others. And one thing that I'm personally quite interested in, is Rust the programming language and Rust already... Because it can compile natively it uses the same tool chain as Swift and C and C++, it compiles natively, and it can be used with WebAssembly.

Erik Dörnenburg:

I can certainly see a class of applications, where it does make sense to use a programming language like Rust to write applications and really treat the web browser as the distribution platform. But as I said, the verdict is really out, we'll see how much momentum that'll gain and how long it will take.

Mike Mason:

Great. I think we'll call it there. Thank you very much, Erik and Rebecca for being on the podcast with me today, I hope everybody you enjoyed listening and do tune into our next episode.