Goood stuff!

One of my long-standing "would make if I had the time and perseverance" themes has been a terminal text editor that's hugely VSCode-like + compatible, so always glad to hear anyone going anywhere near that, and hence I perked up from these:

> Prioritizes standard keybindings and a minimal learning curve.

> Extensibility: Uses TypeScript (via Deno) for plugins, making it accessible to a large developer base.

Because where you are now with Fresh, you're probably really not far from supporting say `settings.json`, `launch.json`, `tasks.json`, `keybindings.json`, `.tmTheme`s and theme `.json`s, and indeed bringing up a VSCode-API-implementing "extension host" that can load up and run/host most `.vsix`es. Now, being terminal-based you'd skip over certain feature subsets such as webviews, custom (non-text) editors and the like... and might postpone Notebooks and such fancies initially, but:

Consider! 1000s of high-value, capable, tech-specific dev extensions out there, all readily supported by your just-spawned new editor. Doesn't that sound pretty exciting?

After all, there's a huge subset of VSCode fans who'd always switch in a heartbeat to a just-simply-non-Electron version (whether native or terminal) of the very same feature-scape & extensions & UI dev experience if only it was made and to max compatibility (and MS won't ever do so).

All that's missing (from screenshot glance) is the other sidebars & panels in addition to File Explorer =)

Will be putting your Fresh on my Github Watch list, but then again, I never really read the GH feed anyway.. but maybe I'll remember to check back in every quarter or so =)

I've been mulling over vscode extension compatibility... There is a challenge there, because the API surface is non-trivial and some of it is "web-ish". I wouldn't want people to be disappointed if 60% of the plugins they try to use don't really work properly.

Also, there are nuances like VSCode exposing APIs that force the entire file to be in-memory (which is how VSCode works), this is fine but in my editor I'm trying to get extensions to work well even if the file is huge (encouraging incremental / partial stuff).

But yes, it's a very compelling vision... and part of the reason I chose TypeScript.

Thanks for the input :)

For flow-compatible electronica, let me add specifically:

https://netlabels.org/electronic-music/

https://files.scene.org/browse/music/

https://netlabelarchive.org/

https://freemusicarchive.org/label/all/

Also very neat is DearImgui via either https://github.com/AllenDang/giu (Go-convenient wrapper) or https://github.com/AllenDang/cimgui-go/ (raw bindings)

That is both .NET stuff, Wails is one of various Go options.

> Speaking of writing javascript instead of JSX, I'm a big fan of the hyperscript approach

Speaking of writing JS instead of JSX or your example, I like the vanjs.org approach:

    const Hello = () => div(
      p("Hello"),
      ul(
        li("World"),
        li(a({href: "https://vanjs.org/"}, "VanJS")),
      ),
    )
    van.add(document.body, Hello())

JSX was such a breath of fresh air after having written and maintained apps which used both of these formats for years (and also having written a library which supported both of them for reusing the same templates on the server and in the browser) - it's the commas! I'm glad it's everywhere now.

But that was also back in the days when trailing commas at the end could break things, JavaScript editor support was relatively poor, and tooling wasn't where it is now (knowing your code is once again valid because the autoformatter just kicked in).

Since we're sharing HTML in JS syntaxes. Don't forget JS tagged template literals like https://jsr.io/@mastrojs/mastro/doc/~/html

Mastro looks like what I do for my offline-first, rendered from Service Workers. I just compose html template string literals and stream them back to the front end. The lib I use for HTML is a bit more powerful though. It is a very elegant way to program.

https://github.com/jon49/Soccer

Thanks, this one? https://github.com/jon49/html-template-tag-async Looks very similar indeed! What makes it "more powerful" than Mastro's html template?

Godot is neat for personal tool-making where I just need a small gui with basic controls and can express the whole proggie in just GdScript (API has sufficient OS interactions for most needs), I just whip it out for those when I otherwise don't really use it anymore, just keeping it around for that. Stuff like that: https://postimg.cc/VJc0pWbB

