标签：#dev

Few lines of code look more innocent than this: retry ( 3 ) It feels responsible. Professional. Resilient. After all, networks fail. Servers become unavailable. Databases occasionally time out. Retrying seems like the obvious solution. And sometimes it is. But after enough years building production systems, I've become convinced of something: Retry is one of the most dangerous keywords in software. Not because retries are bad. Because retries amplify everything. Good systems become more reliable. Bad systems become disasters. The problem is that many developers treat retries as a reliability feature when they're actually a distributed systems feature. And distributed systems are where simple ideas go to become complicated. Why Retries Exist Imagine: await fetch ( " /api/users " ); The request fails. Maybe: Network hiccup Temporary database issue Load balancer restart Service deployment The operation might succeed if attempted again. So we write: retry ( 3 ) Seems reasonable. And in many cases: It Works Which is why retries become popular. The Dangerous Assumption Most developers unconsciously assume: Failure = Operation Did Not Execute Unfortunately that's not always true. A request can: Execute Successfully ↓ Response Never Arrives From the client's perspective: Failure From the server's perspective: Success Now a retry becomes dangerous. The Double Payment Problem Imagine a payment service. await chargeCard ( order ); The card processor successfully charges: $100 The response is lost due to a network issue. Client sees: Request Failed and retries. await chargeCard ( order ); again. Now: Charge #1 = Success Charge #2 = Success The customer paid twice. Nobody wrote bad logic. The retry created the bug. The Email Storm Problem Consider: await sendWelcomeEmail ( user ); Email provider accepts the message. Response times out. Application retries. await sendWelcomeEmail ( user ); again. Customer receives: Welcome! Welcome! Welcome! Welcome! Support ticket created. Marke

I left a multi-agent refactor running overnight. By morning the model was gone, pulled out from under me by a government I don't even vote for, on the other side of an ocean. This isn't really a story about Anthropic. It's a story about who's actually holding the off-switch, and right now it probably isn't you. So here's how my morning went. I had a job running. Not a toy, a proper codebase-wide refactor that had been grinding away continuously for the best part of two days. Multi-agent setup, left to run overnight, the kind of long, messy, long-horizon task that every model before this one just fell over on. Claude Fable 5 was handling it like it was nothing. Anthropic's own launch notes talk about it compressing months of work into days, and honestly, on my own codebase, that wasn't marketing. It was just what was happening. Then I woke up. And the model was gone. Not rate-limited. Not having a wobble. Gone. The thing I'd built two days of momentum on simply did not exist any more. Turns out that on the 12th of June the US government issued an export-control directive telling Anthropic to cut off all access to Fable 5 and Mythos 5 for any foreign national. And because you can't exactly sort a global user base by passport in real time, that meant pulling it for everyone. Including me, sat in Tyrol, watching my overnight run go cold. Anthropic did the right things, for what it's worth. They complied fast, they said out loud that they disagreed, and they're fighting to get it back. About as well as a vendor can behave in that situation. (As I write this it's still down. Anthropic reckon it's a misunderstanding and they're trying to get it restored, so maybe by the time you read this it's back up. Doesn't change a single thing about the point I'm making.) And it made absolutely no difference to me. That, right there, is the whole point of this post. The offer was the trap Wind back a few days. Fable 5 dropped as the best model anyone had shipped, and the offer was lov

I was now done with the basic setup. However, during my time working at my startup, I have learnt to think about a project wearing multiple caps. One such aspect was - With Dhrishti running on a server that was already loaded, I did NOT want the tracking application itself to be heavy. I had to set some benchmarks to ensure that Dhrishti did not consume a tonne of space while tracking the metrics. I also had a problem with unresolved requests - in my mock_services, I had a client that was continuously hitting the API Gateway service. I had to fine-tune all the requests so that I could run tests under different loads, but the advantage was that my project was easily able to discern where the client request was coming from. However, in a production scenario, you can never know where a request is coming from - obviously, we cannot resolve different customer IPs to their respective customer names. This was the first problem. I had to specify what a customer was, and what an unknown request was. I came up with the following solution - Any unresolved IPs are going to be added to a table in the UI called unresolved IP table. This would help me with debugging later. Now, any unresolved IPs which also made requests to an ENTRY-POINT into my application could be added as the customers. For this, I very simply had to filter out the unknown IPs, and keep a configurable entry-point in dhrishti.json in which I would add a bunch of entry-points (in the case of my mock micro-service architecture, only 1) Now, I could differentiate between 2 types of unknown IPs - one which was potentially a customer, one which was a background network call, not important to the working system. The next problem was with the client service itself. It was difficult to simulate, say - a million users in my system. I had essentially built a service which was only being used by 1 customer, but how would Dhrishti behave if I added multiple client IPs? Using K6 k6 is a Grafana based application that helps

