12 ms·

Sneak Peek at WebAssembly Studio

559 points by lainon 9y ago

berdon 9y ago
I came here to complain about it being yet another standalone app. I came back, after RTFA, to say that I'm pleasantly surprised that it runs completely in the web browser. https://webassembly.studio/ https://webassembly.studio/
- ropeadopepope 9y ago
  Funny. I came here to complain that it's not a standalone app and yet another crappy browser app.
  - infogulch 9y ago
    I also would prefer standalone apps, but if my choice is between a browser app and a "standalone app" made with electron, the browser app wins in a landslide.
    - sli 9y ago
      When did Electron even enter the conversation from Mozilla's side? It seems like people are inserting that detail entirely on their own.
    - zaarn 9y ago
      With WASM this is no longer a problem. Just supply your own JVM-for-WASM. The standard does expect it to be ported natively to platforms eventually. It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one)
      - collinmanderson 9y ago
        > It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one) What do you see as the advantage of native at that point - having its own window?
        imtringued 9y ago
        Most likely filesystem access and other native features like desktop notifications. Then there is the efficiency. My suspicion is that electron has a completely misconfigured caching system. Usually only one browser is running on a system and therefore many applications share the caching system. This means each electron application has an oversized cache that wastes memory and disk without meaningfully increasing performance.
        collinmanderson 9y ago
        so is web or electron more efficient? Also, web now has desktop notifications - right?
        stronglikedan 9y ago
        Being able to use it without internet connectivity, as well as the local file system access and efficiency gains that another commentor pointed out.
        zaarn 9y ago
        Electron is basically a standalone browser tab. This is quite resource expensive. If WASM apps simply use their own rendering, ie the Qt Toolkit they get a much more native feel on top of having a rendering engine that is more optimized for out of browser use (due to not having a DOM, etc.) It would also slim down the applications a lot, notably when you dynamically link against the toolkit (which also means you share the lib with other apps instead of every app having it's own copy of electron)
  - berdon 9y ago
    My principal complaint was going to be "why not a plugin" to the various editors that already exist (eg. VSCode, Sublime, Vim, etc). I saw the screenshot and thought, ugh, YAEA (yet another electron app).
    - mbebenita 9y ago
      The goal of the project is to help you "learn and teach others about WebAssembly", so it's more of a fiddle environment than an IDE.
- k__ 9y ago
  Really nice. I like these new in-browser IDEs. They often bring a full-fledged build system with them. Just open the URL, write your code, hit compile and download your build.
  - Ajedi32 9y ago
    You know, now that I think about it... Node projects pretty much have all their tooling written in JavaScript already. I wonder how hard it'd be to run all that in the browser directly (right now I think this IDE is handling that on the server).
    - mbebenita 9y ago
      That's one of our goals, we're already doing a lot client side but the goal is to client side all things - https://github.com/wasdk/WebAssemblyStudio/projects/3 https://github.com/wasdk/WebAssemblyStudio/projects/3
    - tracker1 9y ago
      Depends on the project... for example, I was really sad that Sass won over Less only because the implementation for Sass was C/C++ (or Ruby), and Less was straight JS. There are a number of C/C++ based node libraries... I think sass, sqlite are probably the two most popular. Any dependents of nan[0], node-gyp and node-pre-gyp are others. [0] https://www.npmjs.com/browse/depended/nan https://www.npmjs.com/browse/depended/nan
- pjmlp 9y ago
  This is how it should be, if one wants to build an application out of the Web stack, then please use the browser I already have installed and provide the best UI/UX within those constraints.
  - epicide 9y ago
    You've clearly never tried to support more than one browser. That's the big benefit of Electron packing its own browser: you know exactly what engine it's running in and which version of said engine. It's not dependent on what the user wants to use, the last time they updated it, etc. Are there downsides? Sure, but the upsides vastly outweigh them for most users.
    - pjmlp 9y ago
      > You've clearly never tried to support more than one browser. Sure I do, all the way back to when CGIs were still a thing, that is what Web development is all about. It is no different than using any other programming language, graphical APIs, network API, or OS stacks backed up by standards. Anything else is just being lazy at user's expenses. Just imagine game developers shipping a GPU with their game just to be sure it is the same OpenGL version.
      - epicide 9y ago
        > Just imagine game developers shipping a GPU with their game just to be sure it is the same OpenGL version. Electron apps aren't shipping you hardware. I think the more apt analogy would be installing a specific version of DirectX with your game... which a lot do. Ultimately, I'd rather a company/developer spend more time actually building a better interface/product rather than perpetually fixing browser compatibility bugs. > that is what Web development is all about. While fixing bugs and dealing with compatibility issues are part of building any software, I'd hardly say that's what they are all about. That still holds with web development. Do you think <successful web company> is successful due to their ability to squash compatibility bugs? Hardly. It's a means to an end. > It is no different than using any other programming language, graphical APIs, network API, or OS stacks backed up by standards. I would love for everything to be standardized across browsers, but I don't expect that to ever happen (fully).
glibgil 9y ago
The video is unlistenable
- ElijahLynn 9y ago
  I listened to the whole video and it has good audio all the way through.
kristiandupont 9y ago
I have to say I am pretty excited about WebAssembly. I've been through many programming languages. C# might be my favourite and F# always seemed like it would be if I took the time to learn it properly but for quite a few years now, JS has simply had such gravitational pull that I felt like I had to go with it. And I have to say, I've learned to not only like but to love it. Save for the mutable data structures that it supplies per default, it offers solid functional programming features and the culture embraces those. Still, there are times where I wish I could use something else. NPM features quite a few packages written in other languages, with JS "binaries" available which I think is pretty neat. To me, packages seem like a much nicer place to choose language rather than, say, per microservice. A parser might be much cleaner in some pure functional language while some I/O library might work better in something else. But there is still only a subset of languages that compile to JS and the quality varies. But with LLVM supporting WebAssembly, I can see a future where it truly becomes the global binary format. Which would allow you to either write a combination of desktop, mobile and web apps (plus backend) in any language of your choice. Or, easliy write different packages in different languages and combine them into one app.
- pjmlp 9y ago
  Bytecode formats as portable binaries have always been a thing on the mainframe world all the way back to the 60's, it has just taken quite a few decades to become commodity across mobile, desktop and web worlds.
  - Koshkin 9y ago
    Googling this only turns up Java...
    - pjmlp 9y ago
      Then you need to improve your Google-fu. Burroughs, Xerox PARC systems, ETHZ Lilith, Pascal UCSD, IBM TIMI, IBM Language Environment, ...
      - 9y ago
singularity2001 9y ago
not bad, but four(4) config files for a single code file?
- bpicolo 9y ago
  Where do you see 4? I see package.json only. Arguably the build script. And that number doesn't increase at all with more code. The number of files is exactly the same as if you weren't using webassembly, other than the one rust/c source file.
  - pjmlp 9y ago
    On AssemblyScript I see: - tsconfig.json - gulpfile.js - package.json - setup.js
    - mbebenita 9y ago
      AssemblyScript is slightly more involved because the author of the template loads the compiler dynamically.
- mbebenita 9y ago
  Depends on the template really. Our goal was to not hide any of the magic, the tool only really needs a build.ts file, where you define what the Build button should do.
fizzledbits 9y ago
I work with emscripten and webgl and this looks like a fantastic tool for optimization in particular. Really looking forward to using it. Thank you!
- huy-nguyen 9y ago
  How much optimiztion can you squeeze out of webgl + wasm? Don’t you still have to call into JS?
  - flohofwoe 9y ago
    Yes, it's definitely good practice to reduce calls to WebGL as much as possible (for instance through batching, instanced rendering, maintaining your own state cache etc...). Performance behaviour of WebGL is very different from a native GL implementation, but when keeping that in mind it's not too bad all in all.
pjmlp 9y ago
I love that AssemblyScript and bare Wat format are supported as well.
- vanderZwan 9y ago
  I hope they'll add Walt
danShumway 9y ago
I think WebAssembly is one of the most exciting efforts for the web right now, second maybe only to Houdini or IPFS. I say that even as someone who works pretty much exclusively in Javascript now and who loves the language - a lower level format will be great for everyone. I can't wait for more native languages to start supporting it.
- notheguyouthink 9y ago
  Can someone link Houdini that OP is referring to? I'm having trouble finding it without context due to the ambiguous name edit: is it this? https://github.com/w3c/css-houdini-drafts/wiki https://github.com/w3c/css-houdini-drafts/wiki
  - laughingpine 9y ago
    Yeah -- that should be the one they're talking about.
  - danShumway 9y ago
    Correct. Article talking about why Houdini is different from normal CSS polyfills: https://www.smashingmagazine.com/2016/03/houdini-maybe-the-most-exciting-development-in-css-youve-never-heard-of/ https://www.smashingmagazine.com/2016/03/houdini-maybe-the-m... And the related HN discussion (possibly a bit outdated): https://news.ycombinator.com/item?id=11357794 https://news.ycombinator.com/item?id=11357794
- xnaas 9y ago
  I haven't looked into IPFS in a long while. Is development going well? Has the userbase grown somewhat significantly in the past couple of years?
  - zapita 9y ago
    Development seems to be moving quite fast. I'm also seeing lots of third-party tools and services launching on top of it, which is very encouraging.
watty 9y ago
_Started_ working on it late December? That's an incredible amount of progress for less than 4 months.
- mbebenita 9y ago
  Built on top of the great work of many : https://github.com/wasdk/WebAssemblyStudio#credits https://github.com/wasdk/WebAssemblyStudio#credits
Promarged 9y ago
If available it's better to use instantiateStreaming [0] for faster compilation, e.g. this: fetch('../out/main.wasm').then(response => response.arrayBuffer() ).then(bytes => WebAssembly.instantiate(bytes)) could be expressed as this: fetch('../out/main.wasm').then(response => WebAssembly.instantiateStreaming(response)) [0]: https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-firefoxs-new-streaming-and-tiering-compiler/ https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...
- dmix 9y ago
  Wouldn't that still require `response.arrayBuffer()`? For ex (line 2): fetch('../out/main.wasm').then(response => WebAssembly.instantiateStreaming(response.arrayBuffer())) Otherwise it could just be: fetch('../out/main.wasm').then(WebAssembly.instantiateStreaming)
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
traviscline 9y ago
typos: memeory, "pulling the struct iovec abart."
- ateesdalejr 9y ago
  I thought the meme-ory was on purpose...
angersock 9y ago
WebAssembly Studio is a neat project, and I'm very impressed at the quality of tooling. It's just a shame that WebAssembly itself is a concept so deeply flawed in conception that it is unsalvagable, and that it'll hurt developers and users alike. Does opening the door to frontend development in C, Rust, Java, and the whole menagerie really seem like such a good idea? Consider the mess we've made with Javascript--the spread of that mess to other languages to enable WASM and web support is going to be even worse.
- sctb 9y ago
  Would you care to add some information about why you feel this way?
  - angersock 9y ago
    Summed up here, pretty neatly: https://lobste.rs/s/wjtu7c/webassembly_mozilla_won#c_yqsej7 https://lobste.rs/s/wjtu7c/webassembly_mozilla_won#c_yqsej7
eridius 9y ago
This is really cool! I'd love to see the "Hello World" example template provided for all languages, not just C (or at least, for Rust as well, since the C++ version would be awfully close to the C one already). EDIT: On a different note, I was confused when I loaded a template, hit "Run", and got nothing. I assumed running would automatically build first. It would be nice to somehow hint to the user if they run something that hasn't been built yet.
- steveklabnik 9y ago
  In my understanding, part of why they don't have that in Rust yet is the lack of Cargo support; you'd want to use https://github.com/rustwasm/wasm-bindgen https://github.com/rustwasm/wasm-bindgen (and its README.md has said hello example in it) but there's no easy way to use it just yet. It's coming though.
- wolco 9y ago
  I'm waiting for the php implementation.
z3t4 9y ago
Whoa, that's a lot of wasm to show a hello world, compared to "hello world" in assembly language.
iTokio 9y ago
What would be awesome is a way to easily visualize the code size.
alephnan 9y ago
For those interested, this is using the Monaco editor https://github.com/Microsoft/monaco-editor https://github.com/Microsoft/monaco-editor
- wes-k 9y ago
  Yes! I was so happy when they pulled this out of VSCode. I really want to use it on a future project and I love the idea of code in the browser for sharing learning opportunities!
  - Vinnl 9y ago
    IIRC, Monaco was actually first, and VSCode was based on that :)
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
AnonCoward222 9y ago
I'm non-plussed. Their "Hello World" example in C is essentially unparseable for anyone who doesn't already know what's going on. Anyone care to explain it? I don't know how much of this example is written in js and how much in C, how much is boilerplate or anything. It's awful.
- deleted 9y ago
  [deleted]
