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.
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.
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.
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.
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.
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.
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.
> 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.
> Not true, WebRTC was designed to address this and is already supported in all major browsers.
False, you cannot build decentralized p2p networks on webrtc because you always need a signalling server. the session establishment protocol needs one-time tokens which need to be exchange some way, which means you can't build a self-sustaining network.
For example Kademlia DHTs require the ability to quickly send requests to peers you have not contacted before (that's why it's UDP-based). If that requires a session setup and teardown every time that negates the advantages of iterative lookups, even if you could decentralize that part.
> Not really, creative DRM is common in desktop applications.
None of the ones I'm using on a daily basis have DRM.
> Not true with new web APIs that expose traditionally native functionality like Bluetooth and the FileSystem.
My understanding is that the FileSystem API is an emulation of a filesystem that stores things in a database in the browser profile. That's not interoperability with native. IPC, file access and sockets are some cuicial features for interoperability.
> 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.
aiui chrome apps are dead except on chromebooks. those offline-apis (service workers) don't give you portability, depend on the browser cache and so on. that gives them volatility.
And Electron... well, that just makes it another desktop framework which does provide interoperability with native, I guess I'm kinda ok with that case. But you don't really need wasm then, you can just link to existing libraries. A bit of a pity though that mozilla canceled its positron implementation, would have been nice having two implementations.
But that's besides the point. As I said previously, it's not about the best possible outcome you can achieve with the technology, it's how it will be applied to the masses. And that's where I think it will be used as a tool to move more users into walled gardens.
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.
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.
That'd be fine as long as people only use it for _old_ flash content. The minute people start using it to render their website UI though, then we've got a problem.
> Blazor runs .NET code in the browser via a small, portable .NET runtime called DotNetAnywhere (DNA) compiled to WebAssembly
Very ambitious for a side project. DotNetAnywhere is a 5 y/o interpreter project which needed a lot of love to build to WebAssembly. On top of that add the multiple layers needed for a competitive UI framework..
But aside from these recent tweaks, the code hadn't been touched for about 5 years.
It's just a toy and POC for now, but interesting nonetheless.
JavaScript won't be unseated as the go-to language for web development and web frameworks by WASM, C#, Java, Python, Go, or anything else... at least not in the next decade.
But certainly high-performance pieces will be dropped-in via WASM to interop with JS for things like image manipulation, etc.
Couldn't get it to work under VS 2017. Tried both the 0.2.0 release from the GH repo and also cloning and opening the master branch... I really want to see this working, anyone managed to try it out? Can share how?
For me, creating and running a project with the released VSIX (0.2.0) works fine.
I was not able to build the project itself locally. And I wanted to understand the technology a little better, so I created a simpler version, no Razor involved, just plain C#: https://github.com/valentiniliescu/CSharpWeb
I'm guessing it will download a runtime that will include the garbage collector. Soon you can look forward to every page including a runtime, or maybe several depending on which advertising engines they're using.
The problem is there's been a ton of work on chained garbage collectors, and the frustrating and seemingly non-intuitive result that everyone eventually hits is that you have to collapse down to a single garbage collector to get garbage collection to work reliable. There are just too many edge cases when you have, say, a native browser garbage collector and a separate application garbage collector, with references held between them. That's why mainstream support for C# -> WebAssembly is on hold until WebAssembly exposes native garbage collection support.
61 comments
[ 3.0 ms ] story [ 124 ms ] threadReally cool though
I’ve actually done that to research and break some systems, and webasm is an order of magnitude worse than JS.
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.
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.
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.
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.
False, you cannot build decentralized p2p networks on webrtc because you always need a signalling server. the session establishment protocol needs one-time tokens which need to be exchange some way, which means you can't build a self-sustaining network.
For example Kademlia DHTs require the ability to quickly send requests to peers you have not contacted before (that's why it's UDP-based). If that requires a session setup and teardown every time that negates the advantages of iterative lookups, even if you could decentralize that part.
> Not really, creative DRM is common in desktop applications.
None of the ones I'm using on a daily basis have DRM.
> Not true with new web APIs that expose traditionally native functionality like Bluetooth and the FileSystem.
My understanding is that the FileSystem API is an emulation of a filesystem that stores things in a database in the browser profile. That's not interoperability with native. IPC, file access and sockets are some cuicial features for interoperability.
> 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.
aiui chrome apps are dead except on chromebooks. those offline-apis (service workers) don't give you portability, depend on the browser cache and so on. that gives them volatility. And Electron... well, that just makes it another desktop framework which does provide interoperability with native, I guess I'm kinda ok with that case. But you don't really need wasm then, you can just link to existing libraries. A bit of a pity though that mozilla canceled its positron implementation, would have been nice having two implementations.
But that's besides the point. As I said previously, it's not about the best possible outcome you can achieve with the technology, it's how it will be applied to the masses. And that's where I think it will be used as a tool to move more users into walled gardens.
You can just see how this could become a mainstream approach
http://mattwarren.org/2017/03/30/The-.NET-IL-Interpreter/
https://github.com/NETMF/llilum
http://www.netmf.com
Many (most?) designers will avoid code like the plague and stick to visual tools like Flash.
http://www.adobe.com/products/flash-builder/features.html
Very ambitious for a side project. DotNetAnywhere is a 5 y/o interpreter project which needed a lot of love to build to WebAssembly. On top of that add the multiple layers needed for a competitive UI framework..
[edit] Link to an isolated DNA project fork: https://github.com/ncave/DotNetAnywhere/commit/982238dd3c334...
But aside from these recent tweaks, the code hadn't been touched for about 5 years.
It's just a toy and POC for now, but interesting nonetheless.
JavaScript won't be unseated as the go-to language for web development and web frameworks by WASM, C#, Java, Python, Go, or anything else... at least not in the next decade.
But certainly high-performance pieces will be dropped-in via WASM to interop with JS for things like image manipulation, etc.
install log: 05/07/2017 14:16:10 - System.IO.FileNotFoundException: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\ at System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName) at VSIXInstaller.SupportedVSSKU.get_VersionWithBuildRevisionInfo() at VSIXInstaller.App.IsValidSKUForExtension(SupportedVSSKU supportedSKU, IExtension extension, List`1 validSKUs) at VSIXInstaller.App.ShouldAddSkuToValidSkuList(SupportedVSSKU sku, IInstallableExtension extension, List`1 validSKUs) at VSIXInstaller.App.GetInstallableData(String vsixPath, Boolean isRepairSupported, IEnumerable`1& skuData) at VSIXInstaller.App.Initialize(Boolean isRepairSupported) at VSIXInstaller.App.Initialize() at System.Threading.Tasks.Task`1.InnerInvoke() at System.Threading.Tasks.Task.Execute()
[0] https://github.com/WebAssembly/design/blob/master/GC.md