标签：#JavaScript

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 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 want to enable the V8 runtime on an existing Apps Script project so I can use modern JavaScript, but I am worried about breaking things that are already working. // appsscript.json — set runtimeVersion to enable V8 // Rollback: change V8 back to DEPRECATED_ES5 { " timeZone " : " America/New_York " , " dependencies " : {}, " exceptionLogging " : " STACKDRIVER " , " runtimeVersion " : " V8 " } // Code.gs — safe V8-compatible replacement for a common Rhino pattern // Rhino allowed: for each (var item in collection) {} // V8 requires standard for...of instead function listSheetNames () { var ss = SpreadsheetApp . getActiveSpreadsheet (); var names = []; var sheets = ss . getSheets (); for ( var i = 0 ; i < sheets . length ; i ++ ) { names . push ( sheets [ i ]. getName ()); } Logger . log ( names . join ( ' , ' )); } The one-line change and why it is a project-wide bomb Open the Apps Script editor, click Project Settings (the gear icon), and check "Show appsscript.json manifest file in editor." Then open that file and change "runtimeVersion": "DEPRECATED_ES5" to "runtimeVersion": "V8" . Save. That is the entire migration from a settings standpoint. What catches people off guard is the failure mode. V8 parses every .gs file in the project as a unit before running anything. One Rhino-only statement — a for each loop, a __iterator__ method, a Date.prototype.getYear call in an otherwise untouched utility file — causes a syntax or runtime error that prevents the whole script from initializing. Not just the file that contains the bad line. Every function, every trigger, the entire project goes dark. The first time I hit this it took me twenty minutes to figure out why a completely unrelated trigger had stopped firing. The error message pointed at the Rhino syntax in a helper file I had not touched in two years. V8 does not isolate the damage; it fails at parse time, before any executi

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

Originally written for bulldo.gs — republished here with the canonical link pointing home. I want to programmatically combine several Google Docs into one file without losing tables or list formatting. // Merges all source docs into destDocId, in order. // Run from the Apps Script editor; no triggers needed. function mergeDocs () { var sourceIds = [ ' DOC_ID_ONE ' , ' DOC_ID_TWO ' , ' DOC_ID_THREE ' ]; var dest = DocumentApp . openById ( ' DEST_DOC_ID ' ). getBody (); for ( var i = 0 ; i < sourceIds . length ; i ++ ) { var srcBody = DocumentApp . openById ( sourceIds [ i ]). getBody (); var total = srcBody . getNumChildren (); for ( var j = 0 ; j < total ; j ++ ) { var el = srcBody . getChild ( j ); var type = el . getType (); if ( type === DocumentApp . ElementType . PARAGRAPH ) { dest . appendParagraph ( el . asParagraph (). copy ()); } else if ( type === DocumentApp . ElementType . TABLE ) { dest . appendTable ( el . asTable (). copy ()); } else if ( type === DocumentApp . ElementType . LIST_ITEM ) { dest . appendListItem ( el . asListItem (). copy ()); } } } } Why there is no single appendElement call The Document service in Apps Script does not expose a generic appendElement method on Body . Every element type has its own typed append method: appendParagraph , appendTable , appendListItem , and so on. That means a merge loop that ignores element types will throw TypeError: el.copy is not a function the moment it hits a table, because you would be passing an Element where the API expects a Table . The fix is to call getType() on each child element and switch on DocumentApp.ElementType . The type enum values are strings like PARAGRAPH , TABLE , LIST_ITEM , INLINE_IMAGE , and HORIZONTAL_RULE . In practice the first three account for almost all real document content. The code above handles those three and silently skips anything else (images, rules) rather than crashing the entire merge. Getting the doc IDs and running the script The ID for any Google Doc is the lo

