3 ms·

This awesome, I much prefer to code in C# as compared to js. It is a much cleaner language.

by sirjaz 9y ago

eosrei 9y ago
https://github.com/appcypher/awesome-wasm-langs https://github.com/appcypher/awesome-wasm-langs is the full list of WebAssembly languages and their current status.
- justin66 9y ago
  I wasn't sure if this list would be any good, but it says right at the top that it's "curated." Imagine my relief!
  - skrebbel 9y ago
    Hahah :-) Yeah it's a mess. GitHub is full of "Awesome XYZ" lists which are basically just dumps of links. Awesome Elixir is a good example, it's worthless and full of 2-year old unmaintained afternoon hacks.
cheez 9y ago
You might like Typescript. A lot of the niceness of C# but much more lightweight.
- fauigerzigerk 9y ago
  Typescript as a language may be more lightweight (i.e fewer features) than C# but the development process feels extremely heavyweight and convoluted in comparison. Typescript has no standard library. So you have to resort to using JavaScript libraries and combine those with type descriptions written by yet another group of people for some version or other of the original library. So essentially Typescript is importing JavaScript's already onerous dependency situation putting another set of dependencies on top of it without any formal correctness guarantees or automated compatiblity checks. The language itself is under constant threat of breaking changes introduced by new JavaScript versions. The whole setup feels exremely fragile to me and it is anything but lightweight. But I accept that many people are successfully navigating this mess for now, people who (unlike myself) have created actual production software in Typescript. We'll see how it works out longer term.
  - cheez 9y ago
    Fair point, however I don't see how the situation will be drastically different for C#. The browser still uses JavaScript and I suspect any C# implementation for the browser will use typescript's definition files anyway.
  - WorldMaker 9y ago
    > So essentially Typescript is importing JavaScript's already onerous dependency situation putting another set of dependencies on top of it without any formal correctness guarantees or automated compatiblity checks. An increasing number of JS libraries on npm maintain and provide their own Typescript definitions, so the ecosystem is getting better and in some cases there are no additional type information dependencies beyond your JS library dependencies. > The language itself is under constant threat of breaking changes introduced by new JavaScript versions. I've used Typescript in production software since around TS 1.0, and Typescript has been very adroit of working ahead of JS versions. The biggest change, and closest to a compatibility break, was that import/export syntax changed slightly to reflect ES module import/export syntax, and that wasn't entirely a breaking change (the old syntax still works, though is marked with a deprecation warning). On the other side there were ES2015 features I was happily using in Typescript years before ES2015 was finalized, and am happily using proposed features that are only Stage 2 or Stage 3 today in the standards process. Ecma's TC39 is following a similar playbook to the rest of web standards and using an approach to where multiple implementations should be built before the proposal is accepted into the language. TC39 has the benefit that not only do they get browser implementations, but polyfills/prollyfills, Babel, and Typescript implementations to learn from in adopting a proposal. Typescript very much is leading JS development as much as, if not more than, it is following.

This awesome, I much prefer to code in C# as compared to js. It is a much cleaner language.

by sirjaz 9y ago

This awesome, I much prefer to code in C# as compared to js. It is a much cleaner language.

https://github.com/appcypher/awesome-wasm-langs https://github.com/appcypher/awesome-wasm-langs is the full list of WebAssembly languages and their current status.

justin66 9y ago
I wasn't sure if this list would be any good, but it says right at the top that it's "curated." Imagine my relief!
- skrebbel 9y ago
  Hahah :-) Yeah it's a mess. GitHub is full of "Awesome XYZ" lists which are basically just dumps of links. Awesome Elixir is a good example, it's worthless and full of 2-year old unmaintained afternoon hacks.

cheez 9y ago

You might like Typescript. A lot of the niceness of C# but much more lightweight.

fauigerzigerk 9y ago
Typescript as a language may be more lightweight (i.e fewer features) than C# but the development process feels extremely heavyweight and convoluted in comparison. Typescript has no standard library. So you have to resort to using JavaScript libraries and combine those with type descriptions written by yet another group of people for some version or other of the original library. So essentially Typescript is importing JavaScript's already onerous dependency situation putting another set of dependencies on top of it without any formal correctness guarantees or automated compatiblity checks. The language itself is under constant threat of breaking changes introduced by new JavaScript versions. The whole setup feels exremely fragile to me and it is anything but lightweight. But I accept that many people are successfully navigating this mess for now, people who (unlike myself) have created actual production software in Typescript. We'll see how it works out longer term.
- cheez 9y ago
  Fair point, however I don't see how the situation will be drastically different for C#. The browser still uses JavaScript and I suspect any C# implementation for the browser will use typescript's definition files anyway.
- WorldMaker 9y ago
  > So essentially Typescript is importing JavaScript's already onerous dependency situation putting another set of dependencies on top of it without any formal correctness guarantees or automated compatiblity checks. An increasing number of JS libraries on npm maintain and provide their own Typescript definitions, so the ecosystem is getting better and in some cases there are no additional type information dependencies beyond your JS library dependencies. > The language itself is under constant threat of breaking changes introduced by new JavaScript versions. I've used Typescript in production software since around TS 1.0, and Typescript has been very adroit of working ahead of JS versions. The biggest change, and closest to a compatibility break, was that import/export syntax changed slightly to reflect ES module import/export syntax, and that wasn't entirely a breaking change (the old syntax still works, though is marked with a deprecation warning). On the other side there were ES2015 features I was happily using in Typescript years before ES2015 was finalized, and am happily using proposed features that are only Stage 2 or Stage 3 today in the standards process. Ecma's TC39 is following a similar playbook to the rest of web standards and using an approach to where multiple implementations should be built before the proposal is accepted into the language. TC39 has the benefit that not only do they get browser implementations, but polyfills/prollyfills, Babel, and Typescript implementations to learn from in adopting a proposal. Typescript very much is leading JS development as much as, if not more than, it is following.