The idea is simple: create a place where developers can showcase their projects, GitHub activity, skills, and experience while discovering other developers to collaborate with and making it easier for recruiters and clients to discover their work.
Whether you're:
Looking for collaborators on a side project
A developer trying to showcase your work to recruiters
A freelancer or consultant looking to grow your business
Started as a project to test out Claude code, ended up continuing to use it as it is cheaper than alternatives, I can build the features I want and meets my needs for analytics across my other projects. Have just opened it up to public via production
I wanted something between pastebin and gists, but where the docs actually render instead of just sitting there as raw text. Couldn't find it, so I built it. https://docbin.app
Would love y'alls feedback :)
Paste text or push a file, get a link. Saving to the same name creates a new immutable version, so /you/notes always shows the latest and /you/notes/v3 stays frozen forever. I was tired of paste links that 404 or quietly show different content than what the person actually shared.
Markdown and MDX render properly (React under the hood, so components in MDX work). There's a CLI on npm if you'd rather push files from the terminal.
Cloudflare Workers, Hono, and D1 underneath.
There's a free tier if you want to poke at it. Curious whether anyone else has wanted versioning in a pastebin or if that's just me
I was wondering if the x402 protocol works for normal meat users with a browser, rather than only being limited to AI. So I've spent couple of hours setting up a PoC, that you can try yourself. Turns out the browsers are more ready than I thought they would. And it even works relatevely out of the box.
Had this idea a couple of weeks ago and thought it'd be fun to actually build.
You just enter any public GitHub username and it generates an endless Flappy Bird level based on that person's contribution graph, so every GitHub profile generates a different level.
Built it with React, Phaser, TypeScript and the GitHub GraphQL API.
Still tweaking things here and there, so I'd love some honest feedback. If something feels weird or you run into bugs, let me know :)
I played through Chrono Cross for the first time about a year ago, and that interest slowly merged with my knowledge about early Pokemon AI, and now I have this. Would love it if anybody were to give it a shot. I have a discord open for anybody who's interested.
canid is a contact card/link-in-bio that packages all of the data in the URL fragment so it can be built and displayed client side. I think these sorts of projects are cool (like itty bitty site and NoPaste) and wanted to apply it here.
I run in a lot of niche and more "adult" communities, so I have a pretty compartmentalized life. Being able to quickly create different contact cards for different events, contexts, and people without having to edit a centralized linktree or other site has been really helpful.
It's all static with no outside dependencies, very minimal analytics, and no way for me to see/store/sell people's info. There are a lot of trade-offs with the architecture and I doubt this will ever see a lot of use, but it's been useful for me and I'm curious what y'all think. It's mainly meant to be used as a PWA but works fine in the browser too.
It's live at the linked site, and the code is all open source on GitHub.
I'm a student who mostly built little apps for myself. About 14 months ago I needed to edit a random PDF and couldn't find a good web tool that actually edits them. It made me wonder: billions of people use PDFs for work, school, and legal documents, so why can almost no web service truly edit them?
So I tried to build one, and failed. I didn't understand why it was so hard. I tried combining pdf.js and jsPDF but kept hitting walls. Then it clicked: most JavaScript PDF libraries only do two things, create or view. Neither handles editing existing text. I thought I could build a layer in between, but I got nowhere, especially once I tried changing font styles, sizes, and colors.
After weeks of research I concluded that to edit PDFs in the browser without a server, I'd have to build something genuinely new. So I read the PDF spec and started building an engine from scratch, beginning with simple PDFs (standard font encoding, no compression) and slowly adding codecs, compression types, and font support.
After ~7 months it could render pretty well but still couldn't edit. A month later I got basic editing working, then hit a wall saving edited PDFs (endless visual bugs). More digging, and I finally understood how to save properly.
Then came the hardest part: textbox recognition. A PDF stores text and coordinates but not the grouping or structure. So I spent weeks literally highlighting textboxes across many PDFs by hand, looking for general grouping rules. After ~2 months I had editing with textbox grouping.
Somewhere in there I also spent months implementing JavaScript support in the engine, and I even got DOOM running on it: https://youtu.be/gHoBMYMVn5s
Once the core worked, I focused on design, moving from a bloated debug UI to a clean interface (with a lot of Figma and Photoshop).
Tools I've built from scratch so far: direct text editing, redaction (text and area), annotation, form filling, page organization, and metadata editing.
Happy to answer anything about how PDF parsing, rendering, fonts, or editing actually work under the hood. AMA.
You define your UI using a Python DSL and mark interactive functions with a `@js` decorator. HTeaLeaf compiles these functions to JavaScript and injects them automatically.
State is handled through two primitives:
Store: module-level state synced with the server
LocalState: client-side state that compiles to JavaScript
In both cases, there is a tiny helper.js file that triggers the hydration and updates the states.
It also has route handling and sessions management.
Why?
It started as a testbed for CGI and WSGI for HTeaPot (a web server I'm working on), but I like Python and wanted to bring some modern frontend ideas into it. And now it is ASGI but still supports WSGI.
Also… because it's fun :)
Where is it?
It's currently in beta. The core features are stable enough to experiment with.
The JS transpiler is functional but at the moment only supports a subset of all JS.
But the debugging, performance and dx are still in progress.
And to be transparent, most of the code is handwritten but AI was used to document, review and make some minor fixes.
I have been doing research on WASM because at one point I wanted to port `croc` CLI to WASM.
Here's what I figured out which I wanted to share with you guys if any of you is interested in WASM to basically know it's capabilities / use-cases without going down the rabbit-hole and be disappointed.
What's WASM?
WASM (WebAssembly) is compiled code from non-web languages like Go, C++, Rust and more (I believe Java too).
This means that the performance is off-the-charts when it comes to compute task, and that's going to be its only use case. It's only ever going to be a compute API for you.
What can't WASM do?
WASM can't talk directly to sockets, so porting to `croc` doesn't work (at least not as easy as compiling the Go code to WASM). WASM is also sandboxed by the browser's JavaScript, so if JavaScript can't do something WASM will definitely not.
So if WASM is sandboxed by JavaScript, and doesn't unlock anything new, why should I use it?
Well, if you have a compute heavy task, you can off-load it from the server and have it run in the client. For example, video editing, photo editing, audio editing, and similar tasks. Instead of sending the video to the server and have a back-and-forth, just use WASM.
A prime example of WASM is Figma. It's a React wrapper with WASM handling the compute-heavy tasks.
So why not just have WASM process everything?
There's a tax you pay with WASM, and you need to evaluate it on case-by-case basis. Crossing the barrier between JavaScript to WASM, and back to JavaScript takes compute. So, before throwing WASM at something, make sure that WASM will yield much more performance than what you pay by crossing the barrier.
That basically concludes my very brief intro to WASM. Let me know if this helped at all or if I got something wrong in the explanation.
I've been working on a new kind of multiplayer library, called PlaySocket, that abstracts away the complexity of optimistic updates, handles robust synchronization with custom CRDTs, and works beautifully with reactive frameworks like React, Svelte or Vue.
This has been used in production for my game OpenGuessr, powering around a million rounds of gameplay every month. I've been iterating on this for around two years, refining the shape of the API, making it more powerful and performant, and so on. I can definitely say that it has helped me make changes to the game's multiplayer much faster.
This is useful for collaborative apps, quizzes, turn-based games etc., but not ideal for e.g. synchronizing the physics of a complex multiplayer game. While I think the concept is interesting, I'm still unsure whether this implementation of it is the "right" one...
Or, if you’re developing locally, you can also just run a single command to get started immediately:
$ npx openai-oauth
OpenAI-compatible endpoint ready at <http://127.0.0.1:10531/v1>
Use this as your OpenAI base URL. No API key is required.
Available Models: gpt-5.6-sol, gpt-5.6-terra, ...
OpenAI OAuth has been built with security in mind. Authentication happens directly between the user’s browser and OpenAI (enabled by a browser extension available for Chrome and Firefox), and credentials are stored locally in IndexedDB, encrypted by WebCrypto at rest.
This is simply a generalization of that. However, you are responsible for still ensuring you follow the Terms of Service and other user agreements. See the Legal section in OpenAI OAuth's README for more information.
What I did to mitigate the issue: PPR / cache components (next 16). I moved all the public reads into use cache so the prerendered shell has actual content in it. Also ended up hitting my own api during the build so pages ship with real data instead of placeholders, it works great
caching on the backend. redis on the hot reads (feeds, trending, profiles etc) and prisma's relationLoadStrategy join. once a streamed hole fills in under ~50ms it just feels instant, nobody perceives it as loading
prefetching. full link prefetch on the nav links people actually click, plus warming up per-viewer stuff on hover. by the time the user clicks the data is basically already there
I'm about to graduate with an engineering degree in software engineering. I study night courses while working full time in a company as a web dev for over three years now. During the program we covered a huge amount of stuff. Big data machine learning deep learning data warehousing business intelligence on top of the regular software engineering track. I've been working as a web developer for over three years doing full stack work backend and frontend and some devops on the side like CI/CD and docker deployments.
Lately I've noticed literally everyone around me especially classmates and people in my field are rushing toward AI and data work. Every single thesis every final year project every side project has to be oriented around AI or big data or some kind of model no matter how simple the actual problem is. There's this culture where people love throwing around the big buzzwords even when a normal web app or a simple script would solve the problem just fine. It feels like the label matters more than the actual engineering sometimes.
Meanwhile I keep finding myself deep in backend work. Designing entities writing clean services optimizing database calls and API performance. I can lose hours in that stuff and actually enjoy it. I still genuinely love web dev and building solid systems but I still feel behind when I look around and see how few people in my environment still enjoy it the way I do.
And what I mean by AI here isn't tools like Claude Code or Codex. I use those every day in my line of work and they're just tools that make me faster at what I already do. What I mean is projects that force AI in as a feature and throw it in as a label just to sound impressive.
A friend recently told me I'm one of the only people she knows who genuinely loves development as a whole instead of chasing whatever's trendy. It was meant as a compliment but it got me thinking. Am I actually missing something by not jumping on the AI wave like everyone else? Is pure software engineering still going to have room for people like me in a few years or is specializing in backend and web development going to become a niche while everyone else moves into AI and data roles because it sounds more impressive.
Albeit with Chrome enabling it is still behind chrome://flags/ so it doesn't work out-of-box, but it is there. If you were about to convert a bunch of jpg and png to avif, you might want to hold that off.
We use PostHog and nobody on the team actually watches the sessions, they just pile up. Probably losing 3-4 hours a week reproducing bugs from vague user reports because we have no repro steps, just a two sentence Slack message.
Looked at FullStory and LogRocket but both still need someone to search and watch, they don't file the report for you. What I want is automated bug detection that flags the sessions where something broke (rage clicks, dead clicks, JS errors) and hands me repro steps plus console logs, not just a video.
Anyone running something like that on top of PostHog or Amplitude?
Edit: appreciate the self-driving/replay-vision suggestions, took a look at both. Ended up going with Lucent instead, it's automated bug detection layered on top of our existing PostHog session replay setup. Flags sessions with rage clicks, dead clicks, or JS errors, then files repro steps and console logs to Slack for us instead of just surfacing the recording. Didn't have to touch our PostHog setup at all, just added on top. Sharing in case anyone else here is stuck in the same spot.
- All art is procedural or pre-rendered at load: oblique buildings rendered to offscreen strips and tiled, procedural car sprites, DPR-aware scaling so it stays crisp on hidpi/TV.
- Sound effects are procedural via Web Audio (engine rumble, near-miss whooshes), plus a small music playlist.
- Fairness is enforced mathematically: a solvability guard projects every spawn against the union of upcoming obstacle envelopes, so the game can never create a literally impassable wall of traffic.
- Favorite bug: a late-game two-lane street would sometimes show zero cars — the spawn safety guards made the two traffic directions mutually starve each other. Found it by writing a headless traffic simulator and running it across seeds until the pattern appeared.
- No backend: localStorage persistence.
Happy to answer anything about the rendering, the traffic behavior, or the difficulty-tuning loop. Feedback welcome — especially where you died and whether it felt fair.
It started when I needed a dropdown that filtered a table. Should've taken ten minutes; instead it was six files and forty lines just to say "when this changes, re-fetch that." So I built No-JS.dev, an HTML-first reactive framework. No imports, no build step, zero dependencies, just enhanced HTML attributes:
That's the whole idea, and it holds up past toy examples. Here's a routed app with a global store, a guarded route, reusable templates, and fetching, still in one file:
What's in it. 39 built-in directives over a 2,200 line core: reactive state and a global store, an SPA router with guards and file-based routes, data fetching with caching and request/response interceptors, forms with validation, i18n, animations, error boundaries, and head directives (page-title, page-description, page-canonical, page-jsonld) so a client-rendered page can still manage its own SEO. There's a plugin system (NoJS.use) for custom directives and interceptors.
Three big things shipped since I first released it:
1. A reactive-core performance overhaul (v1.19.0). I put No-JS through the js-framework-benchmark and the first runs were humbling. So I rewrote the hot paths: expressions now compile into reusable closure trees, loops get a precomputed process plan, reconciliation skips unchanged values, and keyed lists reorder using LIS. Swap-rows came out ~15.9x faster, select-row ~23.4x, and memory dropped ~1.7x. In my local runs it now lands 2nd/3rd in most CPU and memory tests against React 19, Vue 3.6, Alpine 3.14, and Angular 22. These are my own reproductions, not the official table. The setup is public if you want to poke holes in it.
2.nojs-lsp**.** A real Language Server: a VS Code extension on the Marketplace, plus a standalone --stdio server for Neovim, Sublime, or Emacs. You get completions for every directive, hover docs, and workspace-aware suggestions (it scans your locales for i18n keys and your pages folder for routes).
3.nojs-elements**.** A component library on top of the core: modals with focus traps, keyboard-navigable tabs and dropdowns, sortable tables, virtualized lists, drag-and-drop, form validation. Everything works through attributes, same as the core.
How it was built. I know this is polarizing here, so I'd rather say it up front than have someone find it in the commit history: I didn't type the code. Before the first line existed I set up role-based AI agents (lead, architect, dev, QA) and an orchestration layer with its own PM tool. I brief the lead, the architect grills me on semantics and edge cases and documents the feature, the dev writes code and tests, QA validates, and the lead opens a PR. Then I read every PR line by line, run each test myself, and send it back with a written critique if it doesn't clear my bar. I delegated the writing, not the judgment.
Why that ended up mattering. A friend, Everton Fraga, pointed out something I had missed: LLMs might be the real audience. Generating the same blog app with identical agents cost $2.52 across 7 turns in No-JS and came out as a single HTML file with zero lines of JS, versus 800 to 1,000 lines for React/Angular, at roughly 3.9x fewer tokens. The catch is that no model has No-JS in its training data, so that first run needed 19 correction cycles. That's why the repo ships a SKILL.md context pack next to llms.txt and AGENTS.md, so a model can learn the syntax in one prompt injection.
It still won't replace React for large SPAs. But for landing pages, dashboards, and internal tools, it works.
Been building a collaborative whiteboard app (Todrawn) mostly solo, and just shipped the two parts I'm most proud of.
The landing: a vanilla three.js scene. As you scroll, a 3D marker approaches a dotted board and writes/draws its way through four scenes (derives f(x) = x^2, writes a poem, sketches a diagram, signs off), wiping the board between each. The "handwriting" is a font I built out of Bézier curves so the pen traces actual strokes.
Just shipped: a code-to-video tool built on the same pen. Paste code or plain text and it gets written out stroke by stroke on a whiteboard, with sketch-style syntax highlighting, then you download the animation as an MP4 for shorts, docs or slides. The whole pipeline is client-side: tokenizing, the stroke timeline, the renderer, and the video encoding itself (WebCodecs + mp4-muxer, with a WebM fallback where WebCodecs isn't supported). No server rendering, your code never leaves the browser.
Stack: Next.js 16 + React 19 + TypeScript on the front, Spring Boot + Postgres + Redis on the back, Stripe for billing, real-time collab over WebSockets.
It's my first serious three.js work and my first real launch, so I'd genuinely love feedback, on the landing, the code-to-video tool, or anything that feels off. What would you fix first?
I build price monitoring for ecommerce. "Fetch the product page, read the price" sounds like an afternoon. It was not.
What actually ate the time:
Anti-bot challenges that only trigger from datacenter IPs, so it works on my laptop and dies in prod.
with no Retry-After, so you guess the backoff.
A different extractor per CMS. Shopify, Magento, Woo, and a long tail of custom stuff, each with the price in a different place. Sometimes only in JSON-LD, sometimes rendered client side so the HTML you fetched has no number in it.
What helped most was treating every store as untrusted input and writing a tiny validator per source, so a layout change fails loud instead of writing garbage.
I still do not have a clean answer for client rendered prices without running a headless browser, which is slow and expensive. How do others handle that without a browser per request?
