Martin Alvarez: This session was something we decided to do after previous early discussions. After a workshop, a small seminar, organized by W3C China with different vendors, different participants, different topics. But one interesting topic was about how to make the web more performant.

Martin Alvarez: Many different thoughts, many different ideas. But basically it was about how we can diversify, create more... attract more engines and more user agents into the web. So creating more... enriching the ecosystem of the web engines. With 2 main objectives: one, increasing the efficiency, and another one also preserving the user experience and maximizing the user experience on the web, and maximizing as well the web as a cross platform tool to create new applications. New applications, new services while preserving and maintaining this interoperability, accessibility, security, and these benefits that we have with the web. So this was the 1st discussions and the 1st ideas we have to start a new activity. We call it something like high performance baseline for engines, or something like that. But this is something that we will evolve. We will change after this session. So we wanted to have more discussions with all of you. So we want to engage web engines. Also the web views we have been discussing with Mini Apps. We saw that many apps for sure are using web views underlying. So it's something that, in some cases, we need this kind of activities as well for Mini Apps. But also we are based on the discussions we are considering as well the use cases of IoT or web of things applications. Perhaps not very popular. But perhaps if we do this, let's say we can enrich the ecosystem of IoT or web of things applications using the web. Also this could be interesting for toolsets related to the current platform development. And what we want to discuss with you is if we need newer standards, if we can create something that we discussed, and we will present you later, like standard profiles. Or we need to redefine, this is a joke, right?, a new web core.

Martin Alvarez: But just what we need to do to create a better and performant web ecosystem of web engines. So for this we will have in the agenda a couple of main topics just to explain these ideas, but the main part will be the discussion. We wanted to hear what you think. We have some different profiles here, and we want to leave room for everyone to express your opinion. But 1st I wanted to give the floor to Vic Yao to explain his thoughts about this new way to create these adaptive, as we call it, adaptive web engines.

Martin Alvarez: Vic Yao, do you want to share...

vic yao: Yeah, sure.

Martin Alvarez: your screen? Thank you.

vic yao: Okay, thank you, Martin and hello everyone. I'm Vic Yao from Tencent. I would like to share why we brought up this topic and why we need a new web engine. It all started from the web performance. But I think it's now, it's more than the performance

vic yao: It's all because the mobile Internet. Because mobile phone have become the main stage of the Internet access today. People spend most of the time on mobile phones, and nearly 90% of the mobile usage is spent within apps, not browsers. Applications have become the primary gateway to the Internet, not website anymore.

vic yao: As you can see, this is some huge change, but Web is still there. We see that the main source of the web traffic are no longer browsers. Instead, traffic comes from within apps like social media platforms, newsfeeds and shopping applications. Users aren't experiencing complete website anymore. They are interacting with some fragmented pages embedded within these applications.

vic yao: And what's even more, thanks to these applications, the structure of the Internet itself has changed. The Internet isn't really a web anymore.

vic yao: It's more like a chain of isolated islands because Apps have decided to keep users inside their ecosystem rather than allow them to jump outside.

vic yao: In summary, there is no browser and no website anymore. But let's look at the web today. Despite this massive shift in user behavior, the web itself has unfortunately remained static. Web was created 35 years ago for desktop environments. And as we move to mobile phones, we have merely made it compatible rather than truly adapting it. Consider the big difference in interacting between laptop and mobile phones. On desktops, we have mice and keyboards. We click forward and back buttons, as we're all familiar with, and we type domains and URLs. And we all get used to the wite screen waiting and suddenly appear when jumping a page. But on mobile phone, on the other hand, users expect touch screen interactions like long list scrolling, gesture control, and smooth page transitions. And web has nothing to do with it. What we have ended up with is a terrible experience on mobile phones.

vic yao: As you can see no one like to type a domain or URL on a cell phone, and you can find a forward and backward button in any apps, or at least most of apps.

vic yao: The reason why people still use mobile phones is only because web is easy to develop and is a cross-platform. But there are dozens of cross-platform frameworks that are much better than web.

vic yao: If we keep the web unchanged, we face several serious consequence. The web will get a reputation as the lowest performance and most complex technology. For example, a DIV has more than 2,000 properties and 80 methods, and CSS display has 23 options.

vic yao: There are too many features that might not be in any new browsers in the future.

vic yao: And second, as car systems, watches, or IoT, and other smart devices show up, the web might get stuck in the desktop, unable to adapt properly. And the further UI technology will become increasingly fragmented. We'll see more frameworks like React Native and Flutter emerge to bridge the gap, fragmenting the development ecosystem rather further.

vic yao: So, the foundational One web principle will become meaningless if web remains the same.

vic yao: If we all agree there is a problem, and the web needs to catch up, what shall we do? Some have suggested subsetting the web features. But I think this is a dead end. Subsetting doesn't solve the biggest issue. Like logic and rendering sets will still be fighting each other. The performance issues won't go away by just removing stuff. A smaller web still won't feel truly native on mobile, and whatever subset we create, it will just grow over time, getting us back to where we started.

vic yao: If we are punching off the web anyway, why not go all in and build a whole new engine. we can completely let go of historical baggage. And here's the main idea of the new engine and the new form of web application. First, it should be distributed as package similar to apps and MiniApps, because package are a perfect fit to mobile use cases.

vic yao: First, they can embed in apps where most traffic now exists, and second, in real time pages developer can provide small package with shorter download time. And third, this solution will support the growing Mini program ecosystem. Mini programs can be a superset based on this solution.

