4 ms·

Web Assembly has (at least in the past) a business problem. In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were d

Web Assembly has (at least in the past) a business problem. In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript. That is a horrible business case that is more effort than any value returned and no user will ever care about. Worse, it won't ever work if you intended it to be a JavaScript replacement because it cannot integrate into the interaction of the surrounding page, because it is a sandbox without compromise. This line of wishful thinking instills false hope and just pisses off everyone else, which slows adoption among other languages. The Web Assembly effort has been very clear about this from the very beginning, but people believe what they want to believe even after this has been clarified dozens of times. There are absolutely valid business cases behind Web Assembly though, here are some: * circumventing iphone restrictions * desktop application portability * security * partial docker alternative * promoting adoption and access of applications written lesser popular languages

durandal1 3y ago
You are not wrong, but it solves another really hard business problem: Hiring and retaining good engineers.
DarkNova6 3y ago
But Blazor seems to do a fine job replacing JS with C#? If you really want go to all-native JS because it has advantages, sure you can do. But what I see are bloated SPAs written in a language not designed for large software, based on an environment that likes to change and break things. It's abstractions upon abstractions get a hold of this mess. I don't see why WASM couldn't compete.
- pjmlp 3y ago
  Blazor is doing a fine job being a home for WebForms and Silverlight refugees, how far it will stay relevant remains to be seen. On my job I have zero reasons to suggest it, given the split between FE and BE teams.
  - DarkNova6 3y ago
    Organisations always move slower than technologies. And if Microservies show anything it is that sometimes you just need a technical solution for a human problem. I understand your lack of desire to touch anything remotely resembling frontend. Yet your hostility towards Blazor perplexes me, as for me it is the hot garbage that is JS is a primary reason.
    - pjmlp 3y ago
      Let's say I use Microsoft technologies since MS-DOS 3.3, and Blazor isn't the first great thing that eventually goes south. I belong to the group of people that knows Web Forms before .NET 1.0, went through Silverlight, XNA, WinRT, UAP, UWP,... One thing that Web Forms and Silverlight taught me, is that working directly with browser tech, regardless how bad it may be, is much better than debugging framework and VS interoperability code. For the same reason I master C, regardless of my opinion on it, and its bad influences in security, I have a much easier time on UNIX clones, than otherwise would be.
- mardifoufs 3y ago
  Blazor is peak corporate software. It's fine for internal apps but a nightmare for users that aren't forced to use something (ie, not internal apps). Blazor WASM in particular is the slowest web framework around, the layout is always broke and even on websites that are created to showcase blaze it absolutely is riddled with layout bugs the moment you use it on mobile. React and other JS native frameworks, as much as they are looked down at from back end (especially dotnet devs) are miles ahead in terms of user experience and even actual development experience (good luck doing more than forms and basic stuff on blazor wasm for example). It's for c#/dotnet devs that have a single hammer and hate learning new things so they will use csharp everywhere. As to your point, can you show me a single user facing, non demo app or blazor related website that actually runs on blazor (especially wasm blazor) ? I'm curious to see why you think it's actually replacing or capable of replacing js on the front end.
- yen223 3y ago
  Are there any good Blazor websites out there? I'm not sure if I've ever encountered one in the wild, but to be fair I wasn't really looking.
darby_eight 3y ago
Why would someone use this for desktop applications if you aren't obligated to target a web browser? The only benefit this brings is access to browser rendering, which is a pretty terrible desktop experience (see e.g. slack, spotify).
- sqeaky 3y ago
  Portability? In some situations it is harder to support different desktop builds and this might unify that. I don't think it is the strongest argument but at least on the margins it is an option I can see teams in some places choosing.
  - darby_eight 3y ago
    I think this is the strongest argument, but the sticking point is still the interface actually integrating with the OS environment well. Otherwise Java/C# would have taken off as a de-facto portable solution decades ago (and, in fact, this seems to work pretty well for stuff like games where native integration isn't a factor—most of my favorite games these days run on some sort of managed code, and in fact modding would be much more difficult without this). Granted, at least the browser code uses native widgets, but the look/feel and layout still tend to be way off.
- leptons 3y ago
  Not sure why you claim it's a "terrible desktop experience"? What's wrong with it, please explain.
  - darby_eight 3y ago
    I already answered re: slack above, but spotify is just slow, ugly, and doesn't conform to native interface expectations. Granted, this is also largely true of iTunes, but the issue is much less flagrant there.
    - kristiandupont 3y ago
      Native interface expectations are only really a thing on MacOS at this point. I agree that they are often slower, but "ugly" is an opinion, one that I happen to disagree with. Native widgets feel primitive and dated to me.
useerup 3y ago
> Worse, it won't ever work if you intended it to be a JavaScript replacement because it cannot integrate into the interaction of the surrounding page, because it is a sandbox without compromise That is a pretty bold statement considering that Blazor actually does allow you to ditch JavaScript and very much integrates with the surrounding page. It is true that for manipulating the DOM, Blazor internally needs to go through JavaScript as there are no direct WASM-to-DOM binding (yet). But you, as a developer, can develop sites that runs its interactivity using webassembly instead of Javascript.
crabmusket 3y ago
> In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript. I couldn't speak for "nearly all prior discussions", though I don't doubt there were many devs excited that they could bring their favourite language into a browser. But if I remember correctly, WASM developed pretty directly out of asm.js, which was about bringing high performance code to the web. Yes, it was compiled from C, but not because people hated JS, but because writing the asm.js subset was awful, and writing C was a better way to target the low level high performance virtual machine. Sure, there were plenty of existing libraries in C which were leveraged (e.g. the demo of Unreal running in the browser), but "I can compile a Python interpreter into a webpage" did not seem to me to be the reason for WASM, just a frivolous side-effect.

