Hey everyone,

I have been working on a side project called Polyglot Formatter. It's an open-source code beautifier that runs entirely in the browser and can format HTML, CSS, JavaScript, PHP and JSON all in one place. You just paste your code, it auto-detects the language and formats it with one click. There is no install, no signup, no backend - everything is client-side.

It also handles things like nested style and script blocks inside HTML, mixed PHP/HTML files, and JSON pretty-printing. The editor uses CodeMirror and the output is syntax-highlighted with Prism.js. It has a dark theme, configurable indentation, line wrapping options, and a responsive layout that works on mobile too.

Live version: https://neiki.eu/polyglot-formatter

GitHub: https://github.com/neikiri/polyglot-formatter

Now I want to be completely honest.. The formatter still has quite a few bugs. Building a tool that reliably formats five different languages including all the possible nested combinations of HTML inside PHP inside JavaScript and so on, turned out to be way harder than I expected when I started. I genuinely had no idea how complex this problem is and I'm still working through a lot of edge cases.

So if you try it out and run into any broken formatting, weird output or unexpected behavior, I would really appreciate it if you could report it on the GitHub issues page at https://github.com/neikiri/polyglot-formatter/issues. I would prefer bug reports there rather than in comments or DMs so I can actually track and fix them properly.

Every report helps a lot. Thanks for checking it out and any feedback is welcome :)

Might be helpful when choosing dependencies ✌️

We've moved our cookie banner implementation out of OpenPolicy and into a standalone repository.

Our goal is to give developers (and their coding agents) the tools to build banners that match your app's style and flow, while we handle all the difficult parts.

React, Vue, Svelte and Solid are supported so far with more coming soon.

Repo: https://github.com/jamiedavenport/opencookies

Hey everyone,

I’ve been working on a React toolkit called Forge. Nothing fancy I just wanted something clean, consistent, and that saves me from rebuilding the same components every two weeks, but with a more personal touch than shadcn/ui or other existing design systems.

It’s a project I started a few years ago and I’ve been using it in my own work, but I just released the third version and I’m realizing I don’t have much perspective anymore. So if some of you have 5 minutes to take a look and tell me what you think good or bad it would really help.

I’ll take anything:

• “this is cool”
• “this sucks”
• “you forgot this component”
• “accessibility is missing here”
• or just a general feeling

Anyway, if you feel like giving some feedback, I’m all ears. Thanks to anyone who takes the time to check it out.

Take a look, whether you're preparing for an entry-level or mid-level software developer role, it should be quite helpful.

Digits is hiring passionate, collaborative, customer-driven engineers who share in our belief that modern business software can be fast, fluid, beautiful, and even joyful to use. 

Digits is the world's first AI-native accounting platform. We automate the complete month-end close for small businesses and accounting firms, saving them hours of tedium every month. We build and train our own domain-specific AI accounting models and agents, and we're the first feature-complete QuickBooks alternative in 20+ years. We launched in 2025 and already work with thousands of businesses and hundreds of accounting firm partners.

We're taking an AI-native approach to development. AI tools have gotten good enough that the bottleneck is no longer writing code, but rather it's taste, architecture, and knowing what to build. We seek someone who can use these tools aggressively to move fast, while focusing their own effort on the decisions that shape the product: how it is structured, how it feels to use, and where quality can't be compromised.

In practice, this means you'll spend less time typing and more time crafting. You'll make product and UI calls in real-time as you build alongside agents, using working code as the design artifact rather than waiting on static mocks. You'll prompt, review, and refine. And when something needs to be written by hand (security, core architecture, tricky interactions), you'll dive in and do it well.

Qualifications

• 5+ years of industry experience building and shipping web software
• Proficiency with TypeScript/React/Javascript
• Familiarity with relational databases and SQL
• Familiarity with test-driven development 
• Desire to work remotely full-time (from home or a co-working space)
• Obsession for building and shipping amazing customer experiences

This role is US based only, and Full time hire. email your resume to [[email protected]](mailto:[email protected])

