Let’s leave the networking aspect aside for a moment.

When a language is compiled, the source files go through a pipeline of parser -> preprocessor -> compiler -> assembler -> linker, to end up with an executable. With interpreted languages, the source code is instantly executed line by line by an interpreter software. With JIT languages, the program gets compiled and optimized into portable bytecode, which is run by the language’s runtime.

If I had to guess, web pages (i.e. HTML/CSS/JS) are most likely run by an interpreter that is a web browser, but isn’t that inefficient given that most of what people do on computers is browsing the web? What about browsers, what standard is there that specifies how each language should be run/rendered? What pipeline does a webpage go through to end up as a process in a computer?

  • cecilkorik@lemmy.ca
    link
    fedilink
    English
    arrow-up
    1
    ·
    7 days ago

    You are conflating a bunch of different things here and it’s hard to tell exactly what you’re even asking. HTML is completely separate from Javascript and CSS. Together, they are web technologies and typically all three are used to display a webpage, but only HTML is actually required. The others provide additional functions, each in their own way.

    More to your point. HTML is not a programming language. It is not turing-complete. It is a markup language. It does not get “compiled”, it gets “rendered”. This may seem like a semantic difference, but these are actually different things and they are handled differently by code and in fact by completely different engines within the code. HTML rendering engines are still very complex beasts, and while you can draw some similarities with a compiler, they are not the same thing.

    Most web standards are defined by the W3C, that includes HTML and CSS. But there are many different standards, even ones defined by the W3C, and many versions of those standards as well. All of these are handled by the browser’s rendering engine. However, there’s also a lot of bad code in the world that still needs to be rendered correctly, and you might be surprised how recently some of these standards actually developed. The browser wars have flared up many times and each time “standards” were usually the casualty. Mozilla has this brief explainer of the three different “quirks” modes currently used for compatibility on the modern web.

    Javascript engines are their own whole different ballgame, as Javascript/ECMAscript is indeed a turing complete programming lanaguage, and all the big players (V8, Spidermonkey/Warpmonkey) are highly sophisticated JIT compilers with multiple layers of on-the-fly optimization. The deeper technical details are frankly beyond me.

    Modern web browsers are as complex, feature-rich environments as any traditional operating system, and they have as many different aspects to them as any complete operating system does. They are not “one engine” or “one compiler” or “one standard” as much as they are an ecosystem of engines, compilers, standards, protocols and libraries all working together while remaining compatible with each other and all the other software that is out there, to ultimately present the user with a coherent, consistent and accessible representation that hides most of the immense complexity of what is going on behind the scenes.

  • brucethemoose@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    7 days ago

    Seems like your really pondering “HTML should be conspicuously slow for such a widely-used standard,” right?

    The answer is that modern browsers are complex and highly optimized rendering engines.

    Read back through this blog: https://mozillagfx.wordpress.com/

    But in a nutshell, there’s a lot of talk about how modern browser are analogous to tuned game engines, heavily relying on the GPU and all sorts of hacks to render HTML efficiently. “Compiler” doesn’t even begin to do them justice, and modern GPUs are a core part of getting a good browsing experience.

    V8 is another good example, taking what was a notoriously slow language (JavaScript) and hacking out a fast JIT engine for it.

    The “standard” is ostensibly the HTML spec and such, but in reality whatever Chrome (and Firefox/Safari) renders is the standard. Devs build around their strengths and quirks, basically, instead of the other way around.

    • grue@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      6 days ago

      The “standard” is ostensibly the HTML spec and such, but in reality whatever Chrome (and Firefox/Safari) renders is the standard.

      This is why it’s vitally important to use FIrefox rather than any Chromium-based browser (even ostensibly “degoogled” ones), BTW: we need a robust diversity of browser engines to prevent Google from having hegemony over web standards.

  • Admiral Patrick@dubvee.org
    link
    fedilink
    English
    arrow-up
    0
    ·
    7 days ago

    HTML is, as the expanded name implies, a markup language.

    It’s just a text document that, based on the markup around the sections of text, gets rendered according to the rules assigned to the markup tags. It’s quite similar to a Word doc.

    Javascript is interpreted and JIT-compiled by the Javascript engine. Works similarly to other interpreted languages (Python, BASIC, VBScript, etc)

    CSS…I’m less clear on but am guessing it’s somewhere between markup and interpreted.

    Pipeline is HTML -> CSS -> Javascript. JS can then go back and alter the previous two.

    • False@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      7 days ago

      Word docs are actually html under the hood. .docx is just an archive containing all the relevant files iirc

      • schnurrito@discuss.tchncs.de
        link
        fedilink
        arrow-up
        1
        ·
        7 days ago

        It’s true that docx (also other Office Open XML and OpenDocument file types) is a zip file containing the files that make up the document, but those files have little in common with HTML, they are their own XML schemas.