Originally written for bulldo.gs — republished here with the canonical link pointing home. I want to pull live JSON data from an API endpoint directly into a Google Sheet without installing an add-on. // Fetch JSON from an API and write it to the active sheet // Adjust API_URL and the field list to match your endpoint function importJsonFromApi () { var API_URL = ' https://jsonplaceholder.typicode.com/users ' ; var sheet = SpreadsheetApp . getActiveSpreadsheet (). getActiveSheet (); var response = UrlFetchApp . fetch ( API_URL ); var raw = response . getContentText (); var data = JSON . parse ( raw ); var headers = [ ' id ' , ' name ' , ' username ' , ' email ' , ' phone ' ]; var rows = data . map ( function ( obj ) { return headers . map ( function ( key ) { return obj [ key ] || '' ; }); }); sheet . clearContents (); sheet . getRange ( 1 , 1 , 1 , headers . length ). setValues ([ headers ]); sheet . getRange ( 2 , 1 , rows . length , headers . length ). setValues ( rows ); } Why getContentText() comes before JSON.parse UrlFetchApp.fetch() returns an HTTPResponse object, not a string. The first time I skipped getContentText() and passed the response object directly to JSON.parse(), it silently parsed to null and the sheet wrote nothing. You need raw = response.getContentText() to get the actual body as a string, then JSON.parse(raw) turns it into a JavaScript object or array. The URL must be publicly accessible or accept an API key via a query parameter or Authorization header. Add headers like this: UrlFetchApp.fetch(url, { headers: { Authorization: 'Bearer ' + token } }). Apps Script's UrlFetchApp quota is 20,000 calls per day on a free Google account, 100,000 on Workspace. The rectangular array constraint — why setValues fails without mapping setValues() is strict: it requires a 2D array where every row has the same number of columns. If you hand it an array of plain JSON objects, it throws 'The number of rows or columns in the range does not match the number of

Originally written for bulldo.gs — republished here with the canonical link pointing home. I have a spreadsheet of names and email addresses and I want to send each person a personalized message from my Gmail account without copy-pasting or using a paid tool. // Mail merge: Sheet cols A=Name, B=Email, C=Sent // Run from Apps Script; authorize Gmail + Sheets scopes function sendMerge () { var sheet = SpreadsheetApp . getActiveSheet (); var rows = sheet . getDataRange (). getValues (); var quota = MailApp . getRemainingDailyQuota (); var sent = 0 ; for ( var i = 1 ; i < rows . length ; i ++ ) { if ( rows [ i ][ 2 ] === ' Sent ' ) continue ; if ( sent >= quota ) { Logger . log ( ' Quota reached at row ' + ( i + 1 )); break ; } var name = rows [ i ][ 0 ]; var email = rows [ i ][ 1 ]; var subject = ' Hey ' + name + ' , here is your update ' ; var body = ' Hi ' + name + ' , \n\n Your personalized content goes here. \n\n Thanks ' ; MailApp . sendEmail ( email , subject , body ); sheet . getRange ( i + 1 , 3 ). setValue ( ' Sent ' ); sent ++ ; } } Set up your sheet and open the script editor Put names in column A, email addresses in column B, and leave column C blank — the script writes 'Sent' there as it goes. Header row in row 1 is assumed; the loop starts at index 1 (row 2) to skip it. Open the script editor from Extensions > Apps Script, paste the function, and save. The first time you run sendMerge() Google will ask you to authorize two scopes: Sheets (read/write the active spreadsheet) and Gmail (send mail on your behalf). Both are required. If you only see a Sheets prompt, delete the file and re-paste — a cached partial authorization sometimes skips the Gmail scope on older script files. Why the Sent column is the whole point Consumer Google accounts cap at roughly 100 outgoing recipients per 24-hour rolling window via MailApp. If your list has 200 rows and you run the script at 11 pm, it will send 100 and log 'Quota reached at row 101'. Without the Sent check, a sec