Suggested AI Report based on talk to typed text

I'm starting to feel like we've collectively given up on native JS for anything heavy.

I’ve been digging into the PDF spec lately and everyone told me that if I wanted to handle 500MB+ files in-browser, I’d need a huge WASM/Rust blob to avoid crashing the tab. But I tried a different approach instead of loading the full object graph (O(n) overhead), I’m just using recursive offset mapping on a raw binary slab to patch the file directly.

I work as a security dev for a bank, so I'm usually paranoid about memory and heap spray. On a 650MB test file, the logic takes like 100ms and my heap growth is literally 0.0 KB. GC impact is under 2ms. Even got the predicators working via a windowed decompressor in raw JS. It passes qpdf audits perfectly.

Are we actually hitting a wall with JS, or is it just that nobody wants to fight with memory lanes anymore? I get that WASM is "safer" for porting C++, but I feel like we're over-engineering things by ignoring how fast V8 actually is if you stay out of the object graph.

Is this just a niche case because of how PDFs work, or are we reaching for WASM way too early?

New component <pointer-orb/> for highlighting pointer movement and gestures.

Same DSL as the chat/UI components I shared last year. Useful for:

• pinpointing elements on screen

• tracking agent movement during browser use or other ui tool calls.

Pointer includes a main body + elastic satellite follower. Supports inline SVG filters (default gooey effect).

Framework wrappers coming later as I find spare time.

What I am trying to do

I am building a browser-based exam proctoring platform that runs in Safari and Chrome on iPad. I need to detect when a candidate opens another app or browser tab in Slide Over (the floating panel) while the exam is running in the background. This is a pure web app - no native wrapper, no MDM.

What I've already tried

I tried listening to window blur and focus events neither fires when Slide Over is triggered on Chrome. I tried document.visibilitychange - same result, it never fires during Slide Over. I tried the resize event but it is completely inconsistent on iPadOS Chrome.

For Split View I am computing the ratio of window.innerWidth to window.screen.width and flagging below 0.80 as a likely split. That works. But Slide Over doesn't change the viewport at all - the exam tab stays full width in the background. So my ratio check is completely blind to it.

My question

Is there any JavaScript API, browser event, visualViewport property, or any other web-accessible signal that fires or changes when iPadOS enters Slide Over mode — specifically from a page running inside Safari or Chrome (WKWebView)? Even an indirect signal would help.

If there's truly no way to detect this from a web page today, is there a recommended pattern or workaround that others have used? I've seen the interaction heartbeat approach (flagging when no pointerdown arrives for N seconds) but that's too noisy for an exam context where a candidate may be reading a long question.

If you’re a JavaScript developer thinking about building a desktop app (maybe even a cross-platform one), your first instinct might be to pick Electron. But it’s no longer the only option.

There are now several solid frameworks, each with different trade-offs in performance, bundle size, native integration, and overall developer experience.

