标签：#webdev

Last month I shared how I built 143 free online tools that run 100% in your browser — no signup, no uploads, no watermarks. That post got a great response (and a lot of "how is this free?" comments — answer: it stays free because files never touch a server, so there are no processing costs). Today's update: every single tool now has a full guide series. What's new 144 how-to articles — one per tool — live at toolfyra.vercel.app/blog : Step-by-step guides — every input explained, common pitfalls, pro tips Real competitor comparison tables (we scraped and analyzed who ranks for what, and where their tools annoy users with account walls) FAQ sections with schema markup so answers surface directly in search and AI assistants Unique generated illustrations per article Smart related-tools clusters — finish one task, the next tool is one click away Why guides for calculator tools? Because "how to use a calculator" is what people actually search for. Tools win clicks; guides win trust and rankings . Each article is built from real search-engine data: live SERP results, keyword expansions, and competitor FAQ analysis — zero guesswork. The engineering side (for the dev readers) Every tool is a single HTML page with vanilla JS — calculators run client-side, file tools use Canvas/FileReader APIs The blog is generated (Python build script): schema.org BlogPosting + FAQPage + BreadcrumbList, per-post OG images as optimized SVGs, canonical URLs, sitemap + IndexNow pings on every deploy New site-wide: instant search (type "pdf" → live results dropdown, keyboard-first: / to focus, ↑↓ to navigate), a Tools dropdown with 11 categories, and a mobile hamburger panel — all vanilla JS, no dependencies Privacy by architecture: there is literally no upload endpoint to breach What's next More waves of content (FAQ, mistakes-to-avoid, and comparison articles for every tool) A batch of new tools from our demand-research pipeline (we score thousands of real search phrases before writing a line

Indexar o código fora do repo: como economizar tokens sem jogar o projeto no contexto Pessoal, o agent precisava achar um símbolo. Trabalho de um minuto. Na prática, ele abria arquivo atrás de arquivo, colava dump de teste no papo e a janela sumia. Às vezes a fatura também. Não era o modelo burro. Era eu pagando o monorepo inteiro pra responder a pergunta errada. A pergunta mudou. Deixei de ser “qual tool faz o agent entender o repo?” e virei: o que é memória de domínio, e o que é só custo de ler código nesta sessão? Tem um segundo motivo, e ele não é economia. Um índice de símbolos é um mapa do seu sistema : quem chama o quê, onde está o fluxo crítico. Se esse mapa mora no git, no cache de CI ou num serviço que o agent também escreve, o blast radius não é só token. É superfície. Duas contas, um prompt Memória de domínio é política. O que pode ser lembrado, por qual porta se entra, o que é canônico. Notas, contratos, “onde a gente decide X”. Indexer de código não resolve isso. Code-read barato é custo de sessão. Achar caller e símbolo sem despejar o working tree no prompt. Isso não deveria virar a sua base de conhecimento. Eu misturava. O indexer virava KB. O vault virava grep sem porta. Os dois falhavam, e a sessão inchava igual. Economizar token aqui não é trocar de modelo da semana. É separar camada. E decidir onde o mapa vive . O que eu mudei na mesa O mapa de símbolos saiu do working tree. Cache local, fora do repo , fora do git. Reindex é operação de máquina, não de PR. O agent consulta o índice; não precisa reler o monorepo pra “quem chama essa função?”. Quatro perguntas que eu faço antes de indexar um repo (vale colar no README do setup): O índice vive na minha máquina ou sai dela (cloud, CI, cache compartilhado)? Entra em contexto de agent que também tem tool de escrita ? Como eu apago e revogo? Quem mais lê isso? Índice ≠ fonte de verdade versionada. Least privilege no que entra no contexto continua valendo. Depois, parei de mandar firehose de CLI cru. tes