- tom_mellior 9y ago
  Well, that's kind of what the README file is there for. Here is my understanding: The C program assumes the C standard library is present. It is present, somewhere. Where, and in what version, is not clear to me. Anyway, while the C standard library has an implementation of printf(), that implementation doesn't actually know how to do I/O. It relies on an underlying operating system to do the actual I/O. In particular, the library assumes that it is running on Linux, so once in a while it will emit system call number 146, which is Linux's writev(2) system call (http://man7.org/linux/man-pages/man2/writev.2.html http://man7.org/linux/man-pages/man2/writev.2.html). But there is no implementation of Linux running in the browser! And if there were, its conception of I/O would probably be different from what you expect. That is, you might want "output" to go to one of many different places, and WebAssembly can't guess what you want. That's why the program also implements a writev_c function to simulate this syscall. The corresponding mapping from syscall number 146 to this function is implemented in the accompanying main.js file. So to program your browser in C-compiled-to-WebAssembly, you must implement your high-level application logic and the relevant low-level system calls, making educated guesses (through testing) about what syscalls the hidden mid-level library layer will emit. I'm a bit underwhelmed by this approach. But I guess over time standard syscall libraries will pop up and included in WebAssembly projects to allow you to go back to worrying only about your actual application.
  - mbebenita 9y ago
    That’s a very nice description of what’s going on. The example is there to illustrate how printf works. In fact this is a lot of what Emscripten does to make C/C++ applications just work.
