6 ms·

Why frightening? This is long overdue - allowing us to use whatever tooling to generate interactive webpages, instead of dealing with JS.

chmpgne 9y ago
I think it’s more frightening the thought of compiling an entire language runtime to run in the browser
dccoolgai 9y ago
Frightening if you're the one who has to debug it.
- Risord 9y ago
  Do you mean debugging third party closed source code? If not just debug normally like we have done decades (and even in web world few years using these "source maps"). If it cannot be done today it will be then when it's main stream.
- juliangoldsmith 9y ago
  Probably not, once tooling is in place. Running an implementation of the .NET platform would make it possible to attach standard .NET tools to the application running in the browser. (Once it was implemented in the .NET interpreter, of course.) That would give you a much nicer debugging environment than you'd normally get in a JavaScript application.
kuschku 9y ago
Because it makes it even harder for users to take apart websites and understand them.
- deleted 9y ago
  [deleted]
- perfectphase 9y ago
  If it ends up executing IL, then tools like Reflector will probably make it easier to read and explore the code than minified JS
  - kuschku 9y ago
    I’m sorry, but have you actually written tools to take apart obfuscated and minified JS vs. webasm? I’ve actually done that to research and break some systems, and webasm is an order of magnitude worse than JS.
    - perfectphase 9y ago
      My understanding was that, at least for this example, is that the DNA runtime is loading raw IL, not webasm, and the interesting site specific stuff will be in IL. I do not doubt what you're saying about webasm.
      - kuschku 9y ago
        That’s until someone, like Microsoft, makes a serious version of this, and integrates automated obfuscation.
- TomMarius 9y ago
  What's bad about that? The owners have every right to not disclose their source code.
  - kuschku 9y ago
    But why do we, as society, grant them that right? I mean, this is the reason why patents were invented originally: You publish the way your technology works, in return, after a short term, everyone can use it, which improves innovation. Yet, nowadays, a lot more is done via trade secrets. It would be awesome if we could get that innovation back that we’ve lost.
    - TomMarius 9y ago
      Because "we as a society" have no business telling other people what to do with their things as long as they don't hurt others. For some people the alternative to closed source isn't open source, it's either "not publicly published" or "not developed at all", which actually slows development down.
the8472 9y ago
desktop application: the software is on your PC, the files are on your PC, you can use it forever, move it around and at least here in the EU your right to reverse-engineer it for compatibility is guaranteed web application: cloud-service, eternally rented, may go out of service at any time (this has already been an an issue, remember zune drm?), does not interoperate with the native environment at all. you can't even read/write to files! p2p networks are impossible in browsers, everything is centralized. People think that the "run applications in the browser" will bring us cross-platform goodness, but I think it will mostly make is more dependent on the ecosystem of cloud providers and lead to more vendor lockin since it is more difficult to get your stuff out of those silos. And the indirect effect of marginalizing desktop applications ultimately means less control for the user. This is easily visible in the mobile sector but is slowly encroaching on the desktop too.
- deleted 9y ago
  [deleted]
- cm2187 9y ago
  I'd argue the contrary. You have more control on a webapp than on a native app on iOS. You can create your own web application without having to pay a toll to Apple.
  - the8472 9y ago
    > This is easily visible in the mobile sector
- themacguffinman 9y ago
  > desktop application: the software is on your PC, the files are on your PC, you can use it forever Not really, creative DRM is common in desktop applications. > does not interoperate with the native environment at all. you can't even read/write to files Not true with new web APIs that expose traditionally native functionality like Bluetooth and the FileSystem. > cloud-service, eternally rented, may go out of service at any time Lots of web apps are being built for offline usage with new offline-oriented web APIs. Web apps can also be packaged as offline Chrome Apps or "native" apps with Electron. > p2p networks are impossible in browsers, everything is centralized Not true, WebRTC was designed to address this and is already supported in all major browsers.
Ajedi32 9y ago
Remember back when some sites used to do their entire UI in flash, completely ignoring standard UI conventions of the web, breaking the back button and deep linking, hijacking the scrollbar and making printing an entire page impossible? Let's not go back to that please.
- MichaelGG 9y ago
  What's that got to do with replacing JS? These platforms will not render their own graphics via canvas, for the most part, but just interface with the browser APIs. They're just to ditch the JS language, not browser tech/UI.

