11 ms·

CIL (.NET bytecode) to WebAssembly compiler

123 points by vmorgulis 11y ago

derefr 11y ago
Does this bring in all of the MSIL for any .NET stdlib modules you happen to link in as well, or is there a dead-code elimination phase pruning them down to just what you use?
- ianlevesque 11y ago
  It looks like at the moment it doesn't support the stdlib at all. Early early prototype.
- Rohansi 11y ago
  JSIL does bring in dependencies and can perform dead-code elimination. I'm not sure if this is supported with ilwasm already.
ianlevesque 11y ago
Neat. I keep hoping for one of these to evolve into a more modern replacement for Silverlight or WPF. There's a lot to like about the .net ecosystem and having a plugin-less deployment story for it would be great.
- tracker1 11y ago
  I was really hoping that Silverlight would gain more traction than it did... for that matter, it's far closer to what I was hoping for when Adobe bought Macromedia. I had been hoping to see a new flash container format that was similar to what Silverlight became using SVG and MP3 with JS as it's main interfaces in an open structure (for the format and player), Adobe could have stayed king of tooling... Flash and Flex are still way better in terms of tooling for some relatively complicated presentations, simulations and the like for a browser than what you now need to hand code with current standards. It really takes something like WebAssembly which multiple browser vendors back to get traction... Adobe was in the position to give us this almost a decade ago.
