13

(long post is long)
This one is for the .net folks. After evaluating the technology top to bottom and even reimplementing several examples I commonly use for smoke testing new technology, I'm just going to call it:

Blazor is the next Silverlight.

It's just beyond the pale in terms of being architecturally flawed, and yet they're rushing it out as hard as possible to coincide with the .Net 5 rebranding silo extravaganza. We are officially entering round 3 of "sacrifice .Net on the altar of enterprise comfort." Get excited.

Since we've arrived here, I can only assume the Asp.net Ajax fiasco is far enough in the past that a new generation of devs doesn't recall its inherent catastrophic weaknesses. The architecture was this:

1. Create a component as a "WebUserControl"
2. Any time a bound DOM operation occurs from user interaction, send a payload back to the server
3. The server runs the code to process the event; it spits back more HTML

Some client-side js then dutifully updates the UI by unceremoniously stuffing the markup into an element's innerHTML property like so much sausage.

If you understand that, you've adequately understood how Blazor works. There's some optimization like signalR WebSockets for update streaming (the first and only time most blazor devs will ever use WebSockets, I even see developers claiming that they're "using SignalR, Idserver4, gRPC, etc." because the template seeds it for them. The hubris.), but that's the gist. The astute viewer will have noticed a few things here, including the disconnect between repaints, inability to blend update operations and transitions, and the potential for absolutely obliterative, connection-volatile, abusive transactional logic flying back and forth to the server. It's the bring out your dead approach to seeing how much of your IT budget is dedicated to paying for bandwidth and CPU time.

Blazor goes a step further in the server-side render scenario and sends every DOM event it binds to the server for processing. These include millisecond-scale events like scroll, which, at least according to GitHub issues, devs are quickly realizing requires debouncing, though they aren't quite sure how to accomplish that. Since this immediately becomes an issue with tickets saying things like, "scroll event crater server, Ugg need help! You said Blazorclub good. Ugg believe, Ugg wants reparations!" the team chooses a great answer to many problems for the wrong reasons:

gRPC

For those who aren't familiar, gRPC has a substantial amount of compression primarily courtesy of a rather excellent binary format developed by Google. Who needs the Quickie Mart, or indeed a sound markup delivery and view strategy when you can compress the shit out of the payload and ignore the problem. (Shhh, I hear you back there, no spoilers. What will happen when even that compression ceases to cut it, indeed). One might look at all this inductive-reasoning-as-development and ask themselves, "butwai?!" The reason is that the server-side story is just a way to buy time to flesh out the even more fundamentally broken browser-side story. To explain that, we need a little perspective.

The relationship between Microsoft and it's enterprise customers is your typical mutually abusive co-dependent relationship. Microsoft goes through phases of tacit disinterest, where it virtually ignores them. And rightly so, the enterprise customers tend to be weaksauce, mono-platform, mono-language types who come to work, collect a paycheck, and go home. They want to suckle on the teat of the vendor that enables them to get a plug and play experience for delivering their internal systems.

And that's fine. But it's also dull; it's the spouse that lets themselves go, it's the girlfriend in the distracted boyfriend meme. Those aren't the people who keep your platform relevant and competitive. For Microsoft, that crowd has always been the exploratory end of the developer community: alt.net, and more recently, the dotnet core community (StackOverflow 2020's most loved platform, for the haters). Alt.net seeded every competitive advantage the dotnet ecosystem has, and dotnet core capitalized on. Like DI? You're welcome. Are you enjoying MVC? Your gratitude is understood. Cool serializers, gRPC/protobuff, 1st class APIs, metadata-driven clients, code generation, micro ORMs, etc., etc., et al. Dear enterpriseur, you are fucking welcome.

Anyways, b2blazor. So, the front end (Blazor WebAssembly) story begins with the average enterprise FOMO. When enterprises get FOMO, they start to Karen/Kevin super hard, slinging around money, privilege, premiere support tickets, etc. until Microsoft, the distracted boyfriend, eventually turns back and says, "sorry babe, wut was that?" You know, shit like managers unironically looking at cloud reps and demanding to know if "you can handle our load!" Meanwhile, any actual engineer hides under the table facepalming and trying not to die from embarrassment.

