Second guessing the single-page-app pattern
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Brehault, Eric
SPA is about providing an entire app by exposing a single physical web page containing an enormous javascript bundle. It breaks the original web paradigm in many ways. Surprisingly enough, we invest a lot of efforts to mimic the regular web behaviour. Isn’t time for modern frontend to reconsider the SPA approach?
 Hey everybody, I'm here with Eric who is going to give us an interesting presentation about some front-end stuff and the single-page application. So Eric, take it away. Thank you Andy. Okay, well, I need to be honest, I feel sad. I really feel sad because of these COVID-19 things, this situation. We can see each other like we do every year and it's really a problem. And I mean, I saw on a very reliable social network that it was mentioned that the other conference last year was probably the first COVID cluster in Europe. Yeah, I think it was on Facebook. So yeah, definitely something true. And yeah, so it's probably the right that we keep it low profile this year I guess. But still yeah, it's super sad. And so that's sad, but on the other hand, I was also thinking about what it means for being a conference speaker in this situation. And actually, as a conference speaker, it's maybe a fantastic opportunity to do stupid things that we could not do if we were not at home, right? So here is my personal take on that. So bear with me. Here is my thing. I think that sharing your screen when you are remote speaker like this, it's super boring because you get the slide taking all the space on the screen of people being at home. They are probably sitting in there so far or something. So they will feel bored really rapidly. They just see my slides. And I don't want that, right? And actually, the human brain is specifically trained to focus on human faces obviously. They are not trained to focus on slides. I mean, if we get to a point where people, brains are actually trained to focus on slide versus on faces, I mean, that would be a totally different civilization. And I don't see where they are. So I was thinking about how I could show my slide without losing my ability to show myself, right? So my idea was I could be the screen. I could video project my slide on myself, on my belly, right? So I do have a video projector and I try that. Actually, it does not work because my belly is not flat. It's tragic, but sadly, it's true. So my second idea was maybe I could take a board like this, right? I take a board and it's a perfect screen. It's made of wood. It's easy to handle. Perm is actually too bright. And I mean, if the board of wood is brighter than me, it's a bit insolent. So I was kind of stuck and I was thinking what kind of superpower does it get to be able to let people enjoy my ugly face and enjoy my slide at the same time? And as I was thinking about superpowers, I was thinking about no superpowers. You don't need superpowers. Think about Batman. Batman is super hero, but he has no superpower. He just has his mental strength and the dark suit. Then if I think about me, I do have mental strength as well. I just don't have a dark suit. Look at that. Origin. So I went to my dressing and I was looking for the darkest suit I could get. And look what I found. Yeah, a plant conference teacher. That's super dark. So here, look, I can show my slides. Yeah. So maybe you cannot read it super nicely, but don't worry. My slides are not super interesting anyway. So after all these nonsense, let's go with the actual presentation. Second guessing, the single-page app pattern. First of all, about me, I'm a developer. I used to be a Python developer. I'm not a front-end developer focusing mainly on TypeScript and Angular at the moment. And I'm currently working at Ona. So Ona is building what we name a knowledge integration platform. So the idea basically is that any person on any company has tons of information spread in many, many different locations like Slack, Google Drive, or Dropbox, or emails, or whatever. And what we do at Ona is we collect all of that. We sync them all, index everything, and then you can explore all your fragmented knowledge from a single entry point. So that's just syncing of it like what Google does for the public internet, what it does that with your own data. And we are a startup. We are based in New York, in Barcelona, in Raeli, San Francisco, London, and Toulouse. Where I am. I'm in France. So yeah, that's who we are. So about this talk. I started thinking about this talk when after reading a very nice blog post from Tom McRite. So Tom McRite is a quite famous developer. And it was, so I will not detail, right? This blog post, you can read it. You can find it easily. But it was actually discussing the relevance of what we named the modern web. And by modern web, most part of time, we mean single page application. So known as SPA. The question is, is single page application a good solution? But before that, let's start with etymology. Because my teacher always told me, you start with a definition from the dictionary, you start with etymology, and then you can start thinking about the actual topic. Okay, good. So shall we say SPA or SPA? Or we should say SPA for single page application, if you pronounce it like SPA, well, that's not the same thing. SPA, interestingly SPA, so it's like a base, it's taking etymology from the SPA city in Belgium. That's why I'm mentioning it because we are actually having this conference virtually in Belgium. And the SPA city take his name from Latin, which is Spaghet, which means scatter or sprinkle. And that's a bit ironic when you think about what SPA are actually. Because what they are? Well, the SPA approach is basically about exposing a single physical web page, so a single HTML page, index.html, containing an enormous GS bundle. That's what it is. And this enormous GS bundle might potentially be divided into smaller sub bundles if we want, but basically it will implement the entire application. And well, along the way, it will make requests to one or several back end in order to get data and will render it locally. That's what SPA are. And if you think about, well, Volto, for example, is a typical SPA, right? So the question is, why are we doing that? Well, I guess we started doing this SPA thing because loading a new page every time we interact with the page. Like every time the user is going to click on a link, we were asking to the server a new HTML page and getting back and rendering. And it was considered slow. Well, I'm not sure the slow aspect of it is a real problem. Because nowadays, is regular web slow? Is internet slow? Think about it. Google is making this Google Stadia thing where it's about streaming server side rendered video games. So if we can render a video game on the back end and play it on the front end, we do have some bandwidth, right? So I'm not sure the SPA thing is about reducing the slowness. It's not that. And anyway, if you consider people having low rate connections, well, I'm not sure SPA is making anything better for them. So it's not about the rapidity of the performance. Performance is not the problem. The problem is the stateless aspect of the regular web model. When you go to click on a link, you get an entire page, you render it, and it's stateless. Every time you get something totally new, you can start from there. There is no history, et cetera. What we want is, well, cleaner interaction. We want the user to feel like he's facing a standalone application, even though it's implemented through web components, web elements, and web technology. So we want something very dynamic, not a sequence of web pages. OK. And well, that's what we can achieve with JavaScript, right? With frontend. And implementing this kind of complex system with frontend is, yes, probably easier and we're, let's say, organized on a better way if you do that through an SPA. That means putting all the code together, making an application per se, to implement this kind of nice behavior of the UI. Because what were we doing before that? We were actually putting some chunk of JavaScript in server-side render page, like we used to do with Plan 4, for example, if we go back there. And that's not efficient. And we discovered that putting GSA everywhere like this is not a rational way to implement the GS server-side application, right? So SPA to this regard makes a lot of sense. But the problem is we are inverting the original web model. OK. The original web model is about having an application, well, the browser, right? The web browser rendering pages, which are the content. And with SPA, we are doing the opposite, right? We are using a page to render an app instead of the opposite. So yeah, inverting the model. And what's kind of surprising is we are investing a lot of effort to mimic the regular web behavior. It's mean. So we break it and we spend a lot of time making sure that while the user feel like he's navigating through pages, we make sure the address in the URL bar is updated. We make sure that he can navigate back and forth. We make sure that the user can share a page even though it's not an actual page. OK. And we make sure, of course, that SEO is working fine, that social network is getting the proper meta, and so on. A lot of things just to mimic the default behavior of a web page. So that's, well, a typical love-ate relationship here. On one hand, we are aware that the original web model is very valuable, and we try to preserve all its benefits. But on the other hand, we are just ignoring its main principle. And while when you twist the model, there are consequences. I will not go into technical detail about those consequences, but we all know the least of them. The rendering is slow, SEO support is super painful, GS building is expensive. I mean, yeah. A lot of trouble just for that. Fortunately, we are ingenious, right? So we know that every problem has a solution. Here we go with the solution. To mitigate the problem, we have created a gigantic technical stack. And what it does? Okay, it does work in some cases, but it also creates other bad consequences. That is always the case in this kind of situation. We are in a typical case of complexity denial, where tools don't seem complex to the person who builds them. The new tool creates new problems we didn't have before, and all those tools might work together, might work well in isolation, but they don't necessarily work well together. And that's where we are. And so to come back to the article I was mentioning initially, I'm cutting Tom Mack right here. He said, Fremont should lure people into the pit of success, where following the normal rules and using normal techniques should be the winning approach. I don't think that react in this context really is that pit of success. The naively implemented react SPA isn't stable or efficient, and it does not naturally scale to significant complexity. And of course, so the react part here is not mine. I could say exactly the same thing about Angular, which I love, but exactly the same problem here. SPA not stable, not efficient. So we are in a situation where the modern web is improving a lot the user experience. Like, I mean, we could not create something like Google Docs, for example, to with server-side only technology, right? I'm currently using Google Doc to run this presentation. I made my slides and so on. Yes, this would not be possible with server-side only. And sometimes I think, do I miss Python? Do I miss the old time? Well, I do miss the time where I had all the information I need in a single HTTP request, and then I just had to make what I take to return a proper response. The thing is this paradigm is over. This is what was called the Web 2.0. So that's 15 years ago, right? How modern is that? I'm not sure. Well, since this time, web is not about putting hypertext online anymore. But it's still about content. So one of the reasons for having SPA is separation of concept. It's a good principle, of course. So yeah, we try to separate the presentation layer from the persistence layer, security layers, etc. That's what SPA tried to achieve. Yeah, good, good. But there are other layers. In our typical SPAs, we are mixing together two different layers. What I would call the browser layer, which is providing the ability to access remote content, to navigate from one to another. And what I would call the content view layer, which is about the content itself. So maybe the text, of course, but the inner layout, the inner logic of the current page. With the original web model, we kept those two layers very separated. And as a result, I can add a new page to my site without recompiling Firefox. And I can recompile Firefox without regenerating the entire Internet. That's the same thing, right? The opposite would be total madness. While by implementing a part of the browser layer in the page, SPA is getting to this kind of madness. So, we are stuck, kind of, because modern web, SPA does bring powerful enhancements, but the way we are implementing it is not the same. It's a typical take, take it or leave it situation. So I'm wondering, what do we want? Well, what we want is proportionate complexity. It should not be SPA or nothing. And to be fair, it's actually not. The old web, let's call it that way, is still around 80% of websites use this PHP. 77% use JQuery. And these numbers are actually increasing. Why is that? Well, they are increasing because a number of websites are increasing and the majority of them, they don't need anything super complex like an SPA. So what are the solutions? I will mention a few technical things I have noticed recently. First, micro frontend. So you may be heard about this micro frontend concept. What is it? Well, micro frontend is actually macro web components. So Mike on Monday made a demo, a very nice demo about custom components. So you can create your own HTML component. You implement it yourself with JavaScript and you can reuse it wherever you want in a rich text editor if you want as Mike demo. Okay. That's a custom component. It's just a very small piece of UI. Like it could be a select or a checkbox, but we make it a bit different, a bit customized, but it's not like more complex than that. You will get all this information from its attributes. A micro frontend is much bigger than that. It's an entire chunk of the full application. If we talk about Plom, let's say you could have the sharing feature as a micro frontend. Okay. So this concept is interesting because a micro frontend is the part of the application that you compile and develop and maintain the part from the rest. And that's something that we can do now with Webpack 5. Webpack 5 is proposing the module federation, which allows to compile code, importing, reading, remote modules, remote modules that are not compiled within the full, the current project. They are external to the project. And to code, Zach Jackson, who is one of the authors of the module federation feature, he said, let's say each page of the website is deployed and compiled independently. Well, of course, for someone knowing about the original web, compiling pages like crazy, but I just love this approach. That's a great move. I mean, you would compile each page separately. So compiling the need, what you need in this page, it has an actual, let's say, JavaScript project and the rest would also be independent JavaScript project. And the way it works with module federation is that wherever you land on your website, so on any page, you're going to land on the page and it will become the host for the authors. So you start from there. It will load all the shell dependencies and the vendors and et cetera. And then when you navigate to other page, it will load lazy loads, the micro bundles needed for the next page, and it will plug dynamically into the host. And the host can be anything. As I said, whatever the landing page is going to be, you're going to start from there and work all compiled separately. That's a great, great thing. The other technical thing I should mention is ES6 native support. So I know we have been mentioning that already in the conference and module federation as well. I think yesterday that was, you honest ES6 native support is interesting because it allowed to import export modules, natively in JavaScript in the JavaScript natively supported by browsers, right? If you combine that with HTTP2, well, you need no bundles. I mean, you can come back to this paradigm where you have a file tree structure for your development with granular date. Like you can go and change this part of the application without bundling the full thing. You just go to your project tree. You change one GIS here and you push it just like we used to update an HTML and push it to the server or update a PHP file, why not? And push it to the server. That's a big win as well. Because I mean, honestly, bundling is the most brutal thing ever. It's awful. I mean, it's terrible. And we need to get rid of that. And my personal point of view is we should make sure we respect the layers. The layers I was mentioning earlier. As we just discussed, but it should be done according to the proper layers. So you should have a browser layer, which is content neutral, acting as a browser. So it offers navigation, authentication, connection to the backend, rendering machinery, and also maybe services like state management, why not? Or Apollo for GraphQL, these kind of stuff. Then you have a content layer, which could be actually very simple. Maybe it's just HTML. If it's good enough in your case, HTML is good. You could have your browser layer, which is a front-end application, taking some HTML and rendering it wherever you need. Or it could be maybe a bit more complex with JSON. So you get JSON, your content layer gets JSON, but maybe a template. And the browser layer will merge that to render the JSON with a template. So basically, it's like if you could teach your browser to render JSON content in a given context. And of course, if you have a very, very complex application, your content layer might be specific components, specific feature you want to render into a specific place, but once again, dynamically plugged into the rest. So both layers are totally independent. They are built separately. They might be based on different technology. Like nowadays we have readers or Apollo implemented in techno-neutral way. And now the question is, I am proposing a more complex solution to solve a complex solution, a complex problem we have. Not quite. Not my idea. What I mean is we should have a generic browser layer. It means as a developer, as a website developer, and as a web application developer, I would not implement the browser layer. It would be generic. It would be something which is common to many different use cases. So providing login, providing navigation, providing a UI library, providing core frameworks and utilities, that's totally generic. I don't want to implement it every time. So we don't code it. We actually we just declare it. For example, if you have dependency, you want to pip install stuff, you just add those dependencies in your file and then it's done. You do not copy, past, implement, build, etc. No. So instead of what we have currently with SPA, where whenever you add a new plugin or whatever dependency you have to plug it manually into your code and it breaks stuff and you need to rebuild everything and so on. No. Think about the plugability style we have in in clone and in Zope. I mean, plugability is key for simplicity. So what you, the way I imagine this browser layer is that we just declare stuff. I declare I want material UI. I declare I want Pasta Naga UI. I declare I want Apollo backend. I declare I want such OS mechanism. I declare that through the file, the text file and you're going to run, you're going to get the proper component wherever they are in registries or wherever. And then as a developer, I just need to focus on the content layer. And if HTML is good enough for that, well, that's done. Okay. I just render HTML. It's just not the old HTML principle where the browser itself is rendering HTML and it is getting not interactive, let's say the SPA aspect of it. SPA quality is implemented by the browser layer and I don't need to care about it. It will be done transparently for me. So the first step, if we want to achieve that, we'll be probably to implement this browser layer, a very generic one and provide it as a reusable solution. Like for example, we have open source application on the server side. CMS, for example, CMS is a tool that is a generic tool allowing to build a custom website. Well, it would be exactly the same thing. We invest time to implement this generic layer and we reuse it in many, many contexts. The second step, well, maybe the second step would be to push that to the browser itself, make a native support for this feature. It's a browser layer for a reason. It should be into the browser. And my point of view is that browser must address the modern web needs. And it's not just about running GS faster year after year. It's about providing tools and utilities that everybody needs when building a web-based application. And I think that if we are struggling today with this crazy tech stack, it's because web browser failed us as supporting complex web app. But well, I think we can fix that. So that was it. Thank you all. Here is my contact information and I will be happy to answer any question on the JITSEE room later. Thank you, Eric. That was great. I appreciate you being able to participate and to provide such an interesting talk. We only have one question in the slide here right now. And we do want to know, did you have to train for a long time in order to be able to hold up a shirt for that entire length of your talk? So that's a good question. Actually, I started with the idea of putting the T-shirt on the board to make it super flat. And it was too heavy for me. So that's why I switched to this solution, which was actually acceptable. I was not sure. I did not train the full length of the talk to make it short, but I'd say let's try it, right? Well, excellent work. And I appreciate you being able to participate, like I say. And thank you for such an interesting talk. And I encourage everyone, you included, to do the face-to-face as well. People have posted comments and other commentary in the track too, in the Slack channel. And thanks again, and enjoy the rest of your conference. Thanks.
 Hey everybody, I'm here with Eric who is going to give us an interesting presentation about  some front-end stuff and the single-page application.  So Eric, take it away.  Thank you Andy.  Okay, well, I need to be honest, I feel sad.  I really feel sad because of these COVID-19 things, this situation.  We can see each other like we do every year and it's really a problem.  And I mean, I saw on a very reliable social network that it was mentioned that the other  conference last year was probably the first COVID cluster in Europe.  Yeah, I think it was on Facebook.  So yeah, definitely something true.  And yeah, so it's probably the right that we keep it low profile this year I guess.  But still yeah, it's super sad.  And so that's sad, but on the other hand, I was also thinking about what it means for  being a conference speaker in this situation.  And actually, as a conference speaker, it's maybe a fantastic opportunity to do stupid  things that we could not do if we were not at home, right?  So here is my personal take on that.  So bear with me.  Here is my thing.  I think that sharing your screen when you are remote speaker like this, it's super boring  because you get the slide taking all the space on the screen of people being at home.  They are probably sitting in there so far or something.  So they will feel bored really rapidly.  They just see my slides.  And I don't want that, right?  And actually, the human brain is specifically trained to focus on human faces obviously.  They are not trained to focus on slides.  I mean, if we get to a point where people, brains are actually trained to focus on slide  versus on faces, I mean, that would be a totally different civilization.  And I don't see where they are.  So I was thinking about how I could show my slide without losing my ability to show myself,  right?  So my idea was I could be the screen.  I could video project my slide on myself, on my belly, right?  So I do have a video projector and I try that.  Actually, it does not work because my belly is not flat.  It's tragic, but sadly, it's true.  So my second idea was maybe I could take a board like this, right?  I take a board and it's a perfect screen.  It's made of wood.  It's easy to handle.  Perm is actually too bright.  And I mean, if the board of wood is brighter than me, it's a bit insolent.  So I was kind of stuck and I was thinking what kind of superpower does it get to be  able to let people enjoy my ugly face and enjoy my slide at the same time?  And as I was thinking about superpowers, I was thinking about no superpowers.  You don't need superpowers.  Think about Batman.  Batman is super hero, but he has no superpower.  He just has his mental strength and the dark suit.  Then if I think about me, I do have mental strength as well.  I just don't have a dark suit.  Look at that.  Origin.  So I went to my dressing and I was looking for the darkest suit I could get.  And look what I found.  Yeah, a plant conference teacher.  That's super dark.  So here, look, I can show my slides.  Yeah.  So maybe you cannot read it super nicely, but don't worry.  My slides are not super interesting anyway.  So after all these nonsense, let's go with the actual presentation.  Second guessing, the single-page app pattern.  First of all, about me, I'm a developer.  I used to be a Python developer.  I'm not a front-end developer focusing mainly on TypeScript and Angular at the moment.  And I'm currently working at Ona.  So Ona is building what we name a knowledge integration platform.  So the idea basically is that any person on any company has tons of information spread  in many, many different locations like Slack, Google Drive, or Dropbox, or emails, or whatever.  And what we do at Ona is we collect all of that.  We sync them all, index everything, and then you can explore all your fragmented knowledge  from a single entry point.  So that's just syncing of it like what Google does for the public internet, what it does  that with your own data.  And we are a startup.  We are based in New York, in Barcelona, in Raeli, San Francisco, London, and Toulouse.  Where I am.  I'm in France.  So yeah, that's who we are.  So about this talk.  I started thinking about this talk when after reading a very nice blog post from Tom McRite.  So Tom McRite is a quite famous developer.  And it was, so I will not detail, right?  This blog post, you can read it.  You can find it easily.  But it was actually discussing the relevance of what we named the modern web.  And by modern web, most part of time, we mean single page application.  So known as SPA.  The question is, is single page application a good solution?  But before that, let's start with etymology.  Because my teacher always told me, you start with a definition from the dictionary, you  start with etymology, and then you can start thinking about the actual topic.  Okay, good.  So shall we say SPA or SPA?  Or we should say SPA for single page application, if you pronounce it like SPA, well, that's  not the same thing.  SPA, interestingly SPA, so it's like a base, it's taking etymology from the SPA city in  Belgium.  That's why I'm mentioning it because we are actually having this conference virtually  in Belgium.  And the SPA city take his name from Latin, which is Spaghet, which means scatter or sprinkle.  And that's a bit ironic when you think about what SPA are actually.  Because what they are?  Well, the SPA approach is basically about exposing a single physical web page, so a single HTML  page, index.html, containing an enormous GS bundle.  That's what it is.  And this enormous GS bundle might potentially be divided into smaller sub bundles if we  want, but basically it will implement the entire application.  And well, along the way, it will make requests to one or several back end in order to get  data and will render it locally.  That's what SPA are.  And if you think about, well, Volto, for example, is a typical SPA, right?  So the question is, why are we doing that?  Well, I guess we started doing this SPA thing because loading a new page every time we interact  with the page.  Like every time the user is going to click on a link, we were asking to the server a new  HTML page and getting back and rendering.  And it was considered slow.  Well, I'm not sure the slow aspect of it is a real problem.  Because nowadays, is regular web slow?  Is internet slow?  Think about it.  Google is making this Google Stadia thing where it's about streaming server side rendered  video games.  So if we can render a video game on the back end and play it on the front end, we do have  some bandwidth, right?  So I'm not sure the SPA thing is about reducing the slowness.  It's not that.  And anyway, if you consider people having low rate connections, well, I'm not sure SPA  is making anything better for them.  So it's not about the rapidity of the performance.  Performance is not the problem.  The problem is the stateless aspect of the regular web model.  When you go to click on a link, you get an entire page, you render it, and it's stateless.  Every time you get something totally new, you can start from there.  There is no history, et cetera.  What we want is, well, cleaner interaction.  We want the user to feel like he's facing a standalone application, even though it's  implemented through web components, web elements, and web technology.  So we want something very dynamic, not a sequence of web pages.  OK.  And well, that's what we can achieve with JavaScript, right?  With frontend.  And implementing this kind of complex system with frontend is, yes, probably easier and  we're, let's say, organized on a better way if you do that through an SPA.  That means putting all the code together, making an application per se, to implement  this kind of nice behavior of the UI.  Because what were we doing before that?  We were actually putting some chunk of JavaScript in server-side render page, like we used  to do with Plan 4, for example, if we go back there.  And that's not efficient.  And we discovered that putting GSA everywhere like this is not a rational way to implement  the GS server-side application, right?  So SPA to this regard makes a lot of sense.  But the problem is we are inverting the original web model.  OK.  The original web model is about having an application, well, the browser, right?  The web browser rendering pages, which are the content.  And with SPA, we are doing the opposite, right?  We are using a page to render an app instead of the opposite.  So yeah, inverting the model.  And what's kind of surprising is we are investing a lot of effort to mimic the regular web  behavior.  It's mean.  So we break it and we spend a lot of time making sure that while the user feel like  he's navigating through pages, we make sure the address in the URL bar is updated.  We make sure that he can navigate back and forth.  We make sure that the user can share a page even though it's not an actual page.  OK.  And we make sure, of course, that SEO is working fine, that social network is getting the proper  meta, and so on.  A lot of things just to mimic the default behavior of a web page.  So that's, well, a typical love-ate relationship here.  On one hand, we are aware that the original web model is very valuable, and we try to preserve  all its benefits.  But on the other hand, we are just ignoring its main principle.  And while when you twist the model, there are consequences.  I will not go into technical detail about those consequences, but we all know the least  of them.  The rendering is slow, SEO support is super painful, GS building is expensive.  I mean, yeah.  A lot of trouble just for that.  Fortunately, we are ingenious, right?  So we know that every problem has a solution.  Here we go with the solution.  To mitigate the problem, we have created a gigantic technical stack.  And what it does?  Okay, it does work in some cases, but it also creates other bad consequences.  That is always the case in this kind of situation.  We are in a typical case of complexity denial, where tools don't seem complex to the person  who builds them.  The new tool creates new problems we didn't have before, and all those tools might work  together, might work well in isolation, but they don't necessarily work well together.  And that's where we are.  And so to come back to the article I was mentioning initially, I'm cutting Tom Mack right here.  He said, Fremont should lure people into the pit of success, where following the normal  rules and using normal techniques should be the winning approach.  I don't think that react in this context really is that pit of success.  The naively implemented react SPA isn't stable or efficient, and it does not naturally scale  to significant complexity.  And of course, so the react part here is not mine.  I could say exactly the same thing about Angular, which I love, but exactly the same problem  here.  SPA not stable, not efficient.  So we are in a situation where the modern web is improving a lot the user experience.  Like, I mean, we could not create something like Google Docs, for example, to with server-side  only technology, right?  I'm currently using Google Doc to run this presentation.  I made my slides and so on.  Yes, this would not be possible with server-side only.  And sometimes I think, do I miss Python?  Do I miss the old time?  Well, I do miss the time where I had all the information I need in a single HTTP request,  and then I just had to make what I take to return a proper response.  The thing is this paradigm is over.  This is what was called the Web 2.0.  So that's 15 years ago, right?  How modern is that?  I'm not sure.  Well, since this time, web is not about putting hypertext online anymore.  But it's still about content.  So one of the reasons for having SPA is separation of concept.  It's a good principle, of course.  So yeah, we try to separate the presentation layer from the persistence layer, security  layers, etc.  That's what SPA tried to achieve.  Yeah, good, good.  But there are other layers.  In our typical SPAs, we are mixing together two different layers.  What I would call the browser layer, which is providing the ability to access remote  content, to navigate from one to another.  And what I would call the content view layer, which is about the content itself.  So maybe the text, of course, but the inner layout, the inner logic of the current page.  With the original web model, we kept those two layers very separated.  And as a result, I can add a new page to my site without recompiling Firefox.  And I can recompile Firefox without regenerating the entire Internet.  That's the same thing, right?  The opposite would be total madness.  While by implementing a part of the browser layer in the page, SPA is getting to this  kind of madness.  So, we are stuck, kind of, because modern web, SPA does bring powerful enhancements,  but the way we are implementing it is not the same.  It's a typical take, take it or leave it situation.  So I'm wondering, what do we want?  Well, what we want is proportionate complexity.  It should not be SPA or nothing.  And to be fair, it's actually not.  The old web, let's call it that way, is still around 80% of websites use this PHP.  77% use JQuery.  And these numbers are actually increasing.  Why is that?  Well, they are increasing because a number of websites are increasing and the majority  of them, they don't need anything super complex like an SPA.  So what are the solutions?  I will mention a few technical things I have noticed recently.  First, micro frontend.  So you may be heard about this micro frontend concept.  What is it?  Well, micro frontend is actually macro web components.  So Mike on Monday made a demo, a very nice demo about custom components.  So you can create your own HTML component.  You implement it yourself with JavaScript and you can reuse it wherever you want in  a rich text editor if you want as Mike demo.  Okay.  That's a custom component.  It's just a very small piece of UI.  Like it could be a select or a checkbox, but we make it a bit different, a bit customized,  but it's not like more complex than that.  You will get all this information from its attributes.  A micro frontend is much bigger than that.  It's an entire chunk of the full application.  If we talk about Plom, let's say you could have the sharing feature as a micro frontend.  Okay.  So this concept is interesting because a micro frontend is the part of the application that  you compile and develop and maintain the part from the rest.  And that's something that we can do now with Webpack 5.  Webpack 5 is proposing the module federation, which allows to compile code, importing, reading,  remote modules, remote modules that are not compiled within the full, the current project.  They are external to the project.  And to code, Zach Jackson, who is one of the authors of the module federation feature,  he said, let's say each page of the website is deployed and compiled independently.  Well, of course, for someone knowing about the original web, compiling pages like crazy,  but I just love this approach.  That's a great move.  I mean, you would compile each page separately.  So compiling the need, what you need in this page, it has an actual, let's say, JavaScript  project and the rest would also be independent JavaScript project.  And the way it works with module federation is that wherever you land on your website,  so on any page, you're going to land on the page and it will become the host for the authors.  So you start from there.  It will load all the shell dependencies and the vendors and et cetera.  And then when you navigate to other page, it will load lazy loads, the micro bundles  needed for the next page, and it will plug dynamically into the host.  And the host can be anything.  As I said, whatever the landing page is going to be, you're going to start from there and  work all compiled separately.  That's a great, great thing.  The other technical thing I should mention is ES6 native support.  So I know we have been mentioning that already in the conference and module federation as  well.  I think yesterday that was, you honest ES6 native support is interesting because it  allowed to import export modules, natively in JavaScript in the JavaScript natively supported  by browsers, right?  If you combine that with HTTP2, well, you need no bundles.  I mean, you can come back to this paradigm where you have a file tree structure for your  development with granular date.  Like you can go and change this part of the application without bundling the full thing.  You just go to your project tree.  You change one GIS here and you push it just like we used to update an HTML and push it  to the server or update a PHP file, why not?  And push it to the server.  That's a big win as well.  Because I mean, honestly, bundling is the most brutal thing ever.  It's awful.  I mean, it's terrible.  And we need to get rid of that.  And my personal point of view is we should make sure we respect the layers.  The layers I was mentioning earlier.  As we just discussed, but it should be done according to the proper layers.  So you should have a browser layer, which is content neutral, acting as a browser.  So it offers navigation, authentication, connection to the backend, rendering machinery,  and also maybe services like state management, why not?  Or Apollo for GraphQL, these kind of stuff.  Then you have a content layer, which could be actually very simple.  Maybe it's just HTML.  If it's good enough in your case, HTML is good.  You could have your browser layer, which is a front-end application, taking some HTML  and rendering it wherever you need.  Or it could be maybe a bit more complex with JSON.  So you get JSON, your content layer gets JSON, but maybe a template.  And the browser layer will merge that to render the JSON with a template.  So basically, it's like if you could teach your browser to render JSON content in a given  context.  And of course, if you have a very, very complex application, your content layer might be specific  components, specific feature you want to render into a specific place, but once again, dynamically  plugged into the rest.  So both layers are totally independent.  They are built separately.  They might be based on different technology.  Like nowadays we have readers or Apollo implemented in techno-neutral way.  And now the question is, I am proposing a more complex solution to solve a complex solution,  a complex problem we have.  Not quite.  Not my idea.  What I mean is we should have a generic browser layer.  It means as a developer, as a website developer, and as a web application developer, I would  not implement the browser layer.  It would be generic.  It would be something which is common to many different use cases.  So providing login, providing navigation, providing a UI library, providing core frameworks  and utilities, that's totally generic.  I don't want to implement it every time.  So we don't code it.  We actually we just declare it.  For example, if you have dependency, you want to pip install stuff, you just add those  dependencies in your file and then it's done.  You do not copy, past, implement, build, etc.  No.  So instead of what we have currently with SPA, where whenever you add a new plugin or whatever  dependency you have to plug it manually into your code and it breaks stuff and you need  to rebuild everything and so on.  No.  Think about the plugability style we have in in clone and in Zope.  I mean, plugability is key for simplicity.  So what you, the way I imagine this browser layer is that we just declare stuff.  I declare I want material UI.  I declare I want Pasta Naga UI.  I declare I want Apollo backend.  I declare I want such OS mechanism.  I declare that through the file, the text file and you're going to run, you're going  to get the proper component wherever they are in registries or wherever.  And then as a developer, I just need to focus on the content layer.  And if HTML is good enough for that, well, that's done.  Okay.  I just render HTML.  It's just not the old HTML principle where the browser itself is rendering HTML and it  is getting not interactive, let's say the SPA aspect of it.  SPA quality is implemented by the browser layer and I don't need to care about it.  It will be done transparently for me.  So the first step, if we want to achieve that, we'll be probably to implement this browser  layer, a very generic one and provide it as a reusable solution.  Like for example, we have open source application on the server side.  CMS, for example, CMS is a tool that is a generic tool allowing to build a custom website.  Well, it would be exactly the same thing.  We invest time to implement this generic layer and we reuse it in many, many contexts.  The second step, well, maybe the second step would be to push that to the browser itself,  make a native support for this feature.  It's a browser layer for a reason.  It should be into the browser.  And my point of view is that browser must address the modern web needs.  And it's not just about running GS faster year after year.  It's about providing tools and utilities that everybody needs when building a web-based  application.  And I think that if we are struggling today with this crazy tech stack, it's because web  browser failed us as supporting complex web app.  But well, I think we can fix that.  So that was it.  Thank you all.  Here is my contact information and I will be happy to answer any question on the JITSEE  room later.  Thank you, Eric.  That was great.  I appreciate you being able to participate and to provide such an interesting talk.  We only have one question in the slide here right now.  And we do want to know, did you have to train for a long time in order to be able to hold  up a shirt for that entire length of your talk?  So that's a good question.  Actually, I started with the idea of putting the T-shirt on the board to make it super flat.  And it was too heavy for me.  So that's why I switched to this solution, which was actually acceptable.  I was not sure.  I did not train the full length of the talk to make it short, but I'd say let's try it,  right?  Well, excellent work.  And I appreciate you being able to participate, like I say.  And thank you for such an interesting talk.  And I encourage everyone, you included, to do the face-to-face as well.  People have posted comments and other commentary in the track too, in the Slack channel.  And thanks again, and enjoy the rest of your conference.  Thanks.
Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_0_2135.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_2136_2231.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_2232_2759.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_2760_2867.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_2868_2963.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_2964_3875.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_3876_4007.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_4008_4307.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_4308_5183.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_5184_5807.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_5808_6035.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_6036_8147.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_8148_9659.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_9660_10967.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_10968_11819.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_11820_12791.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_12792_15047.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_15048_15275.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_15276_16199.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_16200_16511.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_16512_19847.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_19848_23423.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_23424_23663.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_23664_24371.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_24372_25079.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_25080_25751.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_25752_26735.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_26736_28703.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_28704_29999.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_30000_30215.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_30216_30575.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_30576_37319.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_37320_38423.png Second_guessing_the_single-page-app_pattern_-_Eric_Pd8hUyha2sg_38424_43216.png