durandal1 3y ago

You are not wrong, but it solves another really hard business problem: Hiring and retaining good engineers.

DarkNova6 3y ago

But Blazor seems to do a fine job replacing JS with C#? If you really want go to all-native JS because it has advantages, sure you can do. But what I see are bloated SPAs written in a language not designed for large software, based on an environment that likes to change and break things. It's abstractions upon abstractions get a hold of this mess. I don't see why WASM couldn't compete.

pjmlp 3y ago
Blazor is doing a fine job being a home for WebForms and Silverlight refugees, how far it will stay relevant remains to be seen. On my job I have zero reasons to suggest it, given the split between FE and BE teams.
- DarkNova6 3y ago
  Organisations always move slower than technologies. And if Microservies show anything it is that sometimes you just need a technical solution for a human problem. I understand your lack of desire to touch anything remotely resembling frontend. Yet your hostility towards Blazor perplexes me, as for me it is the hot garbage that is JS is a primary reason.
  - pjmlp 3y ago
    Let's say I use Microsoft technologies since MS-DOS 3.3, and Blazor isn't the first great thing that eventually goes south. I belong to the group of people that knows Web Forms before .NET 1.0, went through Silverlight, XNA, WinRT, UAP, UWP,... One thing that Web Forms and Silverlight taught me, is that working directly with browser tech, regardless how bad it may be, is much better than debugging framework and VS interoperability code. For the same reason I master C, regardless of my opinion on it, and its bad influences in security, I have a much easier time on UNIX clones, than otherwise would be.
mardifoufs 3y ago
Blazor is peak corporate software. It's fine for internal apps but a nightmare for users that aren't forced to use something (ie, not internal apps). Blazor WASM in particular is the slowest web framework around, the layout is always broke and even on websites that are created to showcase blaze it absolutely is riddled with layout bugs the moment you use it on mobile. React and other JS native frameworks, as much as they are looked down at from back end (especially dotnet devs) are miles ahead in terms of user experience and even actual development experience (good luck doing more than forms and basic stuff on blazor wasm for example). It's for c#/dotnet devs that have a single hammer and hate learning new things so they will use csharp everywhere. As to your point, can you show me a single user facing, non demo app or blazor related website that actually runs on blazor (especially wasm blazor) ? I'm curious to see why you think it's actually replacing or capable of replacing js on the front end.
yen223 3y ago
Are there any good Blazor websites out there? I'm not sure if I've ever encountered one in the wild, but to be fair I wasn't really looking.

darby_eight 3y ago

Why would someone use this for desktop applications if you aren't obligated to target a web browser? The only benefit this brings is access to browser rendering, which is a pretty terrible desktop experience (see e.g. slack, spotify).

sqeaky 3y ago
Portability? In some situations it is harder to support different desktop builds and this might unify that. I don't think it is the strongest argument but at least on the margins it is an option I can see teams in some places choosing.
- darby_eight 3y ago
  I think this is the strongest argument, but the sticking point is still the interface actually integrating with the OS environment well. Otherwise Java/C# would have taken off as a de-facto portable solution decades ago (and, in fact, this seems to work pretty well for stuff like games where native integration isn't a factor—most of my favorite games these days run on some sort of managed code, and in fact modding would be much more difficult without this). Granted, at least the browser code uses native widgets, but the look/feel and layout still tend to be way off.
leptons 3y ago
Not sure why you claim it's a "terrible desktop experience"? What's wrong with it, please explain.
- darby_eight 3y ago
  I already answered re: slack above, but spotify is just slow, ugly, and doesn't conform to native interface expectations. Granted, this is also largely true of iTunes, but the issue is much less flagrant there.
  - kristiandupont 3y ago
    Native interface expectations are only really a thing on MacOS at this point. I agree that they are often slower, but "ugly" is an opinion, one that I happen to disagree with. Native widgets feel primitive and dated to me.

useerup 3y ago

> Worse, it won't ever work if you intended it to be a JavaScript replacement because it cannot integrate into the interaction of the surrounding page, because it is a sandbox without compromise That is a pretty bold statement considering that Blazor actually does allow you to ditch JavaScript and very much integrates with the surrounding page. It is true that for manipulating the DOM, Blazor internally needs to go through JavaScript as there are no direct WASM-to-DOM binding (yet). But you, as a developer, can develop sites that runs its interactivity using webassembly instead of Javascript.

crabmusket 3y ago

> In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript. I couldn't speak for "nearly all prior discussions", though I don't doubt there were many devs excited that they could bring their favourite language into a browser. But if I remember correctly, WASM developed pretty directly out of asm.js, which was about bringing high performance code to the web. Yes, it was compiled from C, but not because people hated JS, but because writing the asm.js subset was awful, and writing C was a better way to target the low level high performance virtual machine. Sure, there were plenty of existing libraries in C which were leveraged (e.g. the demo of Unreal running in the browser), but "I can compile a Python interpreter into a webpage" did not seem to me to be the reason for WASM, just a frivolous side-effect.