vic yao: And inside the package it will be mixed fast binary code with Javascript script code for better performance.

vic yao: And most importantly, it would feel natural on mobile device, both for developers and users. As for developer language, we can keep the good parts of CSS and APIs. Now this is a subset. And replace the DOM with a new component framework.

vic yao: If we are lucky enough and really achieve this goal, it can be benefit to all smart devices. Imagine a unified cross-device web engine that works everywhere. This standardized low-cost software development could spark innovation in hardware device. And I think only W3C can make this happen. We can ensure the web lives, maybe for next 35 years. That's all. Thank you.

Martin Alvarez: Thank you, Vic Yao. I will continue presenting the second part. Another vision also discussed during this seminar I presented at the beginning. Also some early discussions about modularity. Perhaps it's complementary with what Vic Yao mentioned. But this is another approach we wanted to discuss with all of you.

Martin Alvarez: Another topic we discussed for making this diverse ecosystem a more performant ecosystem of engines was considering a modular web, so creating profiles. Profiles based on the existing standards, so reducing the standards as they are. We know that standards are growing very big. The engines are huge. Starting a new engine from scratch, it's difficult.

Martin Alvarez: The idea we have been discussing is how we can, or if it is possible, to extract specific profiles, extracting specific modules, restricting the access to specific elements or APIs, or whatever limitation we we might have for creating a new engine, specifically for one purpose. It could be the example of Mini Apps. We have seen that the Mini Apps basically use a subset of CSS. Also a subset of HTML. But perhaps could be also interesting for some other profiles, specific scenarios. Like, as I mentioned before, it could be IoT small application for IoT sensors or actuators, something that could be relevant for existing use cases. But perhaps as well, and this is something that I wanted to raise this question. Well, I will raise it later. This could be interesting for new engines, to start a new engine from scratch, and to enable a better planning and strategy. Creating or build a specific engine based on profiles, and making this bigger with the time. So a kind of incremental approach. We have been following some use cases. For instance, in the Mini Apps working group and Community Group, we faced one challenge, which is that most of the Mini Apps we have been exploring, all of them are using subsets of CSS3. And they also include a few additionals, some new properties. But it's really small. Basically, we can say that this is a subset. Scripting is totally based on Javascript. Some limited execution for security. The markup, this is a huge challenge we have, because it's a kind of HTML. So all of them are using a domain specific language based on some kind of HTML. The elements, as you will see in the next slide, some similar to HTML, but it's not the same, but the functions or the purpose is more or less the same. And the APIs are different, but with a similar functionality of the web API. So our question in this Mini Apps Working Group is if we can rely on the existing standards to provide this or to create a newer standard for Mini Apps in terms of APIs, elements, the markup elements, and also the CSS.

Martin Alvarez: We did an early analysis gap analysis of the standard with some of the top Mini Apps implementations, and we have seen that in terms of the, for instance, the APIs, most of the Mini apps are using similar APIs as the web Apis. With similar purposes. The syntax is different but the purpose can be more or less the same.

Martin Alvarez: The conclusion is that with the standards, the system standards, we can solve the requirements for most of the Mini Apps. But also with the markup, the templates, or the templating elements and the markup elements, to use the Mini Apps, we have seen that most of the differences are basically styling, or some new functions added to the elements that we don't have in the standard as a standard solution. But somehow we can use the standards to solve the needs of a Mini App. So this could be seen as a kind of subset of the existing HTML elements, plus some modifications or some additional activities, we should do in terms of standardization. But in this case it's a kind of profile.

Martin Alvarez: We have been observing as well some successful use cases, the top one is EPUB. We all know that it's a successful case. It's a very simple reduced case of what we would need to implement to support EPUBs. Simple way to represent the HTML. Very limited. It might be run in limited resources devices. And basically, this is also a profile of the web standards. Some others we have been observing, I won't go into the details, but just to mention some of the existing profiles already there, and some failed profiles in the past. Most of them focus on media and how we can create profiles to distribute web applications across consumer electronics. In this case, TV sets and similar world to see media content

Martin Alvarez: Also exploring some of the past activities or existing activities like AMP from Google, that is also a kind of profile with some additional custom elements and some advanced components, but for a specific purpose.

Martin Alvarez: More or less something that we are wanting to achieve. And also mentioning that Baidu also have the MIP. It's the acronym of Mobile Instant Pages. They they do something similar. So it's for a specific purpose. And they are defining a specific profile of the web standards with some additional things.

Martin Alvarez: And this is the basically the part we wanted to introduce in the previous discussions. So far we haven't decided anything, Vic Yao and myself. We have been pushing, writing some comments in this new or already created community group. But this is something that we are still deciding, and we wanted to hear all of you. We are considering changing the name to make something more related to the topic, which is adaptive web engines. And we are looking for more use cases. So someone that needs more efficient engines also.

Martin Alvarez: As I mentioned, it could be this interesting for new engines, for creating new engines from scratch, like it would be great to understand what is the approach from Ladybird or Servo to start a new engine from scratch? What is the challenge? Because I suppose you won't implement everything from scratch, you have to go incrementally and in a modular way, right? So if this could be helpful for you.

Martin Alvarez: and something that we all want to preserve is the principles of the web. So making this as part of the full potentiality of the web, so it will contribute to the full potential of the web. Also considering if we are fragmented, the web. This is something that we take into account, making the most of the existing web, and contributing to the web instead of breaking the web. So this is all from our presentation. It's a 25 min passed time, so I will stop the recording.