标签：#web

I wanted to do something entirely different than my normal, meet overwatch.earth Explore the world through a fully interactive 3D globe with real-time feeds from over 150,000 sources. Track live events as they happen—from earthquakes and satellite movements to live webcams, global transportation networks, and digital infrastructure. submitted by /u/tuxxin [link] [留言]

Hi all, About three years ago I built a small library called Trig.js to expose scroll data to CSS via data‑attributes. It recently got highlighted as one of the “Enterprise Heavyweights” of scroll animation libraries by CSSAuthor, which made me revisit the idea. I’d always planned to make a Cursor.js, so I built it and then I started wondering, what else could be exposed to CSS variables? That question spiralled into something bigger, and I’ve now ended up creating a full stack of small, browser‑native libraries that all share the same philosophy: Once I reached Keys.js, something clicked. Keys aren’t animation, they’re input. That led to the bigger question, could you build full applications or even games this way? The answer turned out to be yes, and that’s when I came up with State.js. For the first time, here’s the full stack together: Trig-js - exposes scroll data to CSS Cursor.js - exposes mouse/touch position Motion.js - a global clock for CSS‑driven animation Keys.js - exposes keyboard input State.js - a reactive state layer for HTML Gravity.js - a DOM‑element physics engine rendered in CSS Together, these for a declarative application/game engine using the native browser without webGL, webGPU or canvas. Your HTML is your state graph, the CSS is your rendering engine and JS becomes the wiring that connects everything up. These libraries all work independently or together. As every one of these open up capabilities that wasn't possible before that's why they are all individual so you can pick or choose or use them altogether for a complete stack. A few months ago I wouldn’t have believed half of this was possible in the browser without heavy abstractions. It’s made me realise how much capability we’ve historically hidden behind frameworks instead of exposing directly. I’m excited to share this approach and would love to hear your thoughts, ideas, or critiques. If you’re curious about browser‑native reactivity or CSS‑driven rendering, I’m happy to dive deeper.

I built AIPDFKit because I kept running into the same friction: needing to do something simple with a PDF -- redact some sensitive info, pull out a table, or convert a document to Markdown -- and every tool either required an account, put the good stuff behind a paywall, or made me wonder what was happening to my files afterward. PDFKit is my answer to that. PDFKit -- Free AI-Powered PDF Tools PDFKit is a free, browser-based PDF utility suite powered by AI, built for developers and technical professionals who need fast, reliable document processing without the friction of paid plans or mandatory accounts. Whether you're parsing data out of PDFs, sanitizing sensitive information, or converting documents into developer-friendly formats, PDFKit gets the job done in seconds. What it does AI-assisted PII redaction -- automatically detect and mask emails, phone numbers, names, and more Table extraction to Excel -- pull structured data out of PDFs without copying and pasting PDF to Markdown conversion -- especially useful for feeding document content into LLMs or RAG pipelines These aren't just format converters. The AI layer means the output is clean, structured, and actually ready to use. Privacy first No account creation required. PDFKit stores no user data and automatically deletes all uploaded files after one hour. For developers handling client documents or sensitive data pipelines, this is a meaningful differentiator over SaaS tools that retain files indefinitely. Who it's for Developers preprocessing PDFs before feeding them into RAG pipelines Anyone automating document workflows People who need to quickly extract structured data without spinning up a Python script Anyone dealing with sensitive documents who can't afford to have files sitting on someone else's servers It's the kind of utility you bookmark and reach for constantly. Built to be fast, free, and frictionless. Check it out: https://www.aipdfkit.com/ Would love to hear what features you'd find most usefu

Spent the weekend building a local tokenizer to stop leaking DB passwords and API keys to ChatGPT, literally can't stop testing edge cases. Written in pure TypeScript. Uses greedy reverse anchoring to mask credentials locally in the browser. Provided the core sanitizer logic here: https://github.com/abests/ghost-sanitizer-js submitted by /u/zero_backend_bro [link] [留言]