geokon 9y ago
The tools for working with WASM are here: https://github.com/WebAssembly/wabt https://github.com/WebAssembly/wabt The compiler/converters are here: https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen Maybe someone who knows more could help me understand better. It looks the toolchain "stack" is some-lang through LLVM to a special WASM LLVM backend which then is converted to WASM - which is similar to the LLVM-IR.. but more crossplatform-y.. I think? (can someone confirm?). So I guess going forwards WASM is the new crossplatform bytecode and not necessarily tied to the web - right? I don't really get if WASM has memory-managment / garbage-collection by default or it's something optional available to things like Javascript? Or the GC is written in WASM itself...? With LLVM-IR/WASM/SPIR-V it's kinda a shame we have all these standards doing very very similar things - but I kinda get the rational there
- imtringued 9y ago
  LLVM-IR is not really a standard and it is not backwards compatible across LLVM releases and usually the generated IR is also specific to the target platform. Of course it's still vastly easier recompile already generated IR to a different platform as opposed to writing an emulator but it's not supposed to be used this way. It's simply not possible to compare LLVM-IR to WASM SPIR-V JVM BEAMVM CLR bytecode.
- tom_mellior 9y ago
  > WASM - which is similar to the LLVM-IR.. but more crossplatform-y.. I think? (can someone confirm?) Yes. > So I guess going forwards WASM is the new crossplatform bytecode and not necessarily tied to the web - right? Yes. Andreas Rossberg and other chief WASM people are touring conferences with talks called more or less "WebAssembly: Neither Web nor Assembly". It's a misnomer. > I don't really get if WASM has memory-managment / garbage-collection by default It doesn't. I'm not up to date, but last I heard the best that was offered was "at some point there will be APIs available for calling into the browser's runtime to get GC'd objects" or something like that.
  - geokon 9y ago
    Gotcha. After reading a bit more it sounds like WASM isn't supposed to really be the common target for all "web-languages". ie. Javascript won't be compiling to WASM any time soon. It's just a parallel mechanism to run code in the browser that's more extendable/flexible (b/c people where writing monsters to have their language compile to Javascript/asm.js)

