7 ms·

The problem is, all of this stuff will probably be dead in a few years. I think they would be better off working within established paradigms rather than trying

The problem is, all of this stuff will probably be dead in a few years. I think they would be better off working within established paradigms rather than trying to do something completely new. How about, for example, making it as easy as possible to use React with a C# backend?

pier25 3y ago
React will die too, eventually. Or at least stop becoming the default.
- osigurdson 3y ago
  Agree, but a dying star creates new life and pathways from old to new. A dying snowflake, just evaporates.
  - seti0Cha 3y ago
    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.
- Someone1234 3y ago
  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.
  - progmetaldev 3y ago
    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.
    - Someone1234 3y ago
      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.
      - progmetaldev 3y ago
        Do you not bother testing your JavaScript?
        Someone1234 3y ago
        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.
        progmetaldev 3y ago
        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.
kqr 3y ago
You get a little closer with Fable to compile F# to JavaScript. It lets you model your domain using F# types (which are just as good as – if not better than – C# types) and then you can use them both from your C# backend and F# or JavaScript frontend (whichever you prefer.) It does require you to faff about with toolchains for building frontend code though (WebPack and the like), and it's not always completely seamless, but if you want to invest in a shared domain model it's the most compatible I've been able to go at least.
- theolivenbaum 3y ago
  Or similar for c# with https://h5.rocks https://h5.rocks (disclaimer: author here)
jmnicolas 3y ago
Contrary to Google, MS never kills any tech. You can still develop Winforms apps today.
- twisteriffic 3y ago
  They don't kill it, they just tie it up in the basement and pretend it never existed.
  - glonq 3y ago
    RIP Silverlight
    - unsignedint 3y ago
      Silverlight's phase-out primarily stemmed from the browser ecosystem's shift away from plugins. It's worth noting that Silverlight 5 was supported until October 2021, a decade after its release, indicating substantial longevity despite the changing landscape.
      - v-erne 3y ago
        Ok first thing first - allow me to vent my existential frustration with few off the cuff (mostly rhetorical) questions ... You call decade a substantial longevity? Is this some kind of a joke? Is your ability to assess being held hostage by js ecosystem expererience? But seriously - I expect a bit more from platform that could potentially waste my life and my venture. I am still happily supporting some Java (and JSF) code that I have written for clients 15 years ago (don't you just love that sweet support fees that you get mostly for being alive and breathing ?). Meanwhile my friend that build whole company around product written in silverlight almost went bankrupt. Now after few years working in AI (going into it a bit too soon) he is trying to create same product in ... yes you guessed it, Blazor. Maybe some people do not learn from their mistakes :)?
        miffy900 3y ago
strich 3y ago
You can't be blamed for having that opinion given history. But Blazor is I think standing on the graves of those previous attempts and is looking extremely strong - it is as of even a year ago mature, well supported, and a deep ecosystem. I think it's pretty safe to be optimistic at this point.
password4321 3y ago
Web Forms ("I'm not dead"), Silverlight, etc.
- progmetaldev 3y ago
  .NET Framework has not been EOL'd, so you can still build applications in WebForms. Silverlight was killed off by browsers no longer supporting plugins, that really wasn't a Microsoft decision. Flash is no longer available either, and had nothing to do with Microsoft.
tester756 3y ago
>How about, for example, making it as easy as possible to use React with a C# backend? Aint is easy already?

pier25 3y ago

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

osigurdson 3y ago
Agree, but a dying star creates new life and pathways from old to new. A dying snowflake, just evaporates.
- seti0Cha 3y ago
  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.
Someone1234 3y ago
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.
- progmetaldev 3y ago
  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.
  - Someone1234 3y ago
    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.
    - progmetaldev 3y ago
      Do you not bother testing your JavaScript?
      - Someone1234 3y ago
        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.
        progmetaldev 3y ago
        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.

kqr 3y ago

You get a little closer with Fable to compile F# to JavaScript. It lets you model your domain using F# types (which are just as good as – if not better than – C# types) and then you can use them both from your C# backend and F# or JavaScript frontend (whichever you prefer.) It does require you to faff about with toolchains for building frontend code though (WebPack and the like), and it's not always completely seamless, but if you want to invest in a shared domain model it's the most compatible I've been able to go at least.

theolivenbaum 3y ago
Or similar for c# with https://h5.rocks https://h5.rocks (disclaimer: author here)

jmnicolas 3y ago

Contrary to Google, MS never kills any tech. You can still develop Winforms apps today.

twisteriffic 3y ago
They don't kill it, they just tie it up in the basement and pretend it never existed.
- glonq 3y ago
  RIP Silverlight
  - unsignedint 3y ago
    Silverlight's phase-out primarily stemmed from the browser ecosystem's shift away from plugins. It's worth noting that Silverlight 5 was supported until October 2021, a decade after its release, indicating substantial longevity despite the changing landscape.
    - v-erne 3y ago
      Ok first thing first - allow me to vent my existential frustration with few off the cuff (mostly rhetorical) questions ... You call decade a substantial longevity? Is this some kind of a joke? Is your ability to assess being held hostage by js ecosystem expererience? But seriously - I expect a bit more from platform that could potentially waste my life and my venture. I am still happily supporting some Java (and JSF) code that I have written for clients 15 years ago (don't you just love that sweet support fees that you get mostly for being alive and breathing ?). Meanwhile my friend that build whole company around product written in silverlight almost went bankrupt. Now after few years working in AI (going into it a bit too soon) he is trying to create same product in ... yes you guessed it, Blazor. Maybe some people do not learn from their mistakes :)?
      - miffy900 3y ago

strich 3y ago

You can't be blamed for having that opinion given history. But Blazor is I think standing on the graves of those previous attempts and is looking extremely strong - it is as of even a year ago mature, well supported, and a deep ecosystem. I think it's pretty safe to be optimistic at this point.

password4321 3y ago

Web Forms ("I'm not dead"), Silverlight, etc.

progmetaldev 3y ago
.NET Framework has not been EOL'd, so you can still build applications in WebForms. Silverlight was killed off by browsers no longer supporting plugins, that really wasn't a Microsoft decision. Flash is no longer available either, and had nothing to do with Microsoft.

tester756 3y ago

>How about, for example, making it as easy as possible to use React with a C# backend? Aint is easy already?