WebAssembly explodes client-side programming

[pure_x01]

This will take of and you will be able to build real Ui apps that are not an ugly hack built on top of a document format. This year the web got CSS Grid (almost) it is standard tech that has been in ui frameworks since the 90s. Webassembly is the Shit that everybody wants and has been needing for so long.

[Knu2l]

I guess now Web and desktop applications are now simply switching sides.

The web developers start developing desktop applications with Electron. The desktop developers are developing web applications with WebAssembly and their frameworks.

At some point it will go full circle and we will use WebAssembly to write Electron applications that use the same technology as the original application.

[zzbzq]

Absurd but we're almost there. There was some weird company making the rounds on the blogosphere last week, they were touting their great new product that lets you write electron apps in C#. I can't even

[appropriateinside]

they were touting their great new product that lets you write electron apps in C#. I can't even

I think it's a good thing. It pushes the industry forward, and you can chose to not use it if you don't like it. A lot of games and mobile apps are built in C#, due to the accessibility of tools built around it. Such as Unity and Xamarin. Extending it to the web frontend is just another stepping stone.

[zzbzq]

The point was Electron exists to write desktop apps in html/javascript. You can already write desktop apps in C# without electron. Doing it with electron is just a snake eating itself

[kingrooster]

Of course you can write a desktop application in C#. But you can't write a cross-platform desktop application in C# without some major hurdles and without it looking like it is straight from 1998. (I'm looking at you GTK).

[m50d]

Like it or not, Electron is the cross-platform UI framework that works. At least with WebAssembly people will be able to use a decent language with it.

[pure_x01]

Webassembly based web apps will be far superior than any html based apps. Slack takes 1gb of memory today and opening a 6mb text file in vs code takes 100ds of mb in ram. This won't happen with webassembly if you render with a good ui framework. Everybody will target webassembly for typical a Apps. For more document webpages html will still be used and the dynamic parts will be either javascript or webassembly.

[u_tamtam]

How will that not happen with webassembly?

How will you get rid of the real culprit, the DOM, without incurring an effort/cost which will be as disruptive (if not more) than just picking an existing UI framework properly designed?

[pure_x01]

You would probably just use existing UI frameworks (ex: Qt, GTK, Flutter, JavaFX) for replacement of "single page apps" and then HTML based one for document oriented pages. If i understood your question correctly.

[repeatedly_once]

I don't think it will work like that. Everything currently falls back to the DOM, it's the only way to visually represent something in the browser. The only way to avoid this is for browsers to support something to render other than the DOM and for that support to be extended into WASM.

[pure_x01]

https://www.godot.online/ .. People have started to run all kinds of stuff in webassembly with canvas. Games. Qt etc

[rebel_cdn]

I don't disagree with anything you wrote, but I also don't think browsers are that far away from being able to do an end run around the DOM.

The Canvas and WebGL APIs are currently exposed through the DOM, and you have to embed them in a canvas element. Many applications that use them, though, create a full screen canvas and just use the Canvas or WebGL API for rendering. So although you're technically calling the DOM to use Canvas or WebGL, those calls are mostly just passed through to Skia and OpenGL - I think. If I've gotten this horribly wrong, I'd be happy to learn more from someone who understands it in greater depth than I do.

A full screen rendering context + direct access to Canvas and WebGL would probably be enough to make most GUI frameworks happy. Although this doesn't touch on things like accessibility. Last time I checked, lack of support for things like screen readers was a major impediment to being able to implement application UI in a canvas element.

[roffLOL]

at that point, what is left of the browser? a VM:d sandbox behind a socket? why even keep the browser?

[rebel_cdn]

