6 ms·

I wouldn't build a business on that. Microsoft's track record of keeping front end tech alive and attention on it is pretty fucking low. On a positive note I b

by baz00 3y ago

I wouldn't build a business on that. Microsoft's track record of keeping front end tech alive and attention on it is pretty fucking low. On a positive note I bought my house with the money earned by their lack of attention.

CharlieDigital 3y ago
It's probably a bit better than React, Vue, and other FE stacks which have had large, fundamental changes as well. E.g. React Hooks, Next.js 12 to Next.js 13, Vue 2 Options -> Vue 3 Composition, etc. NPM is a whole other issue. The one constant in FE is JavaScript and now TypeScript. Likewise, the one constant with .NET's FE stacks is C# which has remained quite stable and in many ways influencing JS and TS. C# had had async/await and Lambda expressions before JS (not clear not me how much effect Microsoft had on ECMA working group's decisions). Silverlight was their one big snafu, but even that was kept alive for quite some time.
- pjmlp 3y ago
  Those of us that had a go at XNA, Silverlight, WebForms, Windows Forms, WPF, WinRT, WinRT/UAP, WinRT/UWP, and now WinUI 3.0/WinAppSDK, are a bit burned out with Microsoft GUI frameworks.
  - CharlieDigital 3y ago
    I'm strictly speaking of web FE.
    - pjmlp 3y ago
      Sure, since my list wasn't exaustive. Those of us that had a go at ASP, ASP.NET, ATLServer, ActiveX, Silverlight, WebForms, AJAX Control Toolkit, WebAPI, WebAPI 2, MVC, Core MVC, Razor Pages.
      - CharlieDigital 3y ago
        If you group it like that, then there is a whole graveyard of Node and JS technologies that have died along the way, too. Ember.js, AngularJS, Knockout.js, Backbone.js, etc. Waaaaay more than Microsoft's go at it. I'm not even sure why you're counting WebAPI in there since it's for writing REST APIs.
        pjmlp 3y ago
        I guess because writing Web FE with a .NET backend is something that many .NET developers happen to do, via WebAPI exactly. The graveyard of Node and JS technologies is orthogonal to the current burnout feeling in many Windows circles regarding Microsoft technologies. To the point that, as I already mentioned a few times, I happened to do .NET Framework to something else ports, instead of the more rational migration to modern .NET. You see the same in long time well known Microsoft partners like Sitecore, moving away from .NET.
        CharlieDigital 3y ago
        Feels like moving goalposts here. Technologies change all the time in every stack; flavors come and go. By the standard of the web JS ecosystem, .NET has been relatively stable.
        pjmlp 3y ago
        My goalposts are still the same, Microsoft FE frameworks since the dawn of time, Web and native, and their continuous replacements, when the team doesn't meet whatever KPIs. I don't care what others do. It is like kids on the kindergarten playground, arguing for who behaves better.
      - stanac 3y ago
        Porting MVC to MVC core was not very complicated. ASP.NET Core, MVC Core, Razor Pages are all relevant and in use today. And all of them are using same rendering language (Razor), same language Blazor is using. It's not like your knowledge becomes obsolete when you move from one framework to another. Same thing with most of Windows GUI frameworks MS built. They all use same rendering language/interface (xaml).
  - cpitman 3y ago
    Web Forms and Windows Forms were both relevant for over a decade. For front end tech, that's pretty good. The Windows GUI tools definitely seem to be struggling. Developing native desktop apps is much rarer these days, so all the attempts to create a single toolkit for multiple form factors makes some sense. But that is actually really hard to do, and Microsoft is starting from behind when it comes to mobile frameworks. FWIW, the last time I developed a native desktop app was WPF. I tried again recently, but my general takeaway was that you need full Visual Studio still to make it work.
    - pjmlp 3y ago
      The worst part, is that at least in public like community channels and tickets, they don't seem to get the point that this has burned lots of bridges with the Windows developer community. To the point that many might still use Windows, but not necessarly Microsoft frameworks.
    - fifticon 3y ago
      I am forced to do WPF as part of my day job, but come from 10+ years of Qt and other UI frameworks. I loathe WPF. It feels overengineered and undercooked at the same time. It feels inelegant. It oozes that it was built by people who would never have to use it themselves, with the attitude 'yeah of course I can make one of those, how hard could it be??'. The built-in hbox/vbox are broken, which is inexcusable as those are the bread & butter of any UI. The way margins and borders is handled is horrendous. The way you set up styling/theming/defaults is horrendous. The way the docking layout is designed is ugly - why is the center widget a special case?? The way the grid layout is implemented is demented. The way the default datagrid works is demented. I have two or more tips for anyone who wants to design a UI framework: (1) Try how a default OK/Cancel WITH LAYOUT can be expressed in your idiom. If it looks ugly and convoluted, fix your design until you don't have that problem. (2) Try how a 'tools on the sides, resizable work area in the middle' works in your idiom. If it sucks, see (1). (3) Check how margins and borders are controlled and defined in your idiom. If it requires repeating '10px' 480 places all over your source, see (1). (4) Check if evenly spacing/sizing a bunch of similar components requires special handling for first or last element, again, see(1). WPF fails all of these, and several more.
  - orthoxerox 3y ago
    Why would you even want to write an immediate mode GUI in XNA?
    - pjmlp 3y ago
      The point being the developer burnout regarding GUI frameworks out of Redmond, if XNA can be used for it or not, is besides the point.
      - baz00 3y ago
        We're not burned out, we're just suspicious and conservative based on our years of experience of having the rug pulled out.
        pjmlp 3y ago
        On my book that is relatively the same, as each of them comes with some learning cost, and related ramp on efforts, only to be dropped a couple of years later, without any respect for the developers, see .NET Native and C++/CX deprecation as one example.
  - chollida1 3y ago
    Really, I still use winforms and WPF. Winforms especially is going on 20ish years? How do you feel burned by them.
    - pjmlp 3y ago
      Try to always move on to the newest one, every couple of projects, instead of using a 20 years old stack.
      - nullindividual 3y ago
        Sounds like you burned out by choice. As long as it is supported and meets your needs, keep using it even if it is 20 years old.
        pjmlp 3y ago
        In consulting we don't have the privilege to use fossilised technologies, unless the customer asks for them.
        nullindividual 3y ago
        There is no universal truth in consulting. Consultants still write COBOL.
        pjmlp 3y ago
        You missed my unless part of the sentence.
        nullindividual 3y ago
        You missed the first sentence of mine.
        pjmlp 3y ago
