Advanced Ideas

[00:00:00]
>> Maximiliano Firtman: So, the final section, it's just some ideas, some other patterns that I wanna just throw here that cannot be categorized on the previous one. First, when we are talking about design patterns for web apps, there are a lot of classic patterns that probably you know, but you didn't recognize initially as design patterns.

[00:00:25]
For example, progressive web apps. Progressive web app creation or design or development is actually a design pattern. We don't have an API with the name progressive web app, it's not really a type of HTML. So what it is, it's just a design pattern. It's more an architectural design pattern, but it's a design pattern when you wanna create installable offline capable apps using web technologies.

[00:00:53]
Responsive web design is another design pattern. When you use those terms, and you realize there is no API behind that. Yeah, responsibly using media queries, yeah, it's using, but that using is part of the solution of the design pattern. There was a problem, this design pattern is offering you a solution.

[00:01:14]
Then these are design patterns, mobile first is another classic design pattern for web apps. The idea was, when you start a new project, start thinking about the mobile device first, and then you move it into the desktop offline first. Just think your app for offline usage. So think that the user will never have connection.

[00:01:40]
Of course, at least you will need connection once to actually get your app once. But try to think about your app as if we'll never get connection in the future. Okay, so well in the progressive web app, course, of course, another link to another course, we cover some of those design patterns in more details.

[00:02:05]
Progressive enhancement is another design pattern that we have already used here. In fact, the P in PWAs is coming from progressive enhancement. Not every platform supports all the APIs that we want to use. So instead of just using it or giving the user an error message, I'm sorry, you cannot use my app, your browser is not compatible.

[00:02:27]
That was in the 90s, we were saying this, a message. Now you need Netscape to access my website if not, it's not gonna work. Instead of that, the solution is start by offering A web solution that works everywhere that you can run even on IE4. And then maybe not IE4, but IE12 maybe.

[00:02:49]
And then you add layers on top. It's like if view transitions API is available, okay, we use view transitions. If web Bluetooth is available, we use web Bluetooth. But you don't give them an error message if the API is not there. Yeah, that ability might not be there, but that's all.

[00:03:10]
Use cases, access hardware and platform APIs offline support because maybe you don't have service worker support, accessibility as well, okay? I think I have two or three more quick design patterns to show you in case you wanna get deeper later. HTML streaming, this sounds interesting. So on large pages the browser doesn't render or even parse the page until all the response was sent and downloaded, which leads to a performance issue.

[00:03:47]
And by the way, performance is a large, huge topic. There are a couple of workshops at Frontend Masters just to talk about performance, and there are a lot of design patterns also that are targeting performance. So, In this case, there is a new API known as the Stream API.

[00:04:04]
So you can use the Streams API with Service Workers, and you will be rendering HTML in chunks. So you will be receiving chunks of bytes with the HTML. So the server will actually send you partial HTML responses over the same HTTP connection. Using service workers on the Streams API, you will receive them and you will pass them to the browser, to the main window context so it can start rendering part by part.

[00:04:37]
Okay, make sense? Use case is to improve performance on the initial page load, that's the idea. Also, you can render the data above the fold initially. Do you know what above the fold means? Have you heard about that? Well, I can do this, so this is a newspaper.

[00:04:57]
So think about newspaper, all classic printed newspaper, well that newspapers were actually really large so they were folded. So, of course, if you pay for an ad it's more expensive if it's above the fold not below the fold. And we are actually using the same terms from above the fold and below the fold on the web that has to do that, it's actually about the first scroll.

[00:05:24]
We don't have fold levels, but we are not talking about fold level devices like a Galaxy Fold, it's just that for performance. The idea is that let's download the HTML first for the above default for what you actually are seeing without scrolling. And after that, we render the rest using just one HTTP request, but using Streams, that's the idea.

[00:05:49]
Okay this is how it looks like. Without streaming, it has to wait for the full response before actually parsing that. But now the one from the bottom, as soon as some markup arrives in chunks, you will start parsing and rendering the chunk, okay? It's just that, so then you can render content on the screen faster.

[00:06:14]
>> Speaker 2: So it's like infinite scrolling.
>> Maximiliano Firtman: For infinite scrolling, you can use that pattern. The problem with infinite scrolling is that it's infinite and you cannot for that. It's probably better to use web sockets or other technique, because in this case, we're still we're still using HTTP response, so it's a server sending a response chunks.

[00:06:38]
The problem with infinite scrolling is that you need to wait for the user to. Scroll, and you don't want to keep the HTTP connection open waiting for users the users to scroll. So maybe WebSocket is a better implementation for that problem. Virtual DOM, if you have ever played with React, you probably have heard about the Virtual DOM, what's the idea?

[00:07:01]
Working with the DOM directly is expensive, for example, on an infinite scroll. That's one of the most used examples of why you need this design pattern. So working with the DOM is expensive from a rendering point of view. So the solution is to create a Virtual DOM in memory.

[00:07:21]
So you add elements or remove elements in memory, not in the real DOM. And every once in a while, when you when it's a good time for it. And there are different techniques to actually decide when it's a good time. You go and synchronize your virtual DOM with the real DOM, but you touch.

[00:07:40]
To the real DOM once, not a lot of times, that's kind of the idea. This is for complex user interfaces with lot of elements or large list with re-order and operations that you create, you add, you move, okay? You can use the idea of a virtual DOM.