The performance is quite bad. There are some basics missing or broken.
- no caching for file previews
- no sorting by date in the file picker
- no sorting by size in the file picker
- no sorting by file type in the file picker
- no search in the file picker
- cant enter a folder in the detail view (only expand) in the file picker
- cant go to page (by page number) in the document viewer
- after clicking a button in the document viewer, focus is lost on the document and arrow keys, space, pgup/pgdown dont work until the document is clicked again
- cant select text in the document viewer, unless I search first, in which case it then works
This is after looking at the file picker and document viewer less than 3 minutes(!!!). I gave up after that. Getting 80% of a file picker is easy, getting the last 20% done, so that it's on par with existing software, is not.
Very very odd to have things look this polished, yet be this terrible functionality- and performance-wise. These are not random quirky new ideas I'm having, these have been basics that work in every single file picker and document viewer since the early days of UI, before the web.
gobdovan 9 hours ago [-]
Yeah, it also seems it's made in React & Next. From experience, you'll have a hard time choosing a worse technology for low-level, interaction-heavy UI. You need direct control over focus, keyboard handling, scrolling and so on. You also need to leverage hardware accelerated rendering too, which is clunky with 3rd party React libraries.
What's more, even if state management should technically be easier with the amount of state libraries, you'll realise sooner or later that the established ones are cleverly immutable where you really just want them to be performant.
I am not saying that it's React at fault for the symptoms you see here, but I would expect any such library made in it to hit exactly these kind of edge cases.
rrr_oh_man 8 hours ago [-]
> From experience, you'll have a hard time choosing a worse technology for low-level, interaction-heavy UI.
Can you elaborate on that? What else would you recommend?
gobdovan 6 hours ago [-]
Yes! First, you need to get the DOM-level behaviour right (dragging, resizing, cursor focus). That could mean you may use or build primitives like with interact.js, CodeMirror/Monaco (realistically just use, not build), Fancytree. I really like Muuri for layouts. Usually there's also subtle interaction physics going on when building such libs in unexpected places (such as resizing and drag N drop speed curves), which you should tweak to your taste.
For framework, React wants to own and mediate the DOM via virtual tree, which is a major bottleneck when you need direct control over focus/selection/keyboard routing or hardware accelerated canvases. Instead, look at Svelte or Solid.js, as they integrate nicely with imperative DOM-oriented JS libraries and don't require heavy wrappers or indirect references for the 'unfriendlier' DOM nodes like canvases, scroll containers and so on.
If you're building an OS-like UI, you should also care about state and be sure you have direct control over where your data lives. For example, I usually build with Solid.js and a mix of custom object and lifetime code plus Solid stores for reactive surface state.
I usually end up managing object lifetimes because I end up needing to handle messy edge cases around reference vs value semantics and state merging (e.g. keep cursor position sane after a file sync or track focus across multiple windows, especially after refresh)
For text editing, if you use Monaco, it has so many internal lifecycle hooks you want to be aware of and interact with directly, that you'll see that most of implementation will end up outside classic frontend lib fast and I'd rather build the thing instead of bridges and wrappers to talk with a high-level framework.
All in all, you probably want to own a lot of state and behaviour yourself, and add a cooperating framework on top instead of an all-encompassing one.
It has some rough edges as a result, but your suggestions are very valid. We’ll make those improvements (we’re also taking PRs!).
lionkor 3 hours ago [-]
Nice! That explains it to a degree. I would suggest taking someone who is really annoying about details, from your team, and having them just use the components as they are. Just click around and mess with them for a while -- in my experience this is how you get that final 20% of polish.
andrewlu0 21 minutes ago [-]
added some basic filtering/sort/search support, lmk what you think!
kbyatnal 1 hours ago [-]
agreed! dogfooding is the best — we'll integrate this into our core product, which will force us to improve it very quickly
e12e 9 hours ago [-]
Since there was a recent thread on react compiler[r] - I wonder if adding/pushing the code through react compiler would help? (Assuming it's not already being used)
[r] Thread was about rewrite in rust, but it made me have a look at the purpose/claims made by the project - and fine-grained, automated memoization for speed seems central.
andrewlu0 5 hours ago [-]
Hey! Very valid feedback - working on improving the file system component and overall site performance today
pea 18 hours ago [-]
Looks cool but your home page heavily lags on my mbp m3 pro - you should maybe be lazy loading vs loading all your components upfront
andrewlu0 17 hours ago [-]
Valid feedback a few other comments have mentioned , I’m going to try improving the home page tomorrow
bduffany 16 hours ago [-]
The performance of the "Layout blocks" component is particularly bad. It consumes tons of CPU when scrolling.
dvt 22 hours ago [-]
Super cool. Working on a local AI tool specifically for document workflow automation (where context = screen/web/folders/files), and this could come in super useful. I do most of the PDF/DOCX/etc. parsing natively in Rust, but having a nice way to see the output without spinning up Word or Powerpoint is a huge leap.
Thanks for releasing publicly.
andrewlu0 22 hours ago [-]
nice - did you write a custom parser for PDF/DOCX? we wrote one for XLSX after running into event loop issues with sheet JS
dvt 22 hours ago [-]
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.
Experienced the same nightmare a few times over with citations.
React/next is limiting, we have rebuilt this for angular and now redid it again using lit for better compatibility. Our old one is very similar to this.
Loading citations for each field across 1000s of pages, colliding citations for all the messy formats, zoom, rotate etc. what a mess!
Great that you took the time to MIT this as it would have saved us many hours, though I think today Fable + Codex makes it pretty quick
I could recreate these in lit as a fork, would be very useful to have the full set
andrewlu0 5 hours ago [-]
Someone requested web components earlier so let me know if you make that happen!
CraigJPerry 23 hours ago [-]
Those bounding box demos are decent.
By quirk of fate i've spent the past 2 days prototyping some stuff on pdfjs. Just trying to figure out a game plan for handling bounding boxes in the face of page zooming, different resolutions etc. etc. I can't see it mentioned whether the components are virtualising pages (as in reusing dom elements as document pages scroll by). I guess i just learned what i'll be exploring tomorrow then...
andrewlu0 23 hours ago [-]
yes - the pdf/docx viewer use react-virtual to virtualize the pages
the zoom should work with the bounding box highlights, we're working on adding rotation support
iamsaitam 11 hours ago [-]
The performance on the site is truly terrible, the top animation was probably going at 5fps when scrolling.
andrewlu0 5 hours ago [-]
Heard the performance feedback will work on it today!
egeozcan 22 hours ago [-]
Why doesn't it mention anywhere that they are React components?
resurge 12 hours ago [-]
Not just React, but it apparently also depends on Next.js
Hey! Those components are used for the demo site, and shouldn’t ship or get installed when you install the components in the registry.
None of the ones in the registry should have next as a dependency, please lmk if otherwise
chrisweekly 7 hours ago [-]
React (vs web components) might be questionable, but Next.js as a hard dependency, for a component library, is just weird.
andrewlu0 5 hours ago [-]
Responded above but the components like the file viewers should not depend on next. Please lmk if it gets pulled when installing via CLI
andrewlu0 22 hours ago [-]
we'll try to make it more clear on the landing/introduction page!
hju22_-3 19 hours ago [-]
_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.
andrewlu0 19 hours ago [-]
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
digitaltrees 18 hours ago [-]
Tone.
Lord_Zero 37 minutes ago [-]
Document Splits drag and drop looks weird, like it doesn't drag from where I clicked.
whitephoenix 8 hours ago [-]
It looks really great! But, from what I can see, it’ll need some work on optimisation. Good luck with this project, guys!
andrewlu0 5 hours ago [-]
Thank you! Working on optimizing
mklifelife 14 hours ago [-]
Looks great.
I'm curious whether the primary users are AI-native document products or more traditional SaaS applications.
The document-app niche feels increasingly important with the rise of AI workflows.
sails 3 hours ago [-]
primary use is Document processing automation, or Intelligent Document Processing (IDP)
qreoct 19 hours ago [-]
Cool project! I was playing around with the Excel viewer - the docs claim "Search across sheets and cell ranges", but I can't seem to trigger search functionality and the browser search bar can't find contents on cells.
Is this a known issue?
codingconstable 5 hours ago [-]
its nice, people are harsh, you did something useful, thank you.
spankalee 24 hours ago [-]
These should really be web components. Leaving out every framework other than React is really bad for the web.
digitaltrees 18 hours ago [-]
Then build it yourself. They do work for free, give it to the world, and your response is: do it differently the way I want.
ranger_danger 17 hours ago [-]
let's all try to be nicer
andrewlu0 22 hours ago [-]
thats fair and definitely something we can try supporting in the future. we started with React because of how familiar models are with shadcn and tailwind
we hope this can be useful for people building in React though!
rolls-reus 12 hours ago [-]
Mind sharing a link to the source code? i couldn’t find it on the website.
Thanks, that looks awesome! We were looking to add DOCX and XLSX preview to our app, and were planning to do server-side conversion to PDF (which seems to be what most other apps resort to) due to the lack of good libraries to render it, and this is exactly what we were looking for! :)
andrewlu0 22 hours ago [-]
thanks! would love to get your feedback
i can't promise its visually 1:1 with Word/Excel but its pretty close on the corpus we tested with
warthog 24 hours ago [-]
really like these - curious how the xlsx editor and viewer is built in that what kind of headless spreadsheet?
could not have been easy
andrewlu0 24 hours ago [-]
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
lateforwork 21 hours ago [-]
[dead]
drivingmenuts 23 hours ago [-]
How much was actual engineering and how much was telling an AI what to do?
dvt 20 hours ago [-]
Even if it was just prompting, not sure how that takes away from the final, fairly polished, product. How do you define "actual engineering"?
22 hours ago [-]
promiseofbeans 18 hours ago [-]
How is your PDF coverage? They are notoriously difficult things to render, with endless edge cases.
Mozilla’s PSD.js is the status quo here, so what do you do better than them?
andrewlu0 17 hours ago [-]
We use react-pdf for the viewer which I believe uses pdf JS under the hood
We aren’t not trying to reinvent that engine, rather just provide a building block for people to plug in their design system to its controls
if you mean our docx viewer/editor specifically its hard to say without manually testing the visual fidelity with Word on some complex docx files
you are welcome to try it with your own documents and see, but its just one example we wanted to show. for the blocks that use the react-docx library, you can always copy the code and use a different method to render the docx file/thumbnails
plastic041 19 hours ago [-]
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.
andrewlu0 19 hours ago [-]
it should be much faster on the individual component's page
the root page is a bit slow with all the viewers, in practice you probably wont have that many in your app on one page
greenleafone7 4 hours ago [-]
Another AI built project. Which OK, but then at least have a look at it to fix/optimize things.
stinger 20 hours ago [-]
Does it/will it support Markdown files?
andrewlu0 20 hours ago [-]
i felt like we couldn't build much on top of react-markdown, which i think is what most people are using
dzonga 6 hours ago [-]
so slow like molasses
deafpolygon 7 hours ago [-]
“React components”.. I stopped there.
cactusplant7374 17 hours ago [-]
This is really interesting. Thanks for creating this.
carlosjobim 17 hours ago [-]
Excellent that you offer Miller columns, one of the best tools for computing and information browsing, and management. The world should run on Miller columns.
andrewlu0 16 hours ago [-]
TIL those are called Miller columns !
carlosjobim 3 hours ago [-]
If you're on Windows, you can check out ChromaFiler, which takes Miller columns to the next level:
- no caching for file previews
- no sorting by date in the file picker
- no sorting by size in the file picker
- no sorting by file type in the file picker
- no search in the file picker
- cant enter a folder in the detail view (only expand) in the file picker
- cant go to page (by page number) in the document viewer
- after clicking a button in the document viewer, focus is lost on the document and arrow keys, space, pgup/pgdown dont work until the document is clicked again
- cant select text in the document viewer, unless I search first, in which case it then works
This is after looking at the file picker and document viewer less than 3 minutes(!!!). I gave up after that. Getting 80% of a file picker is easy, getting the last 20% done, so that it's on par with existing software, is not.
Very very odd to have things look this polished, yet be this terrible functionality- and performance-wise. These are not random quirky new ideas I'm having, these have been basics that work in every single file picker and document viewer since the early days of UI, before the web.
What's more, even if state management should technically be easier with the amount of state libraries, you'll realise sooner or later that the established ones are cleverly immutable where you really just want them to be performant.
I am not saying that it's React at fault for the symptoms you see here, but I would expect any such library made in it to hit exactly these kind of edge cases.
Can you elaborate on that? What else would you recommend?
For framework, React wants to own and mediate the DOM via virtual tree, which is a major bottleneck when you need direct control over focus/selection/keyboard routing or hardware accelerated canvases. Instead, look at Svelte or Solid.js, as they integrate nicely with imperative DOM-oriented JS libraries and don't require heavy wrappers or indirect references for the 'unfriendlier' DOM nodes like canvases, scroll containers and so on.
If you're building an OS-like UI, you should also care about state and be sure you have direct control over where your data lives. For example, I usually build with Solid.js and a mix of custom object and lifetime code plus Solid stores for reactive surface state.
I usually end up managing object lifetimes because I end up needing to handle messy edge cases around reference vs value semantics and state merging (e.g. keep cursor position sane after a file sync or track focus across multiple windows, especially after refresh)
For text editing, if you use Monaco, it has so many internal lifecycle hooks you want to be aware of and interact with directly, that you'll see that most of implementation will end up outside classic frontend lib fast and I'd rather build the thing instead of bridges and wrappers to talk with a high-level framework.
All in all, you probably want to own a lot of state and behaviour yourself, and add a cooperating framework on top instead of an all-encompassing one.
It has some rough edges as a result, but your suggestions are very valid. We’ll make those improvements (we’re also taking PRs!).
[r] Thread was about rewrite in rust, but it made me have a look at the purpose/claims made by the project - and fine-grained, automated memoization for speed seems central.
Thanks for releasing publicly.
[1] https://github.com/J-F-Liu/lopdf
[2] https://github.com/d0rianb/rtf-parser
[3] https://github.com/tafia/calamine
testing was mostly manual with a test corpus we generated. its not perfect but its pretty close for most files we've seen
We wrote (should say are writing) our own xlsx parser in Rust on IronCalc:
https://github.com/ironcalc/IronCalc/tree/main/xlsx
React/next is limiting, we have rebuilt this for angular and now redid it again using lit for better compatibility. Our old one is very similar to this.
Loading citations for each field across 1000s of pages, colliding citations for all the messy formats, zoom, rotate etc. what a mess!
Great that you took the time to MIT this as it would have saved us many hours, though I think today Fable + Codex makes it pretty quick
I could recreate these in lit as a fork, would be very useful to have the full set
By quirk of fate i've spent the past 2 days prototyping some stuff on pdfjs. Just trying to figure out a game plan for handling bounding boxes in the face of page zooming, different resolutions etc. etc. I can't see it mentioned whether the components are virtualising pages (as in reusing dom elements as document pages scroll by). I guess i just learned what i'll be exploring tomorrow then...
the zoom should work with the bounding box highlights, we're working on adding rotation support
Dependency in package.json:
- https://github.com/extend-hq/ui/blob/main/apps/v4/package.js...
Dependencies in some components:
- https://github.com/extend-hq/ui/blob/main/apps/v4/components...
- https://github.com/extend-hq/ui/blob/main/apps/v4/components...
None of the ones in the registry should have next as a dependency, please lmk if otherwise
Also, add either user interactive loading of components or lazy load the demos, the amount of demos murder performance on phones.
on the demos - everything below the fold is lazy loaded but i will see what we can do to improve the mobile perf
I'm curious whether the primary users are AI-native document products or more traditional SaaS applications.
The document-app niche feels increasingly important with the rise of AI workflows.
Is this a known issue?
we hope this can be useful for people building in React though!
i can't promise its visually 1:1 with Word/Excel but its pretty close on the corpus we tested with
could not have been easy
We aren’t not trying to reinvent that engine, rather just provide a building block for people to plug in their design system to its controls
you are welcome to try it with your own documents and see, but its just one example we wanted to show. for the blocks that use the react-docx library, you can always copy the code and use a different method to render the docx file/thumbnails
the root page is a bit slow with all the viewers, in practice you probably wont have that many in your app on one page
https://chroma.zone/chromafiler/
On mobile Safari…
1. I saw it was React
2. Nothing loading, just a page full of spinners
I truly wish React could be launched into the sun.