Originally written for bulldo.gs — republished here with the canonical link pointing home. I have a Google Sheet with duplicate rows and I want to remove them programmatically, either on demand or on a schedule, without destroying the rest of my data. // removeDuplicates.gs — dedup active sheet, keep first occurrence // Run from Extensions > Apps Script, or bind to a trigger. function removeDuplicateRows () { var sheet = SpreadsheetApp . getActiveSheet (); var data = sheet . getDataRange (). getValues (); var seen = new Set (); var unique = []; for ( var i = 0 ; i < data . length ; i ++ ) { var key = data [ i ]. join ( ' | ' ); if ( ! seen . has ( key )) { seen . add ( key ); unique . push ( data [ i ]); } } sheet . clearContents (); sheet . getRange ( 1 , 1 , unique . length , unique [ 0 ]. length ). setValues ( unique ); } Why rewrite instead of delete The instinct when deduplicating is to loop through the sheet and call deleteRow on each duplicate. That works, but it has a sharp edge: every call to deleteRow shifts all rows below it up by one. If you delete row 3, what was row 4 is now row 3, and your loop index is already pointing at the new row 4. The safe workaround people reach for is iterating bottom-to-top, which works but means holding the full duplicate set in memory anyway, making one API call per deleted row. The approach here sidesteps the problem entirely. Read everything once with getDataRange().getValues() — a single API call that returns a 2D array. Build the deduplicated array in JavaScript using a Set to track which row fingerprints you have already seen. Then clear the sheet and write the result back with one setValues call. Two API calls total, regardless of how many duplicates you had. For a 10,000-row sheet, this is the difference between a script that finishes in two seconds and one that times out at the six-minute Apps Script execution limit. The row key is built with data[i].join('|'). The pipe character works as a separator in practice; i

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

GitHub热门项目 | ✯ 可直连访问的电视/广播图标库与相关工具项目 ✯ 🔕 永久免费 直连访问 完整开源 不断完善的台标 支持IPv4/IPv6双栈访问 🔕 | Stars: 28,119 | 11 stars today | 语言: JavaScript

GitHub热门项目 | Setup and manage header bidding advertising partners without writing code or confusing line items. Prebid.js is open source and free. | Stars: 1,581 | 0 stars today | 语言: JavaScript

GitHub热门项目 | Datadog APM client for Node.js | Stars: 813 | 0 stars today | 语言: JavaScript

GitHub热门项目 | CRS-自建Claude Code镜像，一站式开源中转服务，让 Claude、OpenAI、Gemini、Droid 订阅统一接入，支持拼车共享，更高效分摊成本，原生工具无缝使用。 | Stars: 12,064 | 12 stars today | 语言: JavaScript

GitHub热门项目 | An open-source JavaScript library for world-class 3D globes and maps 🌎 | Stars: 15,367 | 2 stars today | 语言: JavaScript

GitHub热门项目 | 一分钟搭建影视站，支持Vercel/Docker等部署方式 | Stars: 13,698 | 9 stars today | 语言: JavaScript

Google's Angular team has released a repository called angular/skills, focusing on Agent Skills that enhance AI coding agents' ability to write modern Angular code. The repository includes skills for generating code and scaffolding applications, reinforcing current Angular conventions. It serves as a snapshot, aiming to improve AI suggestions by providing updated context. By Daniel Curtis

TL;DR: A LinkedIn outreach pipeline is a background worker that signs in with your own session, opens profiles, sends connection requests and messages on a schedule you control, and can post content straight to your feed. The hard was staying invisible to LinkedIn's detection. We got to our nineteenth build in about two weeks. Along the way, the session kept dying after three profiles (a device fingerprint mismatch), the stealth layer turned out to be detectable on its own, an authenticated proxy refused to connect, and Chrome froze in ways no timeout caught. This is every failure and the fix that finally held. We built a LinkedIn marketing pipeline inside Ozigi because our own go-to-market runs on it. I didn't just want it to be another tool; I needed it to send real messages to real people without getting my personal account flagged. The very first version we built worked for sourcing and reaching three leads, then the session died. The second version got past that and froze instead. This pattern repeated for two weeks and led us from building v1 of our LinkedIn worker to the current version 26. This article is like a cleaned-up version of our build log for educational purposes. If you are trying to reach people on LinkedIn from code, you will hit most of these walls in roughly this order. I will name the exact failure each time, because "it stopped working" helped me precisely never. What Does a LinkedIn Outreach Pipeline Actually Do? A complete LinkedIn outreach pipeline does four jobs: It signs in with your session cookie so LinkedIn sees you, not a script. It opens a lead's profile. It sends a connection request or a message, depending on whether you are already a first-degree connection. And it can publish a post to your feed. The first three are outreach. The fourth is content. They share the same infrastructure, which matters later. None of these look overly complicated logic. You click a button, type into a box, press send. But the reason this turned into

