731–740 of 777 posts
Earlier quoted context omitted.
Thunderbird isn't a native app, for the record. It's a web application similar to an Electron application, but with extra steps.
Last time I looked, Thunderbird was about: - 1/3 C/C++ - 1/3 Javascript - 1/3 everything else (XML, CSS, etc) known to humanity
My father was right about so many things. The one I have in mind right now is when he said "age is another form of strength against the nitwit, because those with experience see straight through those with misplaced confidence."
He was right. I'm not calling anyone here a nitwit or anything, please be clear on that.
It's just amazing how wrong some of you are, while sounding so absolutely sure of yourselves. A few don't even get easily researched technical details correct, while trying to sound authoritative.
My point is that maybe this is related to why software development is in the sorry state it is in today: the ignorant are confident they know it all, and the knowledged are confident that they know very little.
Earlier quoted context omitted.
For comparison, I just opened up an org-mode file in Aquamacs (Emacs with macOS native GUI) and it weighs in at 105MB, which is actually lower than I would have guessed.
I am running Emacs on macOS, and it only takes 43 MB barebones, and my regular setup takes about 81 MB. Both opening the same org-mode file. Point being that it really depends on what you choose to run on Emacs, and it does not have to be about 100 MB. Just to add to that, I don't think anyone should be concerned about their text editor taking 200 MB anymore. I doubt it is worth worrying about.
(I use PhpStorm and Visual Studio Pro and Rider as my main foreground apps. If Jetbrains products used a mere 200 MiB, I would be worried that something had broken and reset them or reinstall them. But they're not text editors.)
I will come at this from a different, philosophical perspective: Web apps come from a tradition of engaging the user. This means (first order) to keep people using the app, often with user-hostile strategies: distraction, introducing friction, etc. Native desktop apps come from a tradition of empowering the user. This means enabling the user to accomplish something faster, or with much higher quality. If your app dis…
What a perfect HN reply. Webapp bad. Native good. No justification. Just a bunch of generalizations. Gmail empowers me. Wikipedia empowers me. Github empowers me. Of course native application are important. You don't need to rely on those moralistic justifications.
I disagree, therefore the stuff you wrote didn't exist. I mean, don't you think it's a little rude? Think first, engage keyboard later.
Earlier quoted context omitted.
source https://www.statista.com/statistics/272595/global-shipments-...
Sales shrunk doesn't mean usage shrunk. Replacement cycle of PC should be getting longer due to enough performance.
I'm finally upgrading from an Intel Sandy Bridge processor after nine years, and I still don't need to - it's cranking along pretty well as a dev and gaming machine still.
Earlier quoted context omitted.
Qt may not 'look' native, but it has native performance, whereas Electron really doesn't.
The difference between "Qt native" and " native native" (e.g. Win32 or Cocoa) is still noticeable if you pay attention, although it's not quite as obvious as between Electron and the former. (Likewise, applications using the JVM may also look very convincingly like native ones, but you will feel it as soon as you start interacting with them.)
You're fundamentally mistaken about where Qt sits in the stack - it effectively sits in the same place as USER32/WinForms in Windows or NS/Cocoa GUI widgets of OSX. It is reasonable to think of it as an alternative native GUI library in that sense. If it is slower, it's because an implementation of something is slower, not because of where it lives or an abstraction cost.
Qt pretty much draws using low-level drawing APIs on the respective platform. And although Qt itself is not written in the most performance sensitive C++, it is still orders of magnitude faster than most (and it's not like Chrome doesn't pay overhead) - people rag on vtable dispatch speed but jeez its still orders of magnitude faster than something like ObjC which served Apple quite well for years.
The performance of a Qt app is more likely a function of the app itself and how the app developers wrote it.
But no, you're not noticing any micro-seconds differences in C++ overhead for Qt over "native native" - and you're basically comparing the GUI code of the platform - since Qt does it's own rendering. Win32 is mostly pretty good, NS is a mixed bag, and Gtk+ is basically a slug. In all cases there is some kind of dynamic dispatch going on, because that is a fundamental pattern of most GUI libraries. But dynamic dispatch is almost never a factor in GUI render performance. Things like recalculating sizes for 1 million items in a table on every repaint are the things that get people into trouble, and that is regardless of GUI library.
Earlier quoted context omitted.
> Meanwhile, your web app may not be as good as native apps, but at least you don't have to write it 6 times. I must be living in a parallel world because I use a ton of desktop apps that aren't "written 6 times" - and write a few, including a music & other things sequencer ( https://ossia.io ). Just amongst the ones running on my desktop right now, Strawberry (Qt), Firefox (their own toolkit), QtCreator (Qt), Telegr…
QT is excellent, but C++ is quite a tough pill to swallow for many. Especially as QT layers a macro system on top. I predict that native desktop apps will make a comeback when there's QT-quality cross-platform framework in a more approachable language (Rust, nim, or similar).
Earlier quoted context omitted.
> I wasn’t a developer back then. That explains your inaccurate perspective. > Windows NT required a multiple more RAM to run than the consumer versions of Windows (oh no, bloat!), and was much more picky about what hardware it ran on. Allow me to claim that that is also not true, in the form you state it. Again, I've lived through all this, and I can tell you what that was about. The "pickiness" of NT was even at th…
> That explains your inaccurate perspective. Yep, you really succeeded at empathy, there. /s > reasonable price range The word “reasonable” is doing a lot of work, here. Most Pentium II systems were not running Windows NT. They were running Windows 95 or 98, which had arbitrarily severe limitations and lacked memory protections. So, while it was technically possible to run lots of applications simultaneously on 256 M…
Once again: only somebody using a computer not selected for serious development used Windows 95 and 98. No developer who knew what he was doing was using Windows 95 and 98 as his primary development machine. So if you complain about that, you used the wrong tool for your work. Like I've said, it was easy to install Windows NT, and I don't know any computer which wasn't able to run it, if it had reasonably enough RAM.
> on 256 MB of RAM
To illustrate "reasonably" once again, that changed at these times: I remember buying an AMD-based notebook in 2002 with 256 MB and running absolutely without problems Windows 2000 on it for a few years, before upgrading to 512 MB, which was the maximum for that notebook. And that was the time of Pentium III and IV, not Pentium II, and like I've said, I've run Windows NT on 8 MB computers, all with compilers, resource editors, debuggers and even IDE. And even before, I've run Windows 3.11 on 2 MB computer and used that for development too (the development tools being in text mode, of course).
> some buggy program has destabilized the system into needing to reboot to run properly again
Only on non-NT systems, and surely not developer tools. I used Windows 3.x and Windows 9x, and never had to reboot due to the developer tools "making system unstable." Not even on a 4 MB or a 16 MB machine.
> web browsers crashed a lot
I've used both Mosaic and Netscape, and before 2000 my main problem was surely not them crashing. Surfing mostly worked (only the pages loaded slowly, there were no CDNs then). Again, on a NT system.
As a long-time Win32 developer, my only answer to that question is "of course there is!" The efficiency difference between native and "modern" web stuff is easily several orders of magnitude; you can write very useful applications that are only a few KB in size, a single binary, and that same binary will work across 25 years of OS versions. Yes, computers have gotten faster and memory and disks much larger. That does…
You might have used these words as a way to say "way faster", but factually you are incorrect. several orders of magnitude = thousands of times faster. No way.