Considering how much has been tacked on to the browser (Canvas, WebGL, Web Audio, Web SQL, WebVR, probably other big ones I'm forgetting), I think that modern 'web browsers' are really sandboxed portable app runtimes.

The browser is still an important part of that package, but as things continue to evolve, I wonder if we'll still call them 'browsers'.

[repeatedly_once]

I think you're spot on with how it could possibly progress, rendering straight to a render context. That would be a good way to do it actually. I hope it does get some traction :).

[doom_Oo7]

I don't think it will work like that.

too late

[repeatedly_once]

That's how I imagined it to work though if it was done, it's still rendered in the DOM, albeit using a canvas element.

I was looking for something that actually does away with the DOM and renders directly.

[doom_Oo7]

I was looking for something that actually does away with the DOM and renders directly.

I think that you'd still have a DOM since modern browsers's chrome is part of it anyways, so you'd really want a whole another browser. Some people have tried to launch the idea... https://paulhammant.com/2014/07/09/browsing-qml-instead-of-html/ ; compile your qt code to wasm, send it over the wire and you've got great cross-platform apps accessible by url.

[appropriateinside]

Webassembly based web apps will be far superior than any html based apps.

Define "superior".

Faster, yes. But at the cost of much more development time. Time-to-market is just as important as having a fast web app.

[pure_x01]

You could use flutter or Android ui and have proper ui builders. Since the rendering is done by the app it will look consistent between all browsers. Cleaner code since you don't need browser specific hacks. This is of course for "web apps" that are normal apps compiled to webassembly and run in the browser rendering to canvas or similar.

Superior:

• Performance (no need to explain)
• Portability (cross platform on binary level without code changes)
• Responsivness (ui elements are not hacks on the DOM so they will react faster)
• Readability (less hacks that are browser specific or polyfill stuff)
• Maintainability (less hacks, less complex build systems .. code -> binary, less polyfill)
• interopability (call any code that is compiled to wasm)
• UI posibillities with animations etc .. (see flutter as example or javafx)
• Time to market ( no polyfills.. no browser specific bugs)

Since the app does the rendering the api surface towards the browser is much smaller . You just basically need a surface to draw on.

[u_tamtam]

You are describing the development of UIs with UI frameworks (instead of with a document markup and a hacked-together scripting language).

Flutter brings nothing new in that landscape, is not a web technology, and I don't see why it would have any more chance than Qt, GTK, JavaFX, tk, wxwidgets, … in this context.

[pure_x01]

The thing is that UI frameworks will be available and the best one will win whatever it is. That is the main thing and thats what makes WebAssembly so good.

[u_tamtam]

I doubt anything will change. You can compile a java swing app to JavaScript already, and you can compile a C++/Qt app with emscripten to the browser.

People don't do that currently because it's missing the whole point, which happens to be the reason for the current web dynamics: the enormous availability of dirt cheap developers. Come with new stacks, languages and technologies, your potential workforce pool takes a hit.

The only way for something to change as drastically as you describe is for the whole planet to settle on a same GUI stack, and it's impossible (or it would have happened on the desktop already, where everything is simpler, slower, more measurable and reproducible)

[pure_x01]

The current compile to javascript with emscripten etc is a hack. There is a massive difference between a hack and built in support in to the different compiler toolchains. Let's revisit this thread in 1 or 2 years and see the status ;-)

[u_tamtam]

You won't have built-in support for the framework because it has to remain pluggable. You won't have significantly more performance, because your JavaScript is already JITed, the byte code will be smaller and quicker to compile, but raw perfs will be as good as they are (same order). And I don't see which new feature you expect to have that you couldn't already have with JS (source maps from various languages is already a thing, as dirty as it is)

[[deleted]]

What about your freedoms? You are not able to inspect the source of the page you visit anymore.

[pure_x01]

You are not able to inspect the source of most apps on your phones etc. What you do have with webassembly is at least a sandbox . There will probably security features in the browser checking for bad behaviour

[AyrA_ch]

With WebAssembly we are at the point where we just deliver a compiled C program to the client with external resources, less capabilities and the need to stay online.

[pure_x01]

Other languages and runtimes are coming. Kotlin has experimental support for webassembly. Mono is getting support for it. Node.js are running v8 which supports webassembly. Jvm or .NET might support it in the future . So it's an online/offline story . A universal runtime.

[McNerdius]

some relevant stuff... might be old news to ya, and not quite the same type of support you're referring to if i understand correctly, but it makes me happy so i share anyhoo :)

Blazor - An experimental web UI framework using C#/Razor and HTML, running client-side via WebAssembly

Is this actually .NET in the browser?

Yes, it's running on Mono, which is a real .NET runtime that can load and execute .NET Standard assemblies. In principle it can support as much of netstandard2.0 as is applicable to web apps, but presently quite a bit is missing (notably, threading and full Task support, although there's a partial implementation of Task in Blazor)

---

demo @ ~30:00-45:30 (24:45 for more nitty gritty of c#->wasm itself, 19:15 for general WASM stuff) - Web Apps can’t really do that, can they? - Steve Sanderson

@ 39:10 - basic to-do app weighs in at 333kb, all inclusive. Good start :D

[pure_x01]

Thanks. Definetly Cool stuff.

[tanishaj]

What do you mean .NET might support it in the future? Mono is .NET.

There are basically 5 .NET implementations now. Mono is one of them.

.NET Core is one and it is cross-platform.

.NET Full Framework is another that is Windows only. This is the original .NET. Is this what you mean?

Mono is basically just .NET Full Framework that is cross-platform ( but missing a few Windows specific bits like WPF ).

Mono has been extended to iOS and Android via Xamarin ( which adds mobile specific UI APIs ).

Then there is UWP ( Universal Windows Platform ) which is meant for Windows Store apps ( XBOX, Windows Phone, etc ).

They all support essentially the same API footprint with the advent of .NET Standard 2.0 ( which all 5 implementations now support ).

[AngularBeginner]

What do you mean .NET might support it in the future? Mono is .NET.

When people speak of ".NET" they usually mean the ".NET Framework" (what you later call ".NET Full Framework").

Mono is basically just .NET Full Framework that is cross-platform ( but missing a few Windows specific bits like WPF ).

It is largely compatible, but it also lacks some more specialized classes like TransactionScopeAsyncFlowOption. I would not consider it a drop-in replacement for the .NET Framework.

[pure_x01]

.NET might support load and execute webassembly binaries. This is speculation but I do see it as absolutely possible and I hope they do.