4 ms·

> basically every platform has a much better way to create an app for it I accidentally spent 4 hours writing a reply to your point here and it ended up being

> basically every platform has a much better way to create an app for it I accidentally spent 4 hours writing a reply to your point here and it ended up being too long for HN's comment length limit, but I posted it to pastebin: https://pastebin.com/n6AGB62L https://pastebin.com/n6AGB62L > The web is seriously so lacking on several trivial fronts that it is laughable That depends on your project's requirements. Speaking from personal experience, my main beef is that HTML web-forms still lacks a loit of widgets necessary for RAD that native UIs have had for decades, like comboboxes, true hierarchical menus, RTF or Markdown text editing (because `contenteditable` is horrible), and so on. ...however, if you're enthused enough it's very possible and quite straightforward now to create your own controls and widgets from scratch, which is what Electron apps like Slack do. Of course, when you do, you're condemned to having to maintain them for eternity, but that's a cost of doing business. > layouting being one example Actually I was going to say that's exactly where CSS outshines platforms like WPF, XAML, even Cocoa (not to mention Swing and AWT - I can't speak for JavaFX as I've never used it). I agree that for most of the past 20 years CSS has been a pain for so many layout issues ("how do I vertically center a div?" is probably the #1 question repeatedly asked on StackOverflow), but CSS's flexbox and CSS grid have been supported by all major browsers for almost a decade now and I can confidently say that I can build an aesthetic design with a layout that adapts to changing window/screen dimensions and aspect-ratios in a fraction of the time it would take me to do in any native framework. Consider that 1990s-era frameworks like VB6, WinForms, etc were all fixed-layout and required you to write your own repositioning logic in resize-event-handlers. WinForms didn't get anchored-layout until 2005! Post-2000s frameworks like Swing and WPF added layout containers, but they're far from perfect and don't support radical re-layouting. More modern frameworks that use constraint-based layout or support major relayouting (like SwiftUI and WinUI 3, to an extent) are appealing, but I find offer few real advantages over CSS's layout model. A major personal win for CSS is the content/behaviour/presentation separation (<div>-itis, not withstanding). Compared to WPF where a single XAML file will mix content, behaviour, and presentation elements, attributes, and controls without any regard for separation-of-concerns or maintainability (WPF does have CSS-esque Styles, but despite the name suggesting they're strictly presentational they're not: they're invariably used to control behaviour (due to XAML's ugly and unusable template and trigger ceremony) and also content (due to how content-based templates are used). > while goddamn WinForms could deal with it through inheritence. But that's where the failures of inheritance becomes obvious: consider WinForm's own Checkbox control. Surprisingly, the Checkbox is actually a subclass of Button, and shares no relationship with the intuitively similar Radio control despite their very similar visual appearance and behaviour. WinForms' design (like most other OOP-based frameworks) shoehorn both UX behaviour and visual appearance into a single OOP inheritance tree. This only works up-to-a-point, then things quickly fall-apart.

