Jiratui – a Textual UI for Interacting with Atlassian Jira From Your Shell
Posted4 months agoActive4 months ago
jiratui.shTechstoryHigh profile
excitedpositive
Debate
20/100
TuiJiraProductivity Tools
Key topics
Tui
Jira
Productivity Tools
The community is excited about Jiratui, a Textual UI for interacting with Atlassian Jira from the shell, with discussions around its potential to improve productivity and requests for similar tools for other platforms.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
19m
Peak period
22
0-6h
Avg / period
11.4
Comment distribution80 data points
Loading chart...
Based on 80 loaded comments
Key moments
- 01Story posted
Sep 10, 2025 at 10:42 AM EDT
4 months ago
Step 01 - 02First comment
Sep 10, 2025 at 11:01 AM EDT
19m after posting
Step 02 - 03Peak activity
22 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 12, 2025 at 2:01 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45198481Type: storyLast synced: 11/20/2025, 4:38:28 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
One question. Is there any way that if I click a JIRA link somewhere, like email or Slack, that it could open in the TUI instead of in the browser? I just can’t imagine that being possible.
https://textual.textualize.io/
[1] https://github.com/Textualize/textual
Nowadays I'm in ADO, I still want a unified UI for any and all ticketing systems that allows me a consistent UI regardless of JIRA or even ADO. I'm tired of so many different workflows that make no sense.
But they all claim to be scrum / agile.
I wrote lt as a TUI for navigating/searching Linear issues. It is read-only right now.
JIRA speed drives me crazy sometimes, so a couple of months ago I decided to build myself a tool to do instant searches/filters on multiple projects right from the browser just to scratch my own itch.
I just wanted to see if I could have near-instant filtering. I think I got a pretty decent performance by using some JS tricks. I'm sure there might be ways to make it even faster.
Page is around 70kb (HTML+CSS+JS). Everything is manually crafted. I know the design won't win a beauty contest, but it does feel instant and works for my personal use-case. I had a lot of fun building this side-project.
There is a public URL, feel free to try it out [1]. Already mentioned in a previous comment in HN a while ago [2].
[1] https://jetboard.pausanchez.com [2] https://news.ycombinator.com/item?id=44740472
For the record, it uses a proxy because of CORS. Proxy is in few lines of golang. No NPM or any other framework used to make the project. In any case, if anybody is interested in the source code to run it yourself I'm happy to make the project public. Trusting a proxy on some random's guy on internet is probably a bad idea, given all NPM shit that happened yesterday, in any case, if you want to try, feel free, but use at your own risk :P
JIRA's OAuth implementation requires apps to be registered, involves public/private key pairs, and changes the auth flow. That adds complexity and makes setup harder, which is why I opted for a simpler API key setup, you get the API key, you write it down, you can make requests. It is just simpler and does not require JIRA admin rights.
For comparison, JiraTUI also uses the user's API token. The difference, I guess, is that it runs locally on your machine, but they could also send it somewhere else. At the end of the day, it comes down to whether you trust what you're downloading versus trusting what runs on a remote server. It is true that locally you could potentially inspect all HTTPS or even TCP requests whereas in the remote server you don't have a clue.
The thing is, OAuth in JIRA demands app registration and certificate management, so I guess many developers end up defaulting to user API keys as the path of least resistance, even if they encourage OAuth as well.
Run JiraTui in a container / bubblewrap, and only allow it to connect to the Jira API host:port.
Haha, cool site
I will definitely be curious to see how much of Jira's abysmal performance is due to the website design (got to be a fair bit given how badly things like drag and drop perform) and how much is due to the server.
There’s nothing preventing web apps from being built this way, but they just often are not.
I appreciate the value of the web browser providing the universal "quick" GUI (as in "I can open it on most devices and instantly interact"), but for power users I really wish more people were shipping things that helped out people not afraid to learn a bunch of keyboard commands
Notice how I can list with `gh pr list` but then will need to run a full new command to actually inspect the contents of those PRs. I think an interactive interface would be nice!
GitHub becomes much more comfortable with the Refined GitHub extension. It adds a bunch of keyboard shortcuts, among a ton of other small improvements.
I think nothing prevents a web app from having keyboard shortcuts, but more often than not what I see is web apps having bad keyboard shortcuts that hijack the browser's natural behavior (taking over <ctrl>-f is a good example). I think often people go at this as if it's an Electron app and not a browser that has literally a hundred other interfaces loaded into it, leading the user to have certain expectations.
All that aside your Gmail example is spot on, and I'm one of those google-hatin' dudes.
TUIs are usually the most snappy interfaces you can have. Pure bliss in comparison. To their credit, at least Atlassian provides usable APIs.
It breaks everything from text selection to copy and paste.
It’s not your usual TUI framework. I tried using it yesterday to implement a simple console app — the damn thing even uses CSS for styling.
For me the most useful thing would be a cli tool (not tui) to just add stories. This way I could just write a bunch of stories in a text file (..or an .org file..) with the conveniences of my editor and upload them. Seems jiratui actually comes with some cli tools as well, but it doesn't seem this is yet included, or it's not just documented yet. I'll give a shot to this..
Now I'm doing that by copypasting the entries from the file, one by one, to the fields in the web ui, and not all of the fields can be copy pasted, and then updating also the file to have the correct issue ids so I can use them for finding issues with e.g. grep. Naturally this will only work for my stories, and won't synchronize with changes made in Jira.
...I also wonder if Atlassian might try acquire this for 600M? /s
I have something similar for confluence. I'm the only known user though, it's probably full of bugs.
https://github.com/AdrianVollmer/Congruence
I've sensed for years from colleagues or blog posts etc a drive to go deeper and lower in the stack. I attributed this to the huge amount of front end devs who feel detached from the "real" stuff because of layers of frameworks. Not derisively, I think it's great. Even coworkers will express this to me.
This is what I suspect helped Rust skyrocket in the zeitgeist, too. It's got a lot of modern conveniences but it targets the more difficult areas like embedded, drivers, kernel, or performance critical code. And you can justifiably rewrite things (debatable but whatever). A way in!
I wonder if this is related?
Could be wrong on all this, of course.
1 more comments available on Hacker News