3 ms·

Thanks for input. Interesting list. A few notes on that: - Issue state is not tied to commits in the checked out repo. Events live in append-only user-scoped l

Thanks for input. Interesting list. A few notes on that: - Issue state is not tied to commits in the checked out repo. Events live in append-only user-scoped logs and are materialized independently of the checked out branch, so switching branches does not change issue state. This is solved with git worktrees. - Epiq keeps state in a dedicated state branch and does not put issue data into normal code history. The working branch stays clean. - Sync uses normal git push/pull semantics. - Multi-user conflicts are prevented because each user writes only to their own immutable event log file. You never co edit a file. Logs converge state in memory from the combined event stream. There’s no shared mutable issue document being edited. - The non-developer distribution can be addressed with exported state .md files (with the board as ascii). They are currently not generated automatically, but you can generate them at will. [edit - addition: Considerable effort has also been put into making the tool accessible to non-technical people, so there is auto completion, hints, a command palette with descriptions of each command, arrow key navigation and so on. It is my hope that anyone can pick it up rapidly. And a web interface could definitely be crafted for that usecase]

cxr 5mo ago
You don't need to put it on the Web to be able to leverage the World Wide Wruntime. Epiq looks to be written in TypeScript and distributed as JS via NPM. You know what excels at executing JS? The browser. If you want to actually address the usability problems—then create a CONTRIBUTING.html—linked from the README, that users are instructed to double-click to open (i.e. launch in the browser on any sanely configured system). From there, they can/should be able to load the project either by pointing to it with a filepicker-based workflow that's the same as VSCode's "Open Folder…" workflow, or by dragging and dropping the source tree into the browser window. If you do it right, then this should immediately present them with a browser-based UI for poring over and interacting with all the Epiq data in the repo—down to the Git commands to execute to integrate changes into the Epiq "database". It's beyond baffling that so many programmers who are nominally JS developers thumb their noses at writing standards-compliant code and instead insist on coding directly against Node's proprietary APIs.
- locknitpicker 5mo ago
  > It's beyond baffling that so many programmers who are nominally JS developers thumb their noses at writing standards-compliant code and instead insist on coding directly against Node's proprietary APIs. You're talking about node.js projects running on node.js, and you're complaining that it consumes node.js APIs. Strange.
  - cxr 5mo ago
    There is no argument or insight in your comment. It's physically possible to type in code that makes direct use of non-standard APIs that work in NodeJS but not the browser. Pointing out that this is so and that there are people who do it is not the same as engaging with the subject of whether they ought not to—which was the point of the remarks you responded to. Previously: > You're offering a retort to someone who is communicating their position that you ought not do something, where the retort consists of nothing more than explaining that people are doing it. Yes, clearly. But what the person you're responding to is arguing is that you ought not do it.¶ Consider[…]: > Person A: Here's little advice: don't take up smoking. Smoking is bad for you. > Person B: Yet people smoke <https://news.ycombinator.com/item?id=38712699 https://news.ycombinator.com/item?id=38712699>
    - locknitpicker 5mo ago
      [flagged]
      - deleted 5mo ago
        [deleted]
      - deleted 5mo ago
        [deleted]
      - cxr 5mo ago
        I am one of ~3 people primarily responsible for the JS Reference as it appeared/appears on developer.mozilla.org since before NodeJS (or V8) ever existed. I "know what JavaScript is".

cxr 5mo ago

You don't need to put it on the Web to be able to leverage the World Wide Wruntime. Epiq looks to be written in TypeScript and distributed as JS via NPM. You know what excels at executing JS? The browser. If you want to actually address the usability problems—then create a CONTRIBUTING.html—linked from the README, that users are instructed to double-click to open (i.e. launch in the browser on any sanely configured system). From there, they can/should be able to load the project either by pointing to it with a filepicker-based workflow that's the same as VSCode's "Open Folder…" workflow, or by dragging and dropping the source tree into the browser window. If you do it right, then this should immediately present them with a browser-based UI for poring over and interacting with all the Epiq data in the repo—down to the Git commands to execute to integrate changes into the Epiq "database". It's beyond baffling that so many programmers who are nominally JS developers thumb their noses at writing standards-compliant code and instead insist on coding directly against Node's proprietary APIs.

locknitpicker 5mo ago
> It's beyond baffling that so many programmers who are nominally JS developers thumb their noses at writing standards-compliant code and instead insist on coding directly against Node's proprietary APIs. You're talking about node.js projects running on node.js, and you're complaining that it consumes node.js APIs. Strange.
- cxr 5mo ago
  There is no argument or insight in your comment. It's physically possible to type in code that makes direct use of non-standard APIs that work in NodeJS but not the browser. Pointing out that this is so and that there are people who do it is not the same as engaging with the subject of whether they ought not to—which was the point of the remarks you responded to. Previously: > You're offering a retort to someone who is communicating their position that you ought not do something, where the retort consists of nothing more than explaining that people are doing it. Yes, clearly. But what the person you're responding to is arguing is that you ought not do it.¶ Consider[…]: > Person A: Here's little advice: don't take up smoking. Smoking is bad for you. > Person B: Yet people smoke <https://news.ycombinator.com/item?id=38712699 https://news.ycombinator.com/item?id=38712699>
  - locknitpicker 5mo ago
    [flagged]
    - deleted 5mo ago
      [deleted]
    - deleted 5mo ago
      [deleted]
    - cxr 5mo ago
      I am one of ~3 people primarily responsible for the JS Reference as it appeared/appears on developer.mozilla.org since before NodeJS (or V8) ever existed. I "know what JavaScript is".