Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Tritium – The Legal IDE in Rust

tritium.legal

Post reply on HN
Print view View original

151–160 of 171 posts

Re: Show HN: Tritium – The Legal IDE in Rust

#151

Post by giancarlostoro »

piker wrote: post #13
giancarlostoro wrote: post #11

> Tritium is implemented in pure Rust. This beautiful software that looks a bit like VS Code, what did you use to make it? I'm guessing Tauri but curious if you used something else.

That's very kind -- let's hope the legal profession feels the same way. It's certainly inspired by VS code. It's using egui ( https://github.com/emilk/egui ) under the hood. Big hats off to Emil Ernerfeldt and the team at rerun ( https://app.rerun.io/ ) for the incredible work on a great immediate mode GUI library.

I did send it to a lawyer I'm friends with, their hesitation comes from putting anything confidential on "unknown software" so I think you should really focus on highlighting any kind of metrics you keep, and anything that could be fully relevant to a legal professional. I also recommend, I think you mentioned AI is possible, making that opt-in only.

Re: Show HN: Tritium – The Legal IDE in Rust

#152

Post by connicpu »

gwbas1c wrote: post #134
piker wrote: post #89

Earlier quoted context omitted.

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’…

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.

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.

Re: Show HN: Tritium – The Legal IDE in Rust

#153

Post by piker »

gamblor956 wrote: post #149
piker wrote: post #103

Earlier quoted context omitted.

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.

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 sen…

That's not the killer feature. I'm not sure where you got that impression. It's the integrated whole which is the feature. Sorry it seems not to work on firefox, but I'll definitely work on that. It's a desktop application with a "web preview" that is being presented here. Most lawyers never interact with the web preview (or the website for that matter) because it just arrives on their desktop.

Agree to disagree on the UX, but points very much appreciated!

[Edit: what OS and generally what type of edit? Firefox on Windows is working, but perhaps there's a specific edit which caused it to crash. Thanks so much!]

Re: Show HN: Tritium – The Legal IDE in Rust

#154

Post by piker »

brudgers wrote: post #150
piker wrote: post #135

Earlier quoted context omitted.

That's a fair take at surface level, but building a cross-platform application does allow for a broader class of contributors who can also dogfood the product. I'll have to do another write-up about it sometime, but a lot of Tritium's automated tests are written in docx files. So building for Linux as an afterthought allows an employee to develop from their preferred platform (if it's Linux) while still getting the f…

If your target customers care about linux and rust, you have probably over segmented the market.

Yeah, that's true - they really don't. But it helps with the DDQs when you can tell their Infosec people that it's a typesafe language. In the end it's another bullet point but not much more. It's great to be able to run it on Linux and develop in Rust though.

Re: Show HN: Tritium – The Legal IDE in Rust

#155

Post by piker »

giancarlostoro wrote: post #151
piker wrote: post #13

Earlier quoted context omitted.

That's very kind -- let's hope the legal profession feels the same way. It's certainly inspired by VS code. It's using egui ( https://github.com/emilk/egui ) under the hood. Big hats off to Emil Ernerfeldt and the team at rerun ( https://app.rerun.io/ ) for the incredible work on a great immediate mode GUI library.

I did send it to a lawyer I'm friends with, their hesitation comes from putting anything confidential on "unknown software" so I think you should really focus on highlighting any kind of metrics you keep, and anything that could be fully relevant to a legal professional. I also recommend, I think you mentioned AI is possible, making that opt-in only.

Yes that battle is won by getting the IT/infosec team's approval for the desktop application. Lawyers really don't like the WASM version because it seems like you're uploading docs to some server (you aren't).

Thanks a ton for the feedback!

Re: Show HN: Tritium – The Legal IDE in Rust

#156

Post by gamblor956 »

piker wrote: post #153
gamblor956 wrote: post #149

Earlier quoted context omitted.

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 sen…

That's not the killer feature. I'm not sure where you got that impression. It's the integrated whole which is the feature. Sorry it seems not to work on firefox, but I'll definitely work on that. It's a desktop application with a "web preview" that is being presented here. Most lawyers never interact with the web preview (or the website for that matter) because it just arrives on their desktop. Agree to disagree on t…

Firefox on Windows was definitely not working.

Hard disagree on the UX. Remember that it's not what you think of the UX, it's what your users think of the UX. This is basically like GIMP or Darktable; I'm sure it makes sense to power users who have invested a lot of time, but unless you want that tiny group to be your market, you need to make the UX way more user-friendly.

Re: Show HN: Tritium – The Legal IDE in Rust

#157

Post by chaostheory »

gamblor956 wrote: post #98
b0a04gl wrote: post #75

> "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.

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.

It’s not good enough. I know because I had to use it for comparing different versions of contracts and it was painful.

Re: Show HN: Tritium – The Legal IDE in Rust

#158

Post by trinix912 »

fl0id wrote: post #143
piker wrote: post #95

Earlier quoted context omitted.

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.

Word has the worst performance ever. So I don't think competing with Word on performance should be hard.

Not necessarily. You can have dozens of Word instances open and it still doesn't bog the system down nearly as much as 5 Notions with the Chromium renderer. Word might not seem fast, but it's lightweight enough to work on the crappiest PCs you (or the IT dept) can find.

Re: Show HN: Tritium – The Legal IDE in Rust

#159

Post by trinix912 »

ezst wrote: post #147
cAtte_ wrote: post #133

Earlier quoted context omitted.

VS Code, the aforementioned very performant Electron-based IDE, would like to differ

People praising VSCode's performance are probably better defined by having too fast computers than anything else, by all measures VSCode really isn't particularly lightweight nor performant.

It is definitely not as performant as Word on 5+ year old hardware that can barely run Windows 10, that many companies will happily order tons of.

Re: Show HN: Tritium – The Legal IDE in Rust

#160

Post by cryptonector »

piker wrote: post #89
chrismorgan wrote: post #88

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 gene…

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’…

> 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.

Post reply on HN