These days it feels like everyone and their son are building a new IDE (and I say this as someone who’s done the same haha).
Interestingly, they’re using graphics libraries like OpenGL/Vulkan in Go. Like I originally was. But after a year of edge cases, I gave up and switched to Wails (using OS-native webviews). And I found that a good balance between avoiding the slowness and bloat of Electron, while not having to reimplement font atlases, Unicode rendering, and a million other things people take for granted these days.
I use ebiten which through CGO uses glfw, so there’s a few layers of abstraction between Go and OpenGL. It’s true that I had to implement unicode rendering and a bunch of other things for either completeness or performance, but Ebiten was a solid foundation to build from.
Using the system WebView has pretty much the same bloat as electron (in terms of cpu and ram) unless I'm missing something? Sure it's nice that it's not 500MB on disk but day to day it doesn't affect me as much as the fact that you're still running in a browser.
It’s a fair assumption that it would, but that wasn’t my experience in practice.
Browsers are surprisingly efficient renderers. So I can use a lean AOT language for most of the heavy lifting and then just use the webview for the final painting to screen.
The final runtime isn’t actually any more CPU nor memory hungry than when I was having to store images and font atlases in GPU memory and writing to the frame buffer directly via SDL. And as a benefit of the switch, I get a richer library of widgets to draw, far fewer rendering glitches due to edge cases in fonts, graphics drivers, and a plethora of other hard-to-debug problems.
The original plan was to support both WebKit and SDL frontends (like how libghostty works) but the webview was such an accelerant on productivity and with so few drawbacks that i quickly dropped SDL support and went all in with webviews.
This is cool, but I think I'll stick with herdr and a separate browser and zed. Following the linux philosophy of using many tools that do their job well, rather than 1 tool that does everything poorly.
These days it feels like everyone and their son are building a new IDE (and I say this as someone who’s done the same haha).
Interestingly, they’re using graphics libraries like OpenGL/Vulkan in Go. Like I originally was. But after a year of edge cases, I gave up and switched to Wails (using OS-native webviews). And I found that a good balance between avoiding the slowness and bloat of Electron, while not having to reimplement font atlases, Unicode rendering, and a million other things people take for granted these days.
The perfect work environment is something very personal.
I am not happy with your decisions for the ide you sold me. I never was, I just coped.
The LLMs just enable everyone to build exactly what they need. And if that thing has an audience of one, so be it.
Tbh I was building stuff for an audience of one long before LLMs. If people liked what I built then I always considered that a bonus.
That’s why I’ve been running my own $SHELL for ~10 years. Even had my own Linux WM in development for a brief period.
But you’re right that it’s never been easier.
I use ebiten which through CGO uses glfw, so there’s a few layers of abstraction between Go and OpenGL. It’s true that I had to implement unicode rendering and a bunch of other things for either completeness or performance, but Ebiten was a solid foundation to build from.
I was using SDL.
It was a nice API to target and I got some really good performance vs memory and CPU usage out of it. But I also don’t regret moving off it.
Using the system WebView has pretty much the same bloat as electron (in terms of cpu and ram) unless I'm missing something? Sure it's nice that it's not 500MB on disk but day to day it doesn't affect me as much as the fact that you're still running in a browser.
It’s a fair assumption that it would, but that wasn’t my experience in practice.
Browsers are surprisingly efficient renderers. So I can use a lean AOT language for most of the heavy lifting and then just use the webview for the final painting to screen.
The final runtime isn’t actually any more CPU nor memory hungry than when I was having to store images and font atlases in GPU memory and writing to the frame buffer directly via SDL. And as a benefit of the switch, I get a richer library of widgets to draw, far fewer rendering glitches due to edge cases in fonts, graphics drivers, and a plethora of other hard-to-debug problems.
The original plan was to support both WebKit and SDL frontends (like how libghostty works) but the webview was such an accelerant on productivity and with so few drawbacks that i quickly dropped SDL support and went all in with webviews.
This is cool, but I think I'll stick with herdr and a separate browser and zed. Following the linux philosophy of using many tools that do their job well, rather than 1 tool that does everything poorly.
Don't let the Emacs folks read this :)
Have you found that it does everything poorly?
I assume this type of application is the new JavaScript frameworks for the near future.
That sideways traffic light means it's for MacOS, I presume?
The homepage is definitely giving "designed by an LLM"
I’m guessing you scrolled passed the text and went straight to the screenshots?
> You can download it for macOS and Linux
> You can download it for macOS and Linux
This looks really cool - but are we still doing TUIs?
Why wouldn't we?
TUIs now and forever.
We most certainly are.
What would you do instead?