Aspnetcore: Looking for a use-case more like a replacement for large-scale JS

[shawnwildermuth]

While the framework seems like an interesting replacement for client-side dev, I am more interested in a model where I build a wasm that I can talk to via JS. Imagine a Vue or Angular project where I can supply the data and data-access and business logic through a wasm and leave the binding and/or markup to JS.

I'm interested in Blazor as a wasm generator, not as a bridge to JavaScript. It seems like the download of .NET Core assemblies and then using mono.js to execute them is complicating, not simplifying the process. I want to build simple wasm (even if large) that represent what is happening now with webpack/browserify on the JS side.

[danroth27]

With Blazor we are building a full web UI framework. For your scenario I think you will be more interested in something like www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/ once it becomes available.

[richbryant]

All I want - and I'll happily admit it - is an end to webpack, grunt, gulp, system.js, require.js, TypeScript configs, the node CLI and every other last bit of the chain of (often conflicting) dependencies that use of a modern JS framework depends upon.

My job is to create code that solves problems, not wrestle with configuration for three times as long as it takes to write the damned code. All it takes is an obstructive ITSEC department and a clumsy web proxy and half your tooldchain is unusable without weeks of kludges and hacks. It's a disgrace.

Bootstrap, moment, font-awesome - the sooner those aren't necessary, the better for everyone whether they be end-user, original developer, maintenance or support. Not to mention the potential saving in training and debug time if .NET devs suddenly find their skills 100% transferable to the browser.

That's the dream. It'll take a while but it's a good dream.

BTW, I have to repeat the request not to compile Blazor to DLLs - too many ITSEC policies are incompetent.

[conficient]

The plan is for production releases to compile to wasm, so DLLs would be dev only, so hopefully that will fix this issue.

_{Sent with GitHawk}