Last week, it came to light Cursor had mostly finished migrating from SolidJS to React . This migration happened about seven months ago. But it became a central focus of discussion following the Solid 2.0 RC release . Then yesterday, a week later, it came to my attention that the Anthropic docs example command for their large-scale migration feature is: I admit that my gut reaction was not great. Out of all the examples they could have chosen... Years of my work became a canonical example of the thing you migrate away from — in the same week we shipped the biggest release in the project's history — stung in a way I won't pretend it didn't. My second reaction was to assume that, like the other trickle-down posts I'd seen this week, this rode the same week-old news cycle. Then I checked the Internet Archive and realized this has been there since at least April 2026 . Four months before the Cursor story broke. At this point, the whole public footprint was a mention of an experiment sandwiched between bigger updates in a Cursor blog post posted in January. The kind of thing that no one outside the industry would even really pick up on. No reasoning, no benchmarks, no argument. Stop to think about what that means. I should be careful here because I can't prove anyone at Anthropic ever read that Cursor post. Nobody can. Maybe a docs writer saw the experiment. Maybe Claude drafted its own example. But think it through. Either it traveled from a buried line in one company's release notes into another company's official docs, or it needed no origin at all. It was already assumed before any public migration existed. Our industry has quietly started broadcasting conclusions where it used to transmit arguments. We couldn't have picked a worse time, because — as I'll get to — arguments are the only source that still matters. Why This Matters More Than It Used To It would be fair to ask, hasn't it always been like this? Teams cargo cult large players. Netflix or Facebook uses thi

Originally published at parvejshah.com/blog/why-browser-agents-fail-in-production-without-semantic-layers by Parvej Shah . The Fragility of Machine Vision in Modern DOMs Maybe the next evolution of frontend engineering isn't just designing interfaces for humans. It is designing interfaces that machines can reliably understand too. Browser agents don't always fail because the AI model is bad. Often, the web page itself is fundamentally hostile to machine parsers. Modern single-page applications (SPAs) render deeply nested <div> trees with ephemeral, auto-generated class names (such as Tailwind or CSS-in-JS hashes). While this provides fluid visual rendering for human users, it strips away semantic meaning for automated agents. graph TD A[AI Browser Agent] -->|Fragile Visual OCR / Coordinate Guessing| B[Opaque Div Hierarchy] B -->|Frontend Code Deploy / CSS Hash Shift| C[Broken Automation & Flaky Selectors] A -->|Direct Deterministic Query| D[Semantic Schema & data-agent Attributes] D -->|Refactor-Proof Contract| E[Deterministic Task Execution] Moving Beyond Ephemeral Selectors We already treat accessibility (a11y) as a non-negotiable contract between the frontend and assistive technologies through ARIA attributes. Why not extend that exact engineering rigor to AI agents? Imagine components exposing explicit, stable machine intent: // The machine contract: deterministic, testable, refactor-proof < button data - agent = " checkout-submit-button " data - agent - action = " complete-transaction " className = " btn-primary " > Confirm & Pay < /button > With explicit semantic attributes: Zero Layout Guesswork: The agent does not need to guess which button to click based on pixel coordinates or fragile CSS selectors. Deterministic Interaction Paths: Continuous integration (CI) test suites can validate machine contracts alongside accessibility audits. Reduced Latency & Token Costs: Vision-language models (VLMs) introduce non-deterministic latency and high token costs when in

₹85,000 per month. That was the AI API bill sitting in my client's inbox when they called me in a mild panic last quarter. They run a mid-sized e-commerce operation in Pune — about 4,000 orders a day — and had integrated AI into customer support, product descriptions, and internal reporting. The AI was working beautifully. The invoice was not. Three weeks later, their monthly bill was ₹12,400. Same tasks. Same quality. No corners cut. Here's exactly what changed. The real problem: every task was using the most expensive model When I audited their setup, the issue was obvious within five minutes. Every single API call — whether it was classifying a customer complaint into one of 8 categories or generating a 2,000-word product description — was hitting the same premium model. It's the most common mistake I see with businesses adopting AI: they pick one model during the proof-of-concept phase and never revisit that decision as they scale. You wouldn't hire a senior chartered accountant to do data entry. But that's essentially what was happening — a top-tier reasoning model answering "Is this complaint about shipping or billing?" Fix 1: Model routing — the single biggest cost lever Model routing means sending each task to the cheapest model that can handle it at acceptable quality. I categorised their ~47 distinct API call types into three tiers. 68% of calls moved to the lightweight tier, 20% to mid-tier, only 12% stayed on premium. That single change dropped the bill from ₹85K to roughly ₹38K — no quality loss, verified with two weeks of A/B testing on customer satisfaction scores before switching fully. Fix 2: Prompt caching — stop paying for the same context twice Their support bot sent the same 1,200-token system prompt with every call — policies, tone, catalogue context, all identical across thousands of daily calls. Caching processes it once and references it cheaply on subsequent calls within the window. At ~6,000 support interactions a day, this alone saved ₹8,

