6 ms·
Nah, some developers are lazy, that is all, lets not dance around the bush with that one. Most of those Electron folks would not manage to even write C applica
by pjmlp 9mo ago
Nah, some developers are lazy, that is all, lets not dance around the bush with that one.
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.
- reactordev 9mo agoThey wrote a React TUI renderer, that’s what they did. Shame… I understand why, but there is such beauty in the simplicity of ansi.
- pjmlp 9mo agoThe company that supposedly is selling that AI can do everything to replace us.
- esafak 9mo agoI see no contradiction. You could get replaced by an agent that spews out React TUIs; as if corporate buyers are going to care about the difference!
- reactordev 9mo agoThat’s the hard swallow. End users only care about the UX and it working. They don’t care how succinct your code is. They indirectly care about its performance.
- fragmede 9mo agoEven then, the people paying for the product aren't even the users. See also: Microsoft Teams.
- zadikian 9mo agoAt least it seems like a lot more apps are cross-platform than before. I wouldn't call the native devs lazy for not making a Mac version of their Windows app.
- pjmlp 9mo agoAgreed, yet back in the day we even managed to do that with applications being written in Assembly, in some cases. Uphill both ways, should be easy for a company doing C compilers with LLMs.
- codebje 9mo agoEarly games frequently took the approach of inventing an interpreted machine code in which the bulk of the game would be written, with an assembly interpreter that would need to be rewritten for each target IA and modified for the specific peripheral mixes of each target machine. The approach runs slower than a game written directly in assembly, but the cost to port to different architectures is much lower. Sort of like Electron trades off native performance and look-and-feel to make multi-platform apps much more achievable. IMO the OS vendors failed everyone by refusing to even attempt to agree on a common API for UI development, paving the way for web browsers to become the real OS and, ultimately, embedded browsers to be the affordable and practical way to be cross platform.
- paulryanrogers 9mo agoExcept the OS's don't even ship a consistent enough browser engine. (Standards be damned.) So apps ship their own browser over and over again.
- zadikian 9mo agoYeppp. Is there no way for Electron apps to use a shared engine if one is available?
- 9mo ago
- Iolaum 9mo agoIn an age where LLM's start writing applications why would this matter?
- pjmlp 9mo agoYet another reason to have those LLMs create native applications, should be easy apparently.
- avbanks 9mo agoI agree, this is clearly an indictment against LLMs. If LLMs and agents were capable they'd 100% write it natively but they realize the current limitations.
- robinwassen 9mo agoI have tested this and they are very capable, replacing the modern windows calc (38mb mem) with an identical app (ux, looks, features, accessibility, localization) ended up with an app using 2MB memory. You just need to point it in the right direction (c/rust/go etc) and be harsh with the requirements, especially memory usage. If I was Microsoft I would use AI for this rather than badly embedding AI everywhere, a lot of power users would be overwhelmed by a win 11 update where OS apps/features dropped mem usage by 90%+
- mathw 9mo agoIt would be excellent to reduce Windows memory requirements using the very tools which are making memory so expensive... Oh wait no that would be incredibly painful for everyone. Yes reducing memory requirements would be great but not at that cost.
- sehugg 9mo agoRealize, though, that just grabbing a frame buffer is not a thing anymore. To render graphics you need GLES support through something like ANGLE, vectors and fonts via Skia, Unicode, etc. A web browser has those things. Any static binary bundling those things is also gonna be pretty large. And JavaScript is very good at backwards compatibility when you remove the churn of frameworks (unfortunately Electron doesn't guarantee compatibility quite as far back)
- pjmlp 9mo agoAnd CPUs are only sand powered by electricity. I do realise the need for abstractions and they do exist, provided there is actually the interest to learn them.
- dist-epoch 9mo agoI've programmed in every native Windows GUI starting with MFC. Used Delphi too. I've even created MS-DOS TUI apps using Turbo Vision. Compared to the web stack and Electron, native GUI APIs are complete shit. Both for the programmer, but also for the user. Reactive UI (in the sense of React, Vue, ...), the greatest innovation in UI programming ever, was made popular by web-people. Unless you write some ultra-high performance app like a Browser, a CAD app, a music production app, it doesn't make any sense to use native GUIs. Takes longer to program, the result is uglier and with less features. And for those ultra high performance apps you don't use the native UI toolkit anyway, you program your own widgets since the native ones are dog shit and slow.
- VorpalWay 9mo agoDon't forget about all the embedded UIs (kiosks, appliances, car infotainment, industrial equipment, ...), those computers are weaker and it makes a ton of sense to use native toolkits there. They tried to replace our Qt GUI at work in this space with a react based one, the new UI ran like utter shit comparatively, even after a lot of effort was spent on optimisation. Also, most of the world don't use high end developer laptops. Most of the world is the developing world, where phone apps on low end Android phones reign supreme.
- wolvesechoes 9mo agoJust serialize and deserialize your JSON bro, so much faster and easier
- pjmlp 9mo agoInteresting, I have the exact opposite opinion, and I also have to deal with Web since 1999. React is no innovation at all, some folks got a bit enthusiastic with Haskell reactive programming papers.
- wolvesechoes 9mo agoI think it is somewhat similar to how victims of domestic violence rationalize what happens to them. No way someone really used Delphi and claims that it is faster to build UI with HTML/CSS/JS stack.
- __alexs 9mo agoThis is such a lazy take. Electron is very easy to deliver a good quality app for everything but absolute power users. Yes it's horribly slow but it enables rapid experimentation and it's easy to deliver the wide range of UI integrations you are likely to want in a chat-esq experience.
- dangus 9mo agoIt’s not even horribly slow. It works fine. It’s just a chat program. It’s the right trade off for the job. Doing more work for no reason is stupid even if you the have money of a small nation. The inevitable differences between platforms you get with all native everything isn’t a good user experience, either. Now you need to duplicate your documentation and support pages and have support staff available to address every platform. And what’s the payoff? Saving 80MB of RAM? Gaining milliseconds of latency that Joe Business will never notice as he’s hunt and pecking his way through the interface? I thought we were done with Electron hate articles. It’s so 2018 to complain about it. It’s like talking about millennials and their skinny jeans. Yawn.
- hyperman1 9mo agoI'm dealing with MS Teams, which is for me a chat and video app. It uses 2GB of RAM, which is more thand my local postgresql. It must sit there in the background wasting 2/16 of my laptop or people can't reach me. And if MS stopped randomly moving things around in the UI with no benefit whatsoever, their documentation could be usefull instead of telling me where I could find some setting 3 years ago.
- nottorp 9mo agoI think Teams is one of the few apps where we can’t just blame JavaScript induced incompetence. Someone needed actual malice to write that monster.
- hedgehog 9mo agoLet's assume for the moment the developers are doing about the best they can for the goals they're given. The slowness is a product decision, not an engineering problem. They are swimming in cash and could write a check to solve the problem if they cared. Evidence is they have other priorities.
- pjmlp 9mo agoCaring now that is an interesting word, it is clear they don't care about their customers hardware, or user experience, only themselves.
- hedgehog 9mo agoTo be fair to all involved I'm committing a bit of a category error here, a company of any size is not so much a coherent entity as a flock of individuals with their own motivations. As the popular saying goes: the company ships its org chart.
- tracerbulletx 9mo agoGo replace discord, slack, and vscode natively then. If everyone is crying out for the superior missing and obviously better alternative then that's a great opportunity.
- eviks 9mo agoWhat if pursuing that opportunity exceeds the risk appetite / budget of the person you're suggesting this to, by about a billion, and even then has the exact same potential to be corrupted by the organizational dynamics that resulted in the current generation of sloppy designs?
- pjmlp 9mo agoI have already. Don't use Discord, never plan to. Even if I cared, I would only use the browser as it should be. Slack only lives on the browser, as it should. VSCode is only used when there are no SDKs for my editors or IDEs, and I am forced into VSCode. However contrary to Electron crap, VSCode at least has tons of external processes written in a mix of C++, Rust and C#, and parts of it have moved into WebGL, not the traditional Electron crap application.
- Rebelgecko 9mo agoI thought Discord bans people for using alternate clients?
- paulddraper 9mo ago> Even doing a TUI seems like a revelation to current generations Ironic statement, given that Claude Code is exactly that. So maybe Claude could have used another cross-platform desktop development framework, but Electron was better/faster.
- pjmlp 9mo agoncurses then
- senadir 9mo agoDo you think that writing Delphi, a language no one is buying, makes you hardworking?
- pjmlp 9mo agoIf no one would be buying Delphi, Embarcadero would not be in business, yet here they are. https://www.embarcadero.com/products/delphi https://www.embarcadero.com/products/delphi One of the related conferences just took place last October, https://entwickler-konferenz.de/en/ https://entwickler-konferenz.de/en/
- Ygg2 9mo agoThere is a difference between being in business and thriving. I've been in a few companies that managed to eke out a living by maintaining a piece of software no one in their sane mind would still maintain. Sometimes a government gig, sometimes the private sector. Shoutout to my boys that in 2018 maintained a Java 1.3 app. Still going strong to this day (it was migrated to Java 8 last time I checked). EDIT: ~21 Delphi apps in world! Woohoo! Delphi number #525
- pjmlp 9mo agoThat is a poimt of view, besides it was you that decided to pick on Delphi, it could have been C, VB, the random technology that falls under whatever. > Most of those Electron folks would not manage to even write C applications on an Amiga, use Delphi, VB, or whatever.
- Ygg2 9mo agoSure, either of them qualifies. I was just pointing out that Delphi (and C, and VB) aren't really widely used in GUI toolkits anymore. It's not just the difficulty. It's the lack of learning materials, widgets, examples, and whatnot. Debuggers also suck, at least they did when I used Delphi. What also helps is having a huge behemoth of a corporation improving your GUI toolkit for free (Chromium, although you pay in ad exposure).
- nsonha 9mo agoYou mean writing simplistic forms so full of side effects they need to be written in a "native" framework? Sounds like good engineering.
- anon7000 9mo agoThe article concludes with > The real problem is a lack of care. And the slop; you can build it with any stack. so you agree.
- sharts 9mo agoFacts. The sad reality is everyone wanting to have fancy looking pages/apps as quickly and easily as possible. And now, the web (and increasingly desktop) is littered with the lowest common denominator of platforms with all sorts of crazy optimizations that still can’t be as snappy as a Windows 95 app on a 200mhz / 16MB desktop. At this point we may as well just use electron and nodejs for fighter jets and missile defense systems. Surely it’s fast enough for that, too.
- Ygg2 9mo agoWhat's the alternative for cross-platform GUIs? Qt? Swing? Avalonia? Electron is bad, but it's the least bad of all other cross-platform GUIs. > Most of those Electron folks would not manage to even write C applications on an Amiga, use Delphi, VB, or whatever. That's true of most people on the planet. No one has access to them.
- port11 9mo agoI think your view is lazy. The article explains some of the actual reasons, none of which have to do with laziness. I’ve built for Electron and did a course on Swift for macOS apps. Not out of laziness, but I don’t think I’d ever build native for Macs. And the Windows folk have been complaining for a long time about the native APIs. Now, native on mobile, that’s something else. I’ve been stuck on RN/Expo because that’s what the resources the business had allowed for, but native Kotlin is much more enjoyable (AFAIK). Swift… dunno, still icky.
- JKCalhoun 9mo agoFTA: "Looks could be good, but they also can be bad, and then you are stuck with platform-consistent, but generally bad UI (Liquid Glass ahem)." Since the discussion was specifically about platform-consistency, odd that the author would decide that personal taste might take priority over platform-consistency. "It changes too often, too: the app you made today will look out of place next year, when Apple decides to change look and feel yet again." Seems to be arguing the exact opposite? If you adopt a native API for controls, windows, etc., your app will change next year to look completely in place (perhaps for better or worse according to the author). Going DIY on UI and your app might still, in 2026, have brushed aluminum and "lickable" buttons.
- port11 8mo agoI read it as criticism on how the native APIs don’t give you a sure-fire way of getting to a consistent native UI. Case in point is Apple’s own software, with some of its apps looking completely out of place despite being built on native UI.