FRESH
Hacker News
Hacker News Hacker NewsThe first thing you need when you make something new is making it work, it is much better that it works badly than having something not working at all.
Take for example the Newcomen engine, with an abysmal efficiency of half a percent. You needed 90 times more fuel than an engine today, so it could only be used in the mines were the fuel was.
It worked badly, but it worked. Later came efficiency.
The same happened with locomotives. So bad efficiency at first, but it changed the world.
The first thing AI people had to do is making it work in all OSes. Yeah, it works badly but it works.
We downloaded some Clojure editor made in java to test if we were going to deploy it in our company. It gave us some obscure java error in different OSes like linux or Mac configurations. We discarded it. It did not work.
We have engineers and we can fix those issues but it is not worth it. The people that made this software do not understand basic things.
We have Claude working in hundreds of computers with different OSes. It just works.
Most of those Electron folks would not manage to even write C applications on an Amiga, use Delphi, VB, or whatever.
Educated on node and do not know anything else.
Even doing a TUI seems like a revelation to current generations, something quite mudane and quite common on 1980's text based computing of Turbo Vision, Clipper and curses.
This mentality creates a worse experience for end users because all applications have their own conventions and no one wants to be dictated to what good UX is. The best UX in every single instance I've encountered is consistency. Sure, some old UIs were obtuse (90% weren't) but they were obtuse in predictable ways that someone could reasonably navigate. The argument here is between platform consistency and application consistency. Should all apps on the platform look the same, or should the app look the same on all platforms?
edit: grammar
I don't think it's that native has nothing to offer. I think that developing (in case of desktop) for 3 different platforms all with own complication of what is native UI is a nightmare. macos has swiftui (incomplete), uikit and appkit, linux in practice gtk/qt, windows winui 3 (fundamentally broken) with WPF and WinForms still hanging around .
On one hand I also lament the amount of hardware-potential wastage that occurs with deep stacks of abstractions. On the other hand, I've evolved my perspective into feeling that the medium doesn't really matter as much as the result... and most software is about achieving a result. I still take personal joy in writing what I think is well-crafted code, and I also accept that that may become more niche as time goes on.
To me this shift from software-as-craft to software-as-bulk-product has some similarities to the "pets vs cattle" mindset change when thinking about server / process orchestration and provisioning.
Then also on the dismay of JS becoming even more entrenched as the lingua franca. There's every possibility that in a software-as-bulk-product world, LLM-driven development could land on a safer language due to efficiency gains from e.g. static type checking. Economically I wonder if an adoption of a different lingua franca could manifest by way of increasing LLM development speed / throughput.
Sublime Text feels so much snappier than VSCode, for another example. And I can leave it running for weeks without it leaking memory.
I get it, but this is a bit dramatic.
One of the biggest challenges I've found with using non-native tools (and specifically the various frameworks that let you write JavaScript that compile to Native code) is that there is much less of a guarantee that the 3rd party solution will continue support for new OS versions. There's much less of a risk with that with 1st party solutions.
Additionally, those 3rd parties are always chasing the 1st part vendor for features. Being far behind the regular cadence of releases can be quite inconvenient, despite any advantages initially gained.
To read ePubs, however, I was able to write a PWA leveraging epub.js because no native APIs were required.
Sure, native applications can be hard and slow to develop for a number of reasons, but OS vendors are seriously incentivized to have developers build on their platform.
> Native APIs are terrible to use, and OS vendors use everything in their power to make you not want to develop native apps for their platform.
Disagree. I'm most familiar with Windows and Android - but native apps on those platforms, snd also on Mac, look pretty good when using the default tools and libraries. Yes, its possible to use (say) material design and other ux-overkill approaches on native, but thats a choice just like it us for web apps.
And OS vendors are very much incentivised to make natuve development as easy and painless as possible - because lock-in.
> That explains the rise of Electron before LLM times,
Disagree. The "rise of Electron" is due to the economics of skill-set convergence on JS, the ubiquity of the JS/HTML/CSS/Node stack platform, and many junior developers knowing little or nothing else.
As for the rest: minor variations in traffic light positioning and corner radii are topical but hardly indicators of decaying platorms.
Though I haven't tested it too much other than building small personal tools like a work habit tracker, it's very well documented and looks great. Gave me a good excuse to try the language again as well.
[0]: https://www.gpui.rs/
But who cares ?
Electron Apps are cute. A really really ugly looking native application won't have all that nice CSS.
Cross platform development is significantly faster with Electron.
The only ones complaining have the know how to use cli Claude code so, side from a few bloggers no has an issue with this.
Of course, the React ecosystem and community is enormous. I bet if I was building something complex, I would have gotten frustrated building it all from scratch in SwiftUI when I could just reach for a React component library.
Making five different apps just to claim "native" doesn't seem like a great choice, and obviously for now, delivering new claude features takes priority over a native graphics framework, so electron makes sense. But that doesn't mean it'll be on electron forever.
Ultimately, Claude having limitations is an issue. They can't just point it at the code base and ask it to make it faster.
That's just mythical past, in reality you had the full variety of garbage with basic things broken (hello, blurry native text if poor users decide to adjust screen resolution to match his vision, and text is the most basic of the basics of UI). Only today many of those issues are wrapped in a browsers, so many times more inefficient (though, to be fair, making it harder to mess some of the basics through a concentration of dev efforts on one platform)
> the more apps used native look and feel, the better user experience was across apps
This is especially atrociously deep one, that default look of Windows was ugly and the feel - unergonomic, and user experience doesn't magically become better if you stick to the ugliness. And for important productivity apps it also doesn't become better if you stick to the unergonomic - as, you know, there are two sides in a coin, and "familiarity" isn't the only nor even the most important factor.
> The real reason is: native has nothing to offer.
It offers the same things it always has - the potential to be performant and integrated (with better baseline), just as OS god intended (but OS devil intervened) And the counter here is too shallow
> There’s no technical reason why
There is, bad abstractions that make it harder to be performant is a technical reason for poor performance.
> Web apps can be faster, too, but in practice, nobody cares.
Is just very shallow. "Can" is useless alone, you need to engage with all the other major factors that affect reality, not ignore everything at the level of a theoretical "can"
> What makes you think it’ll be different once the company decides to move to native?
Well, reality? There are literally the same companies with the same apps that were different before switching!
it’s about cost. develop once, deploy everywhere. web solved that. web devs are a dime-a-dozen (i’m not saying web dev is bad… just that it’s a saturated market) so the cost is already scraping the bottom of the barrel.
now, compare this to deploying native apps, we need:
- a macOS dev/team
- a windows dev/team
- a linux dev/team
- a web dev/team
- testers for each of those platforms
- coordination between the teams so the UI looks consistent
that’s a 4-5x larger staff
AI is a force multiplier, sure.. but it’s not a 10x force multiplier. it’s 2x at best, but probably 1.5x in practice (and averaged across the board).
1. locked up files ==> that's for security, which wasn't an issue in the 1990s.
2. inconsistent look ==> people are embedding browsers inside apps for all sorts of reasons, ruining the "native" UI/UX even if the OS "look" were stable.
It took a while, but once again open source and the web kinda won, though if you like consistency, then I agree it's a pyrrhic victory...
It can even create a beautiful Java Swing apps.
Start times are atrocious, long conversations literally break rendering (and I’m using the desktop app on a MacBook Pro with an M3 Pro CPU and 36 GB of RAM so an electron app shouldn’t feel so janky so frequently, right?).
IMHO they just don’t care right now (and I get it from their perspective) but I’m pretty sure there’s a lot of low hanging fruit they could fix to make the experience 5x or even 10x smoother. Claude Code (TUI) is also another memory hog and I’ve even had Ghostty literally crash with enough open sessions.
Fortunately Anthropic models are also incredibly so at least I’ve been able to speedrun my own desktop client using Tauri and fix many of the issues I encounter every day. I might release it at some point.
My eyes! The goggles, they do nothing!
Electron is a native wrapper for web content. The wrapper is still native.
> Native APIs are terrible to use, and OS vendors use everything in their power to make you not want to develop native apps for their platform.
I'm honestly not quite sure what the author means here.
Web APIs are equally “terrible” in my opinion. In any case, you have to release an Electron app on Mac the same way you release any native app on Mac. The benefit of using web APIs is not that they are non-terrible but that you can share the same code as your website. And of course you can more easily find web developers than native developers. But that has nothing to do with whether or not the API is terrible. It’s just supply and demand.
I’ll take AppKit and autolayout any day over CSS, ugh. CSS is the worst.
https://news.ycombinator.com/item?id=36060678
I really doubt that at this point. Developers have learned that everything Microsoft says to do for Windows, since 2012, will be garbage within a few years. Guaranteed.
Learned Silverlight for Windows Phone development? Too bad, it's UWP now. And the XAML is incompatible.
Learned WinRT for Windows 8/8.1 app development? Too bad, it's UWP now. And the XAML is incompatible.
Packaged your App for APPX? Too bad, it's MSIX now.
You learned how to develop UWP apps? Too bad, the User Interface layer has been ripped out of UWP, it's now called WinUI 3, and it doesn't even run on UWP. Better port your UWP app back to Win32 now, I guess. Why did you even learn UWP again?
You went and learned WinUI 3 like we recommended? Well, unlike WinUI 2, it doesn't have a visual designer, and it doesn't have input validation, or a bunch of other WinUI 2 features. So, depending on what your app needs, you might have a mix of UWP and Win32, because WinUI 2 is UWP-exclusive and WinUI 3 is Win32-exclusive and neither has all the features of the other. Progress!
You built your Windows 8 app with WinJS? Well, sucks to be you, rewrite it in entirety, WinJS was scrapped.
You ported your app from iOS with Project Islandwood? Well, again, that sucks. It was brilliant, it made pulling apps over from iOS much easier, but it's dead. Rewrite!
You decided to hang it all, develop for good old WPF, but wanted to use the Ink Controls from UWP? Great, we developed a scheme for that called XAML Islands which made so you could have some of the best UWP controls in your old app. Then we released WinUI 3, completely broke it, and made it so complicated nobody can figure it out. So broken; even the Windows Team doesn't use it and is writing the modern Windows components for File Explorer with the old version.
But of course, that would require WinUI 2, for UWP, inside Win32 which is the main feature of the broken WinUI 3; which means that the Windows Team has a bastardized version of XAML Islands for their own use that nobody else has (literally), to modernize the taskbar and File Explorer and built-in apps like Paint, that nobody who wants to emulate them can borrow. Their apps don't look modern and their users complain? Suckers, go learn WinUI 3, even though our own teams couldn't figure it out.
You wanted your app on the Microsoft Store? Well, good news, package it together with this obtuse script that requires 30 command-line arguments, perfect file path formats, and a Windows 10 Pro License! Oh, you didn't do that? Do it 5 years later with MSIX and a GUI this time! Oh, you didn't do that? Forget the packaging, just submit a URL to your file download location. Anyone who bothered with the packaging wasted hours for no real purpose.
Did I mention Xamarin? A XAML dialect of its own, that supports all platforms. But it runs on Mono instead of the authentic .NET, so you'd better... work around the quirks. Also it's called MAUI now, and runs on .NET now. But that might break a few things so hang around for over a year's worth of delays. We'll get it running for sure!
Oh, and don't forget about ARM! The first attempt to get everyone to support ARM was in 2012 with a Windows version called... No, no, no. Go past this. Pass this part. In fact, never play this again. (If you want to imagine pain, imagine running Windows and Microsoft Office on a ARM CPU that came three generations before the Tegra X1 in the Nintendo Switch. Surface RT ended with a $900M write-off.)
And so on...
Or, you could just ignore everything, create a Windows Forms (22 years strong) or WPF app (17 years strong), and continue business like usual. Add in DevExpress or Telerik controls and you are developing at the speed of light. And if you need a fancier UI, use Avalonia, Electron, React, or Flutter.
It's the incentives and everything is a trade off. Time to market, performance, features: none of these choices are made in a vacuum. Oh, and people like to go home and see their families once in a while.
As a developer of over 35 years, I feel like I hear the same arguments over and over again. "Programmers used to care about performance!" No they didn't, they just had no choice because computers sucked and you had to work on performance or your application would barely run. "Progammers used to care about the quality of their code!" Really. You apparently never worked on legacy systems with years of hacks and spaghetti code that took an afternoon to trace through just to figure out what it was doing.
People haven't changed. Kids aren't lazier these days. The incentives are always just to ship as fast as possible. Performance will be dealt with when and if it is so bad that the customer complains and not a moment sooner.
When I was much younger I fancied myself a "craftsman" of software. But any "craft" I was able to bestow on my software was in spite of the surrounding incentives not because of them. Software is closer to assembly line work than craftsmanship and LLMs are just driving that point home faster and harder than ever.
I still love software development after all these years but it's entirely because I love solving problems and computers still fascinate me the same as they did when I got my first TRS-80 Color Computer at age seven. Nobody that's not a programmer cares as long as the software does what they need it to and does fast enough that they don't start wonder why they have to use this piece of crap software in the first place.
It can't die soon enough. Doesn't all have to be Electron, but web tech for the win and force everything to the browser unless you'd like to write it twice.