AWS recently announced CDK Mixins, a new AWS CDK feature that lets developers add reusable capabilities like security, monitoring, and configuration to AWS resources. Mixins work across different construct types, making infrastructure code more flexible and reusable. By Renato Losio

Everyone's debating whether coding is dead. I actually do this job.. with AI writing code beside me for most of my working hours. Here's what the headlines get wrong. Open your feed right now and you'll find the same headline in a dozen costumes: "Why AI will replace 80% of software engineers by 2026." "Is coding dead?" "Should you still learn to code?" It's the most-clicked anxiety in tech, and it's everywhere for a reason, it taps a real fear about real careers. But here's the thing about almost every one of those posts: they're written from the sidelines. Predictions about a job by people who don't do it. I'm writing this from the other side. I'm an engineer, and I drive AI coding agents every single day. They read code, write changes, run tests, and open reviews for most of my working hours. So when someone asks "should you still learn to code in 2026?" , I'm not guessing. Here's my honest answer: Yes. Absolutely. But the job you're learning for has quietly become a different job and almost nobody is telling you which one. The hype isn't entirely wrong Let me start by giving the doomers their due, because pretending the shift isn't real would make me exactly the kind of person I'm criticizing. The productivity jump is genuine, and it's not subtle. Industry surveys in 2026 put the share of new code that's AI-assisted somewhere north of 40%, and developers using these tools self-report double-digit speedups on routine work. That matches my experience. The agent now handles: Boilerplate and glue code —-> the stuff I used to type on autopilot, gone in seconds. First drafts —-> "scaffold something that does X" gets me 80% of the way instantly. Syntax recall —-> I stopped breaking focus to look up things I half-remember. Tedious refactors —-> rename-this-everywhere, migrate-this-pattern, done fast. and all the kludgy things that I dread to do. If your mental image of "coding" is typing syntax into an editor , then yes.. a big chunk of that is being automated. The vira

Google recently announced that WebMCP is entering origin trials in Chrome 149. The new WebMCP standard proposal lets sites expose tools (e.g., JavaScript functions and HTML forms) to in-browser AI agents, which can thus reliably simulate user actions instead of resorting to possibly expensive (e.g., on-screen reading) and often unreliable guesswork (e.g., DOM scraping). By Bruno Couriol

If your Magento store still depends on the old USPS Web Tools integration, you should assume your shipping rates are either already broken or one change away from breaking. That sounds dramatic, but it is the practical reality we have been seeing. USPS has moved away from the old Web Tools model and toward REST API v3 with OAuth 2.0 authentication. Magento's legacy USPS integration was built for a different era. For merchants, the symptom is simple: rates stop showing up, return inconsistently, or fail under conditions you did not use to worry about. For Magento developers, the reason is also simple: the built-in carrier module is not designed for the current USPS authentication and request model. This article explains what changed, why core Magento falls over here, how to migrate cleanly, and what to watch for whether you choose an extension or a custom build. What changed: USPS Web Tools is not the same platform anymore Historically, Magento's USPS integration talked to Web Tools-style USPS endpoints: structured shipping requests, legacy authentication, and XML responses. That is not the model USPS wants merchants using now. The modern USPS stack is based on: REST API v3 endpoints OAuth 2.0 for authentication Different request and response payloads Different onboarding and credential management patterns That shift matters because it is not just a URL update. It changes authentication, token handling, and request structure. In practical terms, a migration now means: Getting the right USPS developer credentials Exchanging those credentials for OAuth access tokens Updating the carrier request layer to use REST payloads Mapping the new response format back into Magento shipping methods If you skip any of that and try to "patch" the old module with endpoint changes, you are going to waste time. Why Magento 2's built-in USPS module no longer works Magento's built-in USPS module was not architected around OAuth-backed REST API calls. It expects a legacy carrier contract