559 points by lainon 9y ago

I came here to complain about it being yet another standalone app. I came back, after RTFA, to say that I'm pleasantly surprised that it runs completely in the web browser. https://webassembly.studio/ https://webassembly.studio/

ropeadopepope 9y ago
Funny. I came here to complain that it's not a standalone app and yet another crappy browser app.
- infogulch 9y ago
  I also would prefer standalone apps, but if my choice is between a browser app and a "standalone app" made with electron, the browser app wins in a landslide.
  - sli 9y ago
    When did Electron even enter the conversation from Mozilla's side? It seems like people are inserting that detail entirely on their own.
  - zaarn 9y ago
    With WASM this is no longer a problem. Just supply your own JVM-for-WASM. The standard does expect it to be ported natively to platforms eventually. It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one)
    - collinmanderson 9y ago
      > It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one) What do you see as the advantage of native at that point - having its own window?
      - imtringued 9y ago
        Most likely filesystem access and other native features like desktop notifications. Then there is the efficiency. My suspicion is that electron has a completely misconfigured caching system. Usually only one browser is running on a system and therefore many applications share the caching system. This means each electron application has an oversized cache that wastes memory and disk without meaningfully increasing performance.
        collinmanderson 9y ago
        so is web or electron more efficient? Also, web now has desktop notifications - right?
      - stronglikedan 9y ago
        Being able to use it without internet connectivity, as well as the local file system access and efficiency gains that another commentor pointed out.
      - zaarn 9y ago
        Electron is basically a standalone browser tab. This is quite resource expensive. If WASM apps simply use their own rendering, ie the Qt Toolkit they get a much more native feel on top of having a rendering engine that is more optimized for out of browser use (due to not having a DOM, etc.) It would also slim down the applications a lot, notably when you dynamically link against the toolkit (which also means you share the lib with other apps instead of every app having it's own copy of electron)
- berdon 9y ago
  My principal complaint was going to be "why not a plugin" to the various editors that already exist (eg. VSCode, Sublime, Vim, etc). I saw the screenshot and thought, ugh, YAEA (yet another electron app).
  - mbebenita 9y ago
    The goal of the project is to help you "learn and teach others about WebAssembly", so it's more of a fiddle environment than an IDE.
k__ 9y ago
Really nice. I like these new in-browser IDEs. They often bring a full-fledged build system with them. Just open the URL, write your code, hit compile and download your build.
- Ajedi32 9y ago
  You know, now that I think about it... Node projects pretty much have all their tooling written in JavaScript already. I wonder how hard it'd be to run all that in the browser directly (right now I think this IDE is handling that on the server).
  - mbebenita 9y ago
    That's one of our goals, we're already doing a lot client side but the goal is to client side all things - https://github.com/wasdk/WebAssemblyStudio/projects/3 https://github.com/wasdk/WebAssemblyStudio/projects/3
  - tracker1 9y ago
    Depends on the project... for example, I was really sad that Sass won over Less only because the implementation for Sass was C/C++ (or Ruby), and Less was straight JS. There are a number of C/C++ based node libraries... I think sass, sqlite are probably the two most popular. Any dependents of nan[0], node-gyp and node-pre-gyp are others. [0] https://www.npmjs.com/browse/depended/nan https://www.npmjs.com/browse/depended/nan
pjmlp 9y ago
This is how it should be, if one wants to build an application out of the Web stack, then please use the browser I already have installed and provide the best UI/UX within those constraints.
- epicide 9y ago
  You've clearly never tried to support more than one browser. That's the big benefit of Electron packing its own browser: you know exactly what engine it's running in and which version of said engine. It's not dependent on what the user wants to use, the last time they updated it, etc. Are there downsides? Sure, but the upsides vastly outweigh them for most users.
  - pjmlp 9y ago
    > You've clearly never tried to support more than one browser. Sure I do, all the way back to when CGIs were still a thing, that is what Web development is all about. It is no different than using any other programming language, graphical APIs, network API, or OS stacks backed up by standards. Anything else is just being lazy at user's expenses. Just imagine game developers shipping a GPU with their game just to be sure it is the same OpenGL version.
    - epicide 9y ago
      > Just imagine game developers shipping a GPU with their game just to be sure it is the same OpenGL version. Electron apps aren't shipping you hardware. I think the more apt analogy would be installing a specific version of DirectX with your game... which a lot do. Ultimately, I'd rather a company/developer spend more time actually building a better interface/product rather than perpetually fixing browser compatibility bugs. > that is what Web development is all about. While fixing bugs and dealing with compatibility issues are part of building any software, I'd hardly say that's what they are all about. That still holds with web development. Do you think <successful web company> is successful due to their ability to squash compatibility bugs? Hardly. It's a means to an end. > It is no different than using any other programming language, graphical APIs, network API, or OS stacks backed up by standards. I would love for everything to be standardized across browsers, but I don't expect that to ever happen (fully).

glibgil 9y ago

The video is unlistenable

ElijahLynn 9y ago
I listened to the whole video and it has good audio all the way through.

kristiandupont 9y ago

I have to say I am pretty excited about WebAssembly. I've been through many programming languages. C# might be my favourite and F# always seemed like it would be if I took the time to learn it properly but for quite a few years now, JS has simply had such gravitational pull that I felt like I had to go with it. And I have to say, I've learned to not only like but to love it. Save for the mutable data structures that it supplies per default, it offers solid functional programming features and the culture embraces those. Still, there are times where I wish I could use something else. NPM features quite a few packages written in other languages, with JS "binaries" available which I think is pretty neat. To me, packages seem like a much nicer place to choose language rather than, say, per microservice. A parser might be much cleaner in some pure functional language while some I/O library might work better in something else. But there is still only a subset of languages that compile to JS and the quality varies. But with LLVM supporting WebAssembly, I can see a future where it truly becomes the global binary format. Which would allow you to either write a combination of desktop, mobile and web apps (plus backend) in any language of your choice. Or, easliy write different packages in different languages and combine them into one app.

pjmlp 9y ago
Bytecode formats as portable binaries have always been a thing on the mainframe world all the way back to the 60's, it has just taken quite a few decades to become commodity across mobile, desktop and web worlds.
- Koshkin 9y ago
  Googling this only turns up Java...
  - pjmlp 9y ago
    Then you need to improve your Google-fu. Burroughs, Xerox PARC systems, ETHZ Lilith, Pascal UCSD, IBM TIMI, IBM Language Environment, ...
    - 9y ago

singularity2001 9y ago

not bad, but four(4) config files for a single code file?

bpicolo 9y ago
Where do you see 4? I see package.json only. Arguably the build script. And that number doesn't increase at all with more code. The number of files is exactly the same as if you weren't using webassembly, other than the one rust/c source file.
- pjmlp 9y ago
  On AssemblyScript I see: - tsconfig.json - gulpfile.js - package.json - setup.js
  - mbebenita 9y ago
    AssemblyScript is slightly more involved because the author of the template loads the compiler dynamically.
mbebenita 9y ago
Depends on the template really. Our goal was to not hide any of the magic, the tool only really needs a build.ts file, where you define what the Build button should do.

fizzledbits 9y ago

I work with emscripten and webgl and this looks like a fantastic tool for optimization in particular. Really looking forward to using it. Thank you!

huy-nguyen 9y ago
How much optimiztion can you squeeze out of webgl + wasm? Don’t you still have to call into JS?
- flohofwoe 9y ago
  Yes, it's definitely good practice to reduce calls to WebGL as much as possible (for instance through batching, instanced rendering, maintaining your own state cache etc...). Performance behaviour of WebGL is very different from a native GL implementation, but when keeping that in mind it's not too bad all in all.

pjmlp 9y ago

I love that AssemblyScript and bare Wat format are supported as well.

vanderZwan 9y ago
I hope they'll add Walt

danShumway 9y ago

I think WebAssembly is one of the most exciting efforts for the web right now, second maybe only to Houdini or IPFS. I say that even as someone who works pretty much exclusively in Javascript now and who loves the language - a lower level format will be great for everyone. I can't wait for more native languages to start supporting it.

notheguyouthink 9y ago
Can someone link Houdini that OP is referring to? I'm having trouble finding it without context due to the ambiguous name edit: is it this? https://github.com/w3c/css-houdini-drafts/wiki https://github.com/w3c/css-houdini-drafts/wiki
- laughingpine 9y ago
  Yeah -- that should be the one they're talking about.
- danShumway 9y ago
  Correct. Article talking about why Houdini is different from normal CSS polyfills: https://www.smashingmagazine.com/2016/03/houdini-maybe-the-most-exciting-development-in-css-youve-never-heard-of/ https://www.smashingmagazine.com/2016/03/houdini-maybe-the-m... And the related HN discussion (possibly a bit outdated): https://news.ycombinator.com/item?id=11357794 https://news.ycombinator.com/item?id=11357794
xnaas 9y ago
I haven't looked into IPFS in a long while. Is development going well? Has the userbase grown somewhat significantly in the past couple of years?
- zapita 9y ago
  Development seems to be moving quite fast. I'm also seeing lots of third-party tools and services launching on top of it, which is very encouraging.

watty 9y ago

_Started_ working on it late December? That's an incredible amount of progress for less than 4 months.

mbebenita 9y ago
Built on top of the great work of many : https://github.com/wasdk/WebAssemblyStudio#credits https://github.com/wasdk/WebAssemblyStudio#credits

Promarged 9y ago

If available it's better to use instantiateStreaming [0] for faster compilation, e.g. this: fetch('../out/main.wasm').then(response => response.arrayBuffer() ).then(bytes => WebAssembly.instantiate(bytes)) could be expressed as this: fetch('../out/main.wasm').then(response => WebAssembly.instantiateStreaming(response)) [0]: https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-firefoxs-new-streaming-and-tiering-compiler/ https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...

dmix 9y ago
Wouldn't that still require `response.arrayBuffer()`? For ex (line 2): fetch('../out/main.wasm').then(response => WebAssembly.instantiateStreaming(response.arrayBuffer())) Otherwise it could just be: fetch('../out/main.wasm').then(WebAssembly.instantiateStreaming)
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]