chmpgne 9y ago

I think it’s more frightening the thought of compiling an entire language runtime to run in the browser

dccoolgai 9y ago

Frightening if you're the one who has to debug it.

Risord 9y ago
Do you mean debugging third party closed source code? If not just debug normally like we have done decades (and even in web world few years using these "source maps"). If it cannot be done today it will be then when it's main stream.
juliangoldsmith 9y ago
Probably not, once tooling is in place. Running an implementation of the .NET platform would make it possible to attach standard .NET tools to the application running in the browser. (Once it was implemented in the .NET interpreter, of course.) That would give you a much nicer debugging environment than you'd normally get in a JavaScript application.

kuschku 9y ago

Because it makes it even harder for users to take apart websites and understand them.

deleted 9y ago
[deleted]
perfectphase 9y ago
If it ends up executing IL, then tools like Reflector will probably make it easier to read and explore the code than minified JS
- kuschku 9y ago
  I’m sorry, but have you actually written tools to take apart obfuscated and minified JS vs. webasm? I’ve actually done that to research and break some systems, and webasm is an order of magnitude worse than JS.
  - perfectphase 9y ago
    My understanding was that, at least for this example, is that the DNA runtime is loading raw IL, not webasm, and the interesting site specific stuff will be in IL. I do not doubt what you're saying about webasm.
    - kuschku 9y ago
      That’s until someone, like Microsoft, makes a serious version of this, and integrates automated obfuscation.
TomMarius 9y ago
What's bad about that? The owners have every right to not disclose their source code.
- kuschku 9y ago
  But why do we, as society, grant them that right? I mean, this is the reason why patents were invented originally: You publish the way your technology works, in return, after a short term, everyone can use it, which improves innovation. Yet, nowadays, a lot more is done via trade secrets. It would be awesome if we could get that innovation back that we’ve lost.
  - TomMarius 9y ago
    Because "we as a society" have no business telling other people what to do with their things as long as they don't hurt others. For some people the alternative to closed source isn't open source, it's either "not publicly published" or "not developed at all", which actually slows development down.

the8472 9y ago

desktop application: the software is on your PC, the files are on your PC, you can use it forever, move it around and at least here in the EU your right to reverse-engineer it for compatibility is guaranteed web application: cloud-service, eternally rented, may go out of service at any time (this has already been an an issue, remember zune drm?), does not interoperate with the native environment at all. you can't even read/write to files! p2p networks are impossible in browsers, everything is centralized. People think that the "run applications in the browser" will bring us cross-platform goodness, but I think it will mostly make is more dependent on the ecosystem of cloud providers and lead to more vendor lockin since it is more difficult to get your stuff out of those silos. And the indirect effect of marginalizing desktop applications ultimately means less control for the user. This is easily visible in the mobile sector but is slowly encroaching on the desktop too.

deleted 9y ago
[deleted]
cm2187 9y ago
I'd argue the contrary. You have more control on a webapp than on a native app on iOS. You can create your own web application without having to pay a toll to Apple.
- the8472 9y ago
  > This is easily visible in the mobile sector
themacguffinman 9y ago
> desktop application: the software is on your PC, the files are on your PC, you can use it forever Not really, creative DRM is common in desktop applications. > does not interoperate with the native environment at all. you can't even read/write to files Not true with new web APIs that expose traditionally native functionality like Bluetooth and the FileSystem. > cloud-service, eternally rented, may go out of service at any time Lots of web apps are being built for offline usage with new offline-oriented web APIs. Web apps can also be packaged as offline Chrome Apps or "native" apps with Electron. > p2p networks are impossible in browsers, everything is centralized Not true, WebRTC was designed to address this and is already supported in all major browsers.

Ajedi32 9y ago

Remember back when some sites used to do their entire UI in flash, completely ignoring standard UI conventions of the web, breaking the back button and deep linking, hijacking the scrollbar and making printing an entire page impossible? Let's not go back to that please.

MichaelGG 9y ago
What's that got to do with replacing JS? These platforms will not render their own graphics via canvas, for the most part, but just interface with the browser APIs. They're just to ditch the JS language, not browser tech/UI.