A few days ago, I shared an article: You Don't Need Another Agent. You Need a Linter. Then I did what I do with anything I write: shared it around — a few publications, a few channels. Two reasons: First, feedback. I'd genuinely rather get roasted and fix my blind spots than stay comfortable and wrong. Second, let's be honest: reach. Every writer enjoys seeing a few more views. Most of the responses were positive. One wasn't. A publication rejected it with the reason: LOW_QUALITY Fair enough. It means there's room for improvement. Funny enough, my caffeinated 1 AM brain disagreed. Then it did what every developer does when someone says "this isn't good enough." It took that personally. So I went back and reread the article. And after the initial ego check, I realized something serious: The article talked in detail about ESLint, why it matters more in an AI-assisted world than ever. What it did not do was answer the question that actually matters: What is ESLint, how does it work, and why has half the JavaScript ecosystem quietly built its quality process around it? So let's fix that. Now, this isn't a sequel to my last piece about untangling vibe-coded code. It stands on its own — one thing, done properly . A complete teardown of ESLint: What it is How it works internally Why companies use it as a quality gate The different classes of problems it solves How plugins work How to write your own rules Where it fails Why it still beats many AI-based review systems Fair warning. This article is going to be technical. There will be syntax trees. There will be compiler concepts. There will be enough JavaScript internals to make frontend developers slightly uncomfortable. I'll try my best to keep it readable not letting it turn into another manual - which nobody finishes. Let's start with the question most people never ask. What Is ESLint Actually Doing? Most developers describe ESLint like this: It checks code for mistakes. Technically true. Also completely useless. That's

Floating-point addition isn't associative. For a corporate inventory with tens of thousands of rows, naive summation drifts — and the number you disclose depends on row order. Here's why, and the fix. Here's a result that should bother anyone building carbon software. Take a corporate emissions inventory — tens of thousands of line items, each a number in tonnes CO₂e. Sum it. Now sort the same rows differently and sum again. The totals don't match. Not by much — maybe the third or fourth decimal place — but they don't match, and nothing in your code changed except the order. If you've never seen this, open a console: 0.1 + 0.2 === 0.3 // false That's the same bug, scaled up to a reporting deliverable. Why order changes the answer IEEE 754 doubles have 52 bits of mantissa. That's about 15–16 significant decimal digits of precision — generous, until you add numbers of very different magnitudes. When you add a small number to a large running total, the small number gets shifted right to line up the exponents before the addition happens. Bits that fall off the end of the mantissa are gone. Add a 0.0001 tCO₂e line to a running total of 80000.0 and there simply aren't enough mantissa bits to hold both the 80,000 and the 0.0001 — the small value is partially or completely swallowed. Float addition, as a result, isn't associative. (a + b) + c is not guaranteed to equal a + (b + c) . Sum your rows largest-first and the small values vanish early against a big accumulator. Sum smallest-first and they accumulate into something large enough to survive. Same data, different total. Here's the effect, deliberately constructed to be visible: const big = 80000 ; const smalls = Array ( 50000 ). fill ( 0.0001 ); // small values first, then the big one let a = 0 ; for ( const x of [... smalls , big ]) a += x ; // big value first, then the smalls let b = 0 ; for ( const x of [ big , ... smalls ]) b += x ; console . log ( a ); // 80004.99999999... console . log ( b ); // 80004.99999999...