22 ms·

I hope and believe that some great companies and teams will use LLMs to build higher quality software. We built Electron because writing UIs using native deskt

by dom96 1mo ago

I hope and believe that some great companies and teams will use LLMs to build higher quality software. We built Electron because writing UIs using native desktop frameworks is tough. Is it still tough? Surely LLMs make it easier to use and so we will end up with faster and more native feeling applications. What about having a couple of ideas of what might make a feature feel good? Well now you can make multiple prototypes fast and pick the best one. Your users get the best one. I hope to build software this way in the future.

judge2020 1mo ago
Idk, OpenAI themselves released some weird Electron app to replace their native version of ChatGPT on mac https://www.siliconreport.com/openais-chatgpt-mac-update-shifts-to-electron-drawing-criticism-for-degraded-interface-08b8c6c355ee45ba https://www.siliconreport.com/openais-chatgpt-mac-update-shi...
- criddell 1mo ago
  That was such a weird move for them to make. If you have AIs that are good at building software, then use them to build great software! Instead they choose lowest-common denominator solutions that are okay everywhere but not great anywhere.
krapp 1mo ago
>We built Electron because writing UIs using native desktop frameworks is tough. Is it still tough? Surely LLMs make it easier to use and so we will end up with faster and more native feeling applications. We built Electron because web devs were a dime a dozen. It was an economic decision, not a technical one.
sharts 1mo ago
You would think so. But it seems all that everyone is obsessed with is increasing the velocity of enshitification in the hopes of becoming the next papa Elon
WhiteDawn 1mo ago
It will be a push and pull and I'm curious where we'll be in a couple of years. I can fly at 100mph if I let AI run loose and with a bit of steering I can get it to output what I'm looking for and generally pass verification and tests. If I care about the code though, and I want to keep it maintainable, the amount of time and tokens I need to spend correcting and iterating on the output quickly eats through much of the initial time I saved, to the point where I'm unsure if I'm actually saving much time at the end of the process. With hobby projects I lean on quality more, and the async nature of AI also makes this much easier to make progress without needing my full attention to do so. In the corporate world, there's both the pressure to accelerate with AI, but also maintain code and product quality. The dials of one way or the other are more obvious now, but I don't believe it's possible to do both with the current models and harnesses without exponential cost. What is interesting though, is I'm now leaning towards faster models rather than smarter ones. Intelligence lets me bite off larger chunks of work at once, and trust the model to behave without having to watch it intensely, but doesn't seem to drive down the number of iterations required to hit my desired quality. Faster models means the iterations I'll have to go through regardless will complete much faster and gets me closer to a proper flow state. Models will keep improving, but maybe we're getting near "smart enough" and the race will pivot to performance > intelligence.
- user43928 1mo ago
  I also spend a lot of time at work trying to get the code into a shape I deem acceptable to open a MR for the team, without looking incompetent. At home I stopped reviewing the code for my mobile app, and I do not feel this has affected maintainability. With 150k LOC, the AI still performs changes as easily as it did three months ago, when I started the project. If anything, the new models made it easier. When I read all those posts from people advocating a very hands-on, understand each line approach, I speculate many come from a position like me at work or have never seriously tried 'vibecoding' a large project from scratch with SOTA models. People routinely post that things I work on for 30 hours/week are impossible.
  - callc 1mo ago
    150k sounds like a LOT… what’s your use case for the app? It seems for any particular problem/comexity there is an estimate of how many LoC is needed (written by humans, good coding practices). And after reaching maturity (and not increasing scope) the LoC converges. My experience with LLMs so far is it’s a constant battle to not explode the LoC. There’s always pressure away from “maintainability” and a “small elegant cohesive” codebase.
dlcarrier 1mo ago
Cross-platform widget engines (Tk, GTK, Qt, wxWidgets, etc…) long predate Electron and have always been robust, stable, well documented, and easy to use. It's not creating a single application for multiple native desktop environments that was difficult, it's writing a single application as both a web interface and a native desktop environment on any platform that's difficult. Because CSS is constantly changing, inconsistently implemented, and difficult to use, it can't easily be targeted by widget engines (although Qt has tried, and maybe others) and web browsers already exist, so webview environments like Electron are the quickest way to get a cross-platform installable application that can also be hosted on a web server. I wouldn't really call it native though.
- dom96 1mo ago
  I've used GTK in the past and I wouldn't consider it robust nor easy to use. But most importantly, it doesn't look good, especially on macOS. No matter how hard you try, you cannot make it feel native. But the point is: LLMs should make it easy to generate a native UI for each of the main platform's UI frameworks. GTK should no longer be needed.
  - dlcarrier 1mo ago
    GTK is probably the worst of the bunch, and Tk is the most underrated. Everything looks bad on macOS, because Cocoa's API isn't as stable or well documented as Microsoft's DirectWrite and GDI variations nor obviously X or Wayland, which are open source. Either way, getting something to appear the way you want it to in GTK is worlds easier than doing so in CSS, and it runs much faster, with a fraction of the resources.
bigstrat2003 1mo ago
> We built Electron because writing UIs using native desktop frameworks is tough. No, we built Electron because there are a huge number of people who are too lazy to learn anything outside of HTML/etc for creating a UI. It's not actually hard to make a UI using the native desktop frameworks.
- tripleee 1mo ago
  It's not hard.. unless you're also expected to know, and be learning 100,000 other things at the same time.
