Hacker News Reader

Comment by ladberg | Hacker News Reader

This would be sooo much worse from a UI point of view. All nice OS features (good text rendering, uniform text editing interface, accessibility, transparency) would all get chucked out the window.

I also don't think Godot is inherently more performant for any random UI than Electron is. It happens that most Godot apps are performant because they're made by the type of people who want to use videogame engines and thus care about performance. Electron can definitely have great performance when the developers care about performance (VSCode).

I say all this as someone who's worked on game engines before.

View on HN

I have never encountered an Electron app that can even display the results of keystrokes in a timely manner, and that includes vscode. All Electron apps waste system resources to an obscene degree. Also, Electron apps have already thrown away OS conventions to the point that user interface consistency has become a thing of the past.

I don't believe that either choice is ideal, but if Godot were ubiquitous instead of Electron, applications would probably at least be less laggy and more memory-efficient.

Something is very wrong with your system configuration if VS Code has issues showing keystrokes in realtime. It's not a VS Code or electron problem.

I've had this happen with VS code. When your system is under load, VS Code not only gets keystrokes in a laggy way, the characters arrive in the wrong order.

Haven't had this problem with other text editors.

Yes same experience here, it'll perform well for the first 3 keystrokes after a rest, then start lagging, compounding lag to the point where the screen is 5 characters behind of what I am typing, then I have to wait 10-15 seconds for it to rest and report all the errors. It's terrible but there's no alternative for the features.

That's entirely different than having "never" seen it handle keystrokes in a timely manner.

I've seen this too. With recent versions nonetheless.

VS code has had 1 or more frames of keystroke latency on every system I've ever used it on (across years of regular use, on multiple devices and OSes).

It's imperceptible to some. Not to me. Drives me up the wall, but the vscode integrations are too good.

People say this but then I look at them typing and I can literally see the lag compared to closer-to-the-metal toolkits.

This happens to me pretty regularly when training ML models or running heavy simulations etc, the system is taxed and electron just gets swamped meanwhile more efficient apps can handle themselves just fine on the side.

Except, maybe, for the fact that they are attempting to run anything Electron at all on their device, it is not a configuration problem to use a machine that was manufactured a couple years ago and was most likely not top-of-the-line hardware even back then.

