3 ms·
"No one asked for this. My personal opinion" You didn't ask. It is, as you say, your personal opinion. From my POV, current Web is fine and the fact that brow
by inglor_cz 4y ago
"No one asked for this. My personal opinion"
You didn't ask. It is, as you say, your personal opinion.
From my POV, current Web is fine and the fact that browsers are powerful liberated us from writing specialized desktop apps for various OSes. I am much happier writing a Web UI than hacking together Win32 or Qt-based apps. Or, God forbid, AVKON Symbian OS UI. That was its own circle of hell.
- grishka 4y ago> liberated us from writing specialized desktop apps for various OSes I use macOS and I very much dislike anything built with cross-platform GUI toolkits, and especially the web stack. And it's always painfully obvious when something is not native. It doesn't behave like the rest of the system. It's not mac-like. It draws its own buttons from scratch and does its own event handling on them instead of using NSButton. I don't want that kind of "liberation". I want proper, native, consistent apps. Most other people probably do too, they just don't realize that or can't put it into words. The only counter-example out there known to me is IntelliJ-based IDEs. They're built with Swing, but they do somehow feel native enough. Also, developer experience is not a something users care about. And I'm saying that as a developer myself. Do use fancy tools to make your job easier, sure, but avoid those of them that stay inside your product when you ship it.
- matthew-wegner 4y agoHold up. It's been ~14 years since Apple shipped machines with 2GB of memory as base their base model. macOS (and iOS) have incredibly good screen reader support, as well as all of the things you're complaining about in your original comment at the top of this thread. Clearly those things are absolutely gobbling memory, and yet you don't seem to connect the dots that they're directly contributing to high memory requirements of macOS? I mean, 8GB on stock machines today is barely manageable. You can't buy a Mac with less than 8GB today; you can't even buy a phone with 2GB or less. I'm not sure you're in an position to rail against high-memory bloat in computing today. p.s. I say this as someone who uses macOS as their daily driver and has for a very long time
- grishka 4y agoScreen reader support by itself doesn't gobble memory. Android has had it for ages, and still runs on devices with less than 1 GB RAM (Android Wear watches). Running several instances of Chromium though... You'll probably run one anyway at all times as your actual web browser, but additional ones in the form of "oh so easy to build" Electron apps don't help. In Apple's eyes, though, you should absolutely ignore other browsers and use Safari exclusively. It might not be as much of a memory hog as Chrome — I haven't researched this, this is simply my guesses. I also heard that M1 Macs are better at memory management compared to Intel. Again, I don't have any concrete evidence to back this up, but knowing Apple, it's believable.
- Dylan16807 4y ago> I'm not sure you're in an position to rail against high-memory bloat in computing today. Nobody is a hypocrite for buying X gigabytes of ram but also wanting the naked operating system to use a much smaller amount, or wanting single programs to use a much smaller amount. > macOS (and iOS) have incredibly good screen reader support, as well as all of the things you're complaining about in your original comment at the top of this thread. Clearly those things are absolutely gobbling memory, and yet you don't seem to connect the dots that they're directly contributing to high memory requirements of macOS? What makes a screen reader gobble memory? And it definitely shouldn't gobble memory when it's not running.
- devinprater 4y agoMainly the TTS engine being ready for input, stuff like that. Of course you could go to Linux where you have to enable assistive technologies support before the whole desktop understands that they should work with screen readers. I'm guessing that there is where accessibility does take up RAM and resources.
- bee_rider 4y agoI don’t like the direction GUIs have gone either, and think the JavaScript-ization of everything has been pretty dumb. But it seems that bloat is doing well in the market. Users might not care about developer experience, but everything is a trade off: developer time is a cost, the cost of producing software is an input into how much it needs to cost. Users seem to want features delivered quickly, without much regard to implementation quality.
- grishka 4y agoUsers just don't have much say in the matter. Case in point: Discord and Slack are atrocious UX-wise. You're still forced to use them because, as with any walled-garden communication service, you aren't the one making this choice.
- blacklion 4y agoIt liberated you as developer. As developer, I could understand. As user I hate you. You never provide me as user with native experience via web UI. You use custom controls, which broke conventions of native controls a little bit there and here. You can not use full power of OS (YouTube or Spotify player doesn't pause itself when workstation is locked, my native player of choice does). You eat my resources. You cannot make your application consistent with application from other vendor, so I need to remember different pattern for different apps. Your typical browser app doesn't have ANY features for power users, like shortcuts for all commands and useful keyboard controls (not to mention full customization of these controls, toolbars, etc). Damn you and your laziness! But I understand, that most of my complains are complains of power user with 25+ years of experience and muscle memory, and I'm not target auditory for almost any new app. You win :-(
- inglor_cz 4y agoEverything is a trade-off. If, as a developer, you have to spend ungodly hours on learning multiple UIs, you will have less time left for the actual business logic of your app. Which, from the user's side, means one of the following three: a) nice looking, but less capable apps, b) more expensive apps, or, apps that have to be paid even if they could be free in an alternate universe, c) limited availability - app X only exists for Windows and not Mac, because either a Mac programmer isn't available or would be too expensive. Developing for multiple UIs at once is both prone to errors and more expensive, you wind up paying for extra developers, extra testers/QA, extra hardware and possibly extra IDEs and various fees. Such extra cost may be negligible for Google, but is absolutely a factor for small software houses outside the richest countries, much more so for "one person shows" and various underfunded OSS projects. I remember the hell that was Nokia Series 60 and 90 programming. Nokia churned out a deluge of devices that theoretically shared the same OS, but they had so many device-specific quirks and oddities on the UI level that you spent most of the time fighting with (bad) emulators of devices you could not afford to buy. This is the other extreme and I am happy that it seems to be gone forever.
- blacklion 4y agoIf your application can be useful on different OSes (and now there are only 3 OSes in existence, as porting Desktop application on Mobile requires completely different UI and UX no matter what technology you use!), break it into business logic and UI and find partner or hire developer who love to develop native UIs for other OS. MVC pattern is old and well known (though not fashionable now, I understand). OSS projects are completely different story, of course, no questions to OSS developers. I prefer to pay $200 for native application than $100 for Electron one. Oh, whom do I try to fool? Of course, it will be Electron app with $9.95/month subscription now :-(
- deleted 4y ago[deleted]