traviscline 9y ago

typos: memeory, "pulling the struct iovec abart."

ateesdalejr 9y ago
I thought the meme-ory was on purpose...

angersock 9y ago

WebAssembly Studio is a neat project, and I'm very impressed at the quality of tooling. It's just a shame that WebAssembly itself is a concept so deeply flawed in conception that it is unsalvagable, and that it'll hurt developers and users alike. Does opening the door to frontend development in C, Rust, Java, and the whole menagerie really seem like such a good idea? Consider the mess we've made with Javascript--the spread of that mess to other languages to enable WASM and web support is going to be even worse.

sctb 9y ago
Would you care to add some information about why you feel this way?
- angersock 9y ago
  Summed up here, pretty neatly: https://lobste.rs/s/wjtu7c/webassembly_mozilla_won#c_yqsej7 https://lobste.rs/s/wjtu7c/webassembly_mozilla_won#c_yqsej7

eridius 9y ago

This is really cool! I'd love to see the "Hello World" example template provided for all languages, not just C (or at least, for Rust as well, since the C++ version would be awfully close to the C one already). EDIT: On a different note, I was confused when I loaded a template, hit "Run", and got nothing. I assumed running would automatically build first. It would be nice to somehow hint to the user if they run something that hasn't been built yet.

steveklabnik 9y ago
In my understanding, part of why they don't have that in Rust yet is the lack of Cargo support; you'd want to use https://github.com/rustwasm/wasm-bindgen https://github.com/rustwasm/wasm-bindgen (and its README.md has said hello example in it) but there's no easy way to use it just yet. It's coming though.
wolco 9y ago
I'm waiting for the php implementation.