kaba0 5y ago
Thanks for the long and very informative answer! I recommend actually posting your full comment, so that it becomes longer-lived. And I have to agree on the CSS part, I mostly meant the older times without flexbox et alia. Perhaps it is generally true of web technologies but they seem to have fixed many of their numerous mistakes in recent years (JS being quite okay as well nowadays).
- DaiPlusPlus 5y ago
  > I recommend actually posting your full comment, so that it becomes longer-lived. Alright, here goes... PART 1: > basically every platform has a much better way to create an app for it Yes and no. On macOS and iOS, using Apple's first-party, in-box UI frameworks/libraries like Cocoa, Cocoa Touch, SwiftUI is the best, and only, way to make a lovable user-experience on macOS and iOS. The downside is that if your application needs some ultra-specific widget that Apple hasn't already made in Cocoa then you've got a lot of legwork to do, especially w.r.t. painting in your NSView subclass. Despite Cocoa's very modern and sophisticated aesthetics, it's still fundamentally a very 1990s OOP widget library based around composing and subclassing opaque view objects. On Linux (and in ancient-times: UNIX environments like CDE): the native desktop app UX story has always been a hot-mess simply due to UNIX specs like POSIX not getting involved in the GUI side, and despite some OS vendors trying to be consistent (rip SGI) the widget/library vendors never had any incentive for consistency. While GTK is considered Linux's "default" widget set today, there are still other equally-native but entirely separate widget toolkits (Motif, Xaw, etc) that developers are free to use - so there is no one true way to build a native GUI for Linux today, or at least, not one readily suitable for 1990s-style RAD, in my experience. On Windows... well, that's where Microsoft has somehow taken Windows from being its (imo) Windows XP heydays: a platform with a (relatively nice) coherent and single widget set (i.e. USER32 and ComCtl32) - with occasional third-party libs like Delphi's VCL. (Other things, like MFC, ActiveX, .NET's WinForms, and so, were just slightly-more-usable wrapper libraries over Win32/USER32/ComCtl. The fundamental unit of a GUI in Win32 is the hWnd (Window Handle), which represents some rectangle on the screen managed by Windows' window-manager (which can be a top-level window with a titlebar etc, or a composed arbitrary rectangle for a composed widget, such as a button or checkbox: Windows has always supported this high-level composition of hWnds, but with severe limitations tied to its dependence on GDI (e.g. when you're using separate hWnds for separate controls then those controls can't have z-axis alpha-blending when overlapping - and you can't do deep-color painting as GDI is fundamentally limited to 32-bit ARGB). By the early 2000s it was to clear to everyone, including Microsoft, that a modern replacement was needed - which we saw in the original Windows Longhorn demos of 2003: Windows Longhorn (then Vista) now had a true compositing window-manager[1] which allowed applications to get top-level hWnds (and without any of GDI's legacy tentacles around them) which then could be used as a render-target directly from Direct3D for high-performance, yet windowed, 3D applications[2] (OpenGL support came later). This was crucial for the design of WPF (Avalon)...

kaba0 5y ago

Thanks for the long and very informative answer! I recommend actually posting your full comment, so that it becomes longer-lived. And I have to agree on the CSS part, I mostly meant the older times without flexbox et alia. Perhaps it is generally true of web technologies but they seem to have fixed many of their numerous mistakes in recent years (JS being quite okay as well nowadays).

DaiPlusPlus 5y ago
> I recommend actually posting your full comment, so that it becomes longer-lived. Alright, here goes... PART 1: > basically every platform has a much better way to create an app for it Yes and no. On macOS and iOS, using Apple's first-party, in-box UI frameworks/libraries like Cocoa, Cocoa Touch, SwiftUI is the best, and only, way to make a lovable user-experience on macOS and iOS. The downside is that if your application needs some ultra-specific widget that Apple hasn't already made in Cocoa then you've got a lot of legwork to do, especially w.r.t. painting in your NSView subclass. Despite Cocoa's very modern and sophisticated aesthetics, it's still fundamentally a very 1990s OOP widget library based around composing and subclassing opaque view objects. On Linux (and in ancient-times: UNIX environments like CDE): the native desktop app UX story has always been a hot-mess simply due to UNIX specs like POSIX not getting involved in the GUI side, and despite some OS vendors trying to be consistent (rip SGI) the widget/library vendors never had any incentive for consistency. While GTK is considered Linux's "default" widget set today, there are still other equally-native but entirely separate widget toolkits (Motif, Xaw, etc) that developers are free to use - so there is no one true way to build a native GUI for Linux today, or at least, not one readily suitable for 1990s-style RAD, in my experience. On Windows... well, that's where Microsoft has somehow taken Windows from being its (imo) Windows XP heydays: a platform with a (relatively nice) coherent and single widget set (i.e. USER32 and ComCtl32) - with occasional third-party libs like Delphi's VCL. (Other things, like MFC, ActiveX, .NET's WinForms, and so, were just slightly-more-usable wrapper libraries over Win32/USER32/ComCtl. The fundamental unit of a GUI in Win32 is the hWnd (Window Handle), which represents some rectangle on the screen managed by Windows' window-manager (which can be a top-level window with a titlebar etc, or a composed arbitrary rectangle for a composed widget, such as a button or checkbox: Windows has always supported this high-level composition of hWnds, but with severe limitations tied to its dependence on GDI (e.g. when you're using separate hWnds for separate controls then those controls can't have z-axis alpha-blending when overlapping - and you can't do deep-color painting as GDI is fundamentally limited to 32-bit ARGB). By the early 2000s it was to clear to everyone, including Microsoft, that a modern replacement was needed - which we saw in the original Windows Longhorn demos of 2003: Windows Longhorn (then Vista) now had a true compositing window-manager[1] which allowed applications to get top-level hWnds (and without any of GDI's legacy tentacles around them) which then could be used as a render-target directly from Direct3D for high-performance, yet windowed, 3D applications[2] (OpenGL support came later). This was crucial for the design of WPF (Avalon)...