This is actually a great proof of concept for using Godot as a cross-platform framework for desktop applications. The distribution package is incredibly simple -- just a single executable and a data file -- and performance is excellent.
This seems much superior to Flatpak and the like as a way to offer fully self-contained distro-agnostic binary packages, and vastly superior to Electron in the performance department. Maybe desktop applications built with game engines are the next big trend.
From the screenshot:
GodotOS is a fake operating system
Is it fake, though? Does the term "operating system" imply the level of hardware it's running on? Otherwise, even if it's running on top of another OS, it's still an OS.
It's a fake OS in the sense that it's actually an application, not something that can be ran as an operating system like Linux or Windows. I've been a bit careful with my wording when advertising this, I wouldn't want to give the wrong impression.
Would "desktop environment" be a more appropriate description?
Absolutely, but I feel like it's a technical term that might be hard to understand or advertise. When I explained the project to my non-technical friends before showing them, I told them "Ah, it's like an operating system" and they generally understood what I'm going for.
Is it a desktop environment in the Gnome or KDE sense? I didn’t see any third party programs in your trailer video so I guess you can only run your built-in “programs,” right? So I would say it is not really a desktop environment… I’m not sure what the technical definition is, but I must have something to do with acting as an environment to draw other programs.
Calling it a fake OS was, IMO, s great choice for avoiding confusion. Maybe something like Concept-OS or Desktop Environment Mockup could be good names if you want to be fancy.
How hard would it be to include a terminal emulator? You’d get a lot of functionality for free, there!
Yes
Desktop Environment is already taken by systems like Gnome and KDE. This is more like a mockup. The “concept car” of desktop environments. It is quite neat.
Is Pharo/SmallTalk/Interlisp a fake OS?
Sounds like a shell https://en.wikipedia.org/wiki/Shell_%28computing%29#Graphica...
Is anything that needs a kernel to run also a fake OS? Or drivers/bios/etc.
I feel like operating system implies the existence of a kernel
An application that spawns processes/apps/modules, controls them and lets them communicate back to the application for some service is also, in a loose sense, an operating system.
That seems a bit too loose.
Doesn't that apply to IDEs that implement the language server protocol, since they spawn language servers and communicate with them?
And servers like Apache that spawn child processes to handle requests?
Apache supervises tasks in the form of threads and subprocesses, including managing memory in the form of pools, so yes, it's doing some of what an OS would do. It isn't, on the other hand, providing abstractions to hardware, and that's what I think of when I hear "OS". It's not really a cut-and-dried thing though: modern web browsers are like 90% of the way to being full-blown OS's, even down to abstracting hardware in the case of things like WebGPU, but they still rely on a host OS to bridge the connection and do the actual bit-banging required to make it work.
Robot Operating System (ROS) is also an operating system, but it runs on top of computer operating systems like Linux and MacOS, and is focused on supplying the services, build toolchain, and communication standards/paradigms that are useful for implementing a robotics system, much as Linux (and its distros) are focused on providing that for a general computing environment.
In any case, it's clear that the project under discussion here isn't really any of these things is rather a system shell/GUI/launcher. But calling it an "OS" falls under the fun tradition many of us enjoyed in our youth of trying to recreate our own Windows in whatever was our programming platform of choice, and thinking that was what an OS was.
Popcar2 , a note on your disclaimer that you are not affiliated with the Godot foundation. Is that usual in projects using an engine? Or is it because of your , IMHO, poor naming choice.
Think of this way, if the tagline of the project was “EstragonOS, a fake os made in godot”, would the disclaimer be so proeminent in the page?
I think you know you are playing with fire, to make the disclaimer a larger font. It’s not too late, consider a rename.
"playing with fire"
I don't think the Godot Foundation would be against this.
As a heard they are quite toxic, so who knows?
From where?
That's irrelevant to the issue of copyright enforcement or handling of the copyright.
I've wanted to know what Pouley Ketchup is talking about for a long time, but we don't know, so hard to use it as evidence for much.
I have my guesses who he's talking about tho.
Thank you for the concern, I did indeed add it preemptively because of the project's name. The reason I chose "GodotOS" is because the project was initially intended to be a sort of tech demo for Godot's UI systems, and I spent most of my time in the official Godot Discord showcasing its development and getting lots of feedback. One of the contributors of the engine itself gave me the thumbs up.
Of course, if anyone officially from Godot wants me to change the name and general branding I'll do so quickly. Right now, I think it should be fine.
It's OK, I'll name my project Popcar2-OS.
Please add a disclaimer that you are not affiliated to IOS
It's a fair point, but I don't think Cisco has too much to worry about in this case!
Related: Grey Hack is a fake OS, Network, Internet in a multiplayer game where the objective is to hack (including each other). It simulates many basic functions quite well (you can steal files, place files on other computers, install software, run commands from a command line, including imitations of many tools). You can also write your own programs.
When will someone go all in and release a hack game with hundreds of emulated real little servers of various operating systems and vulnerabilities?
At a certain point on the realism continuum, just get rid of the gamey parts and deliver someone a set of VM images that they have to boot up and break into.
(Maybe that's actually what Hack the Box is, mentioned in the sibling— I hadn't heard of that and only looked briefly at the homepage for it.)
Maybe that's actually what Hack the Box is, mentioned in the sibling
Hack the Box hosts the VM for you on their servers (and you connect to a VPN to get access), but it's effectively that. They release a box every so often (roughly monthly?) and users compete to collect the user/root flags.
They also have a rotating selection of past boxes (and I think you get access to all of them if you pay them), so it's kind of like an "on demand" CTF.
I’ve always thought it would be interesting to try something like that for a LARP.
It would be fun to run in an “anything goes” type setup. Get a cheap raspberry pi and install some really old Linux kernel with plenty of well know holes. I’d worry about delineating between game-machines and real ones. It would have to be totally isolated from the real network I guess.
That's what CTF at Defcon is like!
Yeah, my employer does that. We call it "infrastructure". /s
Some time ago, I found a site that provided different variants of VMs you could download which contained exploits you could utilize to pwn the machines. There were also walkthroughs and guides available to teach you how to break in.
Unfortunately I can no longer find the site, and my Google fu has failed me.
Unlike Hack the Box, no signup was necessary, you could just download the VM and get started.
Does anyone here know of any good alternatives they'd like to recommend?
Isn’t hack the box already itching this?
I remember when Notch was playing with this space game with a slimed down assembly language he created. He stopped working on it unfortunately, but I still think there's a whole potential genre of hacking on a game. Not a "press F" to hack, but a legit log into this system, get/change whatever. Having a legit in-game OS seems like a good step forward.
Factorio has a mod where you can program electricity circuits using assembly, I forgot the name. You place a "computer facility", connect to the signal network, then open a terminal to start programming.
It's pretty cool because factories can be very complex, giving it real utility. And you can communicate over the wire with fair sophistication using items as signal symbols. The clock speed of the devices was limited to a few instructions per game tick.
At what point does it start looking too much like your real job? Zachatronics game Shenzen had that problem for some friends of mine that do chip design professionally.
Ah yep, that's the one I was thinking of. Really disapointing he never released it.
Bitburners does a pretty good job. Its an idle game with fairly limited "OS" emulation, but the best solutions require real thought and programming knowledge.
You'll be writing scripts to scan the net for open ports, automatically "hack" into them, then globally balance allocate memory between all of them according to certain parameters to make the hack the most "profitable". You'll be writing elementary socket communications, building scripts to feed analytics back to your home PC, even alogirthmic trading in a fake stock market. I had fun with it.
It's more programming than hacking but you might enjoy TIS-100
Reminds me of all the "OSes"/GUIs that got made back in the QBasic days: http://qbasicgui.datacomponents.net/
Always a fun project to do. Thanks for carrying the torch forward in something modern!
ps, my favorite of the QBasic ones is probably M-GUI: http://qbasicgui.datacomponents.net/95_mgui.html which even included its own programming language to make apps in!
Because this site still gets a lot of traffic, I'll be redesigning the site with more of a modern look and feel. [...] I'll try to keep you posted and hopefully won't get sidetracked.
Looks like they did get sidetracked, and I'm glad! If the author is reading this, I think it's a great time capsule that's probably best left as-is.
Another time capsule, this time in the form of an endolink: https://news.ycombinator.com/item?id=38938998
DOS-based GUIs were the rage in its days.
In 1999 I coded a graphical environment for DOS using Borland's BGI in Turbo Pascal. I even used it in one of my uni assignments[0].
I still remember some afternoons in the library, helping pals with linked lists basics and finetuning my textbox scroll code. Good times.
[0] https://github.com/luismedel/jugadores
edit: Forgot to add that I wrote a lot of code in paper :-)
This is absolutely amazing! It brings back great memories of my childhood when I was doing similar mock UIs in QBasic, then QuickBasic, Turbo Pascal and Turbo C. Thanks for sharing!
That was how I learned to program, back in the 90s when I was a teenager.
But it was never what I meant to do. I was quite sure I was going to be a game developer. Knowing absolutely nothing about designing a game, managing a project, et cetera, I just starting writing games at the beginning, with a splash screen or animation, and then started writing the start GUI for the game.
For a 13 year old pushing the boundary of what you could do with QBasic and mode 13h graphics, I never quite got past designing the GUI, but I made a heck of a lot of them.
Fascinating. I wish I could run them in a browser VM - it would probably be pretty fast as well.
GIMI was quite impressive as well, also including its own programming language, but also getting some heavy-lifting weight from a handful of tools written in other languages: https://sourceforge.net/projects/gimi/
I would love a write up on design philosiphy. I'm currently learning Godot coming from web dev, and finding the distributed business logic impossible to organize. I just don't know who, what, or where business logic should be.
My urge is to lift logic up to the parent of any group of interactions, and let nodes just be renderers. But I understand that is absolutely not the design philosiphy of Godot, and probably won't scale.
It's impossible to be sure without knowing your programming experience in general across sectors, but it sounds like you are unused to the paradigms of game programming in general, which is centered on logic executed per-frame rather than per-flow (like in business applications, which is where the concept of "business logic" comes from).
The default approach in game engines is to bind data including state to an actor, then have define per actor, in a given state, how it modifies its own and other actors' data over a frame (usu. processing user input as necessary), and how it renders to the screen. This is what game engines are designed to make easy, by providing something like an "Update" and "OnDraw" virtual functions you fill in for every element in your world.
Inevitably every application needs to have a few "directors" who need to take care of business that can't be isolated to an individual "actor" or per-frame state manipulation, and these are usually structured around async-awaits, callbacks, is a thread handler/dispatcher. But if you go overboard with directors, actors that operate like directors, or actor-director interactions, you're inviting trouble in game-engine-land.
There are some alternate paradigms like "entity component system" and entirely callback-driven event-driven game architectures, but they tend to never exist in purity without the actor-update model.
Ironically, early days Java Applets had you painting things on a canvas with a similar event loop. I think Flash also operated this way.
I almost think if someone were to build applications with Godot (or another engine) that you would need to mentally translate from something like React components and their data to the actor/sprite+state in an event loop model.
For example a todo list in Godot might have an actor that is the checkbox with some text next to it and the state of checked/unchecked, then allow the user to click something which generates more of these actors/sprites dynamically. I think where it really becomes cumbersome with a game engine is no real organization of a scene exists without you explicitly laying out x,y pixels. There are concepts of "relative" but common application concepts of pagination, etc. would be hard to pull off in a simple way in the code I would imagine.
I certainly am unused to it! maybe I’ll ask some advice:
I’m trying to build a circuit simulator. It’s got two main problems to solve: placing and connecting drag and drop electrical components, and the simulation itself.
How would you go about this? The existence of the sim means there’s already guaranteed to be some global manager that understands the current layout and can compute from it. What I don’t know is if that means most things should be handled that way.
Should components be heavy, and make their own changes to the tree, and then let manager read the tree in and build up its schema that way? Or should components be just emit everything to the manager, who then can both build the tree and a state representation.
The second feels cleaner for this use case, but it feels not standard for Godot. Maybe it’s a bad project to start with.
I did build a basic platformer too, and found the distributed logic much easier to deal with there.
The fact that you're playing around with a game engine and using phrases like "distributed business logic" tells me you have a long road ahead of you.
Coming from web dev to Godot was a bit wonky for me and digging into some Godot dev patterns on YouTube and elsewhere went a long way to help me wrap my head around the question of like… “where does this logic/state/etc live and how do I access/use it where I need it?”
Just the other day I was wondering - what would it take to develop a Linux WM in Godot?
Not that much actually if you don't mean as a full WM/DE replacement and instead as an on top layer; Godot 4.2 window management on linux is working quite smoothly for me, including multi-window support. From there what you do within the windows is where the magic happens. (see my other post)
What I mean is a full WM/DE replacement. I mean godot already handles graphics quite nicely. Imagine a desktop that you can control with shaders and runs on Vulkan. That'd be pretty neat.
I've thought about it but it seems daunting so I punted this idea for myself, but it depends on if you mean as an xorg/wayland replacement or if you mean to build on one of those, and even between those two they have a vastly different approach, but there are some minimal foundations that could be built on...
For example, wlroots: "Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 60,000 lines of code you were going to write anyway." So it would also depend on if you mean raw WM or if you want compositing also etc.
Just the other day I was wondering - what would it take to develop a Linux WM in Godot?
It bas been done :
https://github.com/SimulaVR/gdwlroots
But it is not up to date with Godot 4. You can have your Firefox or Blender window be a regular texture inside a full Godot game, pretty crazy...
This is sadly just a nested compositor, it seems like it does not implement any new Godot drivers…
This reminds me of a time circa 2005 where "Sub OSes" were somewhat popular in the GameMaker community. Seems that given enough time someone will try to make an OS-like interface in a given game engine.
It was a great way to understand UI and usability paradigms beyond building game mechanics.
This definitely triggered some pleasant nostalgia for me.
Nice to see someone else who also remembers those.
I was the creator of Tiagix OS, AFAIK one of the first subOSes that actually had support for creating apps for it.
Learned a lot about GUI toolkits making it, since I had to implement one from scratch for it.
Do you have any material online on Tiagix OS? I can't seem to find anything from a quick Google search.
I think there's a build of an older version of it on the YoYoGames archive. The archive didn't save the screenshots that the original website had, sadly.
I also spent a long time working on a very large update which I might have archived somewhere locally but never shared it online.
Also there are some in browser operating system as well, typically they have OS UI shell and applications. Unfortunately I forgot their names.
Yes I remember the same for The Games Factory 2/Multimedia Fusion
The Godot IDE itself is a "game" as in it is entirely built using Godot APIs. Makes me wonder if it would actually be a good environment to build portable business apps, sort of like a modern Visual Basic.
It would have all the issues of Flutter (non-native widgets, accessibility, etc) without the focus on these specific kinds of use cases.
Only nerds care about non-native widgets.
And people with disabilities.
Native widgets come with a bunch of accessibility and localization features that are typically missing from naive custom widgets.
A native English speaker with normal vision might naively assume that they could reimplement a widget that's just as good as the native one in less than a week, but the result will be awful for anyone who doesn't match that description.
If you're building with web tech accessibility and localization are easier to add to a custom widget (though they do still require thought), but this is Godot, not Electron.
This is great. Would you recommend Godot for prototyping UIs, in general, over HTML/JavaScript?
Short answer: Yes!
Long answer: I recommend Godot for rapid prototyping and creating desktop applications, but not necessarily for web app development. The biggest blocker is that Godot 4's export size is quite big compared to web standards, roughly 35MB uncompressed and 7.5MB compressed. The web version of GodotOS is 7.8MB, which may be too big for professional use.
Godot is fantastic for making quick prototypes though. The editor is very quick & intuitive once you understand the core concepts. It's also a fantastic tool for creating cross-platform desktop & mobile applications, some professional apps have been designed with it.[0]
[0]: https://alfredbaudisch.com/blog/gamedev/godot-engine/standal...
Nice. Yeah, I was thinking as a rapid prototyping tool. There's a big gulf between Figma and something like a Godot prototype. The former can give you high fidelity in look, but not in feel (interaction).
I guess you are aware, but Godot can be compiled to JavaScript: https://docs.godotengine.org/en/stable/tutorials/export/expo...
It's a game launcher that uses Godot, but neither an OS nor connected with the Godot project.
It's a bit like writing a game launcher in Rust and calling it RustOS.
Isn't it a bit like making an app that uses Qt and start its name with a Q? Without giving any real name, I can invent "Qnotepad" which would be a notepad implemented with Qt.
I know real projects that follow this pattern, and it never really bothered me that it was not connected to the Qt project (other than by using Qt).
I think it's a fun name
Would be fun if game engine editor environments took on the UI paradigm of an operating system like windows. So that instead of going to the File menu at the top of unreal engine to open the blueprint debugger, you navigated the start menu to find the program.
I’ve reflected to myself so many times that UE4 feels like an operating system, would be fun if in the future it actually was ha
I think that the Godot UI editor is written with Godot, so it should be possible!
Eric Lengyel's C4 engine takes this approach.. it's a bit interesting
Dang! I just realized github no longer works on my old macbook running firefox 78.15.0esr (64-bit).
BigTech wants me to buy a new macbook or switch to chrome.
Edit: it's actually no laughing matter. I'm pretty devastated. :-(
The current FireFox ESR version is 115.6.0. Extended support for 78.15 ended in 2021.
It's weird that your first inclination is a new computer or chrome. Those are two very different things, and neither is necessary.
... or to just update to a newer version of Firefox.
Please consider calling it GodOS (pr: gud-os)
Trust me, you aren't the first to recommend the name. I love the idea of saying godos, but then I'd have to constantly explain that it has no relation to God or TempleOS haha
I trust you
Very nice! (and AGPLv3 too!!)
I have been working on a similar project for actual filesystem/OS interaction (heavily abusing OS.execute (https://docs.godotengine.org/en/stable/classes/class_os.html)) which is actually a sub-project of a much bigger project (only working part-time now so I can spend half my day on it as I near alpha). My favorite part so far has been in my attempts at using Godot to recreate fsv/fsn (3d filesystem representation).
Is there any reason you haven't tried to turn it into a real desktop environment given that Godot provides the mechanisms to do so? I know I've been nervous that I might have a bug that does something destructive and that is why I've been working on my ci/cd pipeline and unit tests but am just curious.
Either way, it has been awesome watching the explosion of creativity happening in Godot land. I compile daily and watch the commits and see such vast improvements being made all the time. It's a great engine with first class c++17 support with GDNative and modules, and I truly believe the future of gaming (and many other things) is FOSS. My only meta-wish is that the engine was GPL instead of MIT, but luckily that doesn't stop me from releasing my stuff built in it as GPL.
Is there any reason you haven't tried to turn it into a real desktop environment given that Godot provides the mechanisms to do so?
It's just too complicated to embed third party applications into a Godot game. I suppose it is technically possible to do so since you can use GDExtension to glue C++ code, but I can't even begin to imagine how that can work. Thanks for the feedback anyways :)
As a side note, Godot can't be GPL because it would imply that you can't make closed source games in it (they'd all have to be GPL as well).
With OS. functions (including OS.execute) you don't need any third party things or GDExtensions from my point of view. You might check it out if you haven't. I am working on a real file browser in 3d and execution launches applications natively in linux for example. It's not launched "within Godot" per se.
As for the GPL thing: that's exactly the point!
Wish you the best in future Godot dev.
Thank you for making this! I’ve been dissatisfied with the options available for making local GUIs and curious about what could be done with game engines. What was it like working with the UI layer of Godot?
Quite fun. I find it a lot simpler and more intuitive than other UI frameworks I've worked with (especially front-end webdev), but I understand it's very opinionated. Once you get accustomed to using Control nodes in Godot (that's what they call UI components), it becomes super easy to rapidly prototype and design anything you'd like.
This just makes me yearn for a UI-centric minimal compilation mode for Godot. It's such an enticing target for GPU-rendered UI, and there are even some excellent libraries and plugins out there for making components that are useful in engineering or data analysis!
You can disable a lot of Godot's features when building the engine from source [1]. Not sure how much you can save while keeping most of the 2d/3d components, but it should be possible.
[1]: https://docs.godotengine.org/en/stable/contributing/developm...
written in GDScript
Quite unfortunate.
Until C# is first class, I still find GDScript more comfortable
I've been thinking about making a cross-platform mobile app but don't want to think about react native, touch javascript, or fiddle with xcode any more than I have to.
Is it accurate to think that I could instead use godot to create a cross-platform app to eliminate complexity from react native while creating something that is performant/native across ios/android?
I’ve worked in both Godot and React Native. I wouldn’t say you are eliminating any complexity.... You are just trading one UI system for another. UI by its nature is complex and requires a lot of “code”. In the Godot case you might be doing less coding in the “typing letters on a keyboard” way, but you still need to figure out the UI controls and fiddle with the settings in the properties panel until you get it juuuust right. The final product is still saved as code, in tscn scene files.
Looks great! I know there are a bunch of games that use this kind of setting (fake OS) as the main mechanic. Her Story comes to mind [1].
Hypnospace Outlaw is the absolute MVP of this category. That game is a trip.
This is really neat!
I almost wonder if this could be adapted into a “real” desktop environment, as in “competing alongside KDE or Gnome”. I have no idea what’s involved with doing that but it it would be cool if you could.
More like GodotDesktop
Heh, back when, I used to do (Q/Turbo)Basic stuff like:
PRINT "Welcome!"
INPUT "Password: ", pw$
We at a stage where desktop environments become faster than the OS they run on (ahem... Windows).
This is great, actually thinking of building something similar for a game I'm working on, but other way around really. OS in game instead of game in OS. :)
This is neat. I always wondered if it was possible or if anyone has made a fancy UI for instrumentation / dashboard using a game engine.
This is awesome!
I'd love to boot this up and see how it runs on a Quest headset
https://simulavr.com/ was coding a VR desktop with Godot.
Godot is a great sketchpad for these things. One time I was at the airport for a flight, so I wrote a quick-and-dirty notepad for the Russian pencil-and-paper game Virus War (“Война вирусов”) for my eInk tablet that my partner and I could play. It was just a grid with tappable buttons in varying states, but I was able to get a playable prototype ready for our flight.
I guess that "a desktop that is minimalist, distraction-free, and aesthetically pleasing" means Windows 2000 with transparent backgrounds.
I mean let's look at all the game menu screens in existence today.
For what they are most of these screens are far better than HTML counterparts. UI is snappier and more special effects.
Game UIs off the menu have always been better than web pages too. Look at say baldurs gate 3. I don't think such a UI is easily pulled off in web. Possible but awkward to build.
silksong never.png
Why do you have to hurt me like this
This might still be useful in the real world. Think movie industry, where having a mock OS for showing characters doing computer things is practically a trope in its own right. I was recently in a discussion with some fans of the movie Hackers, in which one of them asked what OS they used in the movie. My reply was to the effect of, what every movie in the 90s used, which was basically Mac OS with fake UI elements cobbled together in Macromedia Director (or Flash in later films).
With film studios increasingly turning to game engines for applications like providing real-time on-set CG as a reference for a shoot, something like this may well be the modern version of that.
Shouldn’t use the godot name for this
super bit boy made me instantly younger by about 15 years. thanks!
Note: GodotOS is not actually an operating system, it's an application with an interface resembling one.
...actually, is GodotOS any less of an operating system than early versions of Windows?
Have you thought about turning this into a linux desktop environment? It wouldn't even be the first Wayland compositor using Godot.
This is a pretty cool prototype for something I'd considered Godot for: a GUI for a device running embedded Linux. In that environment, you want the least bloat but some decent development tools so you can iterate reasonably fast. That's not a widely-available combo.
The performance is really nice, I kinda love it.
I played and finished Super Bit Boy. :D Reminded me of the game "Thomas Was Alone", that was nice. :)
Very nice. I wish it would also work on mobile. The initial screen showed up but "clicking" on folders does not cause any action.
Ha! This is really cool
I'm really impressed that you were able to create this in Godot. Looks like it's all GDScript too. Nice
You even tucked away a pong game in there.
What do you think of Godot? I've been thinking of switching to it after I finish working on my Unity project
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.
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.
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.
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!
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.
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
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.
They might indeed. There are some very nice native IRC clients for macOS that are fast and good...
Teams is awful on all platforms, I don't ever want to touch it again
I would love it. I would also love for it to switch to silence instead.
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.
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.
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.
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.
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.
Try opening a 100 MB file in your text editor and report back.
People say this but then I look at them typing and I can literally see the lag compared to closer-to-the-metal toolkits.
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.
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.
I have the same not-a-VS-Code-or-electron problem.
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)
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.
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.
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.
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.
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!
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.
The actual metric is “can they handle text at a sufficient level”. I’m inclined to say yes.
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.
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.
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....)
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....
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.
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.
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.
The thing is, there really aren't. Certainly not that I would characterize as a "hobby" text editor.
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.
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 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.
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?
Lite XL, although I usually use Emacs
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 :) )
Sublime text or neovim for me (even with all debugger, language server, tabnine etc installed so to be also a full 2024 ide )
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.
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.
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.
> 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.
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.
Webgl and svg are experimental? I don't think so. Using CSS + HTML + Javascript to build an Windows like application is more experimental.
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. 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.
HTML is replaceable by WebGL which is replaceable by SVG?
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/
It's called a typo.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
Adobe Air, anyone?
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.
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.
I was trying to think of arguments against it, so I thought about the fact immediate mode GUIs might not always be suitable, before I stumbled upon this post: https://stackoverflow.com/questions/47444189/what-are-the-pe... The only other downside I can think about is from a design standpoint, the application has to have the same design language across platforms, so it cannot have a native look for each. Any other cons?
It requires a GPU.
I'm not aware of any GUI stack that doesn't require a GPU, nor any desktop hardware released over the past 30 years that didn't have a GPU.
Qt or Electron don't; they both have software renderers. The latest Godot needs a GLES 3 or Vulkan GPU. The older versions used to only need a GLES 2 GPU.
Qt and Electron output to the OS-level display APIs, where screen rendering is handled by X11, Wayland, Quartz, WDDM, etc., all of which still rely on GPUs for output.
Godot, as a game engine, bypasses the OS and uses lower-level graphics APIs like OpenGL and Vulkan. But you only need these APIs available regardless of what hardware is under them, and you can use software-based rendering with e.g. Mesa, Lavapipe, or other software renderers. With a 2D desktop application, performance should still be fine.
X11, Wayland and WDDM only use the bare minimum functionality from those APIs, so they work just fine on old DX9-level GPUs for example. Godot needs much more recent GPUs.
I RDP or VNC into VMs that run without a GPU all day. It's very much optional for 2D, at least.
Some quick googling tells me Godot doesn't have native tray icons/notifications support or access to peripherals like webcams & printers. Buut if you're using Godot over electron/flutter/QT your app is probably focusing on 3D / physics topics. You can implement plugins for those other niche desktop features as you need them.
There is some ongoing PR, so it might come at some point :
https://github.com/godotengine/godot/pulls?q=is%3Apr+is%3Aop...
I’ve been thinking about this a bit and the main concern I’ve had is around accessibility. The web has had a lot of iteration over time to make it relatively easy to build applications that are well suited for use with screen readers and other assistive technologies. Have you done any testing along those lines with the Godot UI tools?
I feel like the scripting language (GDScript) is pretty bad. There's no real way to handle errors and its type system sucks compared to typescript. Not to mention you lose out on the diverse packages available from npm.
I seriously doubt it. Game engines are, first and foremost, designed to provide a 2D or 3D graphics environment and input handling, they don't typically have the richness of UI components that you would expect for building a desktop app. Godot is no exception here, its UI components are very dated and limited in comparison what modern web-based applications can do. Furthermore, Godot specifically is limited to a single window (apart from popups) last I checked.
The other problem with Godot specifically is that every thing is tied to GDScript/the Godot typing system (yes, even the C# and gdextension APIs) and you need to deal with its inconsistencies. I'm currently implementing something as simple as a schema validator (think JSON schema) and it's nightmareishly tough in comparison to any other language I have implemented this in. And then we are not even talking about the almost universal lack of error handling in a large portion of the built-in functions, or really silly things like that opening a TCP connection apparently requiring active polling. I could go on.
I love Godot, it's super simple to build game-related things with, but holy macaroni do I wish they had thought things through just a little more when they implemented them. I would never want to build a data-heavy desktop app in Godot.
Godot 4 has proper multi-window support.
You should be using C# for stuff like that. Ignore the Godot API, just use .NET 8.
But I agree that any game engine is a poor fit for general applications.
Could you give me a link please? The Godot editor itself can't do multi-window and I haven't found a clear explanation on how to do that in the games either.
I use the non-dotnet version of Godot, I'm not happy with the confusing licensing Microsoft has put around .NET [1]. If anything, I'll go the gdextension route, but it hasn't been painful enough yet to do that. For a UI you couldn't ignore the typing system since you'd need to feed the data into it and read from it a lot.
[1] https://news.ycombinator.com/item?id=35985832
.NET is licensed under MIT[0]. There are additional concessions[1] regarding the code that used to be proprietary specifically to make all the Mono bits to be legally sound.
[0] https://github.com/dotnet/runtime/blob/main/LICENSE.TXT
[1] https://github.com/dotnet/runtime/blob/main/PATENTS.TXT (I think there was another document, please post the link if you remember which one)
As I pointed out in that thread, I wasn't able to track down the license of all required DLLs for the binary distribution.
I think it’s an imagined problem and in practice no one has it. Just stop worrying and start deploying :)
I think the functionality for multiple windows was added before this release but here's the 4.1 notes that you can open the code editor/other stuff in other windows: https://godotengine.org/article/godot-4-1-is-here/#editor
I just tried it and it seems to work.
Have you heard of AppImage?
And use it regularly. It's a great solution to test applications out before installing them, or run "portable" applications from removable media or a remote server.
But as another of those bundled-runtime solutions, like Flatpak, it suffers from the same issues, including high complexity and poor cohesiveness with the rest of the system.
It's already being used for that! I use a program called Dungeondraft[1] for easily creating maps for TTRPGS and it's built on top of Godot (see the modding API page[2] where they mention Godot).
[1]: https://dungeondraft.net/
[2]: https://megasploot.github.io/DungeondraftModdingAPI/
To add to the list, Pixelorama[1] is a pixel art sprite editor built on Godot.
[1]: https://godotengine.org/showcase/pixelorama/
If you're making a certain class of desktop app (CAD, DAWs, Video Editor) this is worth exploring!
Sounds like you're describing Flutter.
Electron apps work with screen readers and os accessibility feature.
Unless accessibility becomes a first class concern, game engines are not going to be good choices for desktop applications.
Completely agreed! I've been meaning to write a blog post on using Godot to professionally create cross-platform applications (and probably will soon). The short of it is that Godot is fantastic as a UI builder, and I think a lot of people are slowly realizing it. Many professional applications have been built with Godot[0] , and I also want to give a shoutout to Lorien[1] which is my favorite whiteboard application also made in Godot, and what partially inspired this whole project.
Godot isn't perfect of course, and there are some things that many other UI creating tools do better, but I think there's a lot of untapped potential here.
[0]: https://alfredbaudisch.com/blog/gamedev/godot-engine/standal...
[1]: https://github.com/mbrlabs/Lorien
The children yearn for Swing Toolkit
The Firefox people have some nice write-ups about how they want to / wanted to use techniques from games to make Firefox's UI faster.
This doesn't remotely solve the same problem Flatpak does, you are comparing apples and oranges.
Did you actually do any benchmarks actually measuring CPU performance?
Last time I did that was two years (I think) ago and "excellent", even with Godot 4 beta, wasn't what I called it.
I don't get why people in this thread are conflating Flatpak with different ways to do desktop UI. Even if your app is a single self-contained binary, it can benefit from Flatpak. Sandboxing, permissions management, separation from system (needed on 'immutable' and image-based distributions), unified package format (don't need to create deb, rpm, etc. for a simple GUI app), and many other Flatpak's features can benefit the devs and the users alike. That has not much to do with what you use to write UI. Flatpak can't be entirely replaced by self-contained binaries.