Hi everyone, I’ve always felt frustrated by how many ads are crammed into most tier list websites. That’s why I created a brand new site with absolutely no ads. I also made sure it's highly mobile-optimized and offers multiple downloading options for your tier lists! I'm always looking to improve, so please feel free to share any feedback or features you'd like to see added. ps. As a thank you for checking it out early, if you create 1 tier list template now, I will upgrade you to a lifetime Premium account. Even if ads are introduced later down the road, your account will remain completely ad-free. submitted by /u/Mountain-Shoe-6070 [link] [留言]

Hello reddit! I am P2P engineer so in my free time was working one little side project I'm excited to share, it's called AlterSend. AlterSend is a free, open-source app for sending files directly between your devices, no cloud, no uploads, no size limits. Files transfer peer-to-peer and are end-to-end encrypted, so nothing is ever stored on a server. GitHub: https://github.com/denislupookov/altersend Features: No accounts No servers storing your files End-to-end encrypted No file size limit Cross-platform (desktop + mobile) Open source The idea was to build a good alternative to the established cloud file-transfer apps, without the cloud. How it works, roughly: AlterSend is built on Hyperswarm, which underneath is a Kademlia DHT. For every transfer we generate a random key that acts as a discovery topic, you share that with whoever should receive the files. Each peer announces itself on the DHT under its own node ID, so peers can find each other directly. A handful of public bootstrap nodes serve as the initial entry point and after that peers discover one another through the DHT without relying on any central server. Once two peers connect, the transfer is direct and encrypted end-to-end. Would love to hear your feedback! submitted by /u/AlgoAstronaut [link] [留言]

Just something for your bookmarks and also a little bit of a learning resource. For those of you who are using PageGym, I also (very) discretely integrated it into the request view dialog. https://pagegym.com/tools/cache-control Cheers! submitted by /u/svvnguy [link] [留言]

I was working with websockets and wanted some lightweight solution which was easy to work with and I never liked working with plain websockets and as an experiment I started building a typesafe solution and which is how I came up with @frsty/wsrpc . You can define procedures on the server (like trpc) , get typed send and on on the client. No codegen, no event codes objects to share between client and server, 0 runtime dependencies. Handlers are generator functions, yield events, return the RPC response: https://preview.redd.it/0igrus569n5h1.png?width=3680&format=png&auto=webp&s=880c6b2fd90a04866058bc91d703995c14482b07 All the event codes, returns and callback functions are typesafe. Works with zod, valibot, arktype, anything that implements Standard Schema. framework-agnostic. Still early so would appreciate some feedback. For detailed example see github.com/frstycodes/wsrpc submitted by /u/frstyyy [link] [留言]

The shadcn registry directory is pretty stacked, but there isn't currently any depth in the gamification space. So I decided to build a library of 17 components across the major features you see in most consumer platforms. Things like streaks, achievements, leaderboards, points etc. Trophy UI is fully open-source, and while it seamlessly integrates with Trophy itself, the UI components just accept regular props and so can be used with any backend. Most interesting components: Streak calendar - weekly, monthly or yearly (git-style) view of streak history, with support for streak freezes which are pretty common in consumer apps like Duolingo. Leaderboard rankings - flat list of rankings each with support for avatars, bylines and change indicators. Also supports pagination and collapsed rows to focus rankings around a particular position i.e. show users to top three users above and below them. Achievement badge - a simple badge with support for locked/unlocked states plus features like percentage completion and rarity (the share of users who have unlocked the badge). Points levels timeline - progression path for points levels with support for sub-levels (Bronze I, II, III, Silver I, II, III etc) plus anchoring to a particular users current progress. Every component is installable via shadcn CLI: npx shadcn@latest add https://ui.trophy.so/<component> Once installed you own the code, customize and modify as you see fit. Also very happy to accept contributions for new components or features for existing components. Would love to hear what people think, and would very much appreciate a star on GH if you think its valuable! submitted by /u/CBRIN13 [link] [留言]

