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

Show HN: Extend UI – open-source UI kit for modern document apps

extend.ai

Post reply on HN
Print view View original

21–30 of 88 posts

Re: Show HN: Extend UI – open-source UI kit for modern document apps

#21

Post by petilon »

dvt wrote: post #18
andrewlu0 wrote: post #17

Earlier quoted context omitted.

nice - did you write a custom parser for PDF/DOCX? we wrote one for XLSX after running into event loop issues with sheet JS

Using lopdf[1] for PDF parsing, rtf-parser[2] for RTF, calamine[3] for XLSX, and I'm sure you know that DOCX/PPTX/etc. is basically just a zip file of XML + text. The LLM cares about textual data (which just gets moderately cleaned up post-extraction), so I (thankfully) didn't have to deal with rendering. But showing a preview or end-result to a user would be a huge plus, so I can see myself using your library. [1] h…

What about rendering? That's the hard part.

Re: Show HN: Extend UI – open-source UI kit for modern document apps

#22

Post by dvt »

petilon wrote: post #21
dvt wrote: post #18

Earlier quoted context omitted.

Using lopdf[1] for PDF parsing, rtf-parser[2] for RTF, calamine[3] for XLSX, and I'm sure you know that DOCX/PPTX/etc. is basically just a zip file of XML + text. The LLM cares about textual data (which just gets moderately cleaned up post-extraction), so I (thankfully) didn't have to deal with rendering. But showing a preview or end-result to a user would be a huge plus, so I can see myself using your library. [1] h…

What about rendering? That's the hard part.

For me, rendering was just a nice-to-have.

Re: Show HN: Extend UI – open-source UI kit for modern document apps

#23

Post by dvt »

drivingmenuts wrote: post #5
andrewlu0 wrote: post #4

Earlier quoted context omitted.

Hi! I'm one of the engineers at Extend that worked on this - one of our other engineers created a Rust XLSX/XLS parser that we ported to WASM to our @extend-ai/react-xlsx package which handles the rendering/charts. It exposes some hooks so users can use their own components for the toolbar

How much was actual engineering and how much was telling an AI what to do?

Even if it was just prompting, not sure how that takes away from the final, fairly polished, product. How do you define "actual engineering"?

Re: Show HN: Extend UI – open-source UI kit for modern document apps

#25

Post by andrewlu0 »

petilon wrote: post #21
dvt wrote: post #18

Earlier quoted context omitted.

Using lopdf[1] for PDF parsing, rtf-parser[2] for RTF, calamine[3] for XLSX, and I'm sure you know that DOCX/PPTX/etc. is basically just a zip file of XML + text. The LLM cares about textual data (which just gets moderately cleaned up post-extraction), so I (thankfully) didn't have to deal with rendering. But showing a preview or end-result to a user would be a huge plus, so I can see myself using your library. [1] h…

What about rendering? That's the hard part.

we built a library @extend-ai/react-xlsx on top of it that renders the parsed contents onto a canvas

testing was mostly manual with a test corpus we generated. its not perfect but its pretty close for most files we've seen

Re: Show HN: Extend UI – open-source UI kit for modern document apps

#27

Post by hju22_-3 »

andrewlu0 wrote: post #13
egeozcan wrote: post #11

Why doesn't it mention anywhere that they are React components?

we'll try to make it more clear on the landing/introduction page!

_Try_ to? Are you serious? We're not taking ambiguity due to phrasing, we're talking straight up not mentioning it on either the front page, on the show all page or even on the page the components button takes you to. Not even on this forum thread. There's barely any text on the front page to change and there are even multiple places you can mention React. You could mention it in the title, e.g. "Open source _React_ UI kit for modern document apps" or you could add it to the second paragraph, e.g. "React components ready to drop into user-facing flows, agents, or internal tools." Not to mention the components page. And given what you use to make the website, how does it take this long to update something this trivial when you are going out of your way to promote it, replying to comments and your other services by proxy?

Also, add either user interactive loading of components or lazy load the demos, the amount of demos murder performance on phones.

Re: Show HN: Extend UI – open-source UI kit for modern document apps

#28

Post by plastic041 »

Looks clean and works fine, but it needs optimization. Clicking "Type" in the "schema builder" example takes 1~2 seconds to open the popover in the landing page(macbook pro m4). I think its because there are lots of heavy components, but still it's too slow.

Re: Show HN: Extend UI – open-source UI kit for modern document apps

#30

Post by andrewlu0 »

hju22_-3 wrote: post #27
andrewlu0 wrote: post #13

Earlier quoted context omitted.

we'll try to make it more clear on the landing/introduction page!

_Try_ to? Are you serious? We're not taking ambiguity due to phrasing, we're talking straight up not mentioning it on either the front page, on the show all page or even on the page the components button takes you to. Not even on this forum thread. There's barely any text on the front page to change and there are even multiple places you can mention React. You could mention it in the title, e.g. "Open source _React_…

coming back to this now and added it in a few places

on the demos - everything below the fold is lazy loaded but i will see what we can do to improve the mobile perf

Post reply on HN