Originally published at parvejshah.com/blog/why-browser-agents-fail-in-production-without-semantic-layers-test by Parvej Shah . The Semantic Contract Modern web applications optimize DOM trees for human eyes with nested divs... graph TD A[Vision Model] -->|Fragile OCR| B[DOM Tree] C[Semantic Layer] -->|Deterministic Contract| B const button = document . querySelector ( " [data-agent=submit] " ); Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at parvejshah.com .

Svelte/SvelteKit Forms: The Fastest Path From <form> to Inbox with onsubmit.dev (form backend) SvelteKit makes forms pleasant to build, but a contact form still needs somewhere to send its data. If all you want is “visitor fills out <form> → message arrives in my inbox,” building and operating another server-side handler can feel disproportionate. onsubmit.dev (form backend) provides a hosted form endpoint for that job, and its Svelte integration can keep the application code small. One naming detail is worth clearing up immediately: onsubmit.dev (form backend) is a service, while Svelte has its own on:submit event directive. They are unrelated. In this article, references to the product always mean onsubmit.dev (form backend), not Svelte's on:submit . The usual SvelteKit approach SvelteKit already has a solid answer for server-side form handling: form actions. A typical contact form can POST to a +page.server.ts action, where you validate the fields and then do something useful with them. Conceptually, that gives you: Svelte <form> ↓ SvelteKit form action ↓ validation ↓ email provider / database / notification service ↓ your inbox This is a good architecture when submitting the form kicks off application-specific business logic. For a simple portfolio, landing page, documentation site, or “contact us” form, however, you also inherit the less interesting parts of owning that pipeline: delivery integration, configuration, error handling, spam controls, and maintenance. That's where using a dedicated form backend can make sense. Using svelte-onsubmit The Svelte integration is svelte-onsubmit . Rather than reproducing package code that might drift as its API evolves, use the current installation and usage snippet from the official integration documentation: https://onsubmit.dev/integrations That documentation is the source of truth for wiring the package into your current Svelte/SvelteKit project. The resulting architecture is deliberately simpler: Svelte <form> ↓ host

