I have a confession to make.

I hope ChatGPT starts writing only short sentences.

Punchy one-liners.

One thought per line.

So marketers finally realize this does not work.

And stop sending me junk emails written like this.

Listen to the sound of HN hawks erupting with joy when they realize they can blame JS, React, RSC, Rust, Cloudflare, and the cloud all for one outage.

For those hawks, Christmas has come early.

I knew plenty of office workers managing just fine using OpenOffice 10-15 years ago.

Today people are much more reliant on real-time collaboration, polished cloud and mobile experiences. Fractionalized open source software has a harder time competing with this than file based boxed software workflows of the past.

Agree, Personally I consider these newer systems a curse as far as productivity goes, using a simple email/open-office combination never caused any issues with clients or suppliers in the last 20 years.

Reminds me of the headline I saw a long time ago: “50 years later, inventor of the pixel says he’s sorry that he made it square.”

https://github.com/zed-extensions/tsgo does exactly this

This is cool, except I don’t want to run multiple copies of my dev stack.

GitButler does this cool thing where you can work on multiple branches at the same time, applied to the same working directory. For example you can work on the css while an agent works on the admin panel on a separate branch. It would be cool to have this with a tool like FleetCode.

I couldn't figure out this part of GitButler. I downloaded it and tried it (since I respect Scott Chacon and remember learning so much about Git from his well-written git guides).

But it was just a bit too much cognitive dissonance for me to try it.

It seems like the next big thing is parallel coding... I've tried GitButler, Spectator, Vibe-Kanban, and Conductor in the past week. And there is now FleetCode.

I liked Spectator's idea (use a separate docker container for each) but it didn't quite work right. So back to worktrees which seem to work just fine.

At some point, we will probably consolidate on 2-3 dominant tools in this space.

I wonder if even work trees will be needed if we can do a "create a copy-on-write version of my code folder" which would result in nearly zero-cost copies of the repo.

Somehow the GitButler workflow works great for me and it is the first VC software that made me drop Magit after a decade of daily use.

I do not use it collaboratively. I use it to continuously ship smaller things while working on bigger pieces and I constantly move independent changes around to different “lanes” to ship frequently as parts of my work mature.

With Magit I used staging area and amended commits continuously. With GitButler I “assign” files or chunks by dragging them into lanes as I am happy with the changes, and when I have a logical unit I commit it. Having this multiple staging areas has been a great workflow improvement as well.

can you elaborate why you don't want to run multiple copies of your dev stack? is it because you want to run your app from one place but be able to test multiple changes, vs having to install deps and start it from multiple folders?

Former. Otherwise I would need to have multiple database instances running, each with its own data and migrations to keep in sync. Plus I would need to re-do local env vars to hook all of this up for each worktree etc. And I often want to know how these branches play together, with GitButler I can bring these branches in and out with a single “apply to workspace” click.

How would having migrations in sync work when each parallel agent is (in principle) making changes to the database schema?

thanks for clarifying. I'll take a look into supporting this

A lightweight alternative to Playwright, which starts a browser instance, is using an HTML parser and DOM implementation like linkedom.

This is much cheaper to run on a server. For example: https://github.com/ozanmakes/scrapedown

Since this is marked as a departure from HTML and has it's own syntax, I think this is a good point to improve upon JSX.

- Remove curly braces from props and children

    <MyComponent name="Joe" onClick=(() => canBeInParanthesis()) />
    <div>userName</div>
    <div>"Text contents"</div>

- Add punning (like how { age: age } becomes { age } in JS)

    const age = 40;
    <MyComponent age />/
    <MyComponent active=true />  // explicit boolean attributes

Or (hear me out) we don’t need any DSL that doesn’t add anything while making code just more verbose compared to Js/ts.

How about... inlining children:

    const age = 40;
    const children = [<div ~ "Moe" />, <div ~ "Larry"/>, <div ~ "Curly" />];
    return <div age ~ children />;

Rationale: single child elements are ubiquitous in web dev, but most JSX formatters will require 3 lines of code even if there's a single child.

Python does an exceptionally bad job. After dragging the community through a 15-year transition to Python 3 in order to "fix" Unicode, we ended up with support that's worse than in languages that simply treat strings as raw bytes.