Comments
  • 5
    Indeed, they couldn't even put out ads for the mythical "Full-stack developer" that saves the money and delivers that fresh, Supreme-brand promotion-fodder, because they're stuck on .net framework 3-4 and there's not a "full-stack" story that isn't straight out of 2005.

    So Blazor comes out(ish), and delivers the promise of "one language, one pile of code across all the things!" Savvy mobile devs will already see where this is heading, no spoilers. Yes, indeed, a wasm package that allows the server-side prognosticated HTML bloat to move onto the client. Cool beans, right? Not really. See, the first problem is they blew right past the data/operation-oriented solution and right to the razor rendered HTML strategy.
  • 5
    Meanwhile, they left a lot of epically useful functionality on the cutting room floor. You're probably aware of wasm and see that it's an excellent strategy for creating truly sandboxed execution and memory that executes hella-fast with near-native capabilities and IO access. The second problem is that it runs on mono.wasm, produced by Miguel de Icaza's team (who is fantastic btw, both as an engineer and a person). It's a neat little experiment of embedding a .Net runtime in the browser (that isn't Silverlight).
  • 4
    The problem is it's not even remotely ready for prime-time. Due to it being a server-side runtime, its size never really came under scrutiny. While a majority of capable engineers lament the package size of javascript applications, the ASP.Net team's response is "hold my beer." Because mono isn't shakeable in this form factor, and it's not modularized, it's 3MB compressed. That means every user has to download 3MB before it can even start processing your application. It is definitively obese.

    All of that aside, there's a more fundamental issue. Because everything about Blazor is catering to the enterprise bubble, the GitHub issues are a who's who of SHIT THE JS ECOSYSTEM ALREADY SOLVED.
  • 4
    It's always been rather apparent that the Sandy one who shall not be named was averse to looking at existing work in the industry as anything other than Victorian curiosity. Blazor is just next level, though. Blazor is, conceptually, and conventionally where JS was 11 years ago, without the benefit of being directly connected to the DOM. There are so many painful layers of indirection that, while evident to devs who have done significant amounts of browser-centric programming, are utterly missed by those who have been content rendering HTML on a server and having a biscuit to reward themselves for their efforts. 99% of the workarounds are "use some JS," which won't change under their current rendering architecture. There are too many holes and paradigmatic inconsistencies for the 4th wall to remain intact.
  • 4
    The one place it might be useful: electron apps. Electron apps have long suffered the ills of being fully node, so any non-node appropriate workloads resulted in poor performance. The side-process execution model of delegating those tasks to a subprocess hasn't ever really had a coherent story until now, so I will give it some thought leadership in that. That is very much an edge case, though, so take it with that grain of salt.

    The core problem here is that we've reinvented massive wheels and decades of work in a vacuum for effectively no reason, all so we can save a few individuals having to learn a little bit of javascript or some rust.
  • 5
    At some point, for the sake of quality and progress, we have to stop catering to the developers who rhetorically and disingenuously ask questions like, "what's wrong with me wanting to use skills I already have on everything?" It's equal parts logical fallacy and boat anchor. It allowed VB.net to hang on for nearly 20 years. It's why so many enterprises will remain on legacy .net. It's the key contributor to NIH-syndrome. It's full of golden hammers. It prevents new ideas from entering and benefitting organizations. It directs funds and efforts to keeping the wheels on rather than improving and evolving technologies. It allows the proliferation of enterprise logical fallacies like "The One Architecture/The One Platform/The One Language," that superficially increases consistency while simultaneously painting themselves into a corner. We have to stop rewarding people who rest on their laurels.
  • 1
    Websocket. Does that mean no HTTP/2/3?

    Considering the unoptimized mess of separate scripts, images, stylesheets, fonts, and other assets which Enterprise sites use, 2 and 3 would be a big benefit to their performance, no?
  • 1
    @AlgoRythm
    Basically. It can run on long poll to get http/2, but you also understand the implications of that.

    I think the broader question is will websockets survivor http/2 in a similar state
  • 0
    @SortOfTested I remember reading about that when HTTP/2 first came out, haven't heard much about it since. I thought there were some drawbacks to how the protocol behaves.
  • 2
    Are they ultimately trying to replace Javascript? Cause that's not really the reason why WebAssembly exists.

    Also, thanks for the intel. Lots of people at work talking about it, but I don't really understand what kind of viable use cases it has (tho the electron argument is a good idea)
  • 1
    @theuser
    Mostly, the goal is give .Net server developers the ability to make spas and web applications without needing to write JS.
  • 1
    @theuser Interesting, Node.JS is bringing the front end to the back end, and Blazor is bringing the back end to the front end.

    What a time to be a web dev.
  • 1
    @SortOfTested Last post was doubled.

    https://m.youtube.com/watch/...

    Anyone remember this.... """"gem"""""?

    I like the basic principle / idea behind WASM. But not in a browser... (for several reasons)

    WASI is more a thing my mind can "tolerate".

    And from reading your post, I must say that I expected something like that...

    I guess C# still has nothing like FFI? Or more precise: real FFI, not some fuckery around the bush...

    Microsoft is very ...shady...

    The OS invest is real, but they're still rotten to the core and making sure that an investition in MS services will either end with an painful migration away from MS or with an costy migration to MS.... Slowly. Very slowly. Since you need not everything at once, but rather at a slow and steady pace.

    And blazor, especially after your lengthy description, sounds exactly like that.

    *sigh* closed enough eco system to get the cash cow melked.
  • 0
    @SortOfTested Ah gotcha, the devs don't have to write any JS themselves, Blazor handles the DOM operations. So as you said, the question is, is it actually any good or should they learn a bit of javascript instead.
  • 1
    @theuser
    The gist of my post is, "it's a piece of shit, learn some js." 😋

    Or better yet, some rust/go/wasmable lang
  • 0
    @IntrusionCM
    FFI, not really unless it's an interop or CLI Lang.

    I can't really argue with that.
  • 0
    @SortOfTested

    Com Interop....

    /me crawls into the darkest corner he can find because of all the PTSD this triggers
  • 1
    Alright question with example. Say you create a form. You don't want the user to submit an empty or unchanged form so you disable the submit button until they make some change to the form. Of course, you manage to find some way to debounce anything but the onChange event on the inputs and when it does fire off, a payload goes to the server and it sends back the markup for a submit button that isn't disabled. (which is then stuffed into the DOM using JS)

    Is this how it would basically work? Cause that seems a bit shitty to me.
  • 1
    @theuser
    It has a "virtual Dom" abstraction that reduces the payload that is returned to what needs to be updated. That said, yes, it is also shitty.
  • 2
    I need to escape my corporate .net job.
  • 1
    @Benutzername
    Supporting your efforts in spirit ✊
  • 0
    I stoped reading after your 1.2.3 list.

    It is false. Blazor doesn't not post HTML back and does not require HTML as return.

    It is possible if you want server side rendering for some reason.

    As a fron end library it work similar to react with benefits of async/await and types API calls.

    Maybe your tested wrong example.

    For me this is a holy gral. it will not ewliminate JavaAScript, but it will make maintaning code base very easy as you can share validation logic. (And other things).

    My only worry is about calls webassembly from JS and in another sens. There are some performances issues (Not Blazor, any WebAssembly)
  • 1
    @NoToJavaScript
    You apparently didn't even read that far. Put some effort into it.
  • 0
    @SortOfTested In ALL my test with blazor I never saw a "payload" beeing send to server, except if you do "server rendering". Which is basiclly WebForms 2.0.

    All tests I did, DOM manipulation were done at fron end side.
  • 0
    @NoToJavaScript
    I'm not interested in having a conversation about 7% of what I wrote.
  • 0
    @SortOfTested Well you start with "Blazor = silverlight", but you know very well it is nothing to do !

    One is a plugin needed, second is an open concept supported by most browsers.

    Yes, they are rushing it. Undestandable.

    The rest is just wild.
    You can use SingnalR only for data. You can leave DOM manipulation to front-end Blazor.

    I did a tests adding 10.000 table lines. It takes 0.2 seconds with Blazor. (0 calls to back end).

    I think you sort of tested server side rendering future which I won’t even use/test as it is literally (Like you said) shit.

    I see the strength in sharing logic back/front and doing my code in C# on front end side. Just having LinQ is awesome !! At least for me.
    And I can keep the separation HTML/code pretty well.

    I would love some more templating options and F12 is not working perfectly yet.
  • 0
    @NoToJavaScript
    My writing outlines concrete points of consternation on both server side, and web assembly, individually. It also points out the electron workflow.
  • 1
    Something similar is making its rounds in the rails community. Think the gem is called stimulus-reflex. Promise is that you define reflexes on events that get sent over via web socket via action cable to a specific reflex controller, this controller acts on this reflex with the data provided, runs the controller#action the page initially was requested from, renders the result, sends it back and stimulus.js updates the Dom with the diff.

    Thought that concept was pretty nifty, but haven't had the time to experiment with it yet. Here you have to manually define the reflexes and also target a specific controller. Not sure if that's any different in what you mentioned.
  • 0
    @fuckwit
    I'll reply tomorrow, I'm sick and tired atm 😊
  • 0
    @pxeger
    Dotnet core is Linux and mac native. Update those refs 😋 Blazor is pretty much windows centric garbage though, in spirit if not in fact.
  • 0
    @fuckwit
    This is similar. It features routing. I'm universally not a fan of server side rendering stories. Tooling is shit, and you're paying for work client hardware could be doing.
  • 0
    The thing is...

    Every synchronization based process is a PITA.

    Especially when it's over a network and not a "direct" communication.

    There are tons of possible situations where stuff can break or behave in a way you wouldn't expect.

    And it's an even greater PITA to analyse and dissect synchronization woes, since it's mostly a 4 dimensional puzzle -.-
  • 0
    @IntrusionCM
    Which portion of the 1500 words are you referring to. It's ambiguous.
  • 0
    @SortOfTested ah sorry.

    i meant the server side rendering <-> transfer to client [diff dom] thingy...
  • 1
    @IntrusionCM
    It's my opinion that it's something they never should have done. It's the existing server side rendering pipeline with extra steps. Both stories are shit, that one is just the worst.
  • 1
Add Comment