A couple of years ago, I built a custom flashcard app. I had a huge list of words and sentences in Japanese that I collected in an Excel file. I wanted an app that could easily take them and display them on flashcards. The flashcard app was useful, but the main issue was that I could only use it on my laptop. This meant that when I wasn't home, I had no access to it. I made some updates so that I could deploy it to Azure and now I can use it on the train or at the park. I wanted to share the app and lessons learned during development. What It Does The app is a straightforward spaced repetition flashcard tool. You create collections, fill them with cards (front/back/optional notes), and review them. After each card you rate your recall: Button Meaning Easy Remembered without effort Good Remembered correctly Hard Remembered with difficulty Again Forgot (resets to day 1) Ratings feed the SM-2 algorithm, which is the same algorithm as other popular spaced repetition apps like Anki. Cards that are easy get pushed further and further into the future. Cards that are difficult will come back sooner. After a while, you're just reviewing what you actually need to review. There's also a 45-second timer per card. If it expires before you complete the card, it automatically counts as Again (Resets to day 1). Before the timer, I found it easy to lose focus or open another tab and forget about the current card. This has helped me stay focused for longer and stay on this task. The CSS is specifically designed to be mobile friendly. The Tech Stack Frontend: Blazor WebAssembly (.NET 10) Backend: ASP.NET Core minimal API (.NET 10) Database: Azure SQL (Basic DTU tier) Hosting: Azure Static Web Apps (frontend) + Azure App Service F1 free tier (backend) I mostly use C# at work, so Blazor WASM was a natural fit. The whole app shares models and flows together without jumping between languages. Importing Cards from Excel This Excel import function is one of the main reasons I made this app.