- lordgroff 3y ago
  One of these (react) does not belong. React brought a new, better, API and kept the old one in. Migrating between react versions is actually a very simple affair, nobody was forcing React hooks.
elboru 3y ago
What do you mean? My first real world project after college was based on ASP.NET MVC, that was 12 years ago. I left the company a long time ago and the project is still healthy and growing they upgraded to ASP.NET Core but they keep using MVC.
- baz00 3y ago
  MVC is fine. The THICK stacks they build are the problem. Web Forms and Silverlight for example. This is just another one of those balls of muddy complexity which will turn into a bad idea which will require a complete front end rewrite of your several hundred endpoint enterprise shite ball in 5 years.
mythz 3y ago
I would, now that Blazor is the flagship Web Framework for .NET which supports multiple render modes and hosting options, inc. in MVC and Razor Pages or as a general templating solution (e.g. for rendering Emails). It's going to be the framework with most of the focus that most .NET Developers will eventually move to. Given the mindshare iron grip Microsoft has over .NET ecosystem, it's able to dictate the Web Framework that most of .NET will use - which is now Blazor. But now that Blazor SSR with Enhanced Navigation offers an optimal UX out-of-the-box, Blazor's going to become the only real future option for Web Development in C#/.NET. I wouldn't have considered it (for Internet App's) before .NET 8, but now its basically the only real future choice for creating any kind of new Web App in .NET (excl. CDN Hostable, SSG Websites).
- baz00 3y ago
  Yeah, um, I was there for Silverlight and Web Forms. Also your last point is quite frankly crack smoking. You can still dump out perfectly good dynamic content with Razor and MVC.
  - mythz 3y ago
    > Yeah, um, I was there for Silverlight and Web Forms. Silverlight's demise was inevitable along with the death of Flash and WebForms is a 20+ year old technology that was focused on retaining a Desktop App development model for the Web, an inferior abstraction which would have never lasted. Blazor is unlike either and delivers a great UX OOB. > You can still dump out perfectly good dynamic content with Razor and MVC. and you always will be, Blazor just has a superior component and development model, an official API for statically rendering components outside a Web Framework context and will eventually be what most of .NET will be using. Feel free to use whatever makes you happy, we still heavily use Razor Pages + SSG for our (CDN hosted) statically generated websites + docs, but will be predominantly using Blazor for new .NET Web Apps.
  - stanac 3y ago
    I was there for silverlight and web forms as well. Web Forms had to die IMHO, it was unnecessary abstraction for those who didn't want to learn web. Silverlight on the other had was not (in my opinion) killed by MS but by browser vendors. It was the same time when flash and other plugin based tech died because browser vendors didn't want to support browser plugins. On the other had MS gave Silverlight 10 years of support when they announced the death of the tech, MS couldn't do anything else about it. If they waited long enough they could have ported silverlight to wasm today. I think there was a company offering dev tools for compiling silverlight to js and wasm, not sure if they are still around.
mgdev 3y ago
I would. MS has had a storied past when it comes to frontend tech, but rather than diverging and dying, what we seem to see now is convergence of a coherent technical vision (and some pruning as a result). They look the same on the surface, but the result is totally different. The latest version achieves exactly what every strung-together implementation of a moderately complex SPA architecture has aimed for in the past decade: fast initial render, low latency interactivity, low server load. They did it in a way that still plays moderately well with the existing JS ecosystem. They did in in a way where everything you do can be airlifted to the desktop or mobile via MAUI Blazor Hybrid. And some of the underlying pieces that are coming along to make this possible are incredible. (Go check out some of the stuff they're doing in the wasm/WASI space.)
- baz00 3y ago
  Have you tried to drag your shit through .Net classic to .Net core via all the stack changes and direction changes? Hell no. It has been horrible.
  - mgdev 3y ago
    Let's call it the "messy middle" and see if we're on the other side of it. :)
jjice 3y ago
Are we talking web frontend, or can we extend this to desktop GUIs as well (that may be cheating, but bear with me). Windows Forms and WPF are both still supported. If you're a business built on Windows Forms (very productive for GUI development), you haven't had to worry. Even VB.NET is still supported, although not receiving active language additions. That said, I personally wouldn't choose to build on MS tech.
johnfn 3y ago
> Microsoft's track record of keeping front end tech alive Microsoft gave us TypeScript. I can't think of front-end tech with more care and attention given to it than TS. For over ten years!

by baz00 3y ago

CharlieDigital 3y ago

It's probably a bit better than React, Vue, and other FE stacks which have had large, fundamental changes as well. E.g. React Hooks, Next.js 12 to Next.js 13, Vue 2 Options -> Vue 3 Composition, etc. NPM is a whole other issue. The one constant in FE is JavaScript and now TypeScript. Likewise, the one constant with .NET's FE stacks is C# which has remained quite stable and in many ways influencing JS and TS. C# had had async/await and Lambda expressions before JS (not clear not me how much effect Microsoft had on ECMA working group's decisions). Silverlight was their one big snafu, but even that was kept alive for quite some time.

pjmlp 3y ago
Those of us that had a go at XNA, Silverlight, WebForms, Windows Forms, WPF, WinRT, WinRT/UAP, WinRT/UWP, and now WinUI 3.0/WinAppSDK, are a bit burned out with Microsoft GUI frameworks.
- CharlieDigital 3y ago
  I'm strictly speaking of web FE.
  - pjmlp 3y ago
    Sure, since my list wasn't exaustive. Those of us that had a go at ASP, ASP.NET, ATLServer, ActiveX, Silverlight, WebForms, AJAX Control Toolkit, WebAPI, WebAPI 2, MVC, Core MVC, Razor Pages.
    - CharlieDigital 3y ago
      If you group it like that, then there is a whole graveyard of Node and JS technologies that have died along the way, too. Ember.js, AngularJS, Knockout.js, Backbone.js, etc. Waaaaay more than Microsoft's go at it. I'm not even sure why you're counting WebAPI in there since it's for writing REST APIs.
      - pjmlp 3y ago
        I guess because writing Web FE with a .NET backend is something that many .NET developers happen to do, via WebAPI exactly. The graveyard of Node and JS technologies is orthogonal to the current burnout feeling in many Windows circles regarding Microsoft technologies. To the point that, as I already mentioned a few times, I happened to do .NET Framework to something else ports, instead of the more rational migration to modern .NET. You see the same in long time well known Microsoft partners like Sitecore, moving away from .NET.
        CharlieDigital 3y ago
        Feels like moving goalposts here. Technologies change all the time in every stack; flavors come and go. By the standard of the web JS ecosystem, .NET has been relatively stable.
        pjmlp 3y ago
        My goalposts are still the same, Microsoft FE frameworks since the dawn of time, Web and native, and their continuous replacements, when the team doesn't meet whatever KPIs. I don't care what others do. It is like kids on the kindergarten playground, arguing for who behaves better.
    - stanac 3y ago
      Porting MVC to MVC core was not very complicated. ASP.NET Core, MVC Core, Razor Pages are all relevant and in use today. And all of them are using same rendering language (Razor), same language Blazor is using. It's not like your knowledge becomes obsolete when you move from one framework to another. Same thing with most of Windows GUI frameworks MS built. They all use same rendering language/interface (xaml).
- cpitman 3y ago
  Web Forms and Windows Forms were both relevant for over a decade. For front end tech, that's pretty good. The Windows GUI tools definitely seem to be struggling. Developing native desktop apps is much rarer these days, so all the attempts to create a single toolkit for multiple form factors makes some sense. But that is actually really hard to do, and Microsoft is starting from behind when it comes to mobile frameworks. FWIW, the last time I developed a native desktop app was WPF. I tried again recently, but my general takeaway was that you need full Visual Studio still to make it work.
  - pjmlp 3y ago
    The worst part, is that at least in public like community channels and tickets, they don't seem to get the point that this has burned lots of bridges with the Windows developer community. To the point that many might still use Windows, but not necessarly Microsoft frameworks.
  - fifticon 3y ago
    I am forced to do WPF as part of my day job, but come from 10+ years of Qt and other UI frameworks. I loathe WPF. It feels overengineered and undercooked at the same time. It feels inelegant. It oozes that it was built by people who would never have to use it themselves, with the attitude 'yeah of course I can make one of those, how hard could it be??'. The built-in hbox/vbox are broken, which is inexcusable as those are the bread & butter of any UI. The way margins and borders is handled is horrendous. The way you set up styling/theming/defaults is horrendous. The way the docking layout is designed is ugly - why is the center widget a special case?? The way the grid layout is implemented is demented. The way the default datagrid works is demented. I have two or more tips for anyone who wants to design a UI framework: (1) Try how a default OK/Cancel WITH LAYOUT can be expressed in your idiom. If it looks ugly and convoluted, fix your design until you don't have that problem. (2) Try how a 'tools on the sides, resizable work area in the middle' works in your idiom. If it sucks, see (1). (3) Check how margins and borders are controlled and defined in your idiom. If it requires repeating '10px' 480 places all over your source, see (1). (4) Check if evenly spacing/sizing a bunch of similar components requires special handling for first or last element, again, see(1). WPF fails all of these, and several more.
- orthoxerox 3y ago
  Why would you even want to write an immediate mode GUI in XNA?
  - pjmlp 3y ago
    The point being the developer burnout regarding GUI frameworks out of Redmond, if XNA can be used for it or not, is besides the point.
    - baz00 3y ago
      We're not burned out, we're just suspicious and conservative based on our years of experience of having the rug pulled out.
      - pjmlp 3y ago
        On my book that is relatively the same, as each of them comes with some learning cost, and related ramp on efforts, only to be dropped a couple of years later, without any respect for the developers, see .NET Native and C++/CX deprecation as one example.
- chollida1 3y ago
  Really, I still use winforms and WPF. Winforms especially is going on 20ish years? How do you feel burned by them.
  - pjmlp 3y ago
    Try to always move on to the newest one, every couple of projects, instead of using a 20 years old stack.
    - nullindividual 3y ago
      Sounds like you burned out by choice. As long as it is supported and meets your needs, keep using it even if it is 20 years old.
      - pjmlp 3y ago
        In consulting we don't have the privilege to use fossilised technologies, unless the customer asks for them.
        nullindividual 3y ago
        There is no universal truth in consulting. Consultants still write COBOL.
        pjmlp 3y ago
        You missed my unless part of the sentence.
        nullindividual 3y ago
        You missed the first sentence of mine.
        pjmlp 3y ago
lordgroff 3y ago
One of these (react) does not belong. React brought a new, better, API and kept the old one in. Migrating between react versions is actually a very simple affair, nobody was forcing React hooks.

elboru 3y ago

What do you mean? My first real world project after college was based on ASP.NET MVC, that was 12 years ago. I left the company a long time ago and the project is still healthy and growing they upgraded to ASP.NET Core but they keep using MVC.

baz00 3y ago
MVC is fine. The THICK stacks they build are the problem. Web Forms and Silverlight for example. This is just another one of those balls of muddy complexity which will turn into a bad idea which will require a complete front end rewrite of your several hundred endpoint enterprise shite ball in 5 years.

mythz 3y ago

I would, now that Blazor is the flagship Web Framework for .NET which supports multiple render modes and hosting options, inc. in MVC and Razor Pages or as a general templating solution (e.g. for rendering Emails). It's going to be the framework with most of the focus that most .NET Developers will eventually move to. Given the mindshare iron grip Microsoft has over .NET ecosystem, it's able to dictate the Web Framework that most of .NET will use - which is now Blazor. But now that Blazor SSR with Enhanced Navigation offers an optimal UX out-of-the-box, Blazor's going to become the only real future option for Web Development in C#/.NET. I wouldn't have considered it (for Internet App's) before .NET 8, but now its basically the only real future choice for creating any kind of new Web App in .NET (excl. CDN Hostable, SSG Websites).

baz00 3y ago
Yeah, um, I was there for Silverlight and Web Forms. Also your last point is quite frankly crack smoking. You can still dump out perfectly good dynamic content with Razor and MVC.
- mythz 3y ago
  > Yeah, um, I was there for Silverlight and Web Forms. Silverlight's demise was inevitable along with the death of Flash and WebForms is a 20+ year old technology that was focused on retaining a Desktop App development model for the Web, an inferior abstraction which would have never lasted. Blazor is unlike either and delivers a great UX OOB. > You can still dump out perfectly good dynamic content with Razor and MVC. and you always will be, Blazor just has a superior component and development model, an official API for statically rendering components outside a Web Framework context and will eventually be what most of .NET will be using. Feel free to use whatever makes you happy, we still heavily use Razor Pages + SSG for our (CDN hosted) statically generated websites + docs, but will be predominantly using Blazor for new .NET Web Apps.
- stanac 3y ago
  I was there for silverlight and web forms as well. Web Forms had to die IMHO, it was unnecessary abstraction for those who didn't want to learn web. Silverlight on the other had was not (in my opinion) killed by MS but by browser vendors. It was the same time when flash and other plugin based tech died because browser vendors didn't want to support browser plugins. On the other had MS gave Silverlight 10 years of support when they announced the death of the tech, MS couldn't do anything else about it. If they waited long enough they could have ported silverlight to wasm today. I think there was a company offering dev tools for compiling silverlight to js and wasm, not sure if they are still around.

mgdev 3y ago

I would. MS has had a storied past when it comes to frontend tech, but rather than diverging and dying, what we seem to see now is convergence of a coherent technical vision (and some pruning as a result). They look the same on the surface, but the result is totally different. The latest version achieves exactly what every strung-together implementation of a moderately complex SPA architecture has aimed for in the past decade: fast initial render, low latency interactivity, low server load. They did it in a way that still plays moderately well with the existing JS ecosystem. They did in in a way where everything you do can be airlifted to the desktop or mobile via MAUI Blazor Hybrid. And some of the underlying pieces that are coming along to make this possible are incredible. (Go check out some of the stuff they're doing in the wasm/WASI space.)

baz00 3y ago
Have you tried to drag your shit through .Net classic to .Net core via all the stack changes and direction changes? Hell no. It has been horrible.
- mgdev 3y ago
  Let's call it the "messy middle" and see if we're on the other side of it. :)

jjice 3y ago

Are we talking web frontend, or can we extend this to desktop GUIs as well (that may be cheating, but bear with me). Windows Forms and WPF are both still supported. If you're a business built on Windows Forms (very productive for GUI development), you haven't had to worry. Even VB.NET is still supported, although not receiving active language additions. That said, I personally wouldn't choose to build on MS tech.

johnfn 3y ago

> Microsoft's track record of keeping front end tech alive Microsoft gave us TypeScript. I can't think of front-end tech with more care and attention given to it than TS. For over ten years!