z3t4 9y ago

Whoa, that's a lot of wasm to show a hello world, compared to "hello world" in assembly language.

iTokio 9y ago

What would be awesome is a way to easily visualize the code size.

alephnan 9y ago

For those interested, this is using the Monaco editor https://github.com/Microsoft/monaco-editor https://github.com/Microsoft/monaco-editor

wes-k 9y ago
Yes! I was so happy when they pulled this out of VSCode. I really want to use it on a future project and I love the idea of code in the browser for sharing learning opportunities!
- Vinnl 9y ago
  IIRC, Monaco was actually first, and VSCode was based on that :)

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

AnonCoward222 9y ago

I'm non-plussed. Their "Hello World" example in C is essentially unparseable for anyone who doesn't already know what's going on. Anyone care to explain it? I don't know how much of this example is written in js and how much in C, how much is boilerplate or anything. It's awful.

deleted 9y ago
[deleted]
tom_mellior 9y ago
Well, that's kind of what the README file is there for. Here is my understanding: The C program assumes the C standard library is present. It is present, somewhere. Where, and in what version, is not clear to me. Anyway, while the C standard library has an implementation of printf(), that implementation doesn't actually know how to do I/O. It relies on an underlying operating system to do the actual I/O. In particular, the library assumes that it is running on Linux, so once in a while it will emit system call number 146, which is Linux's writev(2) system call (http://man7.org/linux/man-pages/man2/writev.2.html http://man7.org/linux/man-pages/man2/writev.2.html). But there is no implementation of Linux running in the browser! And if there were, its conception of I/O would probably be different from what you expect. That is, you might want "output" to go to one of many different places, and WebAssembly can't guess what you want. That's why the program also implements a writev_c function to simulate this syscall. The corresponding mapping from syscall number 146 to this function is implemented in the accompanying main.js file. So to program your browser in C-compiled-to-WebAssembly, you must implement your high-level application logic and the relevant low-level system calls, making educated guesses (through testing) about what syscalls the hidden mid-level library layer will emit. I'm a bit underwhelmed by this approach. But I guess over time standard syscall libraries will pop up and included in WebAssembly projects to allow you to go back to worrying only about your actual application.
- mbebenita 9y ago
  That’s a very nice description of what’s going on. The example is there to illustrate how printf works. In fact this is a lot of what Emscripten does to make C/C++ applications just work.

