“Fullstack dev continues to unleash his terror.”

We were in a meeting the other day discussing how we can integrate our React component with other existing systems easily — other React apps, Ionic, Angular, Vue and vanilla HTML.

All of a sudden, he opens his mouth.

Fullstack dev: So the thing is... it’s like...ummm... (he always starts after with these words. Always) since Ionic and Vue are both “angular-based”. It shouldn’t be a problem.

Me: excuse me! What do you mean vue is “angular-based”? What’s vue gotta do with angular?

Fullstack dev: You need angular installed to run vue apps and you have data binding in vue and in angular.

Me: (fuck me dead) I don’t know what that means, but I know what the Rock is cookin’. (My exact words in the meeting)

They flew him in from India and they keep extending his stay. He’s been working on the project for 2+ years now.

More to come!

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

I prefer to build my solutions bottom-up, creating a component right after identifying the need for it but before whatever would be using it, because this gives me the flexibility to think about the problem in the general sense and produce an optimal solution without overspecialization.

VSCode's Rust plugin is a bit overzelous about dead code detection and runs it whenever the codebase is deemed to be correct, highlighting every item that isn't referenced from main, even if it is referenced from something else that's unreferenced.

Whenever I finally defeat the borrow checker and produce a correct solution my entire codebase lights up in yellow like a christmas tree and I'm completely addicted to this.

!rant

I've tried Ionic in the past, and put off development with it because I couldn't get it to be performant without crosswalk.

In 2015, React Native put an end to the 'Are hybrid apps viable?' argument. It had a much smaller compile size, large component library, and is very reactive.

Ionic recently released news on scaling back their tools to focus on core offerings. I can't help but feel they're flogging a dead horse.

I'm sure the Ionic team has very smart people on board. Can't they see they're about to be 'Parse-ed'?

So they develop this app. That uses our front end component library. That queries a GraphQL layer developed as NPM package. That uses a data service abstraction NPM package. That uses another NPM package mapper library. That queries an old REST API returning XML.

It takes days to make a newly added XML node in the bottom-most layer available in the app, requiring changes to 4 repositories and 3 NPM releases.
Refactoring is dead, because 1 change will affect all layers. And the worst part is: theres only 1 app using these packages, so no case for re-use. Overzealous separation of concerns I guess?