131–140 of 281 posts
How do you deal with zero day vulnerabilities? To me the biggest concern using browser-as-a-desktop solution is that there will be quite a lag between when Chrome patches zero days vs when it gets released. ex) nw.js, electron.
Then this project sounds perfect for you because it's not a browser, it's Qt5 but called via APIs that JS developers are used to.
Earlier quoted context omitted.
20 MB is less than 0.25% of my desktop machine's memory, and 2% of a 2010-era netbook. 20 MB, while much larger than what it has to be, is tiny even by the standards of decade-old computers. RAM is cheap and plentiful. If you don't use it, its value is almost zero (the "almost" comes from OS-level caching of files and CPU-level cache misses of code).
> RAM is cheap and plentiful. If you don't use it, its value is almost zero (the "almost" comes from OS-level caching of files and CPU-level cache misses of code). I have fond memories of my DOS days and the simplicity inherent in a single tasking environment, however nowadays operating systems allow for more than a single application to run at the same time and each application should play nice with the system resou…
Yes, you shouldn't be a bad neighbor, but the OS will generally move things around to accommodate you as necessary. RAM is an afterthought for most of these applications for a reason.
This attitude is like buying a sports car and never redlining it.
Earlier quoted context omitted.
That blog post does speak to me, but 20MB for a program with a truly functional, modern UI doesn't outrage me that much. IMO there's a tradeoff: we could be writing all our programs in C, still. But it would be enormously difficult and there'd be way more bugs. On the other end of the spectrum we can be lazy, use web tech everywhere and never optimise our ballooning JS codebases. This feels like it's at least somewhe…
As mentioned in the other comment, emacs does those things, and so does Vim (with plugins of course). I moved from sublime to atom to VS code, but eventually settled on Vim because I was able to get the same features (that I used) while getting almost instant response. A feeling that has completely changed how much I enjoy writing any sort of text.
For C/C++, could use QT Creater or KDevelop too, which I think are pretty good in latency.
Earlier quoted context omitted.
That blog post does speak to me, but 20MB for a program with a truly functional, modern UI doesn't outrage me that much. IMO there's a tradeoff: we could be writing all our programs in C, still. But it would be enormously difficult and there'd be way more bugs. On the other end of the spectrum we can be lazy, use web tech everywhere and never optimise our ballooning JS codebases. This feels like it's at least somewhe…
As mentioned in the other comment, emacs does those things, and so does Vim (with plugins of course). I moved from sublime to atom to VS code, but eventually settled on Vim because I was able to get the same features (that I used) while getting almost instant response. A feeling that has completely changed how much I enjoy writing any sort of text.
But eventually wasn't able to get the same code completion, and searching was also a bit more painful.
How do you go about that? Would you mind sharing your setup? :)
This looks nice ! However... "Low CPU and memory footprint (...) memory usage is under 20 MB for a Hello World program" : I am the only one who still thinks this is huge ? (-> https://tonsky.me/blog/disenchantment )
20 MB is less than 0.25% of my desktop machine's memory, and 2% of a 2010-era netbook. 20 MB, while much larger than what it has to be, is tiny even by the standards of decade-old computers. RAM is cheap and plentiful. If you don't use it, its value is almost zero (the "almost" comes from OS-level caching of files and CPU-level cache misses of code).
Also HN: "The MacBook Pro is worthless if I can't get it with at least 64GB of RAM."
Earlier quoted context omitted.
> Electron does not provide that much more desired features than apps from 25 years ago. That's true, but advanced GUI features aren't Electron's selling point. It's used because it offers easy portability and the ability to leverage web-dev skills.
What does Electron offer in terms of portability that SDL2 doesn't have?
With the disclaimer that I don't know a lot about this: Electron has solid support for both desktop and mobile targets. I don't think Qt's mobile support is as good, but I might be mistaken.
Maintainer here – Happy to answer any questions!
This looks nice ! However... "Low CPU and memory footprint (...) memory usage is under 20 MB for a Hello World program" : I am the only one who still thinks this is huge ? (-> https://tonsky.me/blog/disenchantment )
That blog post does speak to me, but 20MB for a program with a truly functional, modern UI doesn't outrage me that much. IMO there's a tradeoff: we could be writing all our programs in C, still. But it would be enormously difficult and there'd be way more bugs. On the other end of the spectrum we can be lazy, use web tech everywhere and never optimise our ballooning JS codebases. This feels like it's at least somewhe…
No need for that - you could use Zig or Rust. Though both need a better GUI frameworks, but it's certainly more efficient with them.
Earlier quoted context omitted.
Strongly agree. Hello World apps are great but it would be even better to see a Hello World tutorial that can actually be distributed to customers. You probably also need auto-update, native installers, code signing (notarization on Mac) and the ability to build native modules cross-platform. This is a super-interesting project though.
Both the App Store and Microsoft Store deal with installs and updates, no need for custom wrappers. Not sure about Linux.