5 ms·
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,
by 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 agoThose 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 agoI'm strictly speaking of web FE.
- pjmlp 3y agoSure, 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 agoIf 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 agoI 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 agoFeels 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 agoMy 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 agoPorting 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).
- pjmlp 3y agoThe very fact that some code changes are required, regardless of how little, is a friction point. Doesn't matter how long they have been supported. If by "They all use same rendering language/interface (xaml)." you mean a XML based file format to describe the GUI layout, you are right. If on the other hand you mean a GUI description language that is compatible with zero code changes, then not really.
- cpitman 3y agoWeb 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 agoThe 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 agoI 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 agoWhy would you even want to write an immediate mode GUI in XNA?
- pjmlp 3y agoThe 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 agoWe're not burned out, we're just suspicious and conservative based on our years of experience of having the rug pulled out.
- pjmlp 3y agoOn 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 agoReally, I still use winforms and WPF. Winforms especially is going on 20ish years? How do you feel burned by them.
- pjmlp 3y agoTry to always move on to the newest one, every couple of projects, instead of using a 20 years old stack.
- nullindividual 3y agoSounds 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 agoIn consulting we don't have the privilege to use fossilised technologies, unless the customer asks for them.
- nullindividual 3y agoThere is no universal truth in consulting. Consultants still write COBOL.
- pjmlp 3y agoYou missed my unless part of the sentence.
- nullindividual 3y agoYou missed the first sentence of mine.
- pjmlp 3y ago
- lordgroff 3y agoOne 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.