3 ms·

I've talked up the strengths, you've brought up the big weaknesses. I think there is some interesting work on both of these fronts, but the developer experience

I've talked up the strengths, you've brought up the big weaknesses. I think there is some interesting work on both of these fronts, but the developer experience situation is very primitive so far by comparison. Compile times have been getting better. For reference, on my machine an incremental build of Runebender is 2.3s. Part of this reflects some choices we've made to use platform capabilities rather than build the entire stack ourselves.

pornel 6y ago
DevTools is the killer feature. I've developed a Gtk GUI in Rust recently. It wasn't bad, but I probably won't use it ever again. When I'm debugging a UI, I want to right-click it, select Inspect, and be able to tweak everything live. DevTools is such a force multiplier, that I'm confident I can quickly and reliably develop a whole GUI from scratch, with custom layout animations and bells and whistles using JS+CSS. I have zero confidence in doing anything in Gtk or Cocoa beyond dumping static pre-built controls in a window. The cycle of editing blindly, recompiling, and re-running is the old paradigm that I don't want to return to.
- jakear 6y ago
  Seems to me like the future could well be TS/Electron with bindings to Rust for system-level high perf activities. Let the UI scripting language and mature rendering platform do the UI scripting and rendering, and let the high performance systems programming language do the performance-critical system interfacing. For example, in vscode we do almost everything in TS, but shell out to ripgrep for workspace text search.
  - pjmlp 6y ago
    Great, here is an off topic quick feedback to someone from VSCode, in what concerns search I always end up starting notepad++ Ctrl-Shif-F, get what I was searching for, meanwhile VSCode just keeps showing its increasing blue line without any results to show up. Which is quite disappointing, given ripgrep's reputation in search performance.
    - jakear 6y ago
      Have you perhaps disabled ignore files accidentally? It’s the toggle in right of the the exclude field.
      - pjmlp 6y ago
        Seems to be enabled, oh well there are enough Github issues related to search performance anyway. Thanks for the help.
        jakear 6y ago
        Up to you if you want to go through the rigamarole, though we do appreciate every issue^, even if we do end up closing it as a duplicate :) ^well, every issue that isn't completely void of information ;)
  - brundolf 6y ago
    This is what some people have started doing, and it works well as long as your bottleneck lives outside of the UI itself. But for some highly complex apps, web layout itself can become the bottleneck, and that's really hard to work around. VSCode is an absolute miracle in this regard, but it uses lots of dirty tricks under the hood to accomplish that.
- fulafel 6y ago
  GTK has all bits needed to support this tweaking workflow, no? "Just" missing a UI (outside the GUI builder tools).
  - pjmlp 6y ago
    Kind of, you need introspection capabilities, check for example live tree in VS for WPF and WinUI/UWP for .NET and C++ applications.
- maxxk 6y ago
  Actually there is built-in GTK Inspector [0] and I used it successfully with gtk-rs before. GTK_DEBUG=interactive your-app [0] https://wiki.gnome.org/Projects/GTK/Inspector https://wiki.gnome.org/Projects/GTK/Inspector

pornel 6y ago

DevTools is the killer feature. I've developed a Gtk GUI in Rust recently. It wasn't bad, but I probably won't use it ever again. When I'm debugging a UI, I want to right-click it, select Inspect, and be able to tweak everything live. DevTools is such a force multiplier, that I'm confident I can quickly and reliably develop a whole GUI from scratch, with custom layout animations and bells and whistles using JS+CSS. I have zero confidence in doing anything in Gtk or Cocoa beyond dumping static pre-built controls in a window. The cycle of editing blindly, recompiling, and re-running is the old paradigm that I don't want to return to.

jakear 6y ago
Seems to me like the future could well be TS/Electron with bindings to Rust for system-level high perf activities. Let the UI scripting language and mature rendering platform do the UI scripting and rendering, and let the high performance systems programming language do the performance-critical system interfacing. For example, in vscode we do almost everything in TS, but shell out to ripgrep for workspace text search.
- pjmlp 6y ago
  Great, here is an off topic quick feedback to someone from VSCode, in what concerns search I always end up starting notepad++ Ctrl-Shif-F, get what I was searching for, meanwhile VSCode just keeps showing its increasing blue line without any results to show up. Which is quite disappointing, given ripgrep's reputation in search performance.
  - jakear 6y ago
    Have you perhaps disabled ignore files accidentally? It’s the toggle in right of the the exclude field.
    - pjmlp 6y ago
      Seems to be enabled, oh well there are enough Github issues related to search performance anyway. Thanks for the help.
      - jakear 6y ago
        Up to you if you want to go through the rigamarole, though we do appreciate every issue^, even if we do end up closing it as a duplicate :) ^well, every issue that isn't completely void of information ;)
- brundolf 6y ago
  This is what some people have started doing, and it works well as long as your bottleneck lives outside of the UI itself. But for some highly complex apps, web layout itself can become the bottleneck, and that's really hard to work around. VSCode is an absolute miracle in this regard, but it uses lots of dirty tricks under the hood to accomplish that.
fulafel 6y ago
GTK has all bits needed to support this tweaking workflow, no? "Just" missing a UI (outside the GUI builder tools).
- pjmlp 6y ago
  Kind of, you need introspection capabilities, check for example live tree in VS for WPF and WinUI/UWP for .NET and C++ applications.
maxxk 6y ago
Actually there is built-in GTK Inspector [0] and I used it successfully with gtk-rs before. GTK_DEBUG=interactive your-app [0] https://wiki.gnome.org/Projects/GTK/Inspector https://wiki.gnome.org/Projects/GTK/Inspector