Some other fun examples: https://gist.github.com/ozanmakes/0624e805a13d2cebedfc81ea84...

Yeah I have no idea what is wrong with that. Python simply operates on arrays of codepoints, which are a stable representation that can be converted to a bunch of encodings including "proper" utf-8, as long as all codepoints are representable in that encoding. This also allows you to work with strings that contain arbitrary data falling outside of the unicode spectrum.

> which are a stable representation that can be converted to a bunch of encodings including "proper" utf-8, as long as all codepoints are representable in that encoding.

Which, to humor the parent, is also true of raw bytes strings. One of the (valid) points raised by the gist is that `str` is not infallibly encodable to UTF-8, since it can contain values that are not valid Unicode.

> This also allows you to work with strings that contain arbitrary data falling outside of the unicode spectrum.

If I write,

  def foo(s: str) -> …:

… I want the input string to be Unicode. If I need "Unicode, or maybe with bullshit mixed in", that can be a different type, and then I can take

  def foo(s: UnicodeWithBullshit) -> …:

> If I write [str] I want the inut string to be Unicode.

No, nothing about the "string" type in python implies unicode. It's, for all intents and purposes, its own encoding, and should be treated as such. Not all encodings it can convert to are representable as unicode, and vice versa, so it makes no sense to think of it as unicode.

The Python language developers themselves thought that their code only needed to operate on str and later realized that it needed to handle arbitrary bytes.

It's a common mistake. A lot of code was written using str despite users needing it to operate on UnicodeWithBullshit. PEP 383 was a necessary escape hatch to fix countless broken programs.

No, I'm not standing for that.

Python does it correctly and the results in that gist are expected. Characters are not grapheme clusters, and not every sequence of characters is valid. The ability to store unpaired surrogate characters is a feature: it would take extra time to validate this when it only really matters at encoding time. It also empowers the "surrogateescape" error handler, that in turn makes it possible to supply arbitrary bytes in command line arguments, even while providing strings to your program which make sense in the common case. (Not all sequences of bytes are valid UTF-8; the error handler maps the invalid bytes to invalid unpaired surrogates.) The same character counts are (correctly) observed in many other programming languages; there's nothing at all "exceptional" about Python's treatment.

It's not actually possible to "treat strings as raw bytes", because they contain more than 256 possible distinct symbols. They must be encoded; even if you assume an ecosystem-wide encoding, you are still using that encoding. But if you wish to work with raw sequences of bytes in Python, the `bytes` type is built-in and trivially created using a `b'...'` literal, or various other constructors. (There is also a mutable `bytearray` type.) These types now correctly behave as a sequence of byte (i.e., integer ranging 0..255 inclusive) values; when you index them, you get an integer. I have personal experience of these properties simplifying and clarifying my code.

Unicode was fixed (no quotation marks), with the result that you now have clearly distinct types that honour the Zen of Python principle that "explicit is better than implicit", and no longer get `UnicodeDecodeError` from attempting an encoding operation or vice-versa. (This problem spawned an entire family of very popular and very confused Stack Overflow Q&As, each with probably countless unrecognized duplicates.) As an added bonus, the default encoding for source code files changed to UTF-8, which means in practical terms that you can actually use non-English characters in your code comments (and even identifier names, with restrictions) now and have it just work without declaring an encoding (since your text editor now almost certainly assumes that encoding in 2025). This also made it possible to easily read text files as text in any declared encoding, and get strings as a result, while also having universal newline mode work, and all without needing to reach for `io` or `codecs` standard libraries.

The community was not so much "dragged through a 15-year transition"; rather, some members of the community spent as long as 15 (really 13.5, unless you count people continuing to try to use 2.7 past the extended EOL) years refusing to adapt to what was a clear bugfix of the clearly broken prior behaviour.

I tried Zen for a few months. I like the UX, even more than Arc in many places. But it is just too slow for me on an M1 Max. I've switched back to Orion. Even though I miss some goodies such as Firefox containers, I just need the browser to get out of the way, not use too much power and not warm up my laptop with runaway processes. Plus, tree-style tabs are great.