I was working with being tortured by Instagram API for a client project. Eventually I delivered something that barely worked with duct tapes and prayers. Never again I'll take on any instagram/meta related project. And after that horrible experience github's rate limits, API coverage and documentation, everything about it felt like a breath of fresh air. Whereas instagram was like; "I'll give you one API call per sometimes and you better cache it" I thought I'd add some pictures from the app I'm working on since it's showoff saturday. Though there's still a lot I need to work on and I'm not sure if I'll even finish it. I just found a way to build desktop apps in python using html/css and I'm going nuts with it lol Edit : If I ever finish this app, it'll be free and open source. Basically you generate an API key, put it into the app and it lets you view, filter, and update your issues. Can also click on repo name or issue title to view in your default browser. I recently downloaded github desktop and it didn't have this feature, so I thought I'd do it myself and learn more python in the meantime. I have a few more ideas for it but I'm trying not to scope creep myself submitted by /u/mekmookbro [link] [留言]

I am a senior full stack dev with 7+ YOE and I think we can all agree the market sucks right now! Primarily I have been applying to full stack roles but I am backend leaning (PHP/Laravel) I seem to be seeing a lot of .NET/C# roles for backend-only roles. Is the market for those devs less chaotic? I'm considering learning .NET anyway, but would like to know if it's worth fully investing my time into it if things are better. submitted by /u/EthanCPP [link] [留言]

I've been working on an open-source project called Canary. It reads your code diffs, understands which UI flows are likely affected, and lets Claude Code tests those flows in a real browser. Under the hood, Canary ships with a QuickJS WASM sandbox that exposes the full Playwright API, allowing Claude to perform long-running browser workflows such as authentication, onboarding flows, form submissions, and navigation across complex applications. Each run captures: Screen recordings Playwright traces HAR files Network requests Console logs Screenshots Unlike most agent runs, every Canary session also generates a reusable Playwright script that can be cleaned up and replayed locally or in CI with zero inference cost. Canary UI submitted by /u/wixenheimer [link] [留言]

You pick a tool on the canvas, and in real-time you get suggestions on what you can add next, how your tools pair together, or what can be missing. There are also recommended tech stacks available for different project types. Web apps are one of the primary types, but the tooling also covers data projects, automation and so on. In total there are over 150 tools present. Everything in the app is rule-based, there’s no AI there yet whatsoever. I do plan to add an AI chat later, but it will be built on the same deterministic engine. It’s a beta for now. The builder and the tools catalogue are fully functional, user accounts are also planned for later. But this core part will stay free to use without accounts. Paid plans, if introduced, would cover extras like AI features. For my own tech stack, it’s Vue.js for frontend, FastAPI for the backend and PostgreSQL for the database. https://tekyous.dev submitted by /u/sartek1 [link] [留言]

5 Principles of Survival for Software Engineers Adapted from Leon Business School's "5 Principles of Survival" Your stack won’t save you. Your principles will. In the wild, survival isn’t about having the best gear. In software, survival isn’t about having the absolute best framework. It’s about how you operate when production is on fire, the roadmap shifts overnight, and AI just turned your "moat" into a weekend hobby project. Here are 5 core principles that keep you alive in modern software engineering. 1. 🔥 Adapt or Perish Change is not optional; it is the price of survival. In the wild: The species that cannot adapt to winter dies. In software: The team that cannot adapt to change dies slowly at first, then all at once. "Localhost is for amateurs" used to be a strongly held belief. Now, Claude writes a full CRUD API in 30 seconds on localhost . "We’re a React shop" was a proud identity. Now, HTMX ships the same feature before your Webpack build even finishes. Your identity as an engineer cannot be tied to a specific tool. Your identity is solving problems . The syntax is temporary. Agreement on what to build is what actually matters. 🛠️ Survival Action Every quarter, deliberately kill one "we’ve always done it this way" rule in your workflow. 2. 🧭 Stay Calm Under Pressure Panic is the first casualty of poor preparation. In the wild: Panic burns critical calories and gets you lost. In software: Panic causes a git push --force to main on a Friday at 4:59 PM. Outages don’t kill companies. Panicked responses do. The team that has clear runbooks, relies on feature flags, and can execute a rollback in under 90 seconds stays calm. Why? Because they prepared when it was quiet. If your first step in incident response is opening X (Twitter) or complaining in a public Slack channel, you have already lost. 🛠️ Survival Action If you don't have a tested rollback plan, you don't have a deployment plan. Write it down before your next release. 3. 💡 Resourcefulness Over Resources

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

