thanks for clarifying. it was hard for me to dignify such a comment with a response.

you’re also going to run into hardware acceleration issues trying to run Metal acceleration with a Linux kernel. i don’t really see a need to containerize these workloads these days anyway with tools like uv.

it’s a big pain in my ass at times trying to do web dev work with an aarch64-darwin dev env vs the target x86_64-linux. adding in hardware acceleration issues just sounds painful.

i also just personally don’t like containers. feels like bludgeon of a solution.

in a container

well there’s your issue. i get not liking the OS, but actively crippling your project will cripple your project.

containers on macOS do kinda suck

tough read. super long. i don’t know if it’s my millennial attention span, but i have to admit i mostly skimmed it.

anyway, i like the idea! i think the elephant in the room is that it just kinda sucks doing UI in XML. Kotlin has a similar HTML builder that is a joy to use for the same reasons: you don’t need some arcane templating language to do basic control flow.

super fair. i am a Linux guy normally. i’m just being honest. i wish there was a better more open alternative.

if you want to go with the Linux alternative it’s going to cost. get at least 32GB of RAM and at least a 4090 to run the kind of models you’re asking for. it’s the way she goes

honestly it’s hard to beat Macs these days in this space for two reasons:

• unified memory means that you don’t have to load up on RAM just to load the model and then also shell out for a video card with barely enough VRAM to fit a basic language model
• their supply chain is solid and has mostly avoided the constraints that other OEMs and parts manufacturers are struggling with

pricing is tough. sure, crypto is on its way out, but GPUs are still the platform of choice for most neural net workloads (outside of SoCs like Apple M-series). i built a PC in late 2024, and it’s easily worth twice what i paid for it.

as someone who has been watching far too much Food Network on the treadmill: just give em some freakin time to cook. the best things i’ve made personally are low and slow or from scratch pasta or slaw that sat in the fridge overnight. the 15-45min time frame has produced so many undercooked or otherwise mangled $80 steaks. like, even for a weeknight dinner i’m using things i marinated overnight or whatever. and in a kitchen setting you literally have all morning to prep in addition to doing overnight prep or even coming in super early to start your fresh bread. the format precludes entire classes of dishes.

deleted by creator

i have also thought about doing this on my work computer lol

first, i’m biased. i’m a home row kind of guy. i live in the terminal.

Which of the preferences you mentioned discounts this project?

i’ll be direct: light weight dependencies. i understand why you’d use Electron to build a UI, but does an API tester need a UI as a first class feature? i think something like hurl shows it’s not necessary. i get that maybe it’s an accessibility problem (juniors and Java devs being afraid of the command line etc), but UIs are not composable. i could run hurl (or curl for that matter) via bash or nushell or Elisp or Rust or Powershell or JavaScript or GitHub Actions or as a k8s postDeploy… and, not to draw the ire of Lemmy armchair zealots, they’re not easily usable by agents. an 8B model on my Macbook could figure out hurl, no MCP or crazy preprompting required.

plus: user adoption. this is the self hosted community, so maybe not everyone here has the same concern, but i can’t just commit a bunch of exotic files to my shared repositories. Bruno was a tough adoption, even though it seems obvious to version control this stuff and it was the only real option at the time. now i’m tired of Bruno cuz it goes out of date cuz it’s not easily scriptable with our internal auth services because it runs everything in its bespoke UI. if they haven’t made a button for it, you can’t do it. that’s the problem with UI dev tools.

no shade, i understand some people would be totally lost if their IDE didn’t have a big green run button.

i’ve been looking for a silver bullet in this space. hurl[1] seems promising as well. i feel like Bruno has always been jank, and going 1.0 didn’t help. at work i’ve stuck to vibe coding my API test code with a stack of TOML configs, that way i get to reuse/test my client code as well.

what i want is something version controllable with lightweight dependencies that i can automate easily. i’m afraid that discounts this project. not going to ask my team to download Yet Another Electron API client UI. i’m hesitant to introduce hurl, which can at least be scripted.

1: https://hurl.dev/

generally yeah. the problem is that the barrier to entry used to be higher so fewer people knew how to write code to integrate with the project before coding agents. now anyone who can install Claude Code has a seat at that table

sometimes syntax changes are part of the decision to do a rewrite. these are user interfaces at the end of the day. i’m not saying you’re wrong about any particular case, but it’s like saying “why make Instagram when Facebook exists” or “why make Scala when Java exists” etc. i like a good fresh look at how we use and instrument and teach our development tooling.

also, when i was 18 and would tell IT professionals i was getting a computer science degree, the #1 response was, “get ready to spend the rest of your life learning new things.” and i’ve found that to largely be true

yeah i get that.

generally most modern UIs are moving away from those reactive patterns (React, Svelte, etc) just cuz the composition can be optimized (Kotlin compiler plugin, shadow-DOM, etc), and a lot of people—myself included—find that declarative design easier to reason about. and yeah i guess i outed myself as an Android dev, but i can’t in good conscience recommend the node based Android XML UI lol (although that’s a different SDK).

anyway, not to yuck your yum. i played around with JavaFX back in the day but never made anything to speak of. i’ll have to check out more of your blog!

JavaFX with Kotlin

mad lad.

what makes you snub Compose UI?

i mean, how many realistically? how many systems are out there using non-LTS releases that would actually run into these edge cases? and auto-updating them in production without triggering the bug first? or maybe i’m a naive corpo

honestly, i 100% do not miss GUIs that hopefully do what you want them to do or have options grayed out or don’t include all the available options etc etc

i do get burnout, and i suffer many of the same symptoms. but i have a solution that works for me: NixOS

ok it does sound like i gave you more homework, but hear me out:

• with NixOS and flakes you have a commit history for your lab services, all centralized in one place.
• this can include as much documentation as you want: inline comments, commit messages, living documents in your repository, whatever
• even services that only provide a Docker based solution can be encapsulated and run by Nix, including using an alternate runtime like podman or containerd
• (this one will hammer me with downvotes but i genuinely do think that:) you can use an LLM agent like GitHub Copilot to get you started, learn the Nix language and ecosystem, and create Nix modules for things that need to be wrapped. i’ve been a software engineer for 15 years; i’ve got nothing to prove when it comes to making a working system. what i want is a working system.

this feels like a breaking change akin to macOS changing the Command key to bringing up a start menu because it confuses Windows users. platforms have differences, and this one is actually so tiny and inconsequential it feels like any ameliorated confusion will be offset by confusion of people that rely on it and use it. is this really the barrier to adoption?

other commenters have hinted at this, but the main point of most of the good advice is this: don’t use the system Python install (ie the one from apt) for development. uv is my go to, but the idea behind *conda, pyenv, asdf, etc is the same. the underlying OS shouldn’t be an issue; you should be able to ship the code between OSs and build just fine, ideally.

generally speaking, i think it’s good practice to find several recipes and compare and contrast them. you’ll find opinions and get a sense for what the writer’s priorities are (quick, fewer dishes, what they usually have in the pantry, etc) and can figure out which writer has similar priorities to you. or just synthesize a recipe from those sources. this does require some technical know-how, but i think this is a good skill to have.

my opinion is that the browser in general for rich front ends is the mistake, but i know i’m the minority