Hacker News Reader

Comment by pier25 | Hacker News Reader

React will die too, eventually. Or at least stop becoming the default.

Let's say it does: It leaves behind a WebAPI backend that [new hotness] can utilize. WebAPI is an agnostic protocol.

What does Blazor leave behind? Nothing reusable at all. It is a proprietary server hosting proprietary connections via proprietary pipeline. Plus sometimes inscrutable WebAssembly. Just go ask all the companies STILL stuck on Web Forms or Silverlight how that worked out for them the last times? Exactly.

Friends don't let friends buy into proprietary backends that muddy the water between UI/API layers. Stick to WebAPI and put whatever you want in front. That way you can migrate either front OR back independently of one another (and or do piecemeal migrations).

PS - This has nothing to do with "Microsoft bad." This has to do with standard protocols between front/back Vs bespoke stuff. I'd also criticize the short-sightedness if another company offered the same thing.

Best practices would dictate that you still build WebAPIs for your Blazor apps, to avoid that potentially happening. It will also give you a clean separation of concerns in your application. Even when I build a traditional MVC application, I still built out my API as a separate layer so I can change out the front-end in the future.

So, in order to use Blazor safely, I need to develop and test everything twice. That's a death knell within itself. You just made my argument for me.

Do you not bother testing your JavaScript?

We're discussing which abstraction is between the backend/front end. You said, to use Blazor safely, I also need to deploy WebAPI. I said you therefore need to test and develop it all twice: Blazor and WebAPI.

Your "question" is non-sequitur.

So you would build a solution that combined both using Blazor? I still don't understand, this is just like if you were to build a WebAPI and a front-end JavaScript SPA, except Blazor is your JavaScript SPA. You have your unit tests for your WebAPI, and you have your tests for your JavaScript SPA (in this case Blazor, but fill in Vue or React, etc.). You could then write integration tests if you wished, but there isn't any more testing or development process than if you were building a WebAPI with a traditional JavaScript SPA. Blazor is just affording you the ability to use C# rather than JavaScript.

If you were to include your business logic directly into your Blazor application, then you are setting yourself up to run into the exact same issues that you faced with WebForms, if Blazor were to be discontinued. You stated, "Stick to WebAPI and put whatever you want in front. That way you can migrate either front OR back independently of one another (and or do piecemeal migrations)." Blazor is what you put in front. Blazor gets discontinued, you put a standard JavaScript framework in front. The amount of code written and the amount of tests written should be the same whether you use Blazor or React/Vue/Angular/Svelte/JS Framework of the week. What you get with Blazor is the ability to do all your front-end in C#. I think you are going at it as if you build old WebForms or Silverlight, and I just don't see why you would do that knowing full well that front-end tech changes rapidly.

> I need to develop and test everything twice.

That’s…literally the downside of frontend/backend separation of concerns…

Agree, but a dying star creates new life and pathways from old to new. A dying snowflake, just evaporates.

I used to be a frontend coder, but am no longer. In part this is because I couldn't bring myself to keep up with the constant ecosystem churn of the JS world. I recently worked at a company that was trying to migrate from Vue 2 to Vue 3. It was not going quickly. Is Vue going to even be around in a few years, or will React eat it entirely? Or will react itself be eaten by Svelte? I have no idea, I'm not involved in these things. But after watching how such things play out for a couple of decades, my conclusion is that if you are building for the web, you should use whatever you are comfortable with and what provides the features you want now, because there's no way to know what things will look like a few years down the road. Even if the framework you chose sticks around, you may end up doing a rewrite because of other concerns or throw the whole thing away altogether.

Reply on news.ycombinator.com