vyrotek 11y ago
Would anyone be kind enough to explain what exactly I'm looking at here? I'm very familiar with C# but only have a very simple understanding of the idea behind WebAssembly.
- kevingadd 11y ago
  The WebAssembly design repo (https://github.com/WebAssembly/design https://github.com/WebAssembly/design) has a bunch of high and low level details. Essentially, wasm is a spec for an instruction set and runtime environment for native apps, and it's designed so that existing JavaScript runtimes can support it. This will eventually let it solve most of the problems currently solved by asm.js, NaCL, and (to a lesser degree) NPAPI.
ftcHn 11y ago
This is exciting stuff for c# devs. I dream of writing isomorphic web apps in c#. Is there a runtime environment for executing wasm available yet?
- kevingadd 11y ago
  The ml prototype in the draft specification repository (https://github.com/WebAssembly/spec/tree/master/ml-proto https://github.com/WebAssembly/spec/tree/master/ml-proto) is the closest thing at present. ilwasm targets that presently.
fekberg 11y ago
Originally posted yesterday: https://news.ycombinator.com/item?id=10156709 https://news.ycombinator.com/item?id=10156709
- dang 11y ago
  Yup, but reposts are fine when an item hasn't had significant attention yet (see https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html). That helps offset the random churn of /newest, which otherwise causes many good stories to fall through the cracks. Indeed, we invited vmorgulis to repost this one, which we sometimes do when a good submission didn't get much attention the first time. I've written about this at https://news.ycombinator.com/item?id=9866140 https://news.ycombinator.com/item?id=9866140 and https://news.ycombinator.com/item?id=8790134 https://news.ycombinator.com/item?id=8790134 if you're interested.
  - fekberg 11y ago
    Thanks! I thought re-posting was frowned upon, no matter if the content is considered good or not. I'll check the links!
aikah 11y ago
Finally , people will be able to get rid of javascript wholesale . No transpilation , asmjs whatsoever. It basically means that javascript will die in the long run and people will be able to use whatever language they want to use, actionscript , java , c# you name it. That's a game changer and it's a future standard , so no plugins.
- deleted 11y ago
  [deleted]
- jeswin 11y ago
  I welcome being able to use any language. But, > No transpilation You'll have to compile instead. > people will be able to get rid of javascript wholesale Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. In fact, it might even be better in some cases. No other language is going to come with built-in tools for editing within browser/client dev tools. Modern JS is going to be one of the easy languages to get started on. And of course, you totally underestimate the billions of lines of JS already written for the Web.
  - aikah 11y ago
    > Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. In fact, it might even be better in some cases. ES6 isn't statically typed. It might be better for you , it is not for me. > You'll have to compile instead. Yes, and without caring about Javascript. That's the point. Javascript will become irrelevant when it comes to front-end development. One language cannot possibly satisfy everybody's needs. If that was the case we would all be using nodejs on the server and that's hardly the case.
    - yareally 11y ago
      > ES6 isn't statically typed. It might be better for you , it is not for me. Perhaps you should just look into using TypeScript? It's basically ES6 with static typing.
      - 11y ago
zamalek 11y ago
I thought WASM didn't [yet] have a GC. How are they dealing with memory management?
- JosephRedfern 11y ago
  Can't you just let the browser handle the GC? I don't think this is a port of Mono to JS - i.e. it's not a new runtime. EDIT: A: No, you can't.
  - aardvark179 11y ago
    WASM models memory as a big array which is your heap, all memory management within that is up to you. There is no GC, there is no new / delete or anything else. For the use case of porting C programs to your web browser this is fine, for higher level languages you're a bit stuffed. I hope WASM gains some sort of GC eventually, because writing a GC in WASM will make me cry. :-(
    - JosephRedfern 11y ago
      Ah-ha! I see - apologies, I'd misunderstood.
  - zamalek 11y ago
    WASM, however, is a new runtime that doesn't yet support GC: https://news.ycombinator.com/item?id=9741503 https://news.ycombinator.com/item?id=9741503
- kevingadd 11y ago
  If you look at the FAQ and test cases this is a direct mapping to things wasm currently has, thus: no GC objects, just primitive values and direct heap access.
hacker_9 11y ago
Holy s* yes!!! Finally web dev moves in the right direction! JS developers will finally realise how bad they've had it.
- tracker1 11y ago
  Yeah... I mean give me layers of interfaces, indirection and dependency injection that's hard to follow. Class structures that don't flow well for procedural workflows. Projects with dead end code paths because they are so big no one person understands even half of it. I mean, these are such great things. I've totally missed them in modern JS development, and haven't been fighting against many of these practices for years now at all (/sarcasm). Seriously though, my biggest issue with JS development today is people that don't understand patterns beyond what they use in C# and Java, and don't want to keep things simple and easy to reason about. Most C# and Java applications I've worked with have many layers of unnecessary complexity for the sake of, more because "that's how it's done in 'Enterprise' software" more than it is about what's truly needed. I actually really like C#, and the thought of being able to use some of the features really appeals to me. That said, actually working with solutions common from .Net, I've been happier without it. I've spent the better part of my time the past 4-5 years migrating away from .Net solutions to Node based ones... once you get past people trying to implement overly complex patterns and embracing "the node way" of simple, composable, functional modules... it can and does go much more smoothly. --- edit: When I say complexity for the sake of... it's usually for the purpose of testability, often in scenarios that don't have tests, and beyond that aren't trying to target multiple implementations of an interface. Even then, with JS you don't need the added constraints. I know there are "contract" concerns, but what that gets you is WS-* and SOAP/WSDL hell that nobody really understands vs easy to reason REST/JSON services. In the end, having simple systems where you have to learn a bit of convention tends to be easier than complex systems with layers of indirection.
interdrift 11y ago
Can someone summarize what one could accomplish using WebAssembly with a statically typed language as c#?
- hacker_9 11y ago
  I've worked with both C# and JS for a number of years and to sum up why static typing is ultimately better than dynamic typing, is because of the type system which gives you compile time errors. As programmers on the computer all day, the more work the computer does for us the better. With a type system the computer knows what the system is capable of, and so knows what you are doing - this means it can tell us precisely what members are available in 'foo' when you type 'foo.', and it can accurately tell us that 'bar' does not exist in foo when you type 'foo.bar'. With systems of even minor complexity this is a godsend when you don't have to even read the documentation of a new API you want to use - you just use the autocomplete and contextual documentation to figure things out. It makes code fun again. With dynamic typing, and especially with JS, the computer is mostly oblivious to what can/cannot be done and you end up having to ctrl+F on method names, mispell something and it just gets added as another variable to the type, you can't refactor variable names easily etc. It's pretty bad in comparison. Static typing isn't all perfect though - sometimes types do get in the way where I wish more dynamic features would have been available. But at least now if C# etc can be used for webdev, then solving these problems will become something people will invest time in and we will finally see new innovation again - instead of yet-another-javascript library/hack.
  - pingec 11y ago
    I have also been doing C# and JS for years and completely agree. JS is nice for prototyping because of the light footprint but as soon as your code gets more complex it becomes a problem to manage/maintain, far from impossible, just harder. From this perspective TypeScript is a godsend.
  - user_0001 11y ago
    Dynamic languages are like inventing a new type of car with square wheels. ;-) Compilers are great, they exist for a reason. Use them
vlastachu 11y ago
Is it only proof of concept? If no: How they develop compiler to language with incomplete spec?
rottyguy 11y ago
Do note that aspnet just released their beta7 yesterday and the *nix port of .NET is coming along nicely. http://blogs.msdn.com/b/webdev/archive/2015/09/02/announcing-availability-of-asp-net-5-beta7.aspx http://blogs.msdn.com/b/webdev/archive/2015/09/02/announcing...
anjanb 11y ago
So, where's the JVM to WebAssembly compiler ? I googled for it and couldn't find any ?
- gldalmaso 11y ago
  This is what I could find on the subject: https://groups.google.com/forum/#!topic/google-web-toolkit-contributors/sZ8H80Fw5mU https://groups.google.com/forum/#!topic/google-web-toolkit-c... My thoughts are pretty much exactly what Colin said. Without GC it's not a reasonable target for Java cross compilation because you'd have to embed your own GC implementation into the output. That being said, they plan to add GC, which will make it more attractive.
ftcHn 11y ago
While writing C# with strong types for the browser is a nice idea, this project won't give you strongly typed access to the web api e.g. window. JSIL, which this project is based on, gets around this by making window and other objects available by the dynamic keyword. You can still strongly type everything within your project but creating a complete strongly typed wrapper to the web api would be a big job.

123 points by vmorgulis 11y ago

Does this bring in all of the MSIL for any .NET stdlib modules you happen to link in as well, or is there a dead-code elimination phase pruning them down to just what you use?

ianlevesque 11y ago
It looks like at the moment it doesn't support the stdlib at all. Early early prototype.
Rohansi 11y ago
JSIL does bring in dependencies and can perform dead-code elimination. I'm not sure if this is supported with ilwasm already.

ianlevesque 11y ago

Neat. I keep hoping for one of these to evolve into a more modern replacement for Silverlight or WPF. There's a lot to like about the .net ecosystem and having a plugin-less deployment story for it would be great.

tracker1 11y ago
I was really hoping that Silverlight would gain more traction than it did... for that matter, it's far closer to what I was hoping for when Adobe bought Macromedia. I had been hoping to see a new flash container format that was similar to what Silverlight became using SVG and MP3 with JS as it's main interfaces in an open structure (for the format and player), Adobe could have stayed king of tooling... Flash and Flex are still way better in terms of tooling for some relatively complicated presentations, simulations and the like for a browser than what you now need to hand code with current standards. It really takes something like WebAssembly which multiple browser vendors back to get traction... Adobe was in the position to give us this almost a decade ago.

vyrotek 11y ago

Would anyone be kind enough to explain what exactly I'm looking at here? I'm very familiar with C# but only have a very simple understanding of the idea behind WebAssembly.

kevingadd 11y ago
The WebAssembly design repo (https://github.com/WebAssembly/design https://github.com/WebAssembly/design) has a bunch of high and low level details. Essentially, wasm is a spec for an instruction set and runtime environment for native apps, and it's designed so that existing JavaScript runtimes can support it. This will eventually let it solve most of the problems currently solved by asm.js, NaCL, and (to a lesser degree) NPAPI.

ftcHn 11y ago

This is exciting stuff for c# devs. I dream of writing isomorphic web apps in c#. Is there a runtime environment for executing wasm available yet?

kevingadd 11y ago
The ml prototype in the draft specification repository (https://github.com/WebAssembly/spec/tree/master/ml-proto https://github.com/WebAssembly/spec/tree/master/ml-proto) is the closest thing at present. ilwasm targets that presently.

fekberg 11y ago

Originally posted yesterday: https://news.ycombinator.com/item?id=10156709 https://news.ycombinator.com/item?id=10156709

dang 11y ago
Yup, but reposts are fine when an item hasn't had significant attention yet (see https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html). That helps offset the random churn of /newest, which otherwise causes many good stories to fall through the cracks. Indeed, we invited vmorgulis to repost this one, which we sometimes do when a good submission didn't get much attention the first time. I've written about this at https://news.ycombinator.com/item?id=9866140 https://news.ycombinator.com/item?id=9866140 and https://news.ycombinator.com/item?id=8790134 https://news.ycombinator.com/item?id=8790134 if you're interested.
- fekberg 11y ago
  Thanks! I thought re-posting was frowned upon, no matter if the content is considered good or not. I'll check the links!

aikah 11y ago

Finally , people will be able to get rid of javascript wholesale . No transpilation , asmjs whatsoever. It basically means that javascript will die in the long run and people will be able to use whatever language they want to use, actionscript , java , c# you name it. That's a game changer and it's a future standard , so no plugins.

deleted 11y ago
[deleted]
jeswin 11y ago
I welcome being able to use any language. But, > No transpilation You'll have to compile instead. > people will be able to get rid of javascript wholesale Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. In fact, it might even be better in some cases. No other language is going to come with built-in tools for editing within browser/client dev tools. Modern JS is going to be one of the easy languages to get started on. And of course, you totally underestimate the billions of lines of JS already written for the Web.
- aikah 11y ago
  > Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. In fact, it might even be better in some cases. ES6 isn't statically typed. It might be better for you , it is not for me. > You'll have to compile instead. Yes, and without caring about Javascript. That's the point. Javascript will become irrelevant when it comes to front-end development. One language cannot possibly satisfy everybody's needs. If that was the case we would all be using nodejs on the server and that's hardly the case.
  - yareally 11y ago
    > ES6 isn't statically typed. It might be better for you , it is not for me. Perhaps you should just look into using TypeScript? It's basically ES6 with static typing.
    - 11y ago

zamalek 11y ago

I thought WASM didn't [yet] have a GC. How are they dealing with memory management?

JosephRedfern 11y ago
Can't you just let the browser handle the GC? I don't think this is a port of Mono to JS - i.e. it's not a new runtime. EDIT: A: No, you can't.
- aardvark179 11y ago
  WASM models memory as a big array which is your heap, all memory management within that is up to you. There is no GC, there is no new / delete or anything else. For the use case of porting C programs to your web browser this is fine, for higher level languages you're a bit stuffed. I hope WASM gains some sort of GC eventually, because writing a GC in WASM will make me cry. :-(
  - JosephRedfern 11y ago
    Ah-ha! I see - apologies, I'd misunderstood.
- zamalek 11y ago
  WASM, however, is a new runtime that doesn't yet support GC: https://news.ycombinator.com/item?id=9741503 https://news.ycombinator.com/item?id=9741503
kevingadd 11y ago
If you look at the FAQ and test cases this is a direct mapping to things wasm currently has, thus: no GC objects, just primitive values and direct heap access.

hacker_9 11y ago

Holy s* yes!!! Finally web dev moves in the right direction! JS developers will finally realise how bad they've had it.

tracker1 11y ago
Yeah... I mean give me layers of interfaces, indirection and dependency injection that's hard to follow. Class structures that don't flow well for procedural workflows. Projects with dead end code paths because they are so big no one person understands even half of it. I mean, these are such great things. I've totally missed them in modern JS development, and haven't been fighting against many of these practices for years now at all (/sarcasm). Seriously though, my biggest issue with JS development today is people that don't understand patterns beyond what they use in C# and Java, and don't want to keep things simple and easy to reason about. Most C# and Java applications I've worked with have many layers of unnecessary complexity for the sake of, more because "that's how it's done in 'Enterprise' software" more than it is about what's truly needed. I actually really like C#, and the thought of being able to use some of the features really appeals to me. That said, actually working with solutions common from .Net, I've been happier without it. I've spent the better part of my time the past 4-5 years migrating away from .Net solutions to Node based ones... once you get past people trying to implement overly complex patterns and embracing "the node way" of simple, composable, functional modules... it can and does go much more smoothly. --- edit: When I say complexity for the sake of... it's usually for the purpose of testability, often in scenarios that don't have tests, and beyond that aren't trying to target multiple implementations of an interface. Even then, with JS you don't need the added constraints. I know there are "contract" concerns, but what that gets you is WS-* and SOAP/WSDL hell that nobody really understands vs easy to reason REST/JSON services. In the end, having simple systems where you have to learn a bit of convention tends to be easier than complex systems with layers of indirection.

interdrift 11y ago

Can someone summarize what one could accomplish using WebAssembly with a statically typed language as c#?

hacker_9 11y ago
I've worked with both C# and JS for a number of years and to sum up why static typing is ultimately better than dynamic typing, is because of the type system which gives you compile time errors. As programmers on the computer all day, the more work the computer does for us the better. With a type system the computer knows what the system is capable of, and so knows what you are doing - this means it can tell us precisely what members are available in 'foo' when you type 'foo.', and it can accurately tell us that 'bar' does not exist in foo when you type 'foo.bar'. With systems of even minor complexity this is a godsend when you don't have to even read the documentation of a new API you want to use - you just use the autocomplete and contextual documentation to figure things out. It makes code fun again. With dynamic typing, and especially with JS, the computer is mostly oblivious to what can/cannot be done and you end up having to ctrl+F on method names, mispell something and it just gets added as another variable to the type, you can't refactor variable names easily etc. It's pretty bad in comparison. Static typing isn't all perfect though - sometimes types do get in the way where I wish more dynamic features would have been available. But at least now if C# etc can be used for webdev, then solving these problems will become something people will invest time in and we will finally see new innovation again - instead of yet-another-javascript library/hack.
- pingec 11y ago
  I have also been doing C# and JS for years and completely agree. JS is nice for prototyping because of the light footprint but as soon as your code gets more complex it becomes a problem to manage/maintain, far from impossible, just harder. From this perspective TypeScript is a godsend.
- user_0001 11y ago
  Dynamic languages are like inventing a new type of car with square wheels. ;-) Compilers are great, they exist for a reason. Use them

vlastachu 11y ago

Is it only proof of concept? If no: How they develop compiler to language with incomplete spec?

rottyguy 11y ago

Do note that aspnet just released their beta7 yesterday and the *nix port of .NET is coming along nicely. http://blogs.msdn.com/b/webdev/archive/2015/09/02/announcing-availability-of-asp-net-5-beta7.aspx http://blogs.msdn.com/b/webdev/archive/2015/09/02/announcing...

anjanb 11y ago

So, where's the JVM to WebAssembly compiler ? I googled for it and couldn't find any ?

gldalmaso 11y ago
This is what I could find on the subject: https://groups.google.com/forum/#!topic/google-web-toolkit-contributors/sZ8H80Fw5mU https://groups.google.com/forum/#!topic/google-web-toolkit-c... My thoughts are pretty much exactly what Colin said. Without GC it's not a reasonable target for Java cross compilation because you'd have to embed your own GC implementation into the output. That being said, they plan to add GC, which will make it more attractive.

ftcHn 11y ago

While writing C# with strong types for the browser is a nice idea, this project won't give you strongly typed access to the web api e.g. window. JSIL, which this project is based on, gets around this by making window and other objects available by the dynamic keyword. You can still strongly type everything within your project but creating a complete strongly typed wrapper to the web api would be a big job.