If you've ever hit Unexpected token in JSON at position 42 or Unterminated string , there's a good chance an unescaped character broke your payload. JSON is strict about what's allowed inside a string, and the fix is almost always escaping . Here's the practical version. What does escaping a JSON string mean? A JSON string is wrapped in double quotes. Any character that would confuse the parser must be replaced with a backslash escape sequence. Escaping doesn't change the meaning of your text — it just makes the string valid JSON so parsers can read it. Unescaping is the reverse: turning those sequences back into readable characters (handy when you copy a value out of logs or an API response). The characters you must escape JSON defines exactly seven characters that must be escaped inside a string: Character Escaped as Double quote " \" Backslash \ \\ Newline \n Carriage return \r Tab \t Backspace \b Form feed \f The forward slash / may optionally be escaped as \/ , but it isn't required. Unicode can be written as \uXXXX (four hex digits). JSON escape examples Double quotes — He said "hello" becomes: "He said \" hello \" " Backslashes (Windows paths) — C:\temp\file.txt becomes: "C: \\ temp \\ file.txt" Newlines and tabs — a two-line, tabbed string becomes: "Line 1 \n Line 2 \t Tabbed" How to escape and unescape JSON in code In production you rarely escape by hand — every language has it built in. JavaScript const escaped = JSON . stringify ( text ); // escape const back = JSON . parse ( escaped ); // unescape Python import json escaped = json . dumps ( text ) # escape back = json . loads ( escaped ) # unescape Java (Jackson) ObjectMapper mapper = new ObjectMapper (); String escaped = mapper . writeValueAsString ( text ); String back = mapper . readValue ( escaped , String . class ); C# (.NET) using System.Text.Json ; string escaped = JsonSerializer . Serialize ( text ); string back = JsonSerializer . Deserialize < string >( escaped ); Common escaping mistakes (and f

I shared last Tuesday, but the post was removed as Showoff which can post only on Saturdays. Here again! No external CSS, JS, icon, font frameworks. Manage your composable CSS and HTML partials with a YAML data-driven approach, side-by-side using pure Markdown files. Home widgets: Hero, Bento, Showcase, Action Cards (plug and play) Responsive and adaptive layouts. Support for light and dark modes. Support for multiple documentation sets. Support for a blog. Implement a menu via Hugo configs. Customizable sidebars using Hugo data templates. Plug-and-play/ repeatable home page blocks using separate partials/ css/ data templates. Integrate a search via Pagefind. Demo: https://dumindu.github.io/E25DX/ Demo Setup: https://github.com/dumindu/E25DX/tree/gh-pages/example GitHub: https://github.com/dumindu/E25DX So, No need Hundreds of NPM Packages & Thousands of CSS Classes For A Modern And Modular Technical Documentation & Blog Setup In 2026 submitted by /u/dumindunuwan [link] [留言]

