why don't we have a compiled version of css and html?
The development speed wouldn't be any better. it might take a bit longer to setup, but the result is gonna be really good.
- less memory needed.
- no parsing which means faster runtime.
and if it's well optimized for the size it's gonna be even better. because of the lower latency.
one drawback I see :
- the browser would take some time to generate the equivalent css if you wanna check the dev tools. which means also browser extensions should wait until the browser generates the pars-able strings.
I don't know if casual users and developers could sacrifice this for the speed.
8 Replies
html is markup. browsers would have to parse it regardless, "compiling" wouldn't be any faster unless you change how browsers work, and even then you'd have to compile for each browser separately
1) yes html is a markup and markup is a string that gets parsed and then what?
machines don't understand strings that markup has to be transformed into bytes sooner or later.
so browsers don't have to parse it if it was binary, they would just give it to the VM to run it.
2) of course you need a different browser to be able to get that IR and figure out what it is and how to run it. if the browser thinks it's a string, then it's obviously not gonna work.
3) actually you don't need to compile for each browser, since each browser is compiled for a certain platform, and that's enough, you just have to have a VM and the binary that the browser will receive is going to be an IR(intermediate representation) look up LLVM IR.
JS is already running in a VM, or else it wouldn't be cross platform. it's the same idea. not as fast as native X86 or ARM (machine specific) binary. but it'll be way faster than the current "setup".
WASM is already faster than JS, just because the browser has to parse that string and then generate IR of instructions and then optimise it and then pass it to the VM which will translate that IR to machine specific bytes.
some say that wasm is like asm for web. but it's not true at all since asm is almost(almost because there is an encoding layer) a 1:1 mapping to machine code. while wasm is one step behind.
oh actually the payload size would be bigger since we will remove some abstractions, my fault
but memory will be consumed less
I'm not sure but I think the reason we use strings is because of the network trip. strings are a layer of abstraction, and therefor smaller size(not necessarily but it is in this case)
to what end? as i understand browser performance is mostly due to client side js
even if this proposal worked i don't know if there would be any benefit
and why is that? It's because of the interpretation.
I think the benefit would be speed(runtime)
I just thought of this. maybe a drawback would be a long-ass development and testing process 🙂
I just answered my question, LOL
maybe I should talk to myself more often
compiled code doesn't work with dom
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Just kinda curious cause idk much about the topic, but from a performance pov isnt that what webassembly does?
op probably made wild assumptions about browser engines
html & css can't be compiled because they always change during the lifetime of a page
compiled languages have all possible scenarios already figured out
html and it's dynamic nature is just inspected frequently for changes & the engine written in c++ responds accordingly
you can't compile flexible markup it's just a presentation DSL