We've been a Magento agency in Chicago since 2008. When Hyvä Themes hit the ecosystem, we were skeptical—another theme promise. Then we measured Core Web Vitals on client stores and the case became obvious: Hyvä is the most practical path to a fast Magento storefront without a full replatform. This is the migration framework we use at Towering Media for US and Canadian merchants moving off Luma (or aged custom frontends) onto Hyvä. Why Hyvä now (not next year) Google's CWV thresholds affect ad quality and organic visibility. Luma checkout and catalog pages often ship 1.5–2+ MB of JavaScript before you add analytics, chat, and personalization. Hyvä replaces Knockout/RequireJS on the storefront with Alpine.js and Tailwind. Typical results on our projects: 50–70% less frontend JS on category and product pages LCP improvements of 1–3 seconds on mobile field data (highly variable by hosting and images) Lower maintenance — fewer JS conflicts between theme and extensions Delaying migration means paying for performance twice: once in emergency fixes, again in the eventual theme project. Phase 1: Discovery (1–2 weeks) Extension audit List every module that touches the frontend: bin/magento module:status | grep -v "Module is disabled" Flag anything with view/frontend , RequireJS , or Knockout in: Layered navigation and search Checkout and cart Page Builder widgets Blog and CMS enhancements Hyvä maintains a compatibility module ecosystem; unsupported extensions need replacements or custom Hyvä templates. Towering Media includes extension compatibility mapping in every Hyvä migration engagement. CWV baseline Capture before metrics from: Google PageSpeed Insights (origin-level) Chrome UX Report for key templates: home, category, product, cart Real-user monitoring if the client has it (GA4, SpeedCurve, etc.) Store screenshots. Stakeholders forget how slow the old site felt. Business constraints Document: Peak seasons (do not launch in November without war room

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion. After 7 Tauri apps, I type the same commands constantly. Here's the reference I wish existed when I started. Project setup # New project npm create tauri-app@latest # Add to existing project npm install --save-dev @tauri-apps/cli npx tauri init Development # Dev mode (hot reload) npm run tauri dev # Dev with specific log level RUST_LOG = debug npm run tauri dev # Dev with backend logs visible npm run tauri dev 2>&1 | grep -v "^$" Building # Standard build npm run tauri build # Universal binary (Intel + Apple Silicon) npm run tauri build -- --target universal-apple-darwin # Debug build (faster, no optimization) npm run tauri build -- --debug Plugins npm run tauri add global-shortcut npm run tauri add fs npm run tauri add shell npm run tauri add notification This updates both Cargo.toml and the plugin registration. Faster than doing it manually. Permissions (tauri.conf.json) { "app" : { "security" : { "capabilities" : [ { "identifier" : "main-capability" , "description" : "Main window capabilities" , "windows" : [ "main" ], "permissions" : [ "fs:read-all" , "fs:write-all" , "shell:execute" , "global-shortcut:allow-register" ] } ] } } } Tauri v2 requires explicit permission declarations. If a command silently does nothing, check permissions first. Common Rust patterns // Get app data directory let data_dir = app .path () .app_data_dir () .unwrap (); // Emit event to frontend app_handle .emit ( "event-name" , payload ) .ok (); // Get window let window = app .get_webview_window ( "main" ) .unwrap (); // App state app .manage ( MyState :: new ()); let state = app .state :: < MyState > (); Notarization (macOS) # Submit for notarization xcrun notarytool submit app.dmg \ --apple-id YOUR_APPLE_ID \ --team-id YOUR_TEAM_ID \ --password YOUR_APP_PASSWORD \ --wait # Staple after notarization xcrun stapler staple app.dmg Debugging # Check what's in the bundle

I have been frustrated with YouTube for a while. Not the content, but the everything around it. The homepage full of bait, the auto-play into things I didn't ask for, the Shorts that hijack your scroll, the recommendations that somehow know exactly what will keep you there longest. So I built NoSuggest. What it is A YouTube feed reader that shows you only the channels you follow, nothing else. No algorithm, no recommendations, no Shorts, no homepage, no auto-play, no endless side cards of videos. You add a channel, it fetches their latest videos, done. It lives at nosuggest.com and installs as a PWA on any device — iPhone, Android, desktop — straight from the browser. No app store. The interesting technical constraint: one HTML file The entire app is a single index.html. No account setup, no sign-in, no data collection. Everything that needs to persist — your channel list, saved videos, settings — lives in localStorage. No search history. No watch history. No "you might also like." No trending section. No notification badges designed to create anxiety. No dark patterns anywhere. Every time I was tempted to add something convenient, I asked: does this serve the user's intention, or does it serve engagement? If it was the latter, it didn't make the cut. Try it nosuggest.com — Source Available here , free forever. Curious what others think about this as useful. Thank you.

Originally written for bulldo.gs — republished here with the canonical link pointing home. I'm running a script that processes a large spreadsheet and it keeps dying with "Exceeded maximum execution time" before it finishes. // Checkpoint-resume pattern for long-running sheet jobs function processInBatches () { var props = PropertiesService . getScriptProperties (); var startRow = parseInt ( props . getProperty ( ' lastRow ' ) || ' 2 ' , 10 ); var sheet = SpreadsheetApp . getActiveSpreadsheet (). getActiveSheet (); var lastDataRow = sheet . getLastRow (); var BATCH = 200 ; var SAFE_MS = 5 * 60 * 1000 ; var started = Date . now (); var endRow = Math . min ( startRow + BATCH - 1 , lastDataRow ); var data = sheet . getRange ( startRow , 1 , endRow - startRow + 1 , 5 ). getValues (); for ( var i = 0 ; i < data . length ; i ++ ) { if ( Date . now () - started > SAFE_MS ) { props . setProperty ( ' lastRow ' , String ( startRow + i )); return ; } // process data[i] here } if ( endRow >= lastDataRow ) { props . deleteProperty ( ' lastRow ' ); deleteTrigger_ (); } else { props . setProperty ( ' lastRow ' , String ( endRow + 1 )); } } The 6-minute wall is per-execution, not per-task Apps Script enforces a hard 6-minute execution time limit per run, regardless of whether you're on a free account or a Workspace account (which bumps the limit to 30 minutes, but the same cliff exists). The error doesn't mean your logic is wrong; it means one continuous call to your function took too long. The fix is to stop thinking of your job as a single execution and start thinking of it as a pipeline of short runs. The first time I hit this, I wasted an afternoon trying to speed up the loop. Marginal gains didn't move the needle because the data volume was the real problem — 4,000 rows at one Sheets API call per row will always breach 6 minutes. The correct frame is: how do I save where I stopped and pick up there next run? Saving and restoring a cursor with PropertiesService PropertiesServic

Coding agents are no longer just autocomplete with a longer prompt. GitHub describes Copilot cloud agent as software that can research a repository, create an implementation plan, make code changes on a branch, run in an ephemeral GitHub Actions-powered environment, and let a developer review or create a pull request afterward. OpenAI's Codex GitHub integration similarly positions code review as a repository-aware review pass that follows AGENTS.md guidance and focuses comments on serious issues. That shift changes the buyer question. The useful question is not "does the agent usually write code?" It is "can the team detect when the agent drifts away from the developer's intent before the change reaches production?" A May 2026 arXiv paper, "How Coding Agents Fail Their Users" , gives teams a better vocabulary for that review. The authors studied 20,574 real IDE and CLI coding-agent sessions across 1,639 repositories and define misalignment as a breakdown that becomes visible through developer correction or pushback. The paper reports seven recurring symptom categories: wrong project diagnosis, misread developer intent, developer constraint violation, self-initiated overreach, faulty implementation, operational execution error, and inaccurate self-reporting. Effloow Lab also ran a bounded OpenAI API check using three synthetic, non-confidential coding-agent transcript snippets. The run did not measure real-world incidence, compare vendors, or reproduce the paper. It produced a small rubric that maps visible symptoms to review gates such as diff-scope checks, evidence-before-edit checks, acceptance-criteria coverage, and verification-output requirements. The public lab note is available at /lab-runs/coding-agent-misalignment-failure-taxonomy-poc-2026 . This guide turns that research and lab output into a practical QA checklist for teams buying, piloting, or packaging coding-agent workflows. Why This Matters for Agent Buyers Coding-agent procurement often starts with p

Hey tech family! 👋 If you’ve noticed your favorite Chrome extensions acting a bit differently lately or if you're a developer currently sweating over a massive codebase rewrite you are experiencing the era of Manifest V3 (MV3) . 🤖 Google has officially pushed the web ecosystem forward by deprecating Manifest V2, making MV3 the absolute standard for how browser extensions behave. But why is this happening, what actually changed, and why is the internet so divided over it? Let’s break it all down in plain English! 👇 🧐 What Exactly is Manifest V3? Think of a "Manifest" as the blueprint file ( manifest.json ) that tells the browser exactly what an extension is, what files it uses, and what permissions it needs to run. Manifest V3 is Google's major architectural overhaul of this system. Its core mission sounds great on paper: improve user privacy, beef up security, and boost browser performance . However, achieving those goals meant rewriting the core rules of how extensions interact with your browser. 🛠️ The Biggest Changes & New Features MV3 isn't just a small patch; it fundamentally alters the underlying extension engine. Here are the headline shifts: Goodbye Background Pages, Hello Service Workers! 💤 In MV2, extensions used hidden, persistent background pages that ran 24/7, hogging your computer's RAM even when you weren't using them. MV3 replaces these with Service Workers. They are event-driven meaning they wake up, execute a task (like clicking an extension icon), and go right back to sleep. Hello, free RAM! 🐏 The Ad-Blocker Shakeup: webRequest vs. declarativeNetRequest 🛑 This is the most controversial change. In MV2, powerful extensions like uBlock Origin used the webRequest API to intercept, read, and block network requests in real-time using complex code. MV3 replaces the blocking version of this with declarativeNetRequest . Instead of letting the extension intercept the data, the extension must now hand Chrome a pre-defined list of rules, and Chrome does the b

The first message ever sent across the network that became the internet was not "Hello, world." It was not a grand declaration. It was two letters, transmitted by accident, before the system fell over: LO . That two-letter packet is the ancestor of every connected device, every IoT sensor, and every web request running today. The story of how it happened is also a surprisingly useful lesson for anyone building embedded systems and connected hardware right now. What actually happened on October 29, 1969 On the evening of October 29, 1969, a programmer named Charley Kline sat at a terminal in Leonard Kleinrock's lab at UCLA. His job was simple on paper: log in to a remote computer at the Stanford Research Institute (SRI), roughly 350 miles away, over a brand-new experimental network called ARPANET. The plan was to type the command LOGIN . The remote machine at SRI was set up to auto-complete the rest once it saw the first few characters, so Kline only needed to start typing. He had a colleague on the phone at the Stanford end to confirm each letter arrived. He typed L . Stanford confirmed: "Got the L." He typed O . Stanford confirmed: "Got the O." He typed G - and the SRI system crashed. So the first message ever transmitted over ARPANET was "LO." As Kleinrock later liked to point out, it was an accidental but fitting first word: "LO" as in "lo and behold." About an hour later they fixed the bug and completed the full login, but the historic first packet had already gone out, two letters at a time. Why a crash is the perfect origin story It is tempting to read this as a cute footnote. It is more than that. The very first thing the internet ever did was fail partway through a transaction - and the system was built well enough that the humans on both ends knew exactly how far it had gotten before it died. That is the entire discipline of networked systems in miniature. Connections drop. Remote machines crash mid-request. Packets arrive out of order, or not at all. The n

What I built A small business owner needed an automated customer support system that works 24/7, answering questions based only on their internal policies – no hallucinations, no outside internet knowledge. They also wanted multilingual support (English, French, Spanish) and a natural AI voice introduction. I built the AI Customer Service Suite to solve this exactly. Key features Answers questions strictly from uploaded documents (PDF, DOCX, TXT) – no generic AI guessing Multilingual chat interface (English, French, Spanish) Female AI voice introduction that explains the software and pricing Security badge and Stripe payment link for licensing Optional Twilio integration for WhatsApp and voice calls Full source code delivered Tech stack Python Streamlit Groq Llama 3.1 (RAG) edge‑tts for voice Twilio API (optional) Live demo https://ai-customer-service-suite-bemey6yywchvkz7yrghufc.streamlit.app/ What we do at GlobalInternet.py We provide tailored software solutions that connect the global market with local expertise. We build custom AI‑powered applications, business tools, and automation systems – delivered fast with full source code. Contact us Phone: (509) 4738 5663 Email: deslandes78@gmail.com Website: https://globalinternetsitepy-abh7v6tnmskxxnuplrdcgk.streamlit.app/ What's next I am adding more language options and a live dashboard for businesses to track support questions and user satisfaction. Feedback welcome Try the live demo, break it, ask it questions. I would love to hear your suggestions or feature requests. Comment below or reach out via my website. #python, #streamlit, #chatbot, #ai, #customercare

When you build Shopify apps or integrations, pagination becomes important very quickly. A small test store may have a few products and orders. A real merchant store can have thousands of products, variants, orders, customers, inventory items, metafields, and fulfillment records. You cannot fetch all of that data in one Shopify GraphQL request. You need pagination. More importantly, you need pagination that performs well. Poor Shopify GraphQL pagination can create slow syncs, API throttling, timeout errors, duplicate processing, and incomplete exports. This post explains how Shopify GraphQL pagination works and how to handle large Shopify datasets in a practical way. What Shopify GraphQL Pagination Solves Pagination lets your app retrieve data in smaller chunks. Instead of asking Shopify for 50,000 products at once, your app asks for 100 or 250 products per request. Shopify returns the data and gives your app information about the next page. This protects your app from huge responses and protects Shopify from heavy requests. It also gives your integration more control over retries, progress tracking, and background processing. Shopify Uses Cursor-Based Pagination Shopify GraphQL uses cursor-based pagination. That means you do not request data using page numbers. You request the next page using a cursor from the previous response. A basic product pagination query looks like this: query GetProducts ( $cursor : String ) { products ( first : 100 , after : $cursor ) { nodes { id title handle updatedAt } pageInfo { hasNextPage endCursor } } } The first time you run this query, pass cursor as null. Shopify returns the first 100 products and gives you an endCursor . Use that endCursor as the after value in the next request. Keep doing this until hasNextPage is false. Why Cursors Work Better Than Page Numbers Offset pagination usually works like this: page=1 page=2 page=3 or: offset=5000&limit=100 This approach becomes inefficient when datasets grow. The system may need to sk

JSON and GraphQL dominate modern web development, but XML (eXtensible Markup Language) is far from obsolete. Enterprise integrations, legacy systems, healthcare standards, and financial protocols still rely heavily on XML. If you work across diverse stacks, understanding XML is a skill that pays dividends. This guide covers the core syntax, validation techniques, parsing approaches, and best practices - with code you can put to work right away. Why XML Still Matters in 2026 XML has been around since 1996 and continues to thrive in specific domains. It handles deeply nested hierarchical data well, supports robust native schema validation, and manages mixed document-oriented content better than most alternatives. If you're dealing with SOAP APIs, Android layouts, SVG, DOCX/XLSX files, HL7 healthcare records, or FIX financial protocols, you're already in XML territory. The Core Building Blocks of an XML Document At its core, XML is a tree of nodes serialized as text. Every well-formed document starts with a declaration that tells the parser the version and character encoding - UTF-8 is the standard choice. From there, the document is composed of nested elements, attributes, and optionally text content. Elements - The Tree Nodes Elements are the primary structural unit in XML. They wrap your data in opening and closing tags. XML is case-sensitive, so a tag and a tag are treated as two completely different elements. Every opened element must have a corresponding closing tag to keep the document well-formed. Attributes - Metadata on Elements Attributes sit inside an opening tag and carry metadata about the element rather than the primary data itself. A good rule of thumb: use attributes for identifiers, types, or units (like currency), and use child elements for the actual payload data. This separation keeps your parsers predictable and your document structure clean. Self-Closing Elements When an element has no content or child nodes, you can collapse the open and close t

A decision memo for anyone staring at their package.json and wondering. Most arguments for leaving your SPA framework center on the upgrade treadmill — the endless cycle of major-version migrations, dependency churn, and build-tool turnover. That argument is real but incomplete, and on its own it has never been decisive: every framework shop has learned to live with the treadmill. There's a stronger case, built on four pillars that compound with each other. First, total cost of ownership : vanilla JavaScript on the web platform has unusual TCO properties, dominated by a depreciation curve that is nearly flat. Code written against the platform does not rot, because its substrate does not change. Over long horizons, this single property outweighs almost every per-feature productivity argument in a framework's favor. Second, the labor market : the pool of people who can work on vanilla JavaScript is not a niche within the frontend market — it is the entire frontend market, plus most of the backend market. Every framework developer is, underneath, a JavaScript developer. The reverse is not true. If you hire for a specific framework, you're hiring from a subset while telling yourself you're hiring from the mainstream. Third, AI leverage : engineers now produce a growing share of code with AI assistance, and the economics of that assistance differ sharply by target. The web platform is a small, stable, exhaustively documented body of knowledge; a framework ecosystem is a large, fast-mutating one whose training data is perpetually stale. AI coding tools are measurably more reliable on the former. As AI-assisted development becomes the dominant mode of production, the substrate that AI handles best becomes the cheaper substrate — and the gap widens every year the platform stays still while frameworks move. Fourth, architecture : porting to Web Components is not a transliteration of the same design into different syntax. The platform pushes toward a genuinely different archi

TL;DR: HTML-first means shipping real, server-rendered content before any JavaScript runs, then adding scripts only where they earn their place. In 2026 this approach is winning again, not out of nostalgia, but because the median mobile page now ships around 646 KB of JavaScript, fewer than half of mobile sites pass Core Web Vitals, and the browser already does natively what many sites still pull in libraries for. For most business websites, progressive enhancement is faster to ship, cheaper to run, and easier to keep alive. Sometime in 2026, "just use HTML" stopped being a contrarian take. I noticed it first in my own client work, not in a conference talk. The sites that start close to the platform, plain HTML, forms, links, server rendering, and add JavaScript only where it genuinely helps, are the ones that launch faster, load cleaner, and generate fewer confused support messages two months later. This is not anti-JavaScript. It is a reaction to a decade of reaching for a framework before asking whether the project needed one. The pendulum is swinging back toward the browser, and the numbers explain why. What HTML-first actually means (and why it is not 2009 web design) The fastest way to misunderstand this is to picture table layouts and inline styles. That is not it. HTML-first is an order of operations. You build a page that is complete and usable as server-rendered HTML, then you enhance it. The content is readable before a single script loads. The form submits even if JavaScript never arrives. This is the old idea of progressive enhancement , applied deliberately with modern tools instead of by accident. There is a small but real movement around this now. The HTML First community manifesto argues, fairly, that the platform has far more capability than most teams use. You do not have to agree with every line of it to notice the shift. The point is not to ban JavaScript. The point is to stop treating it as the default starting material for every page. The 2026