Show HN: Tritium – The Legal IDE in Rust
166 comments
·June 12, 2025chrismorgan
If you want people to use it on the web: do not under any circumstances use the pure-canvas approach. You must use real DOM, or it will be an endless frustration that turns many people away. I’ve written about the problems quite a few times, look through https://hn.algolia.com/?type=comment&query=chrismorgan+pure+... if you’re interested. If you’re not intending it to be used via the web, don’t worry.
But it’s a general principle: the more you are implementing from scratch, the more of a mess you’re likely to be in. As one example, at IME is completely broken, completely preventing a lot of non-English usage. Even my Compose key is broken: the key sequence `Compose - >` should produce →, but instead produces “Compose->”. This is the first time I’ve seen the Compose key turn into the word “Compose”!
For serious desktop-style applications, I honestly recommend that you not use plain-Rust GUI just yet. It is definitely steadily getting there, and I’m very optimistic that there will be at least two reasonable choices available within three years, but it’s still not where I’d want it to be for an app like this yet. Web browsers are, unfortunately, typically the pragmatic choice, even for desktop-only apps.
piker
It’s a great point. This uses the canvas element only because it’s rendering in the browser. But this is really a desktop application, so the canvas element doesn't come up as a concept outside of WASM. Your main contention seems to be that nobody other than web browser implementers can render and edit text, and thus we should be limited to the set of applications that can run on the DOM and leverage the web browser’s shaping and layout engines.
There are issues solved by the DOM for sure, but it requires shipping an entire web browser, and this product is a dedicated word processor. I’d rather face those issues head-on than defer to someone else’s implementation of such a core aspect. I know IME is broken, and Tritium’s really only able to address the needs of the happy path at the moment, but if can do that well, then there’s a business model to fund solving the edge cases to bring a real Word competitor to the desktop for lawyers.
miki123211
> thus we should be limited to the set of applications that can run on the DOM and leverage the web browser’s shaping and layout engines.
Yes, if you want to run in the web browser, use the APIs the browser gives you. If you want to go wild, run directly on desktop OSes.
Web browsers just straight up don't have some of the APIs you will need for a working app. Accessibility is a major example. If you want to stay compliant with legislation (probably something to care about when selling to lawyers), you'll end up poorly re-implementing an inferrior version of your GUI framework as a DOM tree for accessibility.
Sometimes your use case is just so uncommon and esoteric that's genuinely what you need to do (see Google Docs), but keep in mind that it requires Google-like levels of engineering investments to do it at least somewhat well.
piker
Very true! That's why this is just a "web preview". It's not intended to be used as the primary application. As mentioned elsewhere, the primary application is a desktop application that does look to leverage native APIs that aren't available on the web.
cryptonector
> Your main contention seems to be that nobody other than web browser implementers can render and edit text,
I took it as a claim that using the canvas you can't implement _inputs_ correctly. The example given was about compose sequences, but I'm sure there's much more to it.
hitekker
Yeah the GP’s reply was a little misleading/ambiguous. It begins by saying “great point” but then it distorts & argues against that point.
Better just to disagree directly, I think.
rapnie
Build it on Makepad, who are building the UI framework (blew me away first time I saw it in action). Leaves you to build the app.
gwbas1c
I for one appreciate the "no html" approach.
That being said, if this is truly a desktop application, why waste time making it run in a browser? If the point is to have a preview, put the time into making some good short videos that can go into a preview page.
piker
Because it's cool to get your hands on something before diving in. Also it allows users in walled off corporate environments to preview it without having to jump through thousands of hours of infosec hurdles.
connicpu
Considering it's just the desktop application being rendered to a canvas, I imagine not a ton of effort even needed to be put in and the UI framework is handling most of it.
wiseowise
> but it requires shipping an entire web browser
That’s a moot point and completely irrelevant for 99.99% people.
piker
Perhaps that is an accurate percentage, but lawyers are in that .01%. If you're competing with Microsoft Word on performance you'd better be stupid fast and lightweight. Transactional lawyers routinely have dozens of Word documents and PDFs open at a time. Not long-term viable with something like Electron.
z3t4
You do get a lot for free with the DOM, but it's messy, works differently between different browser and you have to constantly fight it. With your own rendering engine it's more work but you have much more freedom and can get better performance.
panzi
With DOM you get accessibility integration. At least in the EU if you provide a web service you have to be accessible, otherwise you can get sued.
z3t4
IANAL,afaik the accessibility law is only for government monopoly services. But I don't think it matters, because if you use the DOM you still need to test if the app works in screen readers etc, even normal websites have trouble with accessibility.
a_e_k
This is explicitly called out in the canvas spec's best practices section with a laundry list of things you'd have to re-implement [1].
> Authors should avoid implementing text editing controls using the canvas element. Doing so has a large number of disadvantages:
> [...]
> This is a huge amount of work, and authors are most strongly encouraged to avoid doing any of it by instead using the input element, the textarea element, or the contenteditable attribute.
[1] https://html.spec.whatwg.org/multipage/canvas.html#best-prac...
ModernMech
The way this app is architected with Rust and egui, they can write code once and deploy a GPU accelerated app across all major operating systems and the browser, without having to ship a web browser with their application. That's a strong draw for developers. I think it's important to ship products like this, even if some users are frustrated, because that frustration will breed innovation. Since they said it's meant to be desktop only, I think what they're doing is fine, as the web is just an added bonus.
The approach they've taken can create frustration, but it can also be seamless for users and create joy. For instance, I got to try out their app without any setup on my part, and then I can download it and it works exactly the same on my Windows and my Mac machines, because it's the same codebase for all three platforms. That kind of story was the holy grail of UI tooling for many years, and I think we should keep going down that path to improve it, despite frustrations along the way.
eviks
Wait, which 2 do you expect to become usable?
chrismorgan
It might not be particularly visible from outside just yet, but we’ve reached the stage where a lot of the fundamentals (which are typically deplorable in quick-and-dirty libraries) really are being nailed down quite nicely; and, perhaps more importantly, where a lot of the different teams are sharing work and collaborating on libraries, rather than each project starting from scratch. The momentum around AccessKit is the most visible example of this.
The Linebender community is a very promising venue for such collaboration, and there are at least four organisations investing quite a bit into this and related endeavours.
I won’t name any specific two libraries. It also depends a little on whether you’re targeting web tech only, or web and desktop, or desktop. (Or mobile.)
brundolf
Feedback: the UI feels like a direct reference to VSCode, which is familiar to software developers, but not to lawyers. If you're hoping this will be adopted by lawyers, I would focus on making the UX familiar to them. Look at software that they already use, and mimic those idioms insomuch as it makes sense to do so. I would also have the base web domain link to a normal home/info page, not to the demo directly. And maybe prefill the demo with some actual content (documents/etc) so people can really see what it does and how
Good luck!
piker
Great feedback; and I do agree. The HN link goes to the app itself because we're impatient, but there is an actual landing page most visitors hit.
I've gone back and forth on the UX idea, and while I do agree, it's important that Tritium selects for users that are going to be able to quickly adopt the newer concepts. Just simply presenting a "better Word" isn't really going to move the needle. It's really a shift in expectations. That said, I have recently backed off defaulting to dark mode to make it feel slightly more familiar.
brundolf
I think software people tend to underestimate the value of superficial familiarity. By all means, adhere to your new concepts and mental model. But even things like coloring, placement of the menu bar, the icons that you use, the organization of the UI, etc can go a really long way
Think about programming languages- ones that introduce radical new concepts may still employ familiar syntax/naming to smooth the transition for newcomers. Rust mimicked C++, TypeScript extended JS, etc. These languages were made to introduce powerful new ways of thinking about code, but by appearing as similar as possible to what devs already knew, they freed up more brain cycles for people trying to adopt them. They didn't muddy their concept-space for the sake of familiarity, but they didn't introduce any more unfamiliarity than they actually needed to for the benefits they wanted to give
singleshot_
No attorney who is flummoxed by this UX is going to touch an AI product in any meaningful way. Making legal tools for lawyers who would otherwise be using cuneiform tablets or the dictation pool is a waste of conversation. Looking similar to the tools a seventy five year old lawyer uses is like making an F1 car that would look familiar to Jackie Stewart: yeah, it’d probably help him adapt, but not enough to be competitive with an actual car.
Dig the idea of this product, will give it a whirl tonight.
Source: attorney, former dev
NooneAtAll3
> Rust mimicked C++
if anything, it didn't mimick /enough/
dr_kiszonka
I really like the idea. I could see some of my academic collaborators use something like this because it has features typically only supported when working with plaintext. A lot of academics do not love working with LaTeX.
But I would push back a bit against the UX and it being a "better Word". It is not immediately clear from looking at the website whether you support tracking changes. If you support editing Word documents, why aren't basic editing features, like font selection, size and weight, exposed in the UI. (I am viewing it on mobile Chrome and I might have missed it because your page doesn't support pinch to Zoom.)
You don't have to make it look like Word but it must be designed to facilitate common interaction patterns needed for working with Word documents.
(If you are building it on top of VSCode you could use its multiplayer features, which could be a good sell. )
sails
Figure out how to make it uncompromisingly productive for power users and then dumb it down, not the other way around way around
alexnewman
There's a couple ways to skin it. In fields where people are happy with products, i think familiarity is good. In fields where people hate the products, you get to go in tabla rasa. In this case they take advantage of the form of the interface through multisearch et al. Instead of resembling legal software, I wonder if they should resemble a court or a briefcase?
hiAndrewQuinn
Ha, I had the same thought a while back along a slightly different vector (legal-adjacent technical writing). I ended up writing a blog post of my wishlist of features Word has that static site generators like Hugo don't appear to, yet. [1]
I think there's a lot of money to be made in this arena, especially given that LLMs are much easier to integrate with plain text files than with Word documents.
[1]: https://hiandrewquinn.github.io/til-site/posts/things-word-h...
WorldMaker
Much (but not all) of what you are looking for exists in the reStructuredText [1] space. Sphinx [2] is an SSG focused on technical writing about software that you may find worth exploring.
Also, the scientific text community has been pushing MyST [3] which is an attempt to take some of the best ideas of reStructuredText and reapply them to Markdown-style syntax as a baseline. The MyST tools are a lot more recent and don't have the maturity just yet of Sphinx (including the larger ecosystem such as SaaS hosts like readthedocs).
[1] https://docutils.sourceforge.io/rst.html
rubyfan
I’ve been dreaming of a better contract writing tool for a while now.
I’m not a lawyer but I draft insurance contracts and work with reviewing lawyers closely. As a former software developer I miss version control, partial includes, conditional logic, etc. I am shocked at how poorly supported the business world is by the ubiquity of MS Word.
I’ve been experimenting with Typst now for some time and it has a lot of what I want in creating and versioning documents but I believe may be too technical to become integrated with existing workflows and the non-technical users engaged in the development process. Basically my experience is normal users tune out once you get outside of even basic MS Word.
I really want a great tool to exist but I’m afraid I’m an outlier and unique in my technical ability in this space. Nice to see others interested in such a tool.
gjayakrishnan
I’m part of the team behind Zoho Contracts, focused on simplifying how businesses manage contracts across their lifecycle — from authoring, approvals, negotiation, and signing to renewals, amendments, compliance, with comprehensive analytics built in.
Our document editor is powered by Zoho Writer, offering all the capabilities of a word processor along with versioning, document assembly, and automation features. On top of this, we’ve built structured version control, clause-level change tracking, and workflow-integrated collaboration. This enables legal and business teams to work together seamlessly without relying on external editors or juggling redlined Word files over email.
Just sharing in case anyone else here is tackling similar problems or interested in the space.
jagged-chisel
Ah, a kindred spirit. I have been drafting part time for a local firm, and I feel like i’m on the cusp of a brilliant concept for pulling documents together, presenting case status to the lead lawyer … but I don’t have the time to coalesce my inklings into a tool.
I think we technical folk need to build technical tools for us to use while we explore the space and iterate on something that the normies will accept.
If you find anyone willing to invest money so a team can spend time on this, please let me know! :-)
b0a04gl
> "Finally got sick of diffing contracts in Word and emailing PDFs back and forth"
this is the actual iceberg. forget ai clause generators and buzzwords, 99 percent of the pain is version chaos. localfirst editor is cool and imagine pairing that with proper gitstyle branching across teams. redlines you can merge without manually eyeball.
gamblor956
Word has offered redline merging for over several decades...
There's a reason it's still the standard in the legal industry.
The funny thing is that Word has tons of functionality that techies aren't aware of because they don't actually use it so they keep building products around features Word has had for years. And then they wonder why their startup failed to get any traction.
piker
No, it doesn't work. I'm a long-term lawyer (and a techie), so I'm fully aware of Word's features and shortcomings. Most corporate lawyers use a product called Litera which is pretty good but a clunky COM add-in.
gamblor956
As I said in another comment: you're basing your entire product around doing one feature, but your competition is the entire package.
Redline doesn't appear to be working in Firefox in the web demo you have available. As that is supposed to be your killer feature I would say that your product isn't yet in MVP state. Also, the UI is quite bad and not the slightest bit intuitive; it's the kind of UI that only makes sense once you already have been using it for a while. As you pointed out, most firm lawyers already know and use Litera, so you need to not just be better at your one chosen feature but you also need to be easier and more intuitive to use and you're not.
It's okay for you to be offended by this criticism; this is your baby. But I'm being realistic here. You can choose to ignore critiques and die stillborn, or address these complaints (which other comments have also pointed out) and actually make something that a small but sustainable niche of lawyers will happily use.
b0a04gl
yeah word has redline merge, but it breaks the moment edits arent linear. try merging three branches of the same contract across two firms and an in-house team. tracked changes turn into spaghetti. no merge conflict UI, no real version graph, no concept of rebasing edits. you get a stitched-up doc with 20 authors and no idea who changed what when. and once someone accepts changes early, half the context’s gone. legal folks make it work, but that’s survival, not support.
chaostheory
It’s not good enough. I know because I had to use it for comparing different versions of contracts and it was painful.
flkiwi
It just warms my heart to see so many lawyers pining for git-based change management and drafting-as-code all in one place. I KNEW I WASN'T ALONE.
bernstml19
I created an account just to marvel at this very concept
socalgal2
Couldn't enter Japanese into the web version. Looks like it trying to read keys directly. Copy and paste don't work. Right clicking doesn't bring up a context menu with system options so no looking up words using the locally installed dictionary. No OS level spell checking that uses the user's dictionary.
I guess all of that is TBD though I suspect based on the tech choices will be way harder than it sounds.
piker
Copy and paste don't work on the web version, but they should work (including pasting formatting out into Office products) on desktop. Similarly for fonts. If you're using a font that contains Japanese characters it should render. It doesn't (yet) do a great job on falling back.
Try the download!
sanufar
This looks great! I’m really stoked to see egui being used for the desktop app. While I’m not a lawyer, I was wondering about the potential for external references to cases, i.e doc1 references a case which isn’t present locally, which can then be navigated to via something like “go to definition”. Maybe something like an indexer that crossrefs on a database of legal cases? Do you have any thoughts on some other use cases? The idea of an IDE for lawyers is super cool, can’t wait to see where this goes!
piker
Thanks so much. Yes, the plan is to package libraries along with the product to allow for all kinds of external entities to be resolved.
Egui is great!
blacksmith_tb
It's a catchy name, though ironically tritium is not legal in the US, generally[1] (for "frivolous purposes"). Guess this is serious software!
philsnow
I pine for a DSL for legal documents, both because it’s tedious and tiresome to parse prose like this:
> Except for persons who manufacture, process, produce, or initially transfer for sale or distribution self-luminous products containing tritium, krypton-85, or promethium-147, and except as provided in paragraph (c) of this section, any person is exempt from the requirements for a license set forth in section 81 of the Act and from the regulations in parts 20 and 30 through 36 and 39 of this chapter to the extent that such person receives, possesses, uses, transfers, owns, or acquires tritium, krypton-85, or promethium-147 in self-luminous products manufactured, processed, produced, or initially transferred in accordance with a specific license issued pursuant to § 32.22 of this chapter, which license authorizes the initial transfer of the product for use under this section.
... and also because it is ambiguous / error-prone / subject to interpretation, especially when figuring out antecedents of pronouns, referents, and textual boundaries.
I tried four times to read the above by paragraph without reformatting it with some parentheses etc, but failed.
conartist6
I have designed CSTML with that exact set of usage and features in mind. It would be absolutely perfect for what you describe. I badly need investors though. Know any lawyers interested in investing in a product like you are describing?
PhilipRoman
One thing I would really like to see is the mathematical and/or notation with the tall single curly bracket (with nesting, when appropriate).
I've seen a bulleted list being used for both conjunctions and disjunctions within the same document and in both cases it was not obvious from context (it was related to conditions for receiving funding)
philsnow
.... I think it means that you can make self-luminous products without needing a license, as long as you got them from somebody who does have a license.
pclmulqdq
I think that's pretty much it but IANAL. Tritium vials are available for sale for use in self-luminous products. The vials themselves are pretty expensive for what they are, and they come with documentation about who initially created the vial (or how it was imported).
I have a gun with a tritium-based night sight (so the sight dots glow with no light), and it came with documentation about the provenance of each of the three tritium vials.
I also believe it is a crime to break open a sealed tritium vial.
piker
Can I trademark that slogan? :)
jenadine
Really cool to see a native app instead of another Electron or browser-based tool.
I'm curious what was your experience like building this in Rust? Also, how did you find working with egui, what made you choose egui over other UI frameworks?
piker
Agreed! I don't think lawyers would have accepted an Electron alternative to super fast Word. Rust gives the raw speed and safety necessary to compete.
It's my first Rust project, and I've found Rust to be amazing once you cross over the learning hurdle. The biggest issue was of course the borrow checker, but for a project like this where you aren't really iterating much on the design (as opposed to say a game dev), it lets you fly. It saves you from all the big mistakes and allows you to comfortably use threads and things. No idea how I would have made it without rust_analyzer, though.
Egui was simple to get going, while it has some downsides being an immediate mode UI, those are mostly overcome by the caching necessary for rendering documents, etc.
tonyhart7
why you choose egui or you just choose based on what you commonly used??
piker
I had been messing around with Imgui relatively recently and enjoyed the simplicity. Prior to that I was doing stuff with React which is kind of the polar opposite and found that to be super laborious. So when I saw egui, I jumped at the chance.
benn0
Congrats on the launch, really great stuff. As a software developer who has been studying (very slowly) a law degree, I can really see how products like that improve existing processes can really fill a need. I've also seen some former colleagues gain a lot of traction in a very similar legal process improvement space.
For a completely unrelated use case, I've started using it as my docx viewer on Linux, and so far it's been great (and solves one of my pain points moving from MacOS).
gazpacho
I like the idea! I wish I could use git / PRs to do rounds of edits on legal documents instead of whatever Word’s track changes is.
Speaking of, could we start using version control for keeping track of laws and updating old laws? It seems to me like a much better system than randomly burying in a new law that it strikes out some text from an old law.
socks
Reminds me of this old HN thread: https://news.ycombinator.com/item?id=4353389
$1,500 an hour and still using the software my grandma used to make bingo fliers!?
Hi HN! I'd like to submit for your consideration Tritium (https://tritium.legal). Tritium aims to bring the power of the integrated development environment (IDE) to corporate lawyers.
My name is Drew Miller, and I'm lawyer admitted to the New York bar. I have spent the last 13 years in and out of corporate transactional practice, while building side projects in various languages using vanilla Vim. One day at work, I was asked to implement a legal technology product at my firm. Of course the only product available for editing and running programs in a locked-down environment was VS Code and its friends like Puppeteer from Microsoft.
I was really blown away at all of the capabilities of go-to definition and out-of-the box syntax highlighting as well as the debugger integration. I made the switch to a full IDE for my side projects immediately. And it hit me: why don't we have this exact same tool in corporate law?
Corporate lawyers spent hours upon hours fumbling between various applications and instances of Word and Adobe. There are sub-par differencing products that make `patch` look like the future. They do this while charging you ridiculous rates.
I left my practice a few months later to build Tritium. Tritium aims to be the lawyer's VS Code: an all-in-one drafting cockpit that treats a deal's entire document suite as a single, searchable, AI-enhanced workspace while remaining fast, local, and secure.
Tritium is implemented in pure Rust. It is cross-platform and I'm excited for the prospect of lawyers running Linux as their daily driver. It leverages a modified version of the super fast egui.rs immediate-mode GUI library. The windows build includes a Rust COM implementation which was probably one of the more technical challenges other than laying out and rendering the text.
Download a copy at https://tritium.legal/download or try out a web-only WASM preview here: https://tritium.legal/preview
Let me know your thoughts! Your criticisms are the most important. Thank you for the time.