6 ms·

If you want the advantages of the garbage collector but the power of native there are languages like D, Go, Rust, Objective-C, Swift. If you want an "extremely

by ratww 6y ago

If you want the advantages of the garbage collector but the power of native there are languages like D, Go, Rust, Objective-C, Swift. If you want an "extremely fast, small and lightweight GUI framework" that also handles esoteric keyboards, RTL languages, screen reader accessibility and other things you can use your OSs native controls. I bet most naïve (and native) Cocoa/Win32 app will give you 100x better keyboard navigation than most Electron apps from large companies.

mwcampbell 6y ago
> I bet most naïve (and native) Cocoa/Win32 app will give you 100x better keyboard navigation than most Electron apps from large companies. That may be true for Cocoa, but it actually isn't for Win32. It takes work to make keyboard navigation work correctly in Win32, unless you're using a dialog with nothing but standard controls (note: dialog means something specific in Win32). Windows Forms helps with this. Also, as soon as you depart from the stock Win32 controls, you have to implement the UI Automation accessibility API entirely on your own, and that's not an easy task even for a single custom control. So there are actually good reasons why Win32 isn't a good choice for new projects. There's another reason why web applications tend to be more navigable with third-party Windows screen readers than native applications. For the mainstream web rendering engines, third-party screen readers enable a sort of virtual cursor that let's the user navigate the DOM in a linear way by pressing the up and down arrow keys. This makes it straightforward to navigate to anything in the document, even if the application itself doesn't implement keyboard navigation. Now, this same navigation model could just as well be applied to native applications, and the Narrator screen reader built into Windows actually does offer that option. The fact that third-party screen readers restrict that option to web content is arguably a deficiency, but one that developers who care about accessibility should consider when targeting Windows today. Disclosure: I work for Microsoft on the Windows accessibility team, primarily on UI Automation and Narrator. These are my own opinions though.

by ratww 6y ago

mwcampbell 6y ago

> I bet most naïve (and native) Cocoa/Win32 app will give you 100x better keyboard navigation than most Electron apps from large companies. That may be true for Cocoa, but it actually isn't for Win32. It takes work to make keyboard navigation work correctly in Win32, unless you're using a dialog with nothing but standard controls (note: dialog means something specific in Win32). Windows Forms helps with this. Also, as soon as you depart from the stock Win32 controls, you have to implement the UI Automation accessibility API entirely on your own, and that's not an easy task even for a single custom control. So there are actually good reasons why Win32 isn't a good choice for new projects. There's another reason why web applications tend to be more navigable with third-party Windows screen readers than native applications. For the mainstream web rendering engines, third-party screen readers enable a sort of virtual cursor that let's the user navigate the DOM in a linear way by pressing the up and down arrow keys. This makes it straightforward to navigate to anything in the document, even if the application itself doesn't implement keyboard navigation. Now, this same navigation model could just as well be applied to native applications, and the Narrator screen reader built into Windows actually does offer that option. The fact that third-party screen readers restrict that option to web content is arguably a deficiency, but one that developers who care about accessibility should consider when targeting Windows today. Disclosure: I work for Microsoft on the Windows accessibility team, primarily on UI Automation and Narrator. These are my own opinions though.