Comments by "" (@pierreollivier1) on "Theo - t3․gg" channel.

  1. I think Electron should be used by companies or people who don't have the means or the need for true native app. The problem is that Electron allows too many Lazy developer to make shitty software. VScode is just embarrassing, we have Tflops of power, recent CPU's have SSE extension with a minimum of 128bit width, mine has AVX512, I can do as much as 64 * 8 bits of processing per clock cycle, for each core, we have Mbs of cache, most computers have between 16 and 128gb of Ram nowadays. We have GPU's that are more powerful than most Super computers 15y ago. Yet somehow VScode can't do 120fps, it can't updates it's UI in real time, it can't do syntax highlighting well, it doesn't let me move my cursor fast enough. WTF ??? And that's entirely on the lazy companies and the lazy developers that just simply aren't good enough to make decent software. This is why I will never use an IDE, it's not that I don't think that they are useful or that I think that TUI's are better, but it's simply that the current IDE's are just trash, they just are terrible.
    5
  2. that's an excuse, for lazy devs, and poor architecture. Look at something like Ghostty, they've managed to make native rendering on the set of platform they support, sure you sometimes can't have certain features due to platform specific things. But most apps can and it doesn't take much works if you have a modular architecture that abstracts away the rendering/windowing management, 95% of the features that you may implement would be easily doable in a platform agnostic way.
    5
  3. you just have to install some tools, like yazi, zoxide, atuin, fzf, etc.
    3
  4.  @sirnawaz  You should definitely try another terminal be it kitty, alacrity or my personal favorite ghostty, because it does have an impact
    2
  5. that's a C++ problem but programming language like Zig or Rust, solves that problem with their good build system. The reason C++ is so bad for native Gui is because the tooling around C++ is just terrible. The build system is bad, the dependencies are bad. It's a shit show. But with Rust and Zig, you can soft fork those C/C++ library, integrate them with the proper build system and create a package that you can later fetch and build on all platforms.
    2
  6.  @josephvictory9536  You give me the 30M of the annual VScode dev team, I fire the team, and I implement it from scratch, using vulkan, tree-sitter, and I will even embed a JS Runtime.
    1
  7. It's fast, at least they have that, going for them, VS code is taking 400% more ram on my computer and it's also slower, and less responsive and that's not even mentioning plugins.
    1
  8. Honestly I get it, I really like MacOS too, I think it's one of the best OS after Linux, Windows is a pile of trash. MacOS has the best window manager too, Yabai is incredible, and even on the linux side I never found something that mimics the power of Yabai that doesn't require tons of configuration. But this days I'm on a vanilla ubuntu, no WM, just Ghostty, Helix, and firefox, is what I use and it's not bad at all, sure I can't teleport and move stuff as quickly as when I was using my Mac but this is because I can't find a WM that doesn't suck to configure, or adds instability, the thing I liked the most about Yabai is that you essentially just get the vanilla MacOS desktop, but with keyboard centric control. I3 just remove your desktop you just have nothing to interact with, and I've tested other WM but they also don't let me have the regular ubuntu desktop and just move windows around like yabai, this is definitely skill issue tho, I can probably take hours to figure it out, but I can't be bothered at this point.
    1
  9. You can actually use custom shaders with ghostty if you want, but that's very far away from javascript .
    1
  10. this exist in Ghostty I believe.
    1
  11.  @Descent098  It doesn't have to be native, or have the same features, I mean it's very app dependent but for something where performance and latency matters, it's simply unacceptable to not develop using a native solution. The truth is not a whole lot of people really care about speed and latency otherwise VScode wouldn't be used by anyone.
    1
  12. @ Also I don't belive that most features parity problem are related to the OS, all major OS expose libc, yes it might differ on tiny edge cases, but not enough to justify not adding a rules in your build script to link the libraries and to cross-compile for the target. doing Cross-platform code is really not that hard.
    1
  13.  @Descent098  Exactly, Like if you just want a quick and easy desktop app cross-platform and the app isn't really complex and it's not even that important if it's really snappy and reactive, or you have a small team or a small budget, than yes Electron is really fine by me. But if you are a billion dollar company like Microsoft, that you are literally a company that sells, Freaking proprietary kernel code (aka Windows), but you are telling me that they went with Electron for VScode ? Like It's embarrassing like most of their products, but 2006 Visual Studio, booted in a fraction of a seconds. Everything was snappy and fast, mind you it was freaking 2006 hardware. But now 19 years later we basically have super computers at home. Microsoft is literally one of the biggest company one the planet, recruiting top notch talents across the world, And you are telling me that those guys can't even be bothered to make a native cross-platform editor ? Like VScode is the app I have in mind, it's just so slow, there is no excuse for that, I'm not even asking for much, but not having my UI update in real-time when I change code, is just straight up disrespectful for all of the engineers at AMD and Intel and there is no amount of money that will make me use that piece of trash, when I need to help someone, if they only have vs code, I'll open note, or text edit, or vi, just to make sure I don't ever touch that embarrassment. In absolutely zero parallel universe should a vanilla text editor, doing absolutely jack shit, take 1gb to 1.5gb of memory doing nothing, and if for some reasons it actually need all that memory it better be a thousand times more responsive that it currently is. To me VScode is probably the absolute worst app for Electron.
    1
  14.  @Descent098  No for sure, there are legit cases where you using Electron or some other kind of cross-platform backend might be useful and beneficial. But Take VScode for example, it's a bloody text editor, there is literally zero features that you can't implement on basically anything with an os and a file system. Every major OS has a C api, every one of them support a C compiler. But if we are talking about more edgy stuff, like VR/AR, AI, Decoding/Encoding, etc then sure I expect to find differences across different versions.
    1
  15.  @Descent098  No for sure VScode has it's merit, I'm not saying it's not doing usable to solve problem, and despite my tone this is not an attempt at burning a church to say that mine is better. I really don't care what people use, I know what I want and care about, but I also understand that people are different and some might not be bothered by the things that I noticed when trying VScode. But for some context I use an editor called Helix. It's very much like Neovim, except its' written in Rust, and is basically a Neovim with all the plugins you would want, but written in native language. So it's like 15/20 mb peak RSS, and everything is just as it should be, on our modern computers, meaning instantaneous. ? you want to fuzzy find from your root directory ? instant. You want to quit and open 50 files, quit and reopen them all ? instant. Want to have multiple lsp ? instant. Fuzz your millions of LOC codebase ? instant. And again not saying that to say it's better, not everybody cares about it, but it's why when I see something like VScode, it's just out of this world, like I just can't fathom what is happening to that poor silicon when you decide to open VScode.
    1
  16. I've been part of the development process since early on, and I think a lot of the discussion around this project misses the core point. Let's break it down. Some people say, "Why should I care if my terminal is fast? I don't notice the difference." But here's the thing, why settle for slow software at all? If a terminal doesn't offer a feature you care about, like WezTerm's Lua scripting, that's fair, or if you are missing something that's essential to your workflow, by all means don't use Ghostty. But if you're indifferent beyond that, why not prioritize speed? I'm not saying everyone should use Ghostty, but I do believe anyone who spends significant time in a terminal should at least try a faster one. The difference becomes apparent when you're handling verbose output, such as package installations or extensive logs. Terminals can lag, especially if you're using nerd fonts, special glyphs, or working with non-English languages. Speed matters. I used kitty extensively before switching to Ghostty. As someone who practically lives in the terminal, performance hiccups are glaring. In iTerm2, for example, text rendering artifacts or paste lag can be painfully noticeable. It's not just a minor inconvenience, when pasting a large block of text takes seconds or more, it disrupts workflow and feels archaic. That friction compounds over time. Ghostty's goal isn't just to be another terminal emulator. Its ambition is to serve as a cross-platform, drop-in replacement for existing terminals. Admittedly, the current Windows experience isn't ideal, and on Linux, GTK as the sole native option may put some people off. But let's keep in mind this is version 1.0. The project has been developed behind closed doors, but over the next few years, expect more features, backend flexibility, and expanded customization. The combination of the Zig build system and Ghostty's modular architecture makes adding new platform support straightforward. One of Ghostty's most exciting aspects isn't Ghostty itself, but libghostty the terminal emulation library that powers it. Ghostty is essentially a frontend for libghostty, which is shaping up to be one of the most comprehensive cross-platform terminal emulation libraries available. Right now, Ghostty is the primary showcase, but I envision other projects with embedded terminal components adopting libghostty. Many existing terminals embed home-grown, brittle terminal emulation layers. Replacing those with libghostty could drastically improve performance and feature parity across different environments. Ambition is what sets Ghostty apart. Some features might seem niche today, like the terminal inspector. But consider this: if you ever develop internal TUI tools, having the ability to deeply introspect your terminal could become invaluable. Debugging TUI apps is notoriously cumbersome, and tools like this could make a real difference when printf debugging isn't enough. In the end, Ghostty isn't just about speed, being written in Zig, or ticking off feature checkboxes. It's about elevating the terminal experience. The project's mission, to create an open-source, high-performance, feature-rich terminal is worth paying attention to. It pushes the boundaries of what terminal emulators can do and encourages innovation in a space that often feels stagnant. If nothing else, that ambition deserves recognition.
    1