Comment by com2kid
7 days ago
> Even with help from the "world's best" LLMs, things didn't go quite as smoothly as we had expected. They hallucinated steps, missed platform-specific quirks, and often left us worse off.
This shows how little native app training data is even available.
People rarely write blog posts about designing native apps, long winded medium tutorials don't exist, heck even the number of open source projects for native desktop apps is a small percentage compared to mobile and web apps.
Historically Microsoft paid some of the best technical writers in the world to write amazing books on how to code for Windows (see: Charles Petzold), but now days that entire industry is almost dead.
These types of holes in training data are going to be a larger and larger problem.
Although this is just representative of software engineering in general - few people want to write native desktop apps because it is a career dead end. Back in the 90s knowing how to write Windows desktop apps was great, it was pretty much a promised middle class lifestyle with a pretty large barrier to entry (C/C++ programming was hard, the Windows APIs were not easy to learn, even though MS dumped tons of money into training programs), but things have changed a lot. Outside of the OS vendors themselves (Microsoft, Apple) and a few legacy app teams (Adobe, Autodesk, etc), very few jobs exist for writing desktop apps.
You left out the next lines, which add some important context:
> Then we tried wrapping a NextJS app inside Electron. It took us longer than we'd like to admit. As of this writing, it looks like there's just no (clean) way to do it.
> So, we gave up on the Mac app.
They weren't writing a fully native app. They started with a NextJS web app and then tried to put it inside Electron, a cross-platform toolkit.
All the training data in the world about native app development wouldn't have helped here. They were using a recent JS framework and trying to put it in a relatively recent cross-platform tool. The two parts weren't made to work together so training data likely doesn't exist, other than maybe some small amount of code or issues on GitHub discussing problems with the approach.
I thought that was odd too. There are lots of ChatGPT clones implemented as native MacOS apps.
The main advancement in TFA is using the new Container Swift API for local tool use. That functionality would probably be a welcome contribution to any of these:
https://github.com/Renset/macai
https://github.com/huggingface/chat-macOS
https://github.com/SidhuK/WardenApp
https://github.com/psugihara/FreeChat
I think they started with what they knew (web app development) and then wanted to wrap it into a standalone app later.
> This shows how little native app training data is even available.
FWIW, we have very few desktop native apps nowadays. Most apps are either mobile, cli or web-based. Heck, I’m sure there’s more material online on writing cli apps than gui apps.
I mean outside of HPC why would you when the browser is the world’s most ubiquitous VM?
Because the browser is gross and you can reclaim lot of performance and security when you don't need to use it.
Sure but you're also constrained to only one platform. It's like the C++ vs Python argument in ML, yes writing everything in low level high speed highly optimized native code would be perfect, but ain't (almost) nobody got fucking time or skill for that.
5 replies →
I mean, why aren't the apps on your phone all just webapps, right? (Also, eww)
5 replies →
A lot of us just don't want to be web developers. I mostly write IEC 61131 code, with sprinkles of BASIC (yuck), C, Perl, and Lisp. I've used JavaScript and quite frankly, you can keep it.
Does anyone else think javascript bad? Wow brave!
1 reply →
If you want something better than UI designed for toddlers
Offices when the performance matters against shitty web apps.