Not a single example of what it does or how it works

Fair enough. Trying to keep it concise here - This is how you install it:

pip install "headroom-ai[proxy]"

headroom proxy --port 8787

It will:

* Check all the data going into the LLM and apply intelligent compression based on the content type - different for JSONs, code etc.

* If the LLM is not getting what it is seeking, there is reversible compression - so the LLM will not lose accuracy

* When you think of MCP tools, code function calls etc. that fill up the context window and cause needle in haystack problems - they get eliminated.

There is also an SDK which works like this:

from langchain_openai import ChatOpenAI from headroom.integrations import HeadroomChatModel

# Wrap your model - that's it!

llm = HeadroomChatModel(ChatOpenAI(model="gpt-4o"))

# Use exactly like before response = llm.invoke("Hello!")

Ive personally used it with Claude Code and Cursor and seen the benefits.

The self-hosting solution is completely crippled, everything is paywalled. At this point, might as well go closed source.

Probably the commit history.

Yayiee, the “cant prove it” Doakes Dexter meme, making it to HN

You are neither confirming nor denying, why won't you just tell if you vibe-coded it or not?

you posted the Dexter meme earlier, why are you acting surprised?

With the insane licensing costs, I fail to see how this is still a viable choice for personal / small projects. Also, for larger projects, assuming you can afford the costs, the reality is that it's really hard to find decent Qt developers.

Whilst I really dislike the Qt licensing model, and it often stops me from using Qt, if the "personal / small projects" aren't commercial you can do whatever you want with Qt, and if they are commercial you can still use the LGPL license. In my understanding, you only have to pay for Qt if you have a commercial project and you don't want to use the LGPL license.

Use the LGPL licensing option?

Have fun dodging that minefield when distributing your app.

Is it really so complicated? Genuinely curious.

The admin panel requires an email and a password to check out.

please check the documentation

https://nextmin.gscodes.dev/docs/nextmin-react#default-admin...

It appears to have a fatal flaw: you can't actually save and restore your data, just export it to PNG.

This article is an oversimplification describing basic forms, but as soon as you try to implement any sort of advanced validation using just HTML, the whole paradigm falls apart. Browsers support JavaScript for a reason.

How can you ever trust validation on the client side though? The user can just mess with it and submit anything they want anyway.

Why not validate on the server and return a response or error as HTML?

I’m not trying to argue in bad faith here. I know client side validation is necessary in some cases, but IMO it’s only an augmentation for UX purposes on top of server side validation.

> Why not validate on the server and return a response or error as HTML?

If your form has files you'd want to at least check it before sending data unnecessarily to the server.

Also it's always better to have a tighter feedback loop. That is really the main reason why there's validation on the frontend and backend, not just the latter.

Typically for fetch() I return the error as "text/plain" with the appropriate status code. It is still necessary to give a preflight validation in Vanilla JS, apply an error style and helpful feedback.

HTML has come a long way since the bad old days. General constraints can be applied directly to the input element. It still makes sense add additional explanations for the invalid input with JS though.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

Client-side validation is a progressive enhancement. You always have server-side validation. The validation in the browser exists to provide additional feedback that lets users have realtime feedback about their input.

You have a human in the loop somewhere. This is how we do to not lose clients who accidentally typed @gmail.co

It's also essential in order to not make forms to difficult to fill in, because that means you lose customers and a lot of money.

Just use a generic data structure for your validation rules that you can apply on the front-end, and validate on the back-end. Using JavaScript and doing validation on a server are not mutually exclusive.

You're answering yourself here: client side feedback/validation is essential ux for any complex form. Even for simple signup forms with a few required fields.

You can use JS to provide validation and still submit the form from HTML.

Helpful hints are all you can rely on from client-side. Client-side validation doesn't really exist, true validation only happens server-side.

A pointless distinction when we all know what we're talking about.

Is it? I’ve seen devs bring complicated code to the frontend when a required attribute on the tag would have done the job just as well. Preventing user mistakes is not the same as ensuring correct input.

We've all seen bad implementations of any given thing I'd imagine. Ever submit a form that triggers a full page refresh after about 8 seconds of hanging, only to lose half the data and reveal some arcane requirement to you that wasn't stated up front? Of course this isn't the proper way to do it, but it happens.

What is the difference?

The same is true for any JS "validation" and I was using common terminology.

From a user point of view as long as you keep the feedback loop short what difference can they see?

Neither is it validation when you use JS if the server doesn't check it. You can always send requests with postman, curl or your tool of choice.

You can have a minimal library like HTMX or if you have access to a solution Phoenix LiveView, you need minimal JS to have an interactive page, the only downside is that you could introduce some latency because of the network trip.

I think a part of the point is to question the need for things like that. Do your users actually need all of these bells and whistles?

There's a lot of validation that can be done with HTML; I'd even say most client-side validation can be handled by HTML/the browser. You can specify input types, do RegExp matching, etc. There's a lot in the spec.

You'll need server-side validation anyway…

I thought some people might find this useful. It looks like this: https://share.cleanshot.com/4Fj7wLH9

Example: https://i.imgur.com/vNEIaUI.png

I actually use Dokploy in production, you have to literally press just one button to redeploy using the latest version of your app, straight from the repo.

Or no button auto deploy from main.