geokon 9y ago

The tools for working with WASM are here: https://github.com/WebAssembly/wabt https://github.com/WebAssembly/wabt The compiler/converters are here: https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen Maybe someone who knows more could help me understand better. It looks the toolchain "stack" is some-lang through LLVM to a special WASM LLVM backend which then is converted to WASM - which is similar to the LLVM-IR.. but more crossplatform-y.. I think? (can someone confirm?). So I guess going forwards WASM is the new crossplatform bytecode and not necessarily tied to the web - right? I don't really get if WASM has memory-managment / garbage-collection by default or it's something optional available to things like Javascript? Or the GC is written in WASM itself...? With LLVM-IR/WASM/SPIR-V it's kinda a shame we have all these standards doing very very similar things - but I kinda get the rational there

imtringued 9y ago
LLVM-IR is not really a standard and it is not backwards compatible across LLVM releases and usually the generated IR is also specific to the target platform. Of course it's still vastly easier recompile already generated IR to a different platform as opposed to writing an emulator but it's not supposed to be used this way. It's simply not possible to compare LLVM-IR to WASM SPIR-V JVM BEAMVM CLR bytecode.
tom_mellior 9y ago
> WASM - which is similar to the LLVM-IR.. but more crossplatform-y.. I think? (can someone confirm?) Yes. > So I guess going forwards WASM is the new crossplatform bytecode and not necessarily tied to the web - right? Yes. Andreas Rossberg and other chief WASM people are touring conferences with talks called more or less "WebAssembly: Neither Web nor Assembly". It's a misnomer. > I don't really get if WASM has memory-managment / garbage-collection by default It doesn't. I'm not up to date, but last I heard the best that was offered was "at some point there will be APIs available for calling into the browser's runtime to get GC'd objects" or something like that.
- geokon 9y ago
  Gotcha. After reading a bit more it sounds like WASM isn't supposed to really be the common target for all "web-languages". ie. Javascript won't be compiling to WASM any time soon. It's just a parallel mechanism to run code in the browser that's more extendable/flexible (b/c people where writing monsters to have their language compile to Javascript/asm.js)