I wrote a quick breakdown of 5 modern desktop app frameworks for JavaScript developers, comparing when each option actually makes sense (and when it doesn't).

If you're trying to figure out what to use for your next desktop app, or wondering if there's a better alternative to Electron, this might save you some time.

I keep rebuilding the same UI over and over (dashboards, forms, login screens).

Not the logic — just the structure and layout.

It’s not hard, just repetitive.

Lately I’ve been experimenting with scaffolding UI from prompts and then refining it manually.

What I’ve noticed so far:

- It’s surprisingly good at scaffolding layouts quickly
- Still needs cleanup (spacing, consistency, structure)
- Feels more like a “starting point generator” than a full solution

I’m not sure yet if this actually saves time long-term or just shifts where the effort goes.

Curious if people here are actually using this in real work or just experimenting.

Are you:

- still building everything manually
- using templates
- or experimenting with AI-generated UI?

We didn’t plan to rebuild our marketing site, this kind of forced itself on us.

One of our growth folks sent over a screenshot from Perplexity where it was confidently citing two of our competitors for something we definitely support. That was the first “okay something’s off” moment.

Out of curiosity I opened our site with JavaScript turned off, and it was basically just a shell. Hero loaded, but most of the actual content like blog, docs, pricing, just wasn’t there. It was all waiting for JS to hydrate.

Which probably works fine for users, but not for bots that don’t execute JavaScript (or don’t do it reliably).

So yeah, we ended up scrapping the Framer site and rebuilding everything in Astro.

The main goal wasn’t even performance at first, it was just “can a crawler read this without doing extra work.”

Now everything renders to plain HTML at build time, and we only hydrate small interactive bits where needed. As a side effect Lighthouse scores jumped a lot and most pages don’t ship any JS at all.

The more interesting part was structured data. Earlier we were basically hand-writing JSON-LD when we remembered to. Now every content type has its own little “factory,” so blog posts, FAQs, how-tos all generate the right schema automatically at build time.

We also started pulling structured data straight out of markdown. For example, if there’s an FAQ section, it gets turned into FAQ schema automatically. Same with step-by-step guides. It sounds small but it removed a lot of inconsistency.

One slightly weird thing that actually helped, we added an llms.txt file with a section on what we don’t do. Models tend to confuse you with similar companies, and explicitly stating what you’re not seemed to reduce that.

Not everything went smoothly though. At one point a small regex change broke our FAQ extraction and we didn’t notice for weeks because nothing actually failed. We only caught it later in Search Console. That’s when we added tests to make sure schema is actually being generated before deploy.

Overall takeaway for us was pretty simple, we were building a site that worked great for humans, but not for machines. And now machines are kind of part of your audience whether you like it or not.

Still figuring out how to measure this properly though. It’s easy to ship changes, harder to know if something like ChatGPT or Perplexity actually picked it up.

Curious how others are thinking about this, are you doing anything intentional for AI crawlers, or just treating it like normal SEO?

Monday, April 20 - Sunday, April 26, 2026

Top Posts

Most Commented Posts

Top Ask JS

Top Showoffs

Top Comments

A brief look into our Typescript APIs for managing privacy policy changes

If you used Meteor at some point — for a side project, a startup, at work — and moved on, I’d love to hear the actual breaking point. Not the meme version. The real one.

A few things I’m specifically curious about:

- Was it a technical limit you hit (scaling pubs/sub, MongoDB lock-in, bundle size, build times)?

- Was it ecosystem fatigue — Atmosphere vs npm, fewer packages, slow releases?

- Was it hiring/team friction — nobody knew it, onboarding pain, perceived resume risk?

- Or honestly just vibes — the JS center of gravity moved and you followed it?

I disagree with, as far as I'm aware, literally everyone else about the correct sort order for import statements. When you find yourself disagreeing with everyone, it's probably a sign you should change your thinking. But I guess I'm quite stubborn, so in this ESLint plugin I'm trying to make everyone else change their thinking instead.

Over the last couple of months, I’ve been thinking that while MCP is a great concept for connecting LLMs with external tools, from a library author’s perspective it feels too complex. Creating and maintaining a separate service with a lot of code just to expose things like usage examples seems unnecessary, especially when the library is already installed on the user’s machine. Why not keep everything that helps the LLM use the library correctly near to the library itself?

This reasoning led me to build a tool that simplifies how library authors provide context and how users consume it.

What library authors get

• Define access to context using simple configuration, not code
• No need to worry about distribution, no separate service required, just ship context alongside your library
• Versioning is handled automatically, each library version has its own relevant context

What library users get

• Easy setup with minimal footprint. Install a CLI globally and add a skill that teaches the LLM how to call it
• The LLM uses context that exactly matches the installed package version
• Faster responses. Required context is already available locally, so there are zero network calls
• Token efficiency. The CLI and protocol are designed so the agent gets a high-level overview first and requests only the details it needs

I’d love to hear what you think, what’s missing in this model, what could be improved, and any other feedback. And of course, feel free to open an issue if you find a bug. The project is new, so some things may not work as expected yet.