- dom96 1mo ago
  I don't think that's the reason. The fact is that HTML/CSS gives far more flexibility for design than any native framework has ever done. Also, nope, it's not easy to make a UI using native desktop frameworks, especially if you need to target all 3 platforms.

by dom96 1mo ago

judge2020 1mo ago

Idk, OpenAI themselves released some weird Electron app to replace their native version of ChatGPT on mac https://www.siliconreport.com/openais-chatgpt-mac-update-shifts-to-electron-drawing-criticism-for-degraded-interface-08b8c6c355ee45ba https://www.siliconreport.com/openais-chatgpt-mac-update-shi...

criddell 1mo ago
That was such a weird move for them to make. If you have AIs that are good at building software, then use them to build great software! Instead they choose lowest-common denominator solutions that are okay everywhere but not great anywhere.

krapp 1mo ago

>We built Electron because writing UIs using native desktop frameworks is tough. Is it still tough? Surely LLMs make it easier to use and so we will end up with faster and more native feeling applications. We built Electron because web devs were a dime a dozen. It was an economic decision, not a technical one.

sharts 1mo ago

You would think so. But it seems all that everyone is obsessed with is increasing the velocity of enshitification in the hopes of becoming the next papa Elon

WhiteDawn 1mo ago

It will be a push and pull and I'm curious where we'll be in a couple of years. I can fly at 100mph if I let AI run loose and with a bit of steering I can get it to output what I'm looking for and generally pass verification and tests. If I care about the code though, and I want to keep it maintainable, the amount of time and tokens I need to spend correcting and iterating on the output quickly eats through much of the initial time I saved, to the point where I'm unsure if I'm actually saving much time at the end of the process. With hobby projects I lean on quality more, and the async nature of AI also makes this much easier to make progress without needing my full attention to do so. In the corporate world, there's both the pressure to accelerate with AI, but also maintain code and product quality. The dials of one way or the other are more obvious now, but I don't believe it's possible to do both with the current models and harnesses without exponential cost. What is interesting though, is I'm now leaning towards faster models rather than smarter ones. Intelligence lets me bite off larger chunks of work at once, and trust the model to behave without having to watch it intensely, but doesn't seem to drive down the number of iterations required to hit my desired quality. Faster models means the iterations I'll have to go through regardless will complete much faster and gets me closer to a proper flow state. Models will keep improving, but maybe we're getting near "smart enough" and the race will pivot to performance > intelligence.

user43928 1mo ago
I also spend a lot of time at work trying to get the code into a shape I deem acceptable to open a MR for the team, without looking incompetent. At home I stopped reviewing the code for my mobile app, and I do not feel this has affected maintainability. With 150k LOC, the AI still performs changes as easily as it did three months ago, when I started the project. If anything, the new models made it easier. When I read all those posts from people advocating a very hands-on, understand each line approach, I speculate many come from a position like me at work or have never seriously tried 'vibecoding' a large project from scratch with SOTA models. People routinely post that things I work on for 30 hours/week are impossible.
- callc 1mo ago
  150k sounds like a LOT… what’s your use case for the app? It seems for any particular problem/comexity there is an estimate of how many LoC is needed (written by humans, good coding practices). And after reaching maturity (and not increasing scope) the LoC converges. My experience with LLMs so far is it’s a constant battle to not explode the LoC. There’s always pressure away from “maintainability” and a “small elegant cohesive” codebase.

dlcarrier 1mo ago

Cross-platform widget engines (Tk, GTK, Qt, wxWidgets, etc…) long predate Electron and have always been robust, stable, well documented, and easy to use. It's not creating a single application for multiple native desktop environments that was difficult, it's writing a single application as both a web interface and a native desktop environment on any platform that's difficult. Because CSS is constantly changing, inconsistently implemented, and difficult to use, it can't easily be targeted by widget engines (although Qt has tried, and maybe others) and web browsers already exist, so webview environments like Electron are the quickest way to get a cross-platform installable application that can also be hosted on a web server. I wouldn't really call it native though.

dom96 1mo ago
I've used GTK in the past and I wouldn't consider it robust nor easy to use. But most importantly, it doesn't look good, especially on macOS. No matter how hard you try, you cannot make it feel native. But the point is: LLMs should make it easy to generate a native UI for each of the main platform's UI frameworks. GTK should no longer be needed.
- dlcarrier 1mo ago
  GTK is probably the worst of the bunch, and Tk is the most underrated. Everything looks bad on macOS, because Cocoa's API isn't as stable or well documented as Microsoft's DirectWrite and GDI variations nor obviously X or Wayland, which are open source. Either way, getting something to appear the way you want it to in GTK is worlds easier than doing so in CSS, and it runs much faster, with a fraction of the resources.

bigstrat2003 1mo ago

> We built Electron because writing UIs using native desktop frameworks is tough. No, we built Electron because there are a huge number of people who are too lazy to learn anything outside of HTML/etc for creating a UI. It's not actually hard to make a UI using the native desktop frameworks.

tripleee 1mo ago
It's not hard.. unless you're also expected to know, and be learning 100,000 other things at the same time.
dom96 1mo ago
I don't think that's the reason. The fact is that HTML/CSS gives far more flexibility for design than any native framework has ever done. Also, nope, it's not easy to make a UI using native desktop frameworks, especially if you need to target all 3 platforms.