Two clip-paths, over the navigation:
- The first clip-path is a circle (top-left corner) - The second clip-path is a polygon, that acts like a ray (hardcoded, can be improved)
The original work by Iventions Events https://iventions.com/ uses JavaScript, but I found CSS-only approach more fun
Here's a demo and the codebase: https://github.com/Momciloo/fun-with-clip-path
Example repo: https://github.com/valdanylchuk/breezydemo
The underlying ESP-IDF component: https://github.com/valdanylchuk/breezybox
It is something like Raspberry Pi, but without the overhead of a full server-grade OS.
It captures a lot of the old school DOS era coding experience. I created a custom fast text mode driver, plan to add VGA-like graphics next. ANSI text demos run smooth, as you can see in the demo video featured in the Readme.
App installs also work smoothly. The first time it installed 6 apps from my git repo with one command, felt like, "OMG, I got homebrew to run on a toaster!" And best of all, it can install from any repo, no approvals or waiting, you just publish a compatible ELF file in your release.
Coverage:
Hackaday: https://hackaday.com/2026/02/06/breezybox-a-busybox-like-she...
Hackster.io: https://www.hackster.io/news/valentyn-danylchuk-s-breezybox-...
Reddit: https://www.reddit.com/r/esp32/comments/1qq503c/i_made_an_in...
As a long-time programmer this all just feels all sorts of wrong, but also invigorating. Vibe "coded" the whole thing from 0-100 over the course of few days, on and off. I have no intentions of developing it further since it's obvious what it is; I would absolutely love to work on a licensed game and do it proper with all the various ideas I have, since this is maybe 10% of what I want in such a game, but I heard somewhere licensing is cost-prohibitive.
Putting AI shame aside, it really allowed me to explore so many things in a short amount of time that it feels good, almost enough to compensate the feeling of shame using AI to begin with.
WebGPU isn't in there, although it's in another experimental version, part are indeed written in Rust (game logic).
It has:
- lock delay / grace period (allowing for 15 moves)
- DAS (Delayed Auto Shift) and ARR (Auto Repeat Rate for continuous movement) for horizontal and soft drop movements
- SRS wall kicks (Super Rotation System) to rotate pieces in-place
- Shift+Enter "hidden" level select on the main screen
- Shift+D for debug/performance indicator panel
- Several ranodmizers including 7-bag and NES ones
- combo system with difficulty (time) modes (easy by default) - x2: DOUBLE STRIKE, x5: CHAIN REACTION, x7: MEGA COMBO, x9: PHOSPHOR OVERLOAD, x10+: CRITICAL MASS
- backgrounds which change over time or you can change them with SHIFT+B (B turns it off/on) which react both to music (FFT!) and to your game play when you clear lines
- normal and two phosphor rendering modes of game field (R to toggle)
- CRT Filter (shift+c to toggle)
- F for full screen toggle
- A for previous song, S for pause song, D for next song (all songs made with Suno, of course)
and many more. It was a fun experience for sure, just not sure how to feel about it. On one hand I understand it wouldn't look like it does without my input, and it was a lot of what felt like work (intense sessions looking over the output, correcting etc), yet it doesn't feel like I really made anything by myself. I had fun though.
While at it, created a small demo as well which isn't a game yet: https://www.susmel.com/rolly/ and also something to play with parametric curves here: https://www.susmel.com/graphy/
all within a span of a couple of days while we were having our third baby. The future is weird, and I'm still not sure whether I like it or not. One thing is sure - it's here to stay. Peace out, my friends!
Hello everyone!
I'm a solo developer who's been doing UI/UX work since 2007. Over the years, I watched design tools evolve from lightweight products into bloated feature-heavy platforms. I kept finding myself using a small amount of the features while the rest just mostly got in the way.
So a few years ago I set out to build a design tool just like I wanted. So I built Vecti with what I actually need: pixel-perfect grid snapping, a performant canvas renderer, shared asset libraries, and export/presentation features. No collaborative whiteboarding. No plugin ecosystem. No enterprise features. Just the design loop.
Four years later, I can proudly show it off. Built and hosted in the EU with European privacy regulations. Free tier available (no credit card, one editor forever).
On privacy: I use some basic analytics (page views, referrers) but zero tracking inside the app itself. No session recordings, no behavior analytics, no third-party scripts beyond the essentials.
If you're a solo designer or small team who wants a tool that stays out of your way, I'd genuinely appreciate your feedback: https://vecti.com
Happy to answer questions about the tech stack, architecture decisions, why certain features didn't make the cut, or what's next.
Due to bike-induced concussions, I've been worried for a while about losing my memory and not being able to log back in.
I combined shamir secret sharing (hashicorp vault's implementation) with age-encryption, and packaged it using WASM for a neat in-browser offline UX.
The idea is that if something happens to me, my friends and family would help me get back access to the data that matters most to me. 5 out of 7 friends need to agree for the vault to unlock.
Try out the demo in the website, it runs entirely in your browser!
Hey HN,
Indian high schooler here, currently prepping for JEE, thought itd be nice to share here.
Three years ago in 9th/10th grade I got a knack for coding, I taught myself and made a custom compiler with LLVM to try to learn C++. So I spent a lot of time learning LLVM from the docs and also C++. It's not some marvelous piece of engineering,
I designed the syntax to be a mix of C and what I wished C looked like back in 9th grade.
It has:
- Basic types like bool, int, double, float, char etc. with type casting
- Variables, Arrays, Assign operators & Shorthands
- Conditionals (if/else-if/else), Operators (and/or), arithmetics (parenthesis etc)
- Arrays and indexing stuff
- C style Loops (for/while) and break/continue
- Structs and dot accessing
- extern C interop with the "extern" keyword
- Emscripten and WASM, as I also had to make it run on my demo website
- Learning typescript and all for the website (lol)
- Custom parser with basic error reporting and Semantic analysis was a PITA for my undeveloped brain (I was 15)
- Learning LLVM from the docs
- Testing is a very important aspect of making software, I skipped it - big regret
- Learning how computers interpret text
- Programming in general was a new tour for me
- I appreciate unique_ptrs and ownership
Its on my github and there's a link to my web demo (https://vire-lang.web.app/), it might take some time to load the binary from firebase.
Very monolithic, ~7500 lines of code, I’d really appreciate any feedback, criticism, or pointers on how I could’ve done this better.
Hi HN! Smooth CLI (https://www.smooth.sh) is a browser that agents like Claude Code can use to navigate the web reliably, quickly, and affordably. It lets agents specify tasks using natural language, hiding UI complexity, and allowing them to focus on higher-level intents to carry out complex web tasks. It can also use your IP address while running browsers in the cloud, which helps a lot with roadblocks like captchas (https://docs.smooth.sh/features/use-my-ip).
Here’s a demo: https://www.youtube.com/watch?v=62jthcU705k Docs start at https://docs.smooth.sh.
Agents like Claude Code, etc are amazing but mostly restrained to the CLI, while a ton of valuable work needs a browser. This is a fundamental limitation to what these agents can do.
So far, attempts to add browsers to these agents (Claude’s built-in --chrome, Playwright MCP, agent-browser, etc.) all have interfaces that are unnatural for browsing. They expose hundreds of tools - e.g. click, type, select, etc - and the action space is too complex. (For an example, see the low-level details listed at https://github.com/vercel-labs/agent-browser). Also, they don’t handle the billion edge cases of the internet like iframes nested in iframes nested in shadow-doms and so on. The internet is super messy! Tools that rely on the accessibility tree, in particular, unfortunately do not work for a lot of websites.
We believe that these tools are at the wrong level of abstraction: they make the agent focus on UI details instead of the task to be accomplished.
Using a giant general-purpose model like Opus to click on buttons and fill out forms ends up being slow and expensive. The context window gets bogged down with details like clicks and keystrokes, and the model has to figure out how to do browser navigation each time. A smaller model in a system specifically designed for browsing can actually do this much better and at a fraction of the cost and latency.
Security matters too - probably more than people realize. When you run an agent on the web, you should treat it like an untrusted actor. It should access the web using a sandboxed machine and have minimal permissions by default. Virtual browsers are the perfect environment for that. There’s a good write up by Paul Kinlan that explains this very well (see https://aifoc.us/the-browser-is-the-sandbox and https://news.ycombinator.com/item?id=46762150). Browsers were built to interact with untrusted software safely. They’re an isolation boundary that already works.
Smooth CLI is a browser designed for agents based on what they’re good at. We expose a higher-level interface to let the agent think in terms of goals and tasks, not low-level details.
For example, instead of this:
click(x=342, y=128)
type("search query")
click(x=401, y=130)
scroll(down=500)
click(x=220, y=340)
...50 more steps
Search for flights from NYC to LA and find the cheapest option
Smooth enables agents to launch as many browsers and tasks as they want, autonomously, and on-demand. If the agent is carrying out work on someone’s behalf, the agent’s browser presents itself to the web as a device on the user’s network. The need for this feature may diminish over time, but for now it’s a necessary primitive. To support this, Smooth offers a “self” proxy that creates a secure tunnel and routes all browser traffic through your machine’s IP address (https://docs.smooth.sh/features/use-my-ip). This is one of our favorite features because it makes the agent look like it’s running on your machine, while keeping all the benefits of running in the cloud.
We also take away as much security responsibility from the agent as possible. The agent should not be aware of authentication details or be responsible for handling malicious behavior such as prompt injections. While some security responsibility will always remain with the agent, the browser should minimize this burden as much as possible.
We’re biased of course, but in our tests, running Claude with Smooth CLI has been 20x faster and 5x cheaper than Claude Code with the --chrome flag (https://www.smooth.sh/images/comparison.gif). Happy to explain further how we’ve tested this and to answer any questions about it!
Instructions to install: https://docs.smooth.sh/cli. Plans and pricing: https://docs.smooth.sh/pricing.
It’s free to try, and we'd love to get feedback/ideas if you give it a go :)
We’d love to hear what you think, especially if you’ve tried using browsers with AI agents. Happy to answer questions, dig into tradeoffs, or explain any part of the design and implementation!
I built nginx-defender after repeatedly seeing small and mid-sized NGINX servers get hammered by automated abuse (credential stuffing, path probing, aggressive scraping).
Existing tools like fail2ban or CrowdSec felt either too slow to react, too heavy for low resource servers, or painful to tune for modern traffic patterns.
nginx-defender runs inline with NGINX and blocks abusive IPs in real time based on request behavior rather than static rules. It’s designed to be lightweight, simple to deploy, and usable on small VPS setups.
I’ve been running it on my own servers and have seen thousands of abusive requests blocked within hours with minimal overhead.
Would love feedback from people running NGINX in production, especially on detection logic, false positives, or missing use cases.
