4 ms·

I had a good laugh at it, it was relatable. They are right about the DX with wasm, it's simply not there. Those error messages are all too common and there's a

I had a good laugh at it, it was relatable. They are right about the DX with wasm, it's simply not there. Those error messages are all too common and there's a lot of vague things going on when you compile it down. The whole ecosystem is quite fragmented and a bit of a mess.

hutzlibu 3y ago
"The whole ecosystem is quite fragmented and a bit of a mess." Just the general web style of doing things? I was hoping wasm to be somewhat cleaner and I think it is compared to html and co, but I also ran into quite some wtf moments, with the little experiments I was doing.
- tormeh 3y ago
  A big issue is that it doesn’t currently replace the old webtech, but instead just adds to it. You can’t use WASM in the browser without also using JS, which is unfortunate.
  - couchand 3y ago
    That's the direction they're actively working towards. Unfortunately you can't expect to design a big novel piece of web tech and every intended interface point correctly in a way that a cohort of unrelated browser vendors will implement before the very first release.
    - NohatCoder 3y ago
      If that is what they want then they should scrap WASM and start over. The design is just fundamentally wrong for a JavaScript replacement.
      - couchand 3y ago
        ... based on what do you say that?
        NohatCoder 3y ago
        The lack of integration with anything. The primary method of storage being flat memory that cannot hold a DOM reference in a way that doesn't break garbage collection. The lack of string handling. I'm not saying that it is impossible, but you would end up pretty much building a new language with all the required features, sitting next to the useless array-based thing.
        couchand 3y ago
        > The lack of integration with anything. The primary method of storage being flat memory that cannot hold a DOM reference in a way that doesn't break garbage collection. The lack of string handling. WASM spec authors and implementors seem to agree that this all can be naturally handled by providing direct bindings to regular web APIs in WASM. I would tend to agree... Those don't exactly seem core to the design of the runtime?
        NohatCoder 3y ago
        The DOM is garbage collected, you cannot hold a reference to a DOM element in a non-garbage-collected environment without having to manually mark as held and free. Remember that some old IEs had memory leaks because one could make circular references through the DOM and JavaScript, and they each had separate garbage collectors. Well working garbage collection is not an afterthought, and you can't get two distinct garbage systems to work together in the seamless manner that a single system can operate.
        couchand 3y ago
        I have honestly no idea what you're saying isn't possible. I've been writing a bunch of Rust code running in browsers, for work and play. I'm not futzing with the details, I just use wasm-bindgen and web-sys. I've honestly never worried about garbage collection before, one of the professional hazards of working with a well-designed Rust API. I guess that web-sys provides types with a Drop impl that tell the browser side the object is dead. > without having to manually mark as held and free. I guess that's what you're worried about? It's never been a concern of mine. Maybe if one were writing WASM by hand?
- NohatCoder 3y ago
  You can write all your HTML/CSS/JavaScript by hand and have no weird integration issues. WASM is designed not to be written by hand. It is the only component that forces you to use a compiler chain.
  - yebyen 3y ago
    I said along the lines of, paraphrasing myself, in my beginner talk about Wasm + Ruby at OSS Summit, "I distinctly began to get the impression that Wasm was trying to sell me a compiler, so I decided that I should probably go ahead and let it..." https://www.youtube.com/watch?v=EsAuJmHYWgI&list=PLbzoR-pLrL6prBc8UnTQ9wI3BvFYp17Xp https://www.youtube.com/watch?v=EsAuJmHYWgI&list=PLbzoR-pLrL...

hutzlibu 3y ago

"The whole ecosystem is quite fragmented and a bit of a mess." Just the general web style of doing things? I was hoping wasm to be somewhat cleaner and I think it is compared to html and co, but I also ran into quite some wtf moments, with the little experiments I was doing.

tormeh 3y ago
A big issue is that it doesn’t currently replace the old webtech, but instead just adds to it. You can’t use WASM in the browser without also using JS, which is unfortunate.
- couchand 3y ago
  That's the direction they're actively working towards. Unfortunately you can't expect to design a big novel piece of web tech and every intended interface point correctly in a way that a cohort of unrelated browser vendors will implement before the very first release.
  - NohatCoder 3y ago
    If that is what they want then they should scrap WASM and start over. The design is just fundamentally wrong for a JavaScript replacement.
    - couchand 3y ago
      ... based on what do you say that?
      - NohatCoder 3y ago
        The lack of integration with anything. The primary method of storage being flat memory that cannot hold a DOM reference in a way that doesn't break garbage collection. The lack of string handling. I'm not saying that it is impossible, but you would end up pretty much building a new language with all the required features, sitting next to the useless array-based thing.
        couchand 3y ago
        > The lack of integration with anything. The primary method of storage being flat memory that cannot hold a DOM reference in a way that doesn't break garbage collection. The lack of string handling. WASM spec authors and implementors seem to agree that this all can be naturally handled by providing direct bindings to regular web APIs in WASM. I would tend to agree... Those don't exactly seem core to the design of the runtime?
        NohatCoder 3y ago
        The DOM is garbage collected, you cannot hold a reference to a DOM element in a non-garbage-collected environment without having to manually mark as held and free. Remember that some old IEs had memory leaks because one could make circular references through the DOM and JavaScript, and they each had separate garbage collectors. Well working garbage collection is not an afterthought, and you can't get two distinct garbage systems to work together in the seamless manner that a single system can operate.
        couchand 3y ago
        I have honestly no idea what you're saying isn't possible. I've been writing a bunch of Rust code running in browsers, for work and play. I'm not futzing with the details, I just use wasm-bindgen and web-sys. I've honestly never worried about garbage collection before, one of the professional hazards of working with a well-designed Rust API. I guess that web-sys provides types with a Drop impl that tell the browser side the object is dead. > without having to manually mark as held and free. I guess that's what you're worried about? It's never been a concern of mine. Maybe if one were writing WASM by hand?
NohatCoder 3y ago
You can write all your HTML/CSS/JavaScript by hand and have no weird integration issues. WASM is designed not to be written by hand. It is the only component that forces you to use a compiler chain.
- yebyen 3y ago
  I said along the lines of, paraphrasing myself, in my beginner talk about Wasm + Ruby at OSS Summit, "I distinctly began to get the impression that Wasm was trying to sell me a compiler, so I decided that I should probably go ahead and let it..." https://www.youtube.com/watch?v=EsAuJmHYWgI&list=PLbzoR-pLrL6prBc8UnTQ9wI3BvFYp17Xp https://www.youtube.com/watch?v=EsAuJmHYWgI&list=PLbzoR-pLrL...