> Nothing worked right.
One thing worked right: the app looked the same and acted the same everywhere where it could run.
One thing worked right: the app looked the same and acted the same everywhere where it could run.
Browser plugins could have been fixed to catch up, the VM itself wasn't the problem in terms of drain
Adobe Flex was interesting and not awful. The problem was the runtime.
And the company behind it. Who remains awful.
It took us good three years, it was eventually feature complete and used by 120 people on two local installations synchronised back then with Dropbox (hey, I didn’t know any better and it actually worked great over a hurricane m). We have replaced a home-grown COBOL app.
I don't know or care what apps would match on Windows. I don't use Windows. On the systems I do use, I want apps to look like they fit in.
Nothing against using the pre-built ui components provided by the OS, but looking down on a developer that decides to use something else? Just weird to me. A checkbox is a checkbox, it really doesn't matter whether App A's checkboxes look identical to App B.
Now, if App A's checkboxes look different than App A's other checkboxes, then I'll complain.
I don't understand why you'd be annoyed at different checkboxes within an app but not at different checkboxes between apps. Do you only ever use a single app? I constantly switch between many apps.
More importantly, having things behave the same makes everything much easier to use. If your checkboxes don't work the same way as the standard ones (and yes, this is a thing that happens) then that's a problem.
In addition to intentional behavior differences, you also have bugs. For an example close to my heart, Slack often loses its mind and destroys my input when I try to use the Undo functionality. This sort of bug would be impossible if they just used the standard UI widgets built into the OS, because the OS's widgets have competently implemented undo.
OS Widgets don't implement undo. Undo is inherently tied to app state and the developer is responsible for managing it. At most, the OS will give you an undo button/icon and you can use it to fit in visually.
Frankly, building a separate version of my app per platform to conform to your nativist standards is a huge waste of time. My UI will work across all target platforms. If you can't figure out interfaces that aren't straight out of an Apple/Microsoft design document, that's on you.
Have you actually built any native macOS apps? I have.
Sure, point taken. Native widgets might work differently than cross-platform ones. That said, there's no reason a cross-platform widget couldn't work identically to the native one.
Indeed, a platform's native widgets an effective way to give users a consistent style and functionality across apps from many developers.
Yet, as a one-man dev team, the cost of building a separate version for each platform is prohibitive. The choice is to disregard most platforms or disregard a small corner of the expectations each user has for apps on a given platform.
The choice was pretty obvious to me.
Ironically, out of the apps I use regularly, the ugly, misbehaving apps built with cross-platform frameworks are from big companies that could easily afford to do it right, like Slack. The apps I use that come from small indie developers are all native. I suppose this is down to competition. I tend to have a choice for those apps, so I can choose ones that work the way I like. For Slack, my choices are to use the app, use it on the web (same as using the app, more or less), or find a new job at a company that uses something else.