Hacker News Reader

Comment by lima | Hacker News Reader

The thought of it becoming commonplace is somewhat frightening...

Really cool though

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

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

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

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.

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

If it ends up executing IL, then tools like Reflector will probably make it easier to read and explore the code than minified JS

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.

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.

That’s until someone, like Microsoft, makes a serious version of this, and integrates automated obfuscation.

What's bad about that? The owners have every right to not disclose their source code.

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.

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.

> This is easily visible in the mobile sector

> 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.

Reply on news.ycombinator.com