I love Godot and think it has a great deal of potential for this kind of thing. Sure using a game loop isn't really very efficient for basic UI application, but in your case that doesnt really matter too much. That being said, I really don't like how it handles UI themeing.

Buttons are a good example. If you want to define a button theme, you have to individually define the theme for every possible state the button can be in. No inheritance, the best you can do is copy and paste them over (which means if you want to tweak one, you have to tweak them all). Compared to something like CSS, its a nightmare to theme even slightly interactive Godot GUI's

Yeah that seems like an area for improvement in Godot's GUI system indeed. For my stuff, I never had a need for theming, but good to keep in mind if one ever wanted to do an app shared with others.

Another homegrown personal tool I had once written was in Go with DearImgui, so basically with AllenDang/giu... also really quite rapid dev and lean-enough binary / perf.

But Godot is wysiwyg for GUI stuff, so that's a plus..

Godot is a heavy dependency for making small tools, no?

Release build of such a Godot-built tool is between 60-70 MB. Other than that, it seems fast enough & RAM-friendly enough for the usual simple use-cases. Game engines tend toward self-optimization over time.

Well, lobste.rs has tags and then you can block whatever tags you choose to block, and for HN you'd need a reader that classifies / auto-tags posts and allows blocking out tags, which you'd start doing after verifying the auto-tagging classification works reliably.

Sounds like a bit like a tall order, not sure it's "just a weekend project", would (for my purposes) probably work best as a browser extension for just the listing of posts (auto-tagged and then optionally tag-filtered) to then open them in one's browser, allowing normal native reading+posting+voting+etc.

> the intros really undersell how bad the experience of using SAT solvers directly is, the DIMACS sat file format makes me think of the year 1973

"MiniZinc" is the name of the Pythonic-ish-like syntax targeting (ie on-the-fly translating to) numerous different solvers (somewhere around half-a-dozen to a dozen or so, don't recall exactly =)

I had never used SAT before (was familiar with the concept) and recently wanted to avoid thinking, so I asked gemini (after a few test prompts):

"""Create a MiniZinc script to find the optimal E12-series resistor values for the base ($R_B$) and collector ($R_C$) of a PN2222A transistor switch.

Specifications:

Collector Voltage Supply ($V_{CC}$): 12V DC

Base (Input) Voltage ($V_{IN}$): 3.3V DC

Target Collector Current ($I_C$): Maximize, but do not exceed, 1W (1 watt).

The script must correctly model the circuit to ensure the transistor is in saturation and must execute without Gecode solver errors like 'Float::linear: Number out of limits"""

After a few more try-paste exception loops, that generated a lovely and readable MiniZinc script with variables I can adjust for other circuits. It was exciting to see that basically every constraint problem I learned in school ("at what angle should you swim across the river..." is just a matter of encoding the problem and running a solver (I still think people should learn the basics of constraint problems, but after a certain point the problems are just tricky enough that it makes more sense to teach people how solvers work, and how to encode problems for them...")

> My impression is that it was going to take a few years for things to shake out. Is that wrong?

I had that very impression in early 2020 after some months of Zigging (and being burned by constant breaking changes), and left, deciding "I'll check it out again in a few years."

I had some intuition it might be one of these forever-refactoring eternal-tinker-and-rewrite fests and here I am 5 years later, still lurking for that 1.0 from the sidelines, while staying in Go or C depending on the nature of the thing at hand.

That's not to say it'll never get there, it's a vibrant project prioritizing making the best design decisions rather than mere Shipping Asap. For a C-replacement that's the right spirit, in principle. But whether there's inbuilt immunity to engineers falling prey to their forever-refine-and-resculpt I can't tell. I find it a great project to wait for leisurely (=

Even with JS/TS app code, instead of Electron, you can still also use Tauri afaict: just minimally get the Tauri binding up in your compiles-to-native lang of choice, and then one can still write the overwhelming bulk of the GUI in JS/TS (and perhaps even most/all of app logic, depending on how much of it is expressible via browser web APIs).

Certainly less bloat this way than Electron, for those with a taste for JS/TS.