6 ms·

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

by 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 8y 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).

by berdon 9y ago

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 8y 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).