If you've ever needed to embed Office documents in a web app, you know how hard it is. Your usual options are limited to:

1. Use a JS library to convert to HTML — but lose rendering fidelity

2. Convert documents server-side — adds infrastructure complexity and a mandatory upload pipeline

3. Pay for an enterprise viewer — expensive, often heavyweight, and usually comes with lock-in

I've been building docMentis as a different kind of solution: a universal document viewer for the web.

What makes it different:

- a rendering engine built from scratch for high-fidelity viewing across PDF, DOCX, PPTX, SVG, and images
- a Rust/WebAssembly engine that runs in the browser, with client-side viewing by default
- an MIT-licensed, open-source viewer layer, with a closed-source rendering engine that is free to use in commercial products when shipped with the viewer

The result is one viewer and one integration path across formats, instead of stitching together separate tools with different rendering behavior.

Links:

- Website: 
- GitHub: 
- npm: 

If you've dealt with this problem before, I'd be interested in how you approached it. Happy to answer technical questions about the rendering pipeline, the document model, or the tradeoffs between client-side viewing and server-side conversion.

I’m a frontend developer and lately I’ve been feeling pretty uncomfortable with what’s happening on my team.

I originally built and structured the frontend repo I created reusable components, set up patterns, and tried to keep everything clean and scalable. Recently, one of the backend devs started contributing directly to the frontend using my repo.

The issue isn’t that they’re contributing ,I actually welcome that. But the way it’s being done is worrying. There’s very little thought around structure or scalability. I’m seeing files going 800+ lines, logic mixed everywhere, and patterns that don’t really fit the architecture I had in place.

What bothers me more is that I know this could’ve been done much simpler and cleaner with a bit of planning. Even when I use AI, I don’t just generate code blindly , I first think through the architecture (state management, component structure, data flow), and only then use AI for repetitive parts. Then I review everything carefully.

It feels like AI is being used here just to “make things work” rather than “make things right,” and the repo is slowly becoming harder to maintain.

I don’t want to gatekeep frontend, but at the same time, I feel like the code quality and long-term scalability are getting compromised.

Is this something others are experiencing too? How do you handle situations where non-frontend devs start contributing in ways that hurt the codebase?

👋🏾 Hey guys

I’ve been actively working on a React accessibility toolkit called AccessKit (). The purpose is to make it significantly easier to add real accessibility features to any app without having to reinvent everything from scratch.

A lot of a11y tooling focuses on audits or guidelines, but I wanted something more practical + user-facing; something you can drop into your app and immediately improve usability for real people. You can try it out live at the

Core features

DevTool

• Scans your live page for A, AA, & AAA WCAG issues by default (can be extended by other accessibility tags)

• Provides guidance on offending elements and how to resolve them

Accessbility Widget

• Themeable to match your website's look

• Color vision deficiency filters (protanopia, deuteranopia, tritanopia)

• High contrast modes for better readability

• Font scaling & spacing controls

• Reduced motion support

• Keyboard navigation enhancements

Why I built this

Accessibility is often treated as an afterthought, even though it directly impacts how users interact with interfaces. Modern UI libraries like React make it easy to build components, but ensuring those components are accessible still requires extra effort and expertise.

I wanted to lower that barrier, especially for indie devs and small teams, by providing a plug-and-play solution that actually helps users, not just passes audits.

Thank you for your time! Would love some feedback from this community if you guys get the chance to check it out! Much love and thank you for your help in driving a more accessible web experience for all!