4 ms·

> But why do we need another high-level language, and why should it be W3C's domain to come up with it? One of the biggest mistakes with the web platform was us

> But why do we need another high-level language, and why should it be W3C's domain to come up with it? One of the biggest mistakes with the web platform was using Javascript as the singular first-class way to implement executable logic on the web, and now when WASM is on the verge of becoming a reality, it looks like we are heading down the same path for web-based graphics. WebAssembly has been widely supported for a while now. So the fact that it isn't catching on should tell you something about how great binary formats are. Text formats are more natural in every way: - They are more natural to specify. - They are more natural to codegen. It's easier to write a tool that emits a text format (just use printf) than to emit a binary format (usually need some library). - They are more natural to parse. Parsing text is super clearly understood, and there are off-the-shelf tools to do it. In particular, WHLSL is designed to have a simple-enough grammar that you can use an off-the-shelf parser generator like antlr. - They are easier to introspect. View Source is important on the web.

skohan 8y ago
> WebAssembly has been widely supported for a while now. So the fact that it isn't catching on should tell you something about how great binary formats are. I could argue that this also has a lot to do with inertia: the relative effort of implementing a web application in WASM is not comparable to using Javascript. It's not clear to me that things would be in the same state if there were also decades of work on tooling and libraries for WASM. > They are easier to introspect. View Source is important on the web. In theory yes, but is this really the case in practice? How often can you view source on a modern website and meaningfully understand the javascript? More likely it has been minified and uglified. Besides, it's possible to provide a source-map with binary formats to make source available if the author chooses to do so. As to your other points, it is true that high-level languages are nicer to work with from a developer perspective, but the question is whether the fundamental web interfaces should be optimized for developer experience. I would argue that since web is the most prevalent way that people use software on the planet, web technologies should be optimized for performance and flexibility over developer experience. The advantage of a low-level interface is that it's not opinionated. It's just a thin abstraction layer on top of what the hardware can do, it's not making assumptions about what use-cases should be optimized over what others. The situation with Javascript in that regard is insane: each browser vendor is constantly optimizing their JIT compilers in response to how people use Javascript most often. So the ones writing the code, and the ones optimizing the code are two disconnected groups, each with moving targets. A low level interface lets the end software developer have a consistent baseline to optimize against. Also you don't lose any of the advantages you mentioned with a low-level binary interface. Inevitably there would quickly be tools released to compile HLSL or GLSL down to WSPIRV or whatever the low-level format would be. So if you want to work with a high-level language instead of WSPIRV, you could easily choose another high-level shader language as your target. However you do lose the advantages of a low-level language if you start with a high-level one. It's easy to build nice tooling on top of a low-level interface. But if you require every application to have a nice-tooling-layer as part of its stack, you're essentially incurring a performance penalty on all software whether the application requires it or not.
jcelerier 8y ago
> So the fact that it isn't catching on what makes you say that ? unity uses WASM, Qt uses wasm, Rust uses wasm, autocad uses WASM, SDL uses WASM... or do you expect every JS code to convert to WASM overnight too ?

skohan 8y ago

> WebAssembly has been widely supported for a while now. So the fact that it isn't catching on should tell you something about how great binary formats are. I could argue that this also has a lot to do with inertia: the relative effort of implementing a web application in WASM is not comparable to using Javascript. It's not clear to me that things would be in the same state if there were also decades of work on tooling and libraries for WASM. > They are easier to introspect. View Source is important on the web. In theory yes, but is this really the case in practice? How often can you view source on a modern website and meaningfully understand the javascript? More likely it has been minified and uglified. Besides, it's possible to provide a source-map with binary formats to make source available if the author chooses to do so. As to your other points, it is true that high-level languages are nicer to work with from a developer perspective, but the question is whether the fundamental web interfaces should be optimized for developer experience. I would argue that since web is the most prevalent way that people use software on the planet, web technologies should be optimized for performance and flexibility over developer experience. The advantage of a low-level interface is that it's not opinionated. It's just a thin abstraction layer on top of what the hardware can do, it's not making assumptions about what use-cases should be optimized over what others. The situation with Javascript in that regard is insane: each browser vendor is constantly optimizing their JIT compilers in response to how people use Javascript most often. So the ones writing the code, and the ones optimizing the code are two disconnected groups, each with moving targets. A low level interface lets the end software developer have a consistent baseline to optimize against. Also you don't lose any of the advantages you mentioned with a low-level binary interface. Inevitably there would quickly be tools released to compile HLSL or GLSL down to WSPIRV or whatever the low-level format would be. So if you want to work with a high-level language instead of WSPIRV, you could easily choose another high-level shader language as your target. However you do lose the advantages of a low-level language if you start with a high-level one. It's easy to build nice tooling on top of a low-level interface. But if you require every application to have a nice-tooling-layer as part of its stack, you're essentially incurring a performance penalty on all software whether the application requires it or not.

jcelerier 8y ago

> So the fact that it isn't catching on what makes you say that ? unity uses WASM, Qt uses wasm, Rust uses wasm, autocad uses WASM, SDL uses WASM... or do you expect every JS code to convert to WASM overnight too ?