When I visited the GitHub forum recently, I found a very interesting topic:
Make JavaScript Files a Valid Entry Point to a Web Page
This means that the JavaScript file is used as a valid web entry (instead of an html file). The topic address is here:
https://github.com/w3c/webcomponents/issues/807
This topic aroused my interest, because I have always felt that it is troublesome to use html files as the only entry for web pages. After the separation of front and back ends, fewer people write pure static html. After the rise of front-end frameworks, almost all web pages and applications All are operated by JavaScript. We open the official website https://element.eleme.cn/ developed with Vue and check the source code to get such a common phenomenon:
Almost only one line of code on the entire web page is meaningful:
<div id="app"></div>The rest is all JS. This phenomenon gradually makes us question whether the HTML markup language still exists.
The meaning of markup language
The development of technology is bottom-up, and the order in which new technologies appear is often the opposite of the subconscious (in the eyes of posterity). We all know that JavaScript is the main tool used for front-end computing, and html is a complement to JavaScript, used to more intuitively express the positional relationship of UI elements. This is the real master-slave relationship between js and html. In the same way, in Qt, the qml markup language is a supplement to C++.
However, the fact is that there was HTML on the front end and then JavaScript. Qml was born after C++, mainly because C++ itself is not for UI.
The reversal of the birth order of JS and html has led to a legacy of browser problems: web pages can only be rendered from html, and js must be embedded in html. It can only be said that HTML is really useless, but markup language (or description language) still has an unshakable status.
Note that the native html language mentioned here does not include other markup languages that look a lot like html, such as mvvm markup language and template engine used in front-end scaffolding. Some special syntax in these markup languages such as double curly braces { {}} , php tag <?php ?>, GraphQL style qml , and JS template string `${ }` These are all to solve specific problems An extension to the general JavaScript language. Of course, even without these markup languages, general-purpose programming languages can achieve the goal, but with markup languages, the efficiency is improved by a level.
Instant rendering
Going back to the original question, HTML markup language currently has a trend of being isolated, but it does not mean that HTML will be eliminated. HTML at least supports instant rendering. Instant rendering is a big advantage of markup languages, because markup languages can be split into streams for transmission: Although there are grammatical constraints on closed tags in html, browsers can still accept html streams while rendering UI. When html files are large At the time, this kind of network latency reduction is irreplaceable by JavaScript. The ndJSON markup language introduced in the previous issue can also be parsed and transmitted at the same time. This is why the basic html is often loaded when visiting Gmail in China:
If the internet speed is slow, click "Load basic HTML" to enjoy streaming rendering in advance.
Is it feasible to use JS as a web portal?
The above still does not explain why the entry of the web page must be html. The question now is whether it is possible to support opening the web page directly from JS in the future. This question is the issue author who "arrogantly" questioned the w3c standard under the w3c/webcomponents GitHub repository Lonniebiz, from the description of the problem, it can be seen that he is still a perfectionist. He has repeatedly emphasized that the use of text/html as a web page entry is a fatal flaw in the web standard library, but he can't give a suitable argument, purely from an aesthetic point of view. The w3c committee was asked to make amendments to the standard library, which resulted in unanimous complaints from netizens:
At the same time, the little friends watching the show, including the solution I gave him, basically use the <script> tag to wrap the JavaScript code and then use text/html as the mime type to pass it to the browser as the entrance, like the following:
<!DOCTYPE html><meta charset="utf-8"><script>
addEventListener('DOMContentLoaded', function () {
document.title = 'Hello index.js'; document.head.appendChild( document.createElement('style') ).textContent = ` html {
font-family: sans-serif; font-size: 16px; text-align: center; } `; document.body.appendChild( document.createTextNode('Hello body') );}, {once: true})
</script>This method is already very common, and everyone is using it and there is no opinion, but the moderator Lonniebiz just thinks it is a hack and sneers. After reading dozens of long comments, I finally couldn't bear it. I gave him a "final" solution, hoping to end this meaningless debate:
I also hate the ugly syntax of html, but the responsibility of the browser is to browse media resources of different mime types, not just web pages (text/html)! The browser can also display pictures, audio and video, pdf, plain text, etc. So for text/JavaScript resources, the browser will display the plain text content in js read-only mode (although there is no practical use), but it will not, cannot and should not execute this js file. There are three "nos" here, let me explain:
"No": This is a fact, the browser will not directly parse text/JavaScript
"Not possible": media resources such as text/JavaScript will not trigger the loading of virtual machines and standard libraries
"Should not": Some people really want to browse the content of the js file in the browser without executing
Logically, a webpage also belongs to a kind of media, and it is treated equally with other media types. The mime type of a webpage is text/html, nothing else. So only text/html will allow the browser to load the v8 virtual machine serving web pages and the DOM standard library.
Maybe one morning in the future, the web page will have a second mime called webpage/javascript or webpage/wasm! By that day, the dream of rendering pages directly from JS or WebAssembly has been realized.
(Finish)