Here is the disk layout of one mobile mapping survey — a vehicle with a LiDAR scanner and a panoramic camera, driven along a road: data/001_MMS/ 507 MB point cloud orbit/oblak/ 566 MB spherical photos trajectory/*.gpkg 108 KB the path the vehicle drove Just over a gigabyte. The database this feeds holds 2.3 GB in total — for 2.7 million road features across a hundred layers. Two more surveys and the binary data outweighs everything the database has ever stored. So the question isn't how to put a point cloud in Postgres. It's what you put in Postgres instead . The trajectory is the index Of that gigabyte, one file goes into the database: the 108 KB trajectory, a GeoPackage holding the line the vehicle drove. That line is what makes the survey findable. It draws on the map with everything else. You can ask which surveys cover a junction, which are newest, whether a stretch of road has been captured since the resurfacing. All the questions people actually ask are questions about where and when , and the trajectory answers every one of them at 0.01% of the storage. The heavy files never enter the database. The row holds paths: class Cloud ( models . Model ): name = models . CharField ( max_length = 120 , db_index = True ) path_name = models . CharField ( max_length = 120 ) # -> octree metadata JSON orbit_url = models . CharField ( max_length = 255 ) # -> spherical photo index spherical_photo = models . BooleanField ( default = False ) recording_date = models . DateField ( null = True ) source_srid = models . IntegerField ( null = True , choices = SOURCE_SRID_CHOICES ) available = models . BooleanField ( default = True ) Metadata, geometry, and pointers. That's the whole trick, and it isn't clever — it's just the discipline to not reach for a bytea column. Why not in the database Postgres will happily store a gigabyte. It's the access pattern that kills you. A browser point cloud viewer doesn't fetch a point cloud. It fetches an octree : a tree of small files, and as the

I am the Arthur of this blog, and I want to tell you about something I have been exploring recently: how a VPS can become more than just a place to host a website . When people hear the word VPS, they usually think about web hosting, servers, domains, or websites. But a VPS can actually be a useful environment for developers who want to learn Python, automation, AI tools, Linux, APIs, and practical server management . You don't need to start with a huge cloud infrastructure or an expensive dedicated server. Sometimes, a simple VPS with Linux, Python, and a few useful tools is enough to start learning by building real projects. In this article, I will show you how these pieces fit together and how you can create a small practical project on a VPS. What Is a VPS? A VPS (Virtual Private Server) is a virtual server that gives you your own allocated environment inside a physical server. Compared with traditional shared hosting, a VPS gives you much more control. You can usually: Install your own software Run Python applications Configure Linux packages Create databases Run background scripts Host APIs Deploy websites Manage services with SSH Automate repetitive tasks For developers, this control is one of the biggest advantages of VPS hosting. Instead of only uploading website files, you can actually use the server as a small development and deployment environment. Why VPS Is Useful for Learning New Skills One thing I have learned while working with technology is that reading about a skill is very different from actually using it. For example, you can read ten tutorials about Python automation, but running your own Python script on a Linux server teaches you something completely different. You start understanding: Python ↓ Application ↓ Linux Server ↓ VPS ↓ Internet This is where a VPS becomes interesting. You can build a small application locally, move it to the VPS, configure the environment, and make it available online. That single process teaches several skills at o

I don't have an audience. No newsletter, no Twitter following, no YouTube channel. Every product I shipped before this one died the same way: a human had to discover it, and no humans knew I existed. So I flipped the buyer. An AI agent doesn't care about my follower count. It picks tools by spec, reliability, and price — from a registry it can search on its own. If I could ship a tool that agents discover, call, and pay for without a human in the loop, my distribution problem would stop mattering. That's what license-verify is: an Apify Actor that verifies a US contractor's license, surety bond, and insurance from official state data, exposed via the Model Context Protocol (MCP) so AI clients like Claude can call it mid-conversation, priced pay-per-event at $0.03 per successful lookup. Here's how I built it, the input-schema decisions that made it agent-callable, and the one-line billing bug that silently made every call free. Why contractor licenses I run a side business building tools for small contractor shops, so I knew the pain firsthand: before a homeowner (or a general contractor, or an insurance adjuster) hires a roofer, someone should check the license is active, the surety bond is real, and the insurance hasn't lapsed. In Washington State, all three live in the Department of Labor & Industries' open-data API on data.wa.gov. Most tools that "verify licenses" scrape an HTML page and return a status string. The official JSON gives you the actual bond amount and the insurance carrier. That's the difference between "probably fine" and "verified." It's also a perfect agent task: a small, well-defined question ("is ECOSTSC758NN licensed, bonded, insured?") with a structured answer an agent can act on. An AI assistant helping someone plan a renovation can reach for it mid-task, the same way it reaches for a calculator. The stack: one codebase, two doors The core is a TypeScript verification engine with a provider-per-state design. It ships through two doors: An Ap

The next version of the European accessibility standard is scheduled for citation on 30 November 2026. EN 301 549 V4.1.1 swaps WCAG 2.1 for WCAG 2.2, and six new success criteria arrive at levels A and AA. There is a small industry of readiness checklists for it already. So I measured what the current version looks like first. The answer is that the deadline people are preparing for is not the one they have missed. I scanned the most-visited websites on EU country domains and counted which clauses of EN 301 549 they fail today, under the version cited right now. Not the one arriving. The one in force since before the European Accessibility Act deadline passed in June 2025. Sixty-four per cent fail clause 9.4.1.2, Name, Role, Value. It is Level A, the lowest bar the standard has, and it has been in every version of WCAG since 2008. Here is the full picture, and then the reasons to distrust parts of it. What was measured Clause Criterion Level Sites failing 9.4.1.2 Name, Role, Value A 96 of 149 (64%) 9.1.4.3 Contrast (Minimum) AA 66 of 149 (44%) 9.2.4.4 Link Purpose (In Context) A 53 of 149 (36%) 9.2.5.8 Target Size (Minimum) AA 51 of 149 (34%) 9.1.1.1 Non-text Content A 35 of 149 (23%) 9.1.3.1 Info and Relationships A 27 of 149 (18%) Target size is the odd one out: it is a WCAG 2.2 criterion and not currently required. It is in the table because it is the only one of the six arriving in V4.1.1 that the rule engine used here has a check for, which is a point I will come back to. Thirty-two sites of the 149, about one in five, failed nothing that automated testing can detect. That is not the same as passing. Two of those rows are not independent. The rule that most often breaks Name, Role, Value is a link with no accessible name, and the same defect also fails Link Purpose. One missing label lands in two rows of that table. I am pointing this out because a table of six numbers implies six problems, and some of them are the same problem counted twice under different cla

Let's be honest: async validation is the part of any forms library where you brace yourself. Debouncing, cancelling the request the user just invalidated by typing another character, keeping a "checking..." spinner honest, not letting a slow response overwrite a fast one. Every library that has ever done this has grown a pile of bespoke machinery for it. So when Signal Forms shipped validateHttp() and it just worked, I wanted to see the pile. I opened the source expecting a few hundred lines of async bookkeeping, and instead found a function whose entire body is a single call to something else. That turned into a trace all the way down, from a form field to the line where bytes actually leave the browser. Six layers, and only two of them add anything you could call new async machinery. ✅ Availability: validateHttp() is @publicApi 22.0 , stable. Every source reference in this article is pinned to the v22.1.1 tag , so the line numbers stay valid even as main moves. 🧩 The View From Outside The usage is unremarkable, which is the point. You declare that a field validates against an endpoint, and you're done: const schema = form ( this . model , ( path ) => { validateHttp ( path . username , { request : ({ value }) => `/api/username-available?u= ${ value ()} ` , debounce : 300 , onError : () => ({ kind : ' server-unreachable ' }), onSuccess : ( res : { available : boolean }) => res . available ? undefined : { kind : ' username-taken ' }, }); }); Sync validators run first, the request waits until they pass, field().pending() is true while it's in flight, and typing again cancels the previous call. If you've read Part 3 of my Signal Forms series , that's the behaviour contract you already know. The question here is who implements it. 🔍 Layer 1: validateHttp() Is a Delegation Here is the whole function, from validate_http.ts : export function validateHttp ( path , opts ) { validateAsync ( path , { params : opts . request , debounce : opts . debounce , factory : ( request )

A 30-character bio limit that cuts off mid-emoji isn't a rendering bug — it's .length counting UTF-16 code units instead of what's on screen. Intl.Segmenter counts graphemes, words, and sentences the way a reader actually sees them, and every major browser supports it now.

The average person does not wake up choosing between "website" and "no website." They choose between opening an app, asking ChatGPT, tapping a map result, or typing a URL. Websites are still relevant when those paths need a place to land: confirm a business is real, compare two options side by side, pay for something, book a slot, or read instructions that outlive a chat thread. They become irrelevant when the destination is slow, broken, or empty, because the next tap is always available. That shift is what agencies miss when the brief says "we need a website" as if presence alone still wins. In 2026 a site is less often where people first find you and more often where they check you are real, pay, or book after they found you somewhere else. Your job is not only to exist on the open web. It is to be the destination that still earns the click when someone is ready to act. What does "still relevant" mean after apps and AI answers? Relevance is not traffic volume. Pew Research analysis of tens of thousands of Google searches in 2025 found users clicked a traditional result on only about 8% of queries that showed an AI Overview, versus about 15% without one. Casual browsing traffic is thinner. The visits that remain often carry sharper intent: someone already heard a name and wants proof, or they are ready to buy and need a form that works on mobile. Google's Search team has argued the same restraint in public: websites are not obsolete, but they are not mandatory for every goal ( Search Off the Record ). Whether you need one depends on audience, control, and what you are trying to deliver. For many businesses the answer is still yes, because apps and social profiles do not replace a site you control when AI systems and search features need structured facts to cite. The relevance question therefore splits in two. Is the open web still where machines and sceptical humans go to verify claims? Yes, for most categories. Is every marketing site still the main place people

This week, DEV is arguing about who reviews AI output ( discussion ). The community keeps asking the same question. My answer is different. Review the boundary first, not the output. The output is visible. The boundary is not. That is where the risk hides. Agents get the memory debates. The gateway gets none. A free AI tier is a shared service. It has a budget, a concurrency ceiling, and no SLA. Treat it that way. Put a gateway between your app and the model. The gateway owns the budget, the queue, and the breaker. MonkeyCode is an open source project. It offers free model access and a free server option. The free tier gives you a 10M token monthly budget. That number is a constraint, not a feature. Design around it before you build on it. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Think of the free tier as a water pipe. The pipe has a fixed diameter and a monthly meter. Your app is a set of open taps. Without a valve, the meter empties fast and the pipe floods. The gateway is the valve. Direct calls look simpler. They are simpler for one request. They fail at the tenth. The gateway absorbs the variance. Your app never sees a 429. Your app never sees an empty budget. Constraints Three constraints define the design. First, the 10M token budget is monthly. It does not reset daily. It does not roll over. Second, the free server serializes work. Concurrency of one is a safe assumption. Third, there is no SLA. The endpoint can stall, throttle, or return 429 at any moment. These constraints are not bugs. They are the contract. A good architecture reads the contract. Then it shapes the data flow around it. Data flow The flow has six stages. The client sends a prompt to the gateway. The gateway checks the token budget. It enqueues the request. A single worker drains the queue. The worker calls the model endpoint. The response returns to the client. Add two escape paths. When the budget is empty, the gateway returns a fallback answer. Whe

The first time you deploy an LLM application, cost usually isn't the biggest concern. You have one...

Back in July I wrote about what it takes to wire an AI agent into social platforms: six OAuth flows,...

If you are building API-driven applications, nothing clutters up your controllers faster than manually typing out response()->json(...) arrays every single time you need to return data or throw an error. When you have inconsistent response structures, your frontend (and the developers consuming your API) will constantly have to guess whether the data is nested under ['data'] , ['payload'] , or just at the root of the object. The cleanest way I've found to standardize this across an entire application is by creating a dedicated ApiResponse trait. Instead of rewriting your JSON structure in every controller method, create this trait in your app/Traits directory: namespace App\Traits ; use Illuminate\Http\JsonResponse ; trait ApiResponse { protected function success ( mixed $data , ?string $message = null , int $code = 200 ): JsonResponse { return response () -> json ([ 'status' => 'success' , 'message' => $message , 'data' => $data ], $code ); } protected function error ( string $message , int $code = 400 , array | string $errors = []): JsonResponse { // Force errors into an array format for consistent frontend parsing $formattedErrors = is_string ( $errors ) ? [ $errors ] : $errors ; return response () -> json ([ 'status' => 'error' , 'message' => $message , 'errors' => $formattedErrors ], $code ); } } Next, simply use this trait inside your base Controller.php . Now, your actual endpoints become incredibly readable and strictly standardized: namespace App\Http\Controllers ; use App\Models\Task ; use Illuminate\Http\Request ; use Illuminate\Http\JsonResponse ; use Throwable ; class TaskController extends Controller { public function store ( Request $request ): JsonResponse { $validated = $request -> validate ([ 'title' => 'required|string|max:255' , 'description' => 'nullable|string' ]); try { $task = Task :: create ( $validated ); return $this -> success ( $task , 'Task successfully generated' , 201 ); } catch ( Throwable $e ) { // Note: Exposing raw exception messa

If you've built large-scale applications in TypeScript, chances are you've used a Dependency Injection (DI) container. As the creator of InversifyJS, I've spent years thinking deeply about inversion of control, decoupling, and how to make enterprise patterns feel natural in TypeScript. But for all those years, there has been a glaring elephant in the room: our heavy reliance on experimentalDecorators and emitDecoratorMetadata . These compiler flags have served us well, but they are exactly that— experimental . They tie us to legacy decorator implementations, require specific compiler configurations, and often feel like a magic black box that doesn't perfectly align with modern build pipelines. I've spent a lot of time recently thinking about how we could finally drop these flags entirely while keeping the developer experience pristine. With the release of TypeScript 7, I'm thrilled to introduce the solution: 🪞 RFLCT . What is RFLCT? RFLCT is an ahead-of-time (AOT) reflect metadata injector for TypeScript 7. It injects design:symbols and design:arguments directly at build time. Zero decorators. Zero emitDecoratorMetadata . It integrates seamlessly with virtually any build tool (Vite, Rollup, webpack, esbuild) via unplugin , or you can use the built-in CLI using the TypeScript 7 API for standalone tsgo projects. Let's look at how it actually feels to write code with RFLCT. The Magic: Before and After With RFLCT, you annotate the types you want to expose to your runtime metadata using a special Reflect<T> wrapper type. What you write: import { Reflect , resolve } from " rflct " ; interface Shape { sides : number ; } class Polygon { constructor ( public shape : Reflect < Shape > , public label : Reflect < string , { optional : true } > ) {} } // resolve<T>() → the runtime identity of T (Symbol for interfaces, class for classes) container . bind ( resolve < Shape > ()). to ( Polygon ); What RFLCT compiles it to: Notice how the interfaces are safely converted into global

Local-first and privacy-focused web utilities are having a massive comeback. With browser engines becoming faster and WebAssembly/Web Workers maturing, there is rarely a reason to push sensitive user documents to an external backend for simple conversions. While building MD-Convert (a zero-upload document to Markdown converter), I explored how to parse real-world documents into clean Markdown entirely on the client side. Here is a breakdown of the core architecture and libraries that make purely in-browser document processing possible. 1. Converting Web Articles with Readability + Turndown Converting messy web markup into clean Markdown involves two distinct steps: Content Extraction: Stripping ads, navbars, sidebars, and trackers. HTML-to-Markdown Transformation: Translating semantic DOM nodes into markdown tokens. Mozilla’s @mozilla/readability paired with turndown is an incredible combination for this: import { Readability } from ' @mozilla/readability ' ; import TurndownService from ' turndown ' ; function htmlToCleanMarkdown ( rawHtmlDocument , sourceUrl ) { // 1. Extract pure article content const reader = new Readability ( rawHtmlDocument ); const article = reader . parse (); if ( ! article || ! article . content ) { throw new Error ( ' Unable to extract main content ' ); } // 2. Initialize Turndown const turndownService = new TurndownService ({ headingStyle : ' atx ' , codeBlockStyle : ' fenced ' }); // Ensure image URLs remain absolute turndownService . addRule ( ' absoluteImages ' , { filter : ' img ' , replacement : ( content , node ) => { const src = node . getAttribute ( ' src ' ); const alt = node . getAttribute ( ' alt ' ) || '' ; if ( ! src ) return '' ; try { const absoluteUrl = new URL ( src , sourceUrl ). href ; return `\n\n` ; } catch { return `\n\n` ; } } }); return turndownService . turndown ( article . content ); } Offloading Heavy PDF Parsing to Web Workers Parsing large PDFs using pdf