4 ms·

> it's a working strategy across nearly a half-century. I don't believe it's working, at all, when all these teams end up building GUI with Elektron (ironical

> it's a working strategy across nearly a half-century. I don't believe it's working, at all, when all these teams end up building GUI with Elektron (ironically owned by Microsoft now). It means that developers have very little confidence in all these MSFT technologies.

WorldMaker 5y ago
Nah, it just means that Electron is the new Java is new VB6 is the new FoxPro is the new Pascal is the new… Every era of computing has had its "frowned upon" tools for building software that were productive to a class of developer that needed to get stuff done and couldn't "afford" the "right" tools. Electron kind of proves the strategy is still working more than it proves the strategy is not working. Windows itself doesn't care if you build a UI in Win32 or Electron or XAML or Tcl/Tk or DirectX or bubble gum and duct tape for that matter. That's the strategy: let developers do what they want (for the most part). That's still working as a strategy even if you as a user don't like Electron, or you as a user hate that Electron apps don't look like Win32 apps don't look like XAML apps. "Consistent designs" isn't working, but "software written in late 1990 something in VB6 against Win32 still works in 2022" is a working strategy. As a developer, you have choices, even if that choice is to use Electron or to use VB6 to build apps in 2022 despite the VB6 IDE itself not running or supported in any Windows after Windows XP (the runtime is still supported for eternity, but development tools are stuck).
- throw_m239339 5y ago
  The fact that Microsoft has produced all these half baked UI frameworks that rapidly go unmaintained is a demonstration that this "strategy" isn't one at first place. MSFT doesn't know what they are doing.
  - WorldMaker 5y ago
    The ones I mentioned? What are you talking about? More than half of them were never built by Microsoft in the first place (including Electron). For the most part in its history Windows has officially only ever had 3 UI frameworks: Win16, Win32, and WinRT (or WinUI if you prefer to call it that). Win16 was shut down in the 32-bit transition (but had a compatibility path that lasted for many years following the transition). Win32 has a lot of individual "sub-frameworks" based on the decade the software was written in, but overall is still "maintained", but "stable". WinRT has had some hurdles with branding/naming/messaging/developer support, but that is in part because is very actively maintained and still growing and in part because Win32 is still maintained and legacy code developers don't want Microsoft to forget it/leave it behind, worsened by Microsoft taking too long to nail down a transition more like Win16 to Win32 in "soft" forward compatibility and relatively known end date (end of 16-bit processor support). They've put a lot of work in the "soft" forward compatibility in recent years, though partly in detriment to the "relatively known end date" (in Windows 8-10 it was "as more things move to mobile, HoloLens, Xbox" and in Windows 11 it is now "????").

WorldMaker 5y ago

Nah, it just means that Electron is the new Java is new VB6 is the new FoxPro is the new Pascal is the new… Every era of computing has had its "frowned upon" tools for building software that were productive to a class of developer that needed to get stuff done and couldn't "afford" the "right" tools. Electron kind of proves the strategy is still working more than it proves the strategy is not working. Windows itself doesn't care if you build a UI in Win32 or Electron or XAML or Tcl/Tk or DirectX or bubble gum and duct tape for that matter. That's the strategy: let developers do what they want (for the most part). That's still working as a strategy even if you as a user don't like Electron, or you as a user hate that Electron apps don't look like Win32 apps don't look like XAML apps. "Consistent designs" isn't working, but "software written in late 1990 something in VB6 against Win32 still works in 2022" is a working strategy. As a developer, you have choices, even if that choice is to use Electron or to use VB6 to build apps in 2022 despite the VB6 IDE itself not running or supported in any Windows after Windows XP (the runtime is still supported for eternity, but development tools are stuck).

throw_m239339 5y ago
The fact that Microsoft has produced all these half baked UI frameworks that rapidly go unmaintained is a demonstration that this "strategy" isn't one at first place. MSFT doesn't know what they are doing.
- WorldMaker 5y ago
  The ones I mentioned? What are you talking about? More than half of them were never built by Microsoft in the first place (including Electron). For the most part in its history Windows has officially only ever had 3 UI frameworks: Win16, Win32, and WinRT (or WinUI if you prefer to call it that). Win16 was shut down in the 32-bit transition (but had a compatibility path that lasted for many years following the transition). Win32 has a lot of individual "sub-frameworks" based on the decade the software was written in, but overall is still "maintained", but "stable". WinRT has had some hurdles with branding/naming/messaging/developer support, but that is in part because is very actively maintained and still growing and in part because Win32 is still maintained and legacy code developers don't want Microsoft to forget it/leave it behind, worsened by Microsoft taking too long to nail down a transition more like Win16 to Win32 in "soft" forward compatibility and relatively known end date (end of 16-bit processor support). They've put a lot of work in the "soft" forward compatibility in recent years, though partly in detriment to the "relatively known end date" (in Windows 8-10 it was "as more things move to mobile, HoloLens, Xbox" and in Windows 11 it is now "????").