Hacker News new | ask | show | jobs
by cladopa 108 days ago
I would say that the real reason is because "it works". As simple as that.

The 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.

6 comments

Related to your answer, I would say the reason is that it works good enough for now and it can always be patched later. Back in the good old days that we remember, software was frozen on a gold master disc, which was then tested for weeks or months before its public release. The fact that bugs could not easily be fixed in the field meant they would incur support costs or lost revenue with people returning their purchased software box.

In my opinion that is the true reason why the old native software was developed to such a high standard. But then once online stores and shrink wrap agreements made it impossible to return buggy software, then the financial incentives shifted towards shipping a partially broken product.

Who cares about pleasing with good performance when you can instead keep customers hostage?

Your examples of engines are less about "it works" as more that it does a thing we couldn't do before and it works better than the previous thing. But neither of those are especially true of react.

React was an instant hit because it had the facebook brand behind it and everyone was tired of angular. But ultimately, react has worse outcomes for developers, users, and businesses. On the web, react websites are bloating. They run slower, their javascript payloads are larger, and they take longer to load.

Your suggestion -- that it works and then it gets more efficient later -- would make sense if we lived in a world where react moved off the virtual dom model. A virtual dom is a fine first attempt or prototype but we can do better. We know how. Projects like SolidJS do do better. React has not caught up, but it is still very popular. This whole "It worked badly, but it worked. Later came efficiency" thing is complete nonsense.

And there are loads of businesses that started off with an angular app, started to migrate to react, then started to migrate to react hooks, now switching to whatever the latest methodology is. Time and again you find these products, always endlessly migrating to the new thing, most of them never finishing a migration before beginning a new one. So these products end up being a chimera of four different frameworks held together with pain.

This isn't a good outcome for businesses, or for users, and it's not a good developer experience. react is stagnant and surviving off of being the default or the status quo and supported by tech companies that have long since stopped innovating and subsist on rent seeking. Developers choose react because nobody was ever fired for buying IBM and because they can look busy at their job, and because they buy a new phone and laptop every year with the latest hardware that can compensate for the deteriorating software they ship.

> React was an instant hit because it had the facebook brand behind it and everyone was tired of angular.

Ok, but why was everyone tired of Angular? Sure, web frameworks are examples of Fad Driven Development to the extreme, but Angular.js, was pure unmitigated ARSE.

Made ten bindings on a page? That's 100 cross connections. Made 100 two-way bindings? that's 10000 connections.

Clicked one way through fields A, B then started typing, they show same data. Clicked through fields A and C, now they are bound but B isn't. Clicked B then C, congrats all three of your bindings suddenly start filling in.

It was a combination of shitty performance scaling and unintuitive Angular data flow that primed everyone for React to take over.

I would prefer the old-school approach to wrapping the "Claude bits" in a per-platform framework (or if you really can't be bothered, a platform-specific command-line tool that could then be called natively from the program).

The UI wrapper then could be Electron, or something a little more platform-native you hand off to some junior engineers.

> The 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.

It is better for something to not exist than for a shitty version to exist. Software doesn't get better over time, it gets worse. If you make a bad, suboptimal choice today chances are that solution becomes permanent. It's telling that all of your examples of increasing efficiency are not software.

If are aren't going to do it well, don't do it.

obscure java error? Clojure editor made in Java?

Are you sure it wasn't just an unfamiliarity with Java errors in general?

Clojure popped out of the _senior_ Java camp. It often lives within that mindshare.

They could have done better. They chose the path of least resistance, putting in the least amount of effort, spending the least amount of resources into accomplishing a task.

There's nothing "good" about electron. Hell, there are even easier ways of getting high performance cross platform software out there. Electron was used because it's a default, defacto choice that nobody bothered with even researching or testing if it was the right choice, or even a good choice.

"It just works". A rabid raccoon mashing its face on a keyboard could plausibly produce a shippable electron app. Vibe-bandit development. (This is not a selling point.) People claiming to be software developers should aim to do better.

> They could have done better. They chose the path of least resistance, putting in the least amount of effort, spending the least amount of resources into accomplishing a task

You might as well tell reality to do better: The reality of physics (water flows downhill, electricity moves through the best conductor, systems settle where the least energy is required) and the reality of business (companies naturally move toward solutions that cost less time, less money, and less effort)

I personally think that some battles require playing within the rules of the game. Not to wish for new rules. Make something that requires less effort and resources than Electron but is good enough, and people will be more likely to use it.

Shaming the use of electron? I'll do that every day and twice on sunday. Same with nonsense websites that waste gigabytes on bloat, spam users with ads, and feed the adtech beast. And I'll lay credit for this monument to enshittification we call the internet at the feet of Google and Facebook and Microsoft.

Using electron and doing things shittily is a choice. If you're ever presented with a choice between doing something well and not, do the best you can. Electron is never the best choice. It's not even the easiest, most efficient choice. It's the lazy, zero effort, default, ad-hoc choice picked by someone who really should know better but couldn't be bothered to even try.

What alternative did you have in mind when you said there are even easier ways of getting high-performance cross-platform software built?
The power move would have been Cosmopolitan, or a package similar to it.

https://github.com/jart/cosmopolitan

Cosmopolitan can be used to bundle up any gui package, and your code, and a team of professional software devs should be able to cope with it just fine. You end up with a native executable with a slightly bigger package to ship, since it's carrying executables for various platforms, but you'd effectively have the same code and behavior everywhere. A few extra megabytes, instead of whatever the hell electron is doing. They could also use Java, or even one of the electron type clones that attempt to be better, like Tauri.

The point isn't that electron is so awful. It's that the company with the purportedly best coding AI and one of the best overall AI models in the world chose to do the absolute tawdriest, cheapest, even laziest thing without any consideration of what the right thing to do might be, or what thing they could do that demonstrated their excellence and mastery of craft, or at a bare minimum, the advanced capabilities of the AI.

Cursor used claude to build a browser from scratch; it's not like their AI couldn't do it.

I don’t code, so I’m well out of my league but this point of “premier coding AI company should showcase its capabilities by using their own model to build superior software” rings true to me, right? Especially as we start to discuss AI as more dangerous than nuclear weapons yet it can’t even do that?

Who’s got the rebuttal to this?

It might be a strange thing to say, but Java is still viable alternative route. You can build a nice and fast cross-platform desktop application on it today. The language was designed for this kind of things. The entry barrier is quite high though.
I might hate Qt apps more than I hate Electron so I'm curious about the answer too.
Whats is wrong with Qt apps? Take too little RAM?
As a recent toe-dipper into linux (now running Arch on a powerful minipc and KDE plasma) I'm shocked at how little progress has been made on the native UI side.
Please do continue to waste energy on doing something that will do nothing but allow you to feel superior about yourself. In fact, you will probably waste more energy than Electron ever has.
I agree with you, I even think it's shameful. When I saw it was elctron, I sighted so long I almost choked. Can't even cmd+g nor shift+cmd+f to search, context menu has nothing. Can't even swipe, no gestures etc. ELctron is better than nothing, and I'm grateful, but it tastes bitter. As for performance, somebody if I remember correctly, once asked here "what's the point of 512GB RAM on the mac Studio?" And then someone replied "so you can run two electron apps".