(In my particular case I've a passively cooled laptop from like 2021; The limited compute resource available to applications in that device really made me appreciate the well built applications)

I currently use an old macbook from 2014. Everything is slow and I can't have too many applications open at once. But vscode is still one of the snappier ones and I don't see those keystrokes issues.

Of course you can always go less powerful but at one point you just can't use all more complex editors. It's not an electron issue.

Vscode struggles with intellisense and vm round trips on my older cpu. Feels like a race between displaying the character I just typed and displaying suggestions. Sometimes.

to be fair, it's possible that I also experience this from time to time. Since it's an old laptop, sometimes things are slow and I have to wait a bit for intelligence to initialise and cache results. But generally, especially if I close most other programs, it feels reasonably snappy and I don't have the displaying issue.

As an OSX user I had problems with VS Code only on 2 occasions: 1. Syntax highlighting gives up on larger files. What can be considered "large" depends on your machine of course. In this situation I use Sublime Text. 2. I worked on a web frontend that used React MUI (Material UI). That particular version of MUI & VScode combo didn't work at all. Intellisense would slow the editor down to where it was barely usable. That was a couple of years ago, never seen this issue again.

Try opening a 100 MB file in your text editor and report back.

I have the same not-a-VS-Code-or-electron problem.

Sublime Text and Blender (and I guess the majority of CAD applications) creates their own UI engine. That would be better than the current state of electron apps, but most UI engines I encounter have support for custom elements. The issue is more wanting access to lots of cheap developer resources than branding.

I'm not sure about Sublime Text, but I can't imagine Blender is very accessible. As it's such a visual app that's perhaps not surprising, but this approach wouldn't work for other app styles.

Are you running a 15 year old netbook or something? I've never noticed any input lag in VSCode or Slack (or any other Electron apps I can think of)

I own a 2017 MacBook Air, and I don't see why a block editor like Notion should be so slow on my computer. This is why I'm building my own block editor in Qt C++ and QML[1].

[1] https://www.get-plume.com/

Nice landing page. Tip: make the speed comparison an agonizing animation, like esbuild's:

https://esbuild.github.io/

Edit: Tip 2: the screenplay looks nothing like a screenplay

Haha that's funny. I'll consider that.

> Tip 2: the screenplay looks nothing like a screenplay

Is it because the lack of middle alignment? I was thinking about that. At the end of the day it's all plaintext/markdown underneath, so I need to come up with the right syntax for that.

You can use Fountain

https://fountain.io

Awesome, thanks!

Just wanted to compliment your landing page and the intro gif. Great showcase of the app, if I wasn't hooked on LogSeq I'd give it a try!

Thanks a lot, I'm very happy to hear! Essentially, all notes are just markdown/plaintext, so it should be easy to move your data to/from LogSeq. I'm saying essentially tho cause, although the underlying data is plaintext, they are stored inside a local database rather than an arbitrary folder. But soon I'll change that.

Because Notion is slow period. The web app is insane

Looks good. I joined the waitlist.

How does it compare to Obsidian? I didn't see it in any of the comparison graphs.

Hey there, just saw your comment. Obsidian isn't a block editor (see below what it means in practice) so it's not being compared.

- Obsidian is using the resource-hag framework Electron. So it uses much more resources. Plume is built using Qt C++ and QML, and it's actually faster than comparable native apps.

- Obsidian editor is not a block editor (i.e., like Notion), so you can't put advanced blocks like a Kanban (tasks board) within the same page.

- Since it's not a block editor, you can't drag & drop different components.

Unlike Notion (which is also a web app wrapped with Electron), Plume is:

- Fast (Qt C++ vs Electron)

- Easier to use (opinionated design vs. Notion's complex databases)

- Portable (Underlying data is plaintext* vs. proprietary database)

*Currently all the notes' plaintext is stored in a database, but soon we'll change that to support arbitrary folder.

You're probably used to high latency.

You'd be, if you got into computers only recently. It got this bad.

Only those who have used systems yielding low input latency (e.g. Commodore 64, BeOS or the Amiga) can tell that something is very wrong.

What does low latency have an effect on, productivity?

Sanity.

Whether sanity and productivity are correlated, I won't go into.

When you've experienced low latency, high latency is very noticeable, and drains mental health.

Yes, that's the most probable. I use a M3 Max so nothing is really slow but speed difference between vscode and Sublime is abysmal.

they're a text editor and a chat client, and a 30 year old computer can run vim/emacs and irssi just fine.

brb, just switching my 100k employee company from Teams to IRC, should be quick and easy, everyone is going to love it.

If they are on MacOS they may make you their king. I still have PTSD from the last job that I had to use Teams on a Mac.

Teams is awful on all platforms, I don't ever want to touch it again

They might indeed. There are some very nice native IRC clients for macOS that are fast and good...

Excellent idea! You'll have a mature, open standard protocol under the hood, with no vendor lock-in, excellent extensibility, and great modern frontends like The Lounge (https://thelounge.chat/) or Convos (https://convos.chat/) to choose from (and you can choose).

I would love it. I would also love for it to switch to silence instead.

VS Code ID top laggy for you? Honestly asking because I think it performs adequately when compared to like IntelliJ.

According to one benchmark intelliJ can reach an average latency of 3ms on an i5 3427U from 2012 [0]. In a 2022 Github issue someone profiled VS Code which resulted in 12ms latency on an i7-12700KF released in 2021 [1].

If those results are even remotely representative of real-world scenarios then VS Code can't come close to intelliJ performance.

[0] https://pavelfatin.com/typing-with-pleasure/#windows

[1] https://github.com/microsoft/vscode/issues/161622#issuecomme...

When doing what? Also why did you leave out that in the actual apples to apples comparison (the screenshot in the GitHub issue), IDEA literally is shown to have a worse latency versus vscode. Also, just going by pure graphical latency is... niche to say the least. What matters most is how fluid it is, how quick it actually processes stuff and how well it does all the required background IDE stuff without lagging or loading too slowly. Painting onto the display is just one part of the equation (and one that vscode still seems to beat IDEA on, even in a bug report about latency on... vscode)

If you want to check an application that runs on Electron and is quite speedy, try Obsidian.md. I didn't even know performance like that was possible in an Electron app. Unfortunately this example is the exception instead of the norm.

> This would be sooo much worse from a UI point of view. All nice OS features (good text rendering, uniform text editing interface, accessibility, transparency) would all get chucked out the window.

This is what is already happening with people using sandboxed-runtime containers (like Flatpak) and webapp wrappers (like Electron). Desktop UX is becoming a hodgepodge of siloed runtimes and inconsistent interface paradigms.

I don't think Godot would be a great alternative to developing a conventional desktop app, relying on the OS-provided runtime environment, but if you're already deviating away from that, it might still be much better than Flatpak or Electron.

> Electron can definitely have great performance when the developers care about performance (VSCode).

But most Electron applications do not have great performance because they're not being developed this way. Using Godot would provide an easy-to-learn frontend environment (with a scripting language that might even be simpler than using web-derived JS) while still providing the performance of a game engine under the hood. So non-Microsoft developers who would otherwise use Electron might still stand a chance of releasing decent software.

> This is what is already happening with people using sandboxed-runtime containers (like Flatpak) and webapp wrappers (like Electron). Desktop UX is becoming a hodgepodge of siloed runtimes and inconsistent interface paradigms.

Flatpak and Electron don't sabotage any of these things. Flatpak usage is entirely orthogonal, and Electron actually has best-in-class accessibility, i18n, text rendering, keyboard navigation, RTL support, hi-DPI support, etc.; its widgets feel by default as-or-more-native than anything Qt or GTK produce.

Without massive engineering work, handcrafting your GUI in Godot is going to suck for anyone using a screen reader, anyone who reads Arabic, anyone who can't use a mouse, etc.

Trying to come up with a way to open this without "well, actually..."

Godot UI components are keyboard accessible by default and do support Arabic. I haven't tested them with a screen reader so I have no data there.

The Godot editor itself is made in Godot, and it doesn't feel particularly snappy when compared to vscode, so I agree with the general premise that it wouldn't be a huge step forward. That said, it is more accessible out of the box than you might expect.

> Flatpak and Electron don't sabotage any of these things.

Flatpak does, you need to give access to xdg-config/fontconfig to each flatpak or globally for it to respect your fontconfig settings. I've hit this, and it's one of the reasons why I don't use nor want to use flatpak.

Exactly. People hate on Electron because they have bad experiences with many Electron apps, but that's not because Electron is inherently terrible, it's because most developers choose Electron because it requires the lowest amount of effort. When you start with that as your single reason for choosing a tech stack, it's unsurprising that optimizing performance never happens.

VSCode works because they chose Electron for the advantages that web tech has when it comes to building a plugin ecosystem. They were then willing to put in the effort to make performance decent.

> People hate on Electron because they have bad experiences with many Electron apps, but that's not because Electron is inherently terrible, it's because most developers choose Electron because it requires the lowest amount of effort. When you start with that as your single reason for choosing a tech stack, it's unsurprising that optimizing performance never happens.

Which amounts to a strong argument in favor of using a tech stack that has superior default performance, and therefore requires less dev effort for optimization.

The problem is that Electron is superior to something like a Godot UI in absolutely everything else.

Sure Godot can be ok for trivial apps, but extracting performance out of Electron is also not that difficult for trivial apps in the first place.

> The problem is that Electron is superior to something like a Godot UI in absolutely everything else.

Why? What capabilities does Electron provide that Godot doesn’t and can’t? I’m genuinely asking. I don’t know.

Electron has literally thousands and thousands of very, very complex UI/UX features offered by the OS, plus thousands and thousands of very, very complex UI/UX features offered by a browser engine.

Godot has barely nothing compared to that, as it's not an UI toolkit and never tried to be.

Even basic things like "rendering text correctly in multiple languages, with emojis, while making it selectable with the mouse or with the keyboard" are super hard to get right, but it's a problem already solved by your OS, in a way that is not only better optimized and has less unseen bugs than a hypothetical bespoke implementation: it also looks and feels more familiar. Then there's the whole accessibility part, which has different native APIs depending on the OS.

Some other people have written detailed answers:

https://news.ycombinator.com/item?id=38953558

https://news.ycombinator.com/item?id=38954455

https://news.ycombinator.com/item?id=38954087

EDIT: You asked "doesn't and can't". Here's something: there is no can't if you have a turing complete language. But you need a large team to re-do it from scratch, as you're throwing away 40 years of work.

Video game engines absolutely handle text rendering across a wide range of languages. Not all games involve complex text input, but it’s a sufficiently common need that’d I’d expect a generic engine to support robustly.

Accessibility is often language in game technology. That should be better.

To be honest my first reaction was negative to this idea. But if your comments and links have done anything it’s convince me that maybe this isn’t a bad idea after all!

> Video game engines absolutely handle text rendering across a wide range of languages.

They handle specific subsets of text rendering across a wide range of languages. There's a ton of interactions with the OS-level text interactions that are both difficult to fully enumerate and even more difficult to re-implement non-natively. Font programming can get really, really complex—some of it might be perceived as unnecessary—ligatures, proper kerning, certainly sub pixel rendering, glyph variants, arguably emoji—but others will really suck, like poor interactions with highlighting and cursor movement; replicating native keybindings; replicating differences in how e.g. linux and Macs kill, yank, copy, cut, paste, etc; replicating differences in how "paragraphs" are split into "lines" (logical or visual?) across platforms.... this isn't even touching the complexity of processing input (do you really want to implement wubi chinese? Do you know how to properly handle unicode normalization the same way the local editor does so that typing the same keystrokes causes the same behavior? how about differences between punctuation glyphs between scripts? Are you even handling hyphenation correctly? Does it reflow as expected when the layout constraints change?) and simply processing unicode in a consistent and well-behaved manner.

(and of course this isn't even touching attributed text or rich text editing or combining fonts on a single line....)

> Accessibility is often language in game technology

I'm no expert, but accessibility concerns must be wildly different in a game than in a data-heavy or prose-heavy app. I can't imagine implementing a screen reader without relying heavily on the OS....

> They handle specific subsets of text rendering across a wide range of languages.

People radically overstate how hard this is. Yes there’s a lot of cases. But God bless UTF-8 which provides a very clear path.

There are countless hobby text editors and libraries that handle literally all of this.

> I can't imagine implementing a screen reader without relying heavily on the OS....

Of course. You “just” need to use the documented OS APIs. It’s not trivial. But like it’s not that hard to use the APIs that lots of programs and libraries already use.

> There are countless hobby text editors and libraries that handle literally all of this.

The thing is, there really aren't. Certainly not that I would characterize as a "hobby" text editor.

> But God bless UTF-8 which provides a very clear path.

It's a very clear middle finger for CJK users if text rendering issues were dismissed because "we do UTF-8." Thanks to the Unicode Consortium, letters from CJK languages have shared code points in Unicode. This makes it very easy to have, for example, Chinese style fonts sprinkled over Japanese text. This kind of mixed styles are aesthetically inconsistent, unpleasant, and hard to read.

https://en.wikipedia.org/wiki/Han_unification

i18n is very much not about slapping on UTF-8 support and calling it a day.

> i18n is very much not about slapping on UTF-8 support and calling it a day.

Every major game engine has robust support for internationalization. It’s a strict requirement for professional video games.

I never said it was impossible, I just said that a lot of what's currently possible in game engines is absolutely dogshit compared to even Electron. This is not really an opinion, the features just aren't implemented yet, and UX is not a concern.

And I never said video games can't handle text. I said it currently can't do it at the same level as the OS or browser, with all the features.

Implementing is of course possible. But unlike something like React Native, or Electron, if you want to keep the rendering model of game engines, you won't be able to leverage 40+ years of OS development and 30+ years of browser development. You gotta restart from scratch. The ceiling here is something like Flutter, which cost Google millions of dollars.

It even remains to be seen if performance will be even comparable to Electron if someone implement all the missing features.

> "Accessibility is often language in game technology. That should be better."

There are exactly zero game engines or game engine libraries currently that provide the automatic accessibility at the level of something like Electron. This is something else that must be rebuilt from scratch.

> And I never said video games can't handle text. I said it can't handle at the same level as the OS or browser.

The actual metric is “can they handle text at a sufficient level”. I’m inclined to say yes.

> Due to the rendering model of game engines, you won't be able to leverage 40+ years of OS development and 30+ years of browser development. You gotta restart from scratch.

Oh baby don’t threaten me with a good time.

Web browsers are kinda terrible at UX. Native mobile apps are sooo much better than web.

> There are exactly zero game engines or game engine libraries currently that provide the automatic accessibility at the level of something like Electron. This is something else that must be rebuilt from scratch.

It’s weird that you say “nothing to level of electron and therefore must start from scratch”. As if there aren’t already libraries and utilities to build off of. At the end of the day electron “just” uses the documented Windows API! It’s not a trivial project. But it’s hardly insurmountable.

Hmmm, I don't know what's this about "actual metric". Is it "sufficient" for simple projects? Sure. Is it as good as Electron in terms of UX, and look/feel? No, it's not even close. Because Electron is doing native rendering.

Let me try to explain a different way:

- You are saying that native is better. Sure. UX is better, look and feel is better, rendering, accessibility (in most cases), consistency, configurability.

- Electron leverages native for a lot of functionality, so it is able to provide good quality. With light styling and semantic tags, it will use a lot of native functionality and will look exactly like the OS.

- Game engines can't use native to the extent that Electron does, because the rendering model is fundamentally different (as explained in one of the links), so it must use libraries that don't exactly have the look/feel/quality of native and must simulate it. It doesn't get as far from native than that.

> It’s weird that you say “nothing to level of electron and therefore must start from scratch”.

But this is true. There is currently nothing close to Electron accessibility in the game world. I'm not talking about base-level accessibility. Check the kind of accessibility provided by browser engines and operating systems, and you'll see it is a lot of work already cut out for developers.

Are there libraries? Of course there are, I never disputed that. I actually managed to sneak a few commits and opened a few issues in AccessKit, which is a Rust accessibility library that can be integrated with game engines. But it's still early days compared to what Electron can do.

Browser accessibility is actually really great, and it's virtually automatic for developers. I would say that only Apple has as good/simple accessibility as browsers. Check these posts to see the opinion of a Microsoft alumnus that specializes in accessibility: https://news.ycombinator.com/item?id=27338151 https://news.ycombinator.com/item?id=24188387

I will grant you that Accessibility is not handled well.

But I don’t find any of the other arguments compelling.

Sure. But there's no argument here. Me and others are merely answering your questions. You said above "I'm legitimately asking. I don't know." I'm assuming this was said in good faith.

That’s fair. It was good faith. Thanks for engaging. I’ll leave it at that.

Electron allows you can do webdev stuff, so you don't need custom knowledge of anything special. That's the 'superiority'.

Doing UI in Godot means either their pythonish custom language or C# (and via GDExtension technology, C and C++ ).

I mean, I've never used Godot, but from my usage of Unreal, Unity, and a couple of proprietary engines: while I hate webdev and the way Javascript evolved, every game engine's UI solution has shown me that the US workflow is still way ahead of games'.

Maybe Scaleform or other flash based UI frameworks solved this problem elegantly for games, but it died ahead of my time.

I think that you might find that Electron has perfectly fine default performance! Think about filling out an <input> field in your browser that doesn't have any weird magic on it. It's basically instant right?

The issues come from stuff like autocompletion tricks etc leading to weird lagginess. People get a first version of a thing working, and then it just kind of exists in that state forever.

I think that it instead amounts to a strong argument that many apps simply wouldn't exist if Electron didn't lower the barrier of entry.

VSCode is slow as heck and a needless memory hog. Something like VS6.0 or Code Warrior with crisper fonts would be my first choice on a graphical interface.

I think it's very subjective what is considered performant. I for one don't think about VSCode as a performant app, for me it is a resource hog, not at all that responsive app, there's always a slight delay / lag in input reaction, simply not a fast application.

So that the rest of us can calibrate, what text editors do you use that you consider to be performant?

Sublime text or neovim for me (even with all debugger, language server, tabnine etc installed so to be also a full 2024 ide )

SublimeText, Notepad++, CudaText and LiteXL have acceptable performance, memory footprint and responsiveness for my taste (but this is certainly not a benchmark, just another subjective viewpoint :) )

Lite XL, although I usually use Emacs

VSCode works, because Microsoft has written a ton of C++, C# and Rust code to make it work in a usable manner.

Exactly what most devs reaching out to Electron don't want to do, only cozy JavaScript.

Except VSCode most certainly does not have great performance. I can open the same set of files in VSCode and Sublime, and Sublime will use a few hundred MB of memory while VSCode uses well over 1 GB. That's not acceptable.

No it's better for an os UI. A web page UI is better with electron where you click on a link an open a page. But floating windows with resizeable and highly dynamic UIs Godot is likely easier, better and much more well suited.

HTML was never intended for dynamic interfaces. Whenever you diverge beyond what it does best which is hypertext, things become more and more hacky and awkward. If you wanted to design an os UI in electron, you would use a framework called react, and you would use a language called JavaScript that compiles down into typescript and you'd need a whole build ecosystem and connect everything together, then you might find HTML to awkward so you have to switch to webgl which is too low level or you might switch to svg... In both cases you miss the text rendering from HTML. If you stick with HTML then you'd be using css to move shit around and create windows which is also incredibly awkward.

People use electron because it's easy. The reason why it's easy is because of familiarity not because of actual superiority.

Web UI is one of the most hacked together technology stacks ever. Developers with nothing better to do keep coming up with new abstractions trying to build for a moving target. It's not unique in this regard but it doesn't change the reality. Godot has the benefit of a very specific design implementation for a target that is highly dynamic and likely will never change. Plus it's new so you don't have armies of developers trying to "abstract" shit on it over years and years of horizontal progress.

> HTML to awkward so you have to switch to webgl which is too low level or you might switch to svg

HTML is replaceable by WebGL which is replaceable by SVG?

> JavaScript that compiles down into typescript

JS compiles down to TS?

I am not sure if anything in this comment indicates you have any experience with developing for the web but that is not my primary issue with this comment. My gripe is claiming that things are "awkward" or can't be done without even looking around. None of the examples below use WebGL

Here's a WinXP UI clone that runs in your browser with floating, resizable windows. - https://winxp.vercel.app/

Here's one that mocks macOS - https://macos-web.app/

>JS compiles down to TS?

It's called a typo.

>I am not sure if anything in this comment indicates you have any experience with developing for the web but that is not my primary issue with this comment. My gripe is claiming that things are "awkward" or can't be done without even looking around. None of the examples below use WebGL

I think you're smart enough to recognize it's a typo. The primary issue with your comment is hiliteing issues as if it weren't typos but actual lapses in experience. It's like saying someone misspelled a word and claiming they therefore have no experience with the English language. If someone did that, the intent is 100% malice, not a misunderstanding. Don't be malicious. Don't debate and use malice to prove a point. What you should do is Make a point and change your stance based off of evidence.

Also I never said it can't be done. I said it's awkward. It certainly can be done.

WebGL is low level. Same with WebGPU, it means you have to use shaders. Godot has a library for UI. Which makes it less awkward. I'm saying it's JUST as awkward to build these things with webGL then with other web front end technologies.

>Here's a WinXP UI clone that runs in your browser with floating, resizable windows. - https://winxp.vercel.app/ >Here's one that mocks macOS - https://macos-web.app/

What do these examples prove? That it can be done? Did I say it can't be done? Again I didn't. It's obvious these examples exist, everyones seen them. Heck you can probably do the whole thing with CSS and no JS. The gist of my comment is that it's awkward to do, not that it can't be done. You can construct a house out of toothpicks and glue. I'm sure it CAN be done. But bricks are the less awkward tool.

I'm another person who read your comment who doesn't like Electron/web dev and, while reading your comment, I thought "does this guy even know what he's talking about?".

So as someone aligned closer to your team (preferring other toolkits to Electron) I don't think the other user who replied to your comment previously was being malicious in interpretation.

So did you think i actually meant that Javascript compiles down into typescript?

I'm sorry but that comment alone makes me think malice. It's too obvious. To each their own.

Yes, I did and I was confused (hence my thought it was someone focusing on things other than web dev that made the comment).

It's not like I'm attributing ill intent now that you've clarified what you meant (I mentioned having the same anti-Electron inclination as you to demonstrate that) but I probably can't change your mind if you think two people's misinterpretation of the same comment came from malice.

Such typos are common and obvious.

It's more likely someone utilizes such errors as ammunition. Such an action is quite common. It's obvious to me that this is the more likely scenario here from the other replyer.

Another common thing is to team up with people who have similar intentions. When such a situation happens they synchronize their biases. Two coworkers with the same intent will synchronize their biases in a meeting in order to push their intent... Happens all the time.

You like the front end, my guess of what's going on with you is a team up of sorts. Malice is too strong of a word for what you're doing. You're doing a team up and you're adjusting some obvious biases to favor your intent and create alignment with your team mate. This is all done subconsciously too. But that's just my guess on what you're doing.

These are all obvious human behaviors that are quite common but people don't think about it until it's explicitly pointed out.

But in the end. Who cares. We both are now clear about what's going on. No point in debating this further.

> Developers with nothing better to do keep coming up with new abstractions trying to build for a moving target

Bullshit. React is almost 11 years old, the only other two really popular competitors are 10 and 13 and use the same paradigm.

Everything else in this area is very experimental and tentative, as it should be, but it is mostly celebrated by people who, surprise, complain that "the web is too complex".

Even "new hotness" like Tailwind is based off quite old Atomic CSS ideas that started in the late 2000s and early 2010s at Yahoo.

>Bullshit. React is almost 11 years old, the only other two really popular competitors are 10 and 13 and use the same paradigm.

React has been changing a lot. And before react it changed even more. There's all kinds of change in the front end world and you know it. Not even close to bullshit.

>Everything else in this area is very experimental and tentative, as it should be, but it is mostly celebrated by people who, surprise, complain that "the web is too complex".

Webgl and svg are experimental? I don't think so. Using CSS + HTML + Javascript to build an Windows like application is more experimental.

>Even "new hotness" like Tailwind is based off quite old Atomic CSS ideas that started in the late 2000s and early 2010s at Yahoo.

I never talked about whether something is based off of old technology. I'm just saying all the state of the art is always changing constantly as people build new things. Whether those new things are recycling old ideas is besides the point. The main problem is that each "new" thing is placed as this big ugly layer above something that was designed to be a high level interface anyways.

React had a single major incremental change in the form of hooks. It was built upon existing established foundation: functional components. And even then, it still didn't break backwards compatibility. That's far from "changing a lot" in 11 years.

And "before react it changed even more" is a terrible argument. We had a handful second-tier frameworks who never gained enough traction compared to React/Vue/Angular even in their first months. None of those temporary frameworks achieved more than a very small fraction of jQuery popularity in their heyday. jQuery was king since almost launch, and was never really threatened, until React came along.

By "in this area" I obviously mean frameworks. And good call: WebGL is gonna be 13 years old this year and SVG will be astonishing 25 years.

And no, the "state of the art" is not really changing, unless you're going for non-market-tested technology. But that's you, that's not the market, that's not what people are hiring for, and that's not even what's getting stars in Github. New experimental projects are not "change".

The "state of the art" is still React/Vue/Angular, perhaps with SASS or CSS, which is from 2006. Even Webpack is 10 years old next February! And only now it is getting serious competition. Typescript is still 100% optional but is 11 years old.

The meme that "Javascript changes too much" was already old and tired in 2015. In 2024 it's absurd.

No the meme is frontend changes too much not JavaScript changes too much and that meme is still relevant and will be relevant for a while.

Heck you can argue for how HTML and JavaScript are 20 years old!! Wow that means front end hasn't changed at all for 20b years! Come on man.

Anyway my overall point wasn't even about what's changed. My point is that these are all awkward apis to use to develop a windows style UI.

Even if you think they are old, these frameworks are bending and adjusting an underlying layer to do something it wasn't designed to do in the first place. Hence the awkwardness.

I'd be happy to discuss specific changes in good faith, but "Wow that means front end hasn't changed at all for 20b years!" is a gross misrepresentation and dismissal of my arguments.

I will maintain that the pace of change is not the same as you portray. Definitely not when it comes to professional frontend developers working in the industry. Blog-oriented-development or experimental niche frameworks that reach top of HN don't count as "industry" yet.

It's not a gross misinterpretation. I'm sorry, but a huge portion of the evidence you've stated was simply the ages of certain technologies and using that as invalid evidence for your arguments. I've clearly presented evidence to the contrary and you simply call it a gross misinterpretation without even providing a counter argument?

Your job is to prove why ages of technologies is relevant to your argument. If it's not then the only thing you can do is admit how that part of your argument is fucking baseless. You may be happy to discuss other things with me but until you admit or prove me wrong on this point there is zero further discussion about anything. Just walking up to someone and telling them they're wrong is useless. When you say gross expectation I expect some evidence to back that shit up. If not then you can just leave.

That being said I don't think I'm in the mood discuss anything with you. Let me be clear, any response you make to me after this will be illogical because I won't care for it or respond and it will be a complete waste of your time. We are done.

My point was simply that the technologies we use are established, and haven't changed much. The age matters, because the current dominant players have been dominant for longer than jQuery was at the top.

Your counterpoint was instead that React changed a lot, but I counter argued. You are free to disagree with that, of course, but instead chose to answer with "Come on man!!"...

I understand that it might seem overwhelming to see lots of "new things" here at HN and other sites, but the reality is that those things are pet projects or new incumbents that haven't been adopted at large by the industry, if at all. In reality, movement in frontend has been slower after 2015 than it was in the 10 years before.

And sorry but you can't preemptively call my response illogical. This is not cool.

Hey I'm not reading your response. As I said, I don't want to talk with you, so you are wasting your time irrationally talking to me. This conversation is over. Please leave.

You are overlooking a massive point that invalidates your concerns from a homebrew developer's POV: it is _easier_ on the mind to make apps using low-code graphical interfaces than with full-code.

VSCode is super laggy even on a $4000 MBP. Compared to something like IntelliJ sure, but that's a super low bar on responsiveness.

I keep seeing this complaint but I have never reproduced it locally. VSCode runs at a buttery smooth 120hz on my MBP. What are you doing that causes such poor performance?

It's extensions. Some of them can drag a machine to its knees, with unbounded CPU usage. The worst is the C++ extensions. Gets stuck at 100% CPU if you open a file it doesn't like, which is most of them.

VSCode with no extensions is very fast and light. VSCode with 30 extensions you've accumulated? Not so much.

I think that's why you see such conflicting experiences - people have different extensions.

I think I have like, 50 extensions though not all of them are active at the same time (that's how vscode works I think) and I don't really see the lag. I have a high refresh rate screen, I'm pretty used to differentiating between laggy and non laggy graphics, etc and still nothing stands out. Maybe some extensions are resource hogs but I think vscode provides stats about extension resource usage and how much an extension slows down the editor so people can easily check what is causing their slowdowns.

Yeah, that god damn cpptools intellisense scanner seems to grab one core and peg it for 10’s of minutes after deigning to break an include. I don’t get what it’s doing in there that it can’t at least get spread out over more cores; as-is, it spools up the fan because you’ve got one cpu melting while the rest of the processor is just chilling.

I absolutely love vscode and think all of the people complaining about it being sluggish are ridiculous, but the cpp extensions really are genuinely annoying.

I regularly must sit and wait for vscode to catch up rendering the text I just typed. I suspect the main culprit is the vim extension, but unfortunately that's one of the few extensions I cannot go without.

Ah yes the vim extension is known to be an issue. IIRC the problem is it works by hooking into every key press and blocks VSCode in a way that no other extensions really do.

Actually I think Rust analyser had a "smart enter" feature that worked in a similar way and was similarly slow.

Basically if an extension overrides typing then it's going to be slow.

> All nice OS features (good text rendering, uniform text editing interface, accessibility, transparency) would all get chucked out the window.

Could you explain this to someone who doesn't program and knows nothing about how os internals?

My naive question is wouldn't the OS/DE/WM still take care of the above for an application?

From an "interfacing with the OS" point of view, a game engine interacts differently. Most desktop apps ask the OS "please render this text here, with this font" and the OS takes care of that. A game engine just asks the OS "here is a canvas I have drawn, please just put these pixels on the screen". The OS doesn't know that a chunk of pixels is text, so you can't select it, copy and paste it, or screen reader it by default.

This is the same difference between an system like Flutter and native App toolkits (I'm going to talk about Flutter because I know more about it). It has massive advantages on portability - Flutter rendering is very predictable on different phones because the only thing that can vary is screen size. The subtle variations between OS versions and phone manufacturer UI skins don't screw things up.

There are downsides: You need to implement all the common stuff that you'd normally get for free. This includes native look and feel - Flutter has to have all the Android and Apple widgets. It also includes text rendering accessibility, etc. etc.

To give an example comparing a text field in a native OR webview-based macOS app with a hypothetical Godot-based one, the Godot version would need to reimplement (or likely just omit):

- Copy/paste

- Emacs/readline keybindings (Ctrl-A, Ctrl-E, etc.)

- User's preferred text size and font as selected in System Preferences

- Spellcheck

- Nice features for non-latin text (e.g. built in pinyin keyboard)

- Crisp text rendering

- Dictation support

- Screen reader support

- Autofill

- Automatically updated with OS updates (e.g. HiDPI, all Java UIs had looked almost-native but were now stuck looking pixelated)

- And hundreds more features I'm forgetting...

This is all possible to do in Godot (e.g. the Godot Editor does a lot of these) but with a lot of work required. It's completely built in to any native or web-based text field and doesn't need any additional work.

Think of it like the difference between building a bicycle by taking existing parts and assembling them, vs just starting with raw materials and fashining a bicycle. If you use the pre-built seat that has a spring (suspension) on it, then you get that "for free." If you're assembling from scratch, you either have to build a spring (not very easy) or go without one. For many bikes, it's going to be without and for the ones that do it, odds that the spring will be as good as or better are low.

With a game engine the OS is basially handing you a blank canvas and telling you to draw what you want. With a GUI toolkit like GTK or Qt, the "OS" is handing you a bunch of pre-made parts and you get to arrange them on the page how you like.

If you're writing a game, the former is obviously better. If you're writing a standard application, the latter is usually better. By "better" I mean higher quality output, and less work to construct.

> I don't think Godot is inherently more performant for any random UI than Electron

It probably depends on the app?

Electron will obviously excel at things that resemble an oldschool web page, but one would think Godot would excel at more dynamic OS UIs? If something is already sluggish or GPU heavy in Electron, I would think its right up Godot's alley.

Accessibility of course is a seperate and huge concern.

Adobe Air, anyone?

Reply on news.ycombinator.com