In the last update, I introduced MDL as an HTML-first language for building websites and apps with less noise. This update is about the next layer: adapters . The goal is simple: MDL source should describe intent. Adapters decide how that intent becomes deployable HTML. Why adapters? I don’t want MDL to become locked into one frontend framework. Instead, the same MDL structure should be able to target different deployment styles: static HTML MDL-native runtime attributes HTMX future template or framework adapters So this: form@api(post /api/login)@result(loginResult)@swap(replace): .input@type(email)@required .btn-primary@type(submit)(Sign in) status@id(loginResult): Waiting. Can become plain HTML: html <form method= "post" action= "/api/login" > Or HTMX: html <form hx-post= "/api/login" hx-target= "#loginResult" hx-swap= "outerHTML" > Security before convenienceThe important part is that MDL does not pass behavior attributes through blindly. Raw HTMX attributes like this are blocked: mdl form@hx-post(/api/login): Instead, MDL uses intent-based attributes: mdl form@api(post /api/login): Then the adapter validates and translates it. Current safety rules include: external api(...) URLs are rejected raw @hx-* attributes are blocked raw browser events like onclick(...) are blocked unsafe URL schemes like javascript: are blocked broad form inclusion like @params( ) is blocked @inherit( ) is blocked @disinherit(*) is allowed because disabling inherited behavior is safer That means MDL can support HTMX without making MDL source depend directly on HTMX’s full raw surface area. New HTMX adapter attributesThe HTMX v2 adapter now supports more behavior attributes: mdl @select-oob(...) @swap-oob(...) @disabled(...) @disinherit(...) @encoding(...) @history-elt(...) @inherit(...) @params(...) @preserve(...) @prompt(...) @replace(...) @request(...) @sync(...) @validate(...) Example: mdl form@api(post /api/profile)@result(profileResult)@swap(replace)@params(email csrfToken)@disable

I grew tired of mocks lying to me and the extra complexity they bring. This led me back to a classic design pattern: the Command. The idea is simple: separate an action from its execution. I wanted a functional take on this, though: no classes, no mutation, just pure functions returning plain data. Most importantly, I wanted it without the academic vocabulary of category theory. The result is a tiny library a developer could master in a single afternoon. It removes the need for mocking libraries and comes with additional benefits such as time-travel debugging. submitted by /u/aijan1 [link] [留言]

Inspired by Nir Eyal's "beliefs are tools" framework Beliefs are tools, not truths. Tech stacks are too. Pick the ones that work for you. Most "tech debt" is actually "belief debt". We hold onto frameworks, patterns, and processes long after they stop serving the product. To build great software, we need to introduce a core rule: If a tech belief or "best practice" doesn’t solve a real problem for you right now, it must be treated as false. Here is how to audit your tech beliefs using 5 filters. 1. ARE THEY USEFUL? The real question isn’t "Is this the best tech?" It’s "Does this serve the user?" Tools are tools. Keep the ones that ship. Bad belief (Treat as False): "We need Kubernetes because it’s the industry standard." Useful belief (True for Now): "A $5 VPS serves 10k users. We’ll use K8s when we have a scaling problem, not a resume problem." If your architecture choice doesn’t make the core loop faster, cheaper, or simpler for users, it’s not serving you. Delete it. 2. ARE THEY TESTED? A useful stack holds up when the world pushes back. Pay attention to production, not the trending blog posts. Bad belief (Treat as False): "Microservices are inherently more scalable"—said before you even have 2 concurrent users. Tested belief (True for Now): "Our monolith handles 50 req/s perfectly. We’ll split services only when latency exceeds 300ms in prod." Load test it. Dogfood it. If it only works in a conference slide deck, it’s a story, not a tool. 3. ARE THEY OPEN? A tech choice you can’t change has stopped being a tool and has become a cage. Hold opinions firmly, but hold implementations loosely. Bad belief (Treat as False): "We’re a React shop forever." Open belief (True for Now): "React serves us today. If HTMX lets us ship this feature in 2 days instead of 2 weeks, we’ll use HTMX." In a famous study on hope, Curt Richter’s rats swam for 60 hours when they believed rescue was coming. Your team will grind for years on a legacy stack if they believe it can actually be r