Tooling and Developer Experience
JavaScript and TypeScript ecosystem tooling: package managers, bundlers, formatters, linters, compilers, SDKs, observability, testing, mocking, and developer workflow.
28%
Best tweets about JavaScript
50 Best Tweets About JavaScript (2026)
Discover the best tweets about JavaScript, including language features, browser APIs, performance, tooling, frameworks, debugging, and engineering practices.
Technical JavaScript code, language behavior, browser features, performance, tooling, debugging, architecture, and developer experience.
- Creators
- 43
- Updated
Original Xholic analysis
What 50 top JavaScript posts reveal
The dataset emphasizes browser capabilities, static or platform-native approaches, runtime fundamentals, tooling, and JavaScript security. The largest supplied score outliers span browser experimentation, privacy, creative JavaScript, CSS alternatives, and rendering/indexability claims.
- Dominant tone
- Positive
- Median score
- 12.9
- Leading format
- Other
- Recent posts
- 36%
60% of posts
All-time engagement
100% of posts
Published in 90 days
Conversation map
The themes creators return to
Language and Runtime Fundamentals
JavaScript language fundamentals, runtime behavior, and learning material: closures, objects, async/await, event loop, DOM, null quirks, algorithms, and Node.js internals.
26%
Browser Platform Capabilities
Browser APIs, rendering engines, DOM/CSS capabilities, client-side WebAssembly, and creative in-browser JavaScript applications.
22%
Architecture and Frameworks
Architecture and framework choices across frontend, backend, and mobile: React/React Native, Astro, Node.js, OTA bundles, stack complexity, and client-server boundaries.
20%
Performance, Rendering, and Delivery
JavaScript performance and delivery strategies, including bundle reduction, static/SSR rendering, layout cost, benchmarks, and avoiding unnecessary client-side JavaScript.
20%
Security and Privacy
Supply-chain and application-security risks in JavaScript, including npm compromises, malicious install scripts, obfuscated repository code, and browser fingerprinting.
12%
Web Indexability and Semantics
JavaScript SEO, crawlability, accessibility, semantic HTML, and the limits of client-rendered content for search and AI agents.
10%
Type Systems and Type Safety
TypeScript adoption, stricter type systems, null safety, functional patterns, and proposals for better frontend languages.
6%
Tone and stance
Sentiment Positive leads
Author posture Supportive leads
Performance benchmark
- Median likes
- 64
- Median reposts
- 4
- Median replies
- 4
- Median views
- 5.8K
Posts with media make up 66% of this collection. Their median all-time score is 19.2, compared with 5.38 for text-only posts.
Format mix
- Other 100% · score 12.9
Consensus and debate
Where creators agree, and where they do not
Shared view
Use less JavaScript where the platform suffices
A recurring engineering preference is to replace unnecessary client-side JavaScript with platform features or static HTML, spanning CSS-native UI behavior and Astro-based marketing pages.
Shared view
Runtime fundamentals remain core knowledge
Learning-oriented posts repeatedly prioritize runtime literacy: closures, the event loop, async behavior, Node.js internals, and debugging beyond surface-level syntax.
Shared view
Execution surfaces demand security scrutiny
Security discussion centers on JavaScript execution and supply-chain exposure, including package-install risks, inherited repositories, and browser-based extension probing.
Open debate
JavaScript rendering prompts competing crawl strategies
Posts differ in how broadly to treat JavaScript rendering as an indexability problem: one urges SSR, another recommends beginning with raw fetch and adding rendering only when necessary, while Astro is presented as a static-first option.
Open debate
Shared JavaScript is framed as leverage and liability
React Native OTA updates frame JavaScript bundles as a deployment advantage, while another post argues that using JavaScript on both client and server has blurred architectural boundaries.
What performs
Patterns behind standout posts
Largest score outliers span several JavaScript topics
The five supplied score outliers cover browser experimentation, privacy concerns, creative JavaScript, CSS alternatives to JavaScript, and SEO/rendering critique. Their supplied all-time scores range from 194.9 to 7430.86.
Performance and delivery has the highest supplied theme median
Performance, Rendering, and Delivery has the highest supplied theme median all-time score, at 22.2. Its cited posts discuss CSS capabilities, static HTML, and reducing heavy client-side bundles.
Media posts have a higher supplied median score than text posts
Media appears in 33 of 50 posts (66%). The supplied median all-time score for media posts is 19.198, compared with 5.383 for text posts.
Statistical standouts
- View standout post 1 Score 7430.9 · 575.14× median
- View standout post 2 Score 4122.1 · 319.05× median
- View standout post 3 Score 3692.0 · 285.76× median
- View standout post 4 Score 364.0 · 28.18× median
- View standout post 5 Score 194.9 · 15.08× median
Creator landscape
Who shapes this conversation
The five most represented creators account for 20% of the selected posts.
-
1. K.O.O
@Dominus_Kelvin
2 posts
-
2. freeCodeCamp.org
@freeCodeCamp
2 posts
-
3. GitHub Projects Community
@GithubProjects
2 posts
-
4. Darren Shepherd
@ibuildthecloud
2 posts
-
5. Ihtesham Ali
@ihteshamali
2 posts
-
6. Artem Zakharchenko
@kettanaito
2 posts
freeCodeCamp blends practical and foundational teaching
freeCodeCamp.org’s two posts cover practical browser-side implementation and foundational education: local QR generation and a detailed closures handbook.
Victor spotlights CSS alternatives to JS
Victor’s posts present CSS alternatives for common JavaScript UI tasks: accordion size interpolation and text truncation.
Mocking advances beyond request interception
Artem Zakharchenko’s posts focus on API mocking, including socket-level interception and MSW’s reported increase in weekly downloads.
How this analysis was made
Themes, sentiment, stance, and post format are classified per tweet. All counts, shares, medians, creator concentration, freshness, and performance comparisons are then calculated directly from the published snapshot.
Xholic's all-time score compares engagement while accounting for reach, post age, and creator consistency. It is used for relative comparisons within this collection.
This report analyzes the exact 50-post snapshot shown below. AI identifies editorial categories and drafts explanations; all statistics are calculated from the snapshot, and every narrative claim is checked against cited posts before publication.
Best JavaScript tweets
Top JavaScript tweets from 43 creators
Ranked 01–50
- 01
@om_patel5 ·
SOMEONE VIBE CODED A VIDEO STREAM THAT IS SECRETLY 100% TEXT SO IT CANT BE BLOCKED it plays 360p video at 30fps, but theres no actual video on the page. every frame is just colored text characters being repainted on a canvas to the browser its not media at all, its javascript updating some text its called asciline, and here's the trick: > the server decodes the real video and streams it as binary packed text over websockets > the browser paints thousands of colored block characters fast enough to look like 360p > ad blockers and autoplay blockers cant catch it because theres no video element to catch > it streams in kilobytes since its just strings, so it runs on trash internet since the video is literally text, you can apply css glows to it, let people copy paste a moving frame, or feed it straight to a local llm however, an unblockable stream is also an unblockable ad as well
Watch video
- 02
@katexbt ·
Wow, LinkedIn just got caught in a huge scandal. Here's what's going on: > Every time you open LinkedIn in a Chrome-based browser, LinkedIn’s JavaScript executes a silent scan of your installed browser extensions. > The scan probes for thousands of specific extensions by ID, collects the results, encrypts them, and transmits them to LinkedIn’s servers. It gets worse: > The scan doesn’t just look for LinkedIn-related tools. > It identifies whether you use an Islamic content filter (PordaAI — “Blur Haram objects, real-time AI for Islamic values”) > whether you’ve installed an anti-Zionist political tagger (Anti-Zionist Tag), or a tool designed for neurodivergent users Huge L after L
- 03
@anulagarwal ·
You all are overthinking your side projects. >This guy made digital balls physically bounce off real objects/sticky notes using just a webcam, a projector, and JavaScript. Go build something fun. (via ig/bongyunng)
Watch video
- 04
- 05
@jbobbink ·
Google is gaslighting the entire SEO industry about JavaScript. I have the receipts. This week Google removed the "Design for accessibility" section from their official JavaScript SEO documentation. Their reason? JavaScript rendering is "no longer a barrier" for Google Search. I nearly choked on my coffee. I manage SEO across hundreds of properties. I see what actually happens when Google tries to render JavaScript sites. Every single day. This is the fifth update to the same document since December 2025, part of a systematic campaign to replace broad cautions with specific technical guidance Here is what I see that Google apparently does not. Content behind tabs, accordions, and "load more" buttons? Completely invisible. Google does not click. Google does not scroll. Google does not interact. That content simply does not exist for them. Structured data injected via JavaScript? Random. Google's own documentation on https://t.co/COodItApeI admits that JS-generated Product markup makes shopping crawls less frequent and less reliable. I see it break constantly. Images loaded through JavaScript? Good luck getting those indexed. Lazy-loaded images behind interaction events are a black hole. Internal links rendered via JavaScript? Onely proved Google needs 9x more time to crawl JS pages than plain HTML. Nine times. Their experiment showed 313 hours for JS versus 36 hours for HTML to reach the same depth. A 2024 counterpoint study by Vercel/MERJ found most pages rendered within minutes. And here is the part nobody is talking about. AI crawlers cannot render JavaScript at all. GPTBot, ClaudeBot, PerplexityBot. They see raw HTML only. Onely's 2025 research estimated about 70% of modern websites may be completely invisible to AI search because of JavaScript dependencies. So Google removes the warning. Developers lean harder into client-side rendering. And what happens? Sites become more dependent on Google's proprietary rendering pipeline while going completely dark for every competing search and AI system. Convenient timing. Google is not telling you JavaScript is fine because it is fine. Google is telling you JavaScript is fine because it benefits Google. Server-side rendering is not optional. It never was. Do not let a documentation update convince you otherwise. Sources: 1. Barry Schwartz, "Loading Content With JavaScript Does Not Make It Harder For Google Search" Mar 5, 2026 2. Google Developers, JavaScript SEO Basics (the removed section) 3. Google Developers, Structured Data with JavaScript (the shopping crawl admission) 4. Vercel "How Google handles JavaScript throughout the indexing process" Jul 20224
- 06
@betomoedano ·
Every mobile developer eventually hits this moment: a bug is live in production, the fix is one line, and App Store review stands between you and your users for days. Web developers just deploy. Mobile developers wait. Except you don't have to. Over-the-air (OTA) updates let you push JavaScript changes directly to installed apps, in minutes. And it's fully within Apple's and Google's rules, their guidelines explicitly permit updating interpreted code like JavaScript, as long as you don't change what your app fundamentally does. The mental model is simple. A React Native app is two layers: - The native binary, the thing Apple actually installs - The JavaScript bundle inside it, where most of your app lives An OTA update swaps the bundle. The native layer never changes. That's both the mechanism and the limit: JS changes ship in minutes, anything native still goes through the store. I wrote a full walkthrough on my blog: the complete @bitrise CodePush setup on Inkigo, my app that's live on the App Store. Free for up to 100,000 monthly active users. (link below) 👇
- 07
@justinstorre ·
I am experimenting with something I call "Typescript Ultra Strict". Basically, typescript with no nulls, no classes, no undefineds, no switch statements, and no vars + the addition of match macros. Basically forcing AI to write functional AI code through compilation errors that is more deterministic and testable. Back in 2008 Chrome built the V8 Javascript engine and the entire world built edge compute on top of this amazing primitive. However, Javascript had it's short comings so we made Typescript, but Typescript still was "too friendly", mainly to appeal to a human audience. We no longer have humans writing code, so why not give the AI something less clunky and more clanky 😉 UX - write .tsus files - add a one-line plugin to webpack, Vite, esbuild, or Bun Features include: - Option/Result runtime, with boundary helpers that turn the outside world's nulls and throws into Option and Result - match macros - good error messages, so an agent can fix its own errors in a loop
- 08
@techNmak ·
🚨BREAKING: Someone is finally challenging Google's grip on the web. In 2026: → Chrome = 65%+ market share → Edge, Brave, Arc, Opera = all Chromium → Firefox = under 3% and dying → Safari = Apple-only Google doesn't just dominate browsers. They control the engine. Ladybird is building a completely independent alternative: → New rendering engine → New JavaScript engine → New WebAssembly → New everything No Chromium. No Google. No strings. 59.8K stars. 1,240 contributors. BSD-2-Clause license. The web's first real competition in a decade.
- 09
@jahirsheikh8 ·
Step-1: Learn JavaScript (not just syntax, understand the weird parts) Step-2: Master closures, prototypes & the event loop Step-3: Understand async deeply (promises, async/await, microtasks vs macrotasks) Step-4: Build real UIs with React (state, hooks, rendering behavior) Step-5: Learn Node.js internals (streams, buffers, non-blocking I/O) Step-6: Build APIs (Express/Fastify) & handle errors properly Step-7: Work with databases (SQL + NoSQL) like you actually care about queries Step-8: Optimize performance (debouncing, memoization, caching) Step-9: Deploy (Docker, CI/CD, Vercel/AWS) Step-10: Ship it
- 10
- 11
@ayushagarwal ·
we just rebuilt @dodopayments from scratch. migrated entirely off framer. rewrote the whole thing in astro. the old site looked fine but under the hood it was slow. heavy javascript bundles. unnecessary client-side rendering for what is fundamentally a static marketing site. page speed scores were mid. every time we wanted to change something it felt like fighting the tool instead of building. so we nuked it. astro ships zero javascript by default. every page is static HTML unless you explicitly need interactivity. the result is a site that loads almost instantly. lighthouse scores through the roof. SEO actually works because crawlers aren't waiting for javascript to render your content. the migration took effort but the tradeoff was obvious. full control over every pixel. no vendor lock-in. no mysterious build steps. no "why is this component re-rendering on every page." if you're running a SaaS marketing site on a no-code builder and wondering why your page speed is garbage, this is your sign.
Watch video
- 12
@sankitdev ·
My girlfriend takes 45 minutes to get ready. I used to just stand at the door. Doing nothing. Completely blocked. Staring at the wall. Waiting. Frozen. Then one day I just... stopped doing that. I took her sister to play with in meantime like badminton, chess, carrom, etc. I lived my life while she got ready. Same wait time. Completely different outcome. That's exactly what async/await does to your JavaScript. ───────────────────────── What is Async/Await? async/await is a syntax built on top of Promises that lets your code wait for an operation to finish without blocking everything else from running. Two keywords. Completely changes how your program breathes. async function getUser() { const response = await fetch("https://t.co/86T5inz1nE") const data = await response.json() return data } The function pauses at await. But the rest of your program keeps running. ───────────────────────── The problem it solves Before async/await, you had callbacks inside callbacks inside callbacks. This was called callback hell. It looked like this: getUser(function(user) { getPosts(https://t.co/8FGd7HzhGQ, function(posts) { getComments(posts[0].id, function(comments) { console.log(comments) }) }) }) Unreadable. Unmaintainable. A nightmare to debug. > Promises cleaned it up. > async/await made it feel like normal code. ───────────────────────── Synchronous vs Asynchronous > Synchronous = one thing at a time, fully blocked // everything freezes here const data = fetchDataSync() console.log(data) Asynchronous = start the task, come back when ready async function run() { const data = await fetchData() // only THIS pauses console.log(data) } She's still taking 45 minutes either way. The difference is whether you freeze at the door or live your life. ───────────────────────── How await actually works When JavaScript hits an await, it: 1. Starts the async operation 2. Suspends that function 3. Returns control to the rest of the program 4. Resumes once the Promise resolves Nothing is blocked. Call stack stays free. ───────────────────────── Error handling with try/catch async function getUser() { try { const response = await fetch("https://t.co/86T5inz1nE") const data = await response.json() return data } catch (error) { console.log("Something went wrong:", error) } } Clean. Readable. Exactly what your code deserves. ───────────────────────── Running things in parallel // Slow - sequential const user = await getUser() const posts = await getPosts() // Fast - parallel const [user, posts] = await Promise.all([ getUser(), getPosts() ]) Don't await things one by one if they don't depend on each other. ───────────────────────── Bonus: Real world applications 1. API calls Every backend request uses async/await to avoid freezing the server for other users. 2. File I/O in Node.js Reading and writing files without blocking the event loop. 3. React data fetching useEffect with async functions to load data after component mounts. 4. Database queries Prisma and Mongoose return Promises, async/await makes querying feel like sync code. ───────────────────────── Congratulations🥳, you just learned async/await. async/await didn't make the wait shorter. It just stopped your program from freezing while it waited. She still takes 45 minutes. But now you ship features in the meantime.
- 13
- 14
- 15
@freeCodeCamp ·
Many QR code generators send your data to a server, even though modern browsers can handle the job locally. In this tutorial, @allinonetools teaches you how to build a QR code generator with JavaScript and a client-side QR code library. You'll also learn input validation, UX improvements, and how to extend it with downloads, styling, and more. https://t.co/TAJ4oq3nNf
- 16
@freeCodeCamp ·
Closures are one of the most misunderstood parts of JavaScript - but they're important to understand. So @sumit_analyzen wrote this in-depth handbook to teach you the detailed ins and outs of closures. You'll learn about functions and parameters, accessing variables, scope, let vs var, and you'll see a bunch of code examples along the way. https://t.co/AesFjtQ4ew
- 17
@GithubProjects ·
JavaScript algorithms and data structures implemented in JavaScript with detailed explanations and complexity analysis. - Beginner and advanced levels for both data structures and algorithms - Includes Linked Lists, Trees, Graphs, Hash Tables, and Bloom Filters - Covers sorting, searching, dynamic programming, and graph algorithms - Each implementation has its own README with links to further reading Explore it here: https://t.co/13bf1VEuKS
- 18
@staysaasy ·
When I first became a manager I was managing someone way more senior than me in a tech stack I knew nothing about. We were doing JavaScript SDK development - the kind of stuff that customers would lose their minds over if you got it wrong. I basically became his QA engineer. I reviewed all of his PRs. Super careful line by line analysis of promises and local storage and browser support code. The I’d check out the code and test it out. Really aggressively try to find bugs and issues. I was ultimately responsible for the output, our customers demanded quality, and it was the way I could add most value. Years later I found myself really, really good at thinking about software quality. I’d have debates with my senior leaders about whether we needed QA engineers. I was adamant that it wasn’t needed. At the same time, I was always shocked at how bad most engineers were about ruining through testing, releasing, and risk management. Eventually, way later, I realized that most people have just never had to do it regularly in a high stakes environment. I often think back to those days of basically being that guys personal tester. It was maybe, on face value, the lamest thing I’ve ever had to do. But it also turned out to be one of the top and most differentiated learning experiences I’ve ever had.
- 19
- 20
- 21
- 22
- 23
@ManningBooks ·
JavaScript works. Understanding why it works is a different skill. JavaScript in Depth by James Snell focuses on what's under the hood: engines, runtimes, and real execution. It's useful for debugging edge cases, revisiting forgotten concepts, and making sense of AI-generated code. The book: https://t.co/GcHHCC4j5a
- 24
@Dominus_Kelvin ·
JavaScript used to let small teams ship big things. Now developers need: • frontend framework • backend framework • BFF layer • auth service • serverless platform • edge runtime • ORM • state library • RPC layer • cache layer just to build an invoicing app. The Boring JavaScript Stack is a calmer, saner alternative to that.
- 25
- 26
@ihteshamali ·
JavaScript runs almost the entire internet. It was built in 10 days. Brendan Eich wrote the first version in May 1995a. He was a new hire at Netscape, the browser company racing against Microsoft, and the deadline was already on top of him before he started. He didn't even want to build what they asked for. Eich wanted to put a language he loved, Scheme, into the browser. His managers said no. They had just signed a deal with Sun, and Java was the hottest thing in tech. So the order came down. Make it look like Java. Keep it small. In his own words, he was told to build a silly little brother language. Something for non-programmers to add tiny effects to a page. A blinking image. A scrolling message at the bottom of the screen. That was the whole point. He shipped the prototype in 10 contiguous days. It had bugs. It had quirks people still complain about 30 years later. Then it never stopped growing. That throwaway toy now powers nearly every website on Earth. The thing built to be the small one outlived Java's dominance, outlived Netscape, and became the foundation of the modern web. Nobody plans the thing that takes over the world. They just build the thing in front of them and the world decides the rest.
- 27
@SumitM_X ·
As a frontend dev, do you know how JavaScript talks to your HTML? That magic starts with the document object! It’s like the remote control for your entire web page. NOTE: document isn’t part of JavaScript itself! It’s a gift from the browser, through the Web API. When a browser loads your webpage, it reads the HTML and creates a DOM (Document Object Model) : a tree-like structure in memory that represents everything on the page. This DOM is not HTML , it’s a JavaScript-friendly version of your HTML. JavaScript gets access to this DOM through the document object. So when you write: document.getElementById("btn") You're saying: “Hey browser, give me the JavaScript object that represents the HTML element with id="btn".” Once you get that, you can: Read or change its text Add event listeners Change styles Add/remove it from the page …and more. Some common document usage: document.getElementById("btn") – grab a button document.title = "New Page" – change the tab name document.querySelector(".box") – select like CSS document.createElement("div") – build new stuff
- 28
@firt ·
We keep defaulting to the biggest model in the room every time we touch AI in our apps. Claude, GPT, Gemini. Cloud or nothing. But the browser is already more capable than most people realize: WebAI and WebMCP may change this. With WebAI you can run models client-side. With WebMCP, your site can expose real actions as JavaScript functions. Agents don't need screenshots, DOM scraping, or blind clicking. They can just use your app. I talked about this with @guypod on @tessl_io AI Native Dev podcast: the browser is turning into an AI runtime. Links in first reply :)
Watch video
- 29
@heynavtoor ·
🚨 A JavaScript library with 100 million weekly downloads was just hacked. Malicious versions were live on npm. Your machine might already be compromised. It's called Axios. On March 31, 2026, attackers hijacked the lead maintainer's npm account and published poisoned versions that silently install a Remote Access Trojan on your computer. Bloomberg covered it. Sophos covered it. Malwarebytes covered it. Google Threat Intelligence attributed the attack with high confidence to a North Korea-nexus financially motivated threat actor. This is not a drill. Here's what happened: → March 30: Attacker hijacks the npm account of Axios's lead maintainer → Changes the account email to an attacker-controlled ProtonMail address → Publishes a clean decoy package 18 hours before the attack. Pre-staged. → March 31: Publishes two poisoned Axios versions. 1.14.1 and 0.30.4. → Both contain a hidden dependency that runs a postinstall script → That script silently downloads and installs a cross-platform RAT (Windows, macOS, Linux) → The malware deletes itself after installation to hide from investigators → The malicious versions were live for 2 to 3 hours before npm pulled them Here's why this is terrifying: → Axios gets over 100 million weekly downloads on npm → Any developer or CI/CD pipeline that ran npm install during those 2 to 3 hours is potentially compromised → The RAT gives attackers full remote access to your machine → StepSecurity detected anomalous C2 contact in over 12,000 projects → Google warns "hundreds of thousands of stolen secrets could potentially be circulating" → Microsoft attributed the attack to Sapphire Sleet, a North Korean state actor Here's what you need to do RIGHT NOW: → Check your lockfiles for [email protected], [email protected], or [email protected] → Check CI logs for any npm install between 00:00 and 03:30 UTC on March 31, 2026 → If found: treat that machine as FULLY COMPROMISED. Re-image it. Do not just uninstall. → Rotate ALL credentials accessible from the affected machine → Block sfrclak[.]com at your firewall → Safe versions: [email protected] and [email protected] → Update immediately Here's the part that should keep the entire industry up at night: Legitimate Axios releases include OIDC provenance metadata and SLSA build attestations linking every package to a verified GitHub Actions build. The malicious versions had none. Zero verifiable build trail. And npm installed them anyway. 100 million weekly downloads. One compromised account. One postinstall script. Full remote access. Check your lockfiles. Now.
- 30
@aiwithmayank ·
A broke guy in Russia runs 75 of the top 100 websites on Earth. His name is Denis Pushkarev. In 2014 he published a small JavaScript library called core-js. It became the invisible thing that lets modern websites work in any browser. Apple, Netflix, Spotify, and PayPal all run on it. It's baked into React, Angular, and Vue. Nine billion downloads, and he maintains all of it alone. When he asked for help, his Patreon brought in 57 dollars a month. People didn't just refuse to pay him. They called him a parasite and wished death on his family. The companies built on his code are worth trillions. He survives on a few hundred dollars a month and still ships updates twelve years later. The most important work in tech is almost always the work nobody can see. We never notice the person holding the ceiling up until the moment he lets go.
- 31
@ihteshamali ·
This tiny JavaScript library is doing something browsers should have built in years ago. Pretext measures multiline text and calculates layout without triggering a single DOM reflow. You get the height, line count, and individual line data back as pure numbers with zero browser layout cost. The use cases are wild. You can do proper list virtualization without height guesswork, prevent layout shift when new text loads, verify at development time that button labels don't overflow, and build masonry grids without hacks. → walkLineRanges() lets you binary search the perfect container width → layoutNextLine() lets each line have a different max width → Handles bidirectional text, mixed scripts, and browser quirks automatically → Server-side rendering support is coming 14.1K stars. MIT License. 100% Opensource. Link in comments.
- 32
- 33
@priyankapudi ·
Meet Ryan Dahl - Creator of Node.js - Grew up in San Diego, California - Got his first computer (Apple IIc) at age 6 - Loved math and studied it at UC San Diego - Started a PhD but dropped out , abstract math wasn't applicable to real life - Left for South America and started building web apps in Ruby - While freelancing in Germany, he noticed a major problem - Web servers like Apache used one thread per connection - Servers choked under heavy traffic - Handling thousands of users at once was a nightmare - One day he uploaded an image on Flickr - Saw the progress bar repeatedly querying the server just to show upload status - That moment clicked , the web needed a better way to handle I/O - Started coding in a WiFi-less Starbucks in Cologne, Germany - 8-hour daily coding sprints for 6 months straight - Built it on Google's V8 JavaScript engine - Used non-blocking, event-driven I/O , a radical approach at the time - Presented Node.js at JSConf EU in 2009 - The crowd went wild - He said he was "in a continual state of surprise for four years" - Joined Joyent and worked on Node full-time - Designed it to be lightweight, fast, and asynchronous - JavaScript could now run outside the browser , on servers - Node.js became one of the most transformative tools in web development - Powers: Netflix, LinkedIn, PayPal, Uber, NASA dashboards - Millions of developers use it worldwide - npm became the largest package registry in history - Later gave his famous "10 Things I Regret About Node.js" talk - Then built Deno : a modern rewrite fixing his own mistakes - Literally changed how the internet works behind the scenes Set inspiration for many like me !
- 34
- 35
@flydotio ·
Built the world's simplest code runner in 5 mins with Sprites. This is doubly cool. First off, how it works: User writes some scary JavaScript, which then gets run in a new Sprite. Sprites are literally built for running random code, so bring on the footguns. 🧵
Watch video
- 36
- 37
@_vmlops ·
THIS JS LIBRARY READS TEXT OUT OF ANY IMAGE, RIGHT IN YOUR BROWSER no server, no API calls, pure javascript OCR wrapping tesseract via webassembly ▪️ works in browser (webpack, esm, script tag) and Node.js ▪️ 100+ languages supported ▪️ v7 needs Node v16+, requires just a few lines to get text out of an image ▪️ 38.1k stars, used by 37k+ projects, actively maintained since 2019 ▪️ doesn't handle PDFs directly, that's where scribe.js comes in three lines of code and you've got OCR running client-side: createWorker → recognize → terminate https://t.co/90y8FSFzDC
- 38
@the_smart_ape ·
cloudflare just dropped a /crawl endpoint and everyone's losing their mind. calm down. let me tell you what it actually is, what it isn't, and why you probably don't need it. the /crawl endpoint is a wrapper. you give it a URL, it spins up headless browsers on Cloudflare's infra, follows links, renders JavaScript, and hands you back markdown or JSON. all with 1 API call. it's cool but not revolutionary. firecrawl does this. crawl4AI does this. spider does this. they've been doing it for months. cloudflare just added it to their existing Browser Rendering product and everyone acted like they invented crawling. what IS interesting: it's cloudflare. that means it's cheap ($0.09/hour). but the thing is you probably don't even need a crawler. there are 8 ways an AI agent can read a webpage. most jump straight to the complex ones when a 50ms HTTP request would've done the job. so let's break them all down, from the simplest to the most overkill. 1. raw HTTP fetch your agent sends a request, gets back HTML. that's it. like reading a book's source code instead of the printed page. works great for simple sites, blogs, wikis, docs. breaks on anything that uses JavaScript to load content. speed: ~50ms. cost: free. 2. readability parser same thing, but with a cleaning step. strips out nav bars, ads, footers, cookie banners. gives you just the article text in clean markdown. doesn't handle JavaScript-rendered content. but for articles and docs, it's perfect, and it's what I use daily. speed: ~100ms. cost: free. 3. headless browser (local) launches an invisible Chrome that loads the page like a human would. JavaScript runs, content renders, everything loads. you can click, scroll, fill forms, log in. the problem: slow (2-10s), eats ~200MB RAM per instance, and you maintain the infra. tools: Playwright, Puppeteer, Selenium. 4. cloud browser API same as #3 but someone else runs the browser. you send a URL, get back the rendered page. this is where Cloudflare's /crawl lives, along with Browserbase and Steel. no infra headaches, scales easily, cheap. tradeoff: less control over interactions. 5. managed scraping API this is the anti-bot warfare tier. ScrapingBee, Bright Data, rotating proxies, CAPTCHA solving, residential IPs. for when the site actively fights you. works. costs $49-499+/month. 6. AI-native crawler Firecrawl, Crawl4AI, Spider. crawl + render + auto-convert to clean markdown/JSON. built for RAG pipelines. define extraction schemas in natural language. the "new wave" that Cloudflare is now competing with. 7. LLM extraction skip the code entirely. dump the page content into an LLM, ask "what's the price?" in plain english. no CSS selectors, no regex, no maintenance when the site redesigns. downside: expensive at scale (tokens add up fast). best as the final step after cleaning with methods 1-6. 8. official APIs the one everyone forgets. X, Reddit, most SaaS, they have APIs. structured data, no parsing, no anti-bot games. when an API exists, it's always the right choice. the good setups combine 2-3: → fetch → readability → LLM for cheap article extraction → cloud browser → LLM for JavaScript-heavy sites → sniff the actual API in DevTools → call it directly, the holy grail, free, fastest, most reliable → AI crawler → vector DB for full know ledge bases real costs at 10,000 pages/month • HTTP Fetch: $0 • Jina Reader: $0 • Cloudflare Browser: ~$5 • Spider: ~$4.80 • Firecrawl: $47/mo • ScrapingBee: $49-147/mo • Bright Data: $499+/mo 2 rules i follow: start simple. API > fetch > readability > browser. only add complexity when the simpler method fails. I see people spinning up Playwright for sites where curl works fine. most sites don't need JS rendering. 60%+ of the web is static or server-rendered. test with a simple fetch first.
- 39
@joncphillips ·
Alright, a little story and a warning for anyone who works on code they didn't write. Recently I pulled down an existing codebase for some contract work, nothing unusual. Cloned it, installed deps, spun it up locally, and started poking around. Then I noticed something weird at the end of one of the backend files. Right after the last real line of code, sitting just after a module.exports, there was a wall of obfuscated JavaScript wrapped in some self-decoding string-shuffle routine, committed right into the repo. Because it sits after module.exports in a CommonJS module, it self-executes the moment that file gets required, so it runs the instant the app boots. You don't have to import it or trigger it or click anything, it just goes. I pulled it apart with static analysis, reading it without ever running it. Here's what the thing was actually doing. On a loop (throttled to roughly every 30 seconds with a global flag), it: 1. Queried the latest transaction from a couple of attacker-controlled wallets on the Tron blockchain (via the TronGrid API, with an Aptos node as a fallback for resilience). 2. Read a pointer out of that transaction, which was the hash of a second transaction over on BNB Smart Chain. 3. Fetched that BSC transaction over JSON-RPC (eth_getTransactionByHash) and pulled the payload out of the calldata. 4. XOR-decrypted that payload with a hardcoded key. 5. Executed the result two different ways, straight through eval() and as a detached hidden child process (child_process.spawn('node', ['-e', ...]) with stdio ignored and windowsHide set). This is a technique called EtherHiding. The code in the repo is really just a loader. The actual commands live on-chain, so the attacker can push new payloads whenever they want by broadcasting a new transaction. There's no domain or server for anyone to seize since the blockchain itself is the command channel, and the code sitting in the repo never has to change at all. And because it runs at boot, it's got the entire process environment in scope. Like... DB credentials, API keys, tokens, whatever's in process.env. The payload itself was built around crypto-wallet theft. Here's the thing though. By the time I spotted it, I'd already started the app a few times to see it run. So this thing had quietly self-executed on my machine several times before I even knew it existed. When I finally sat down to analyze the payload I was careful to only read it and never run it, but that window was already wide open before I understood what I was looking at (had a fun time scanning my machine and cleaning things up...) The worst part is it had been hiding in that repo for over a year. It slipped in through an innocent looking merge commit under a boring title. Merges and dull messages like "fix" or "time zone" make great camouflage, because a pickaxe search and a normal git log tend to skip right over merge commits. A few things I'm taking from this and passing on: - Treat any repo you inherit as untrusted code until you've actually read it. Cloning doesn't run anything, but the second you boot it up you're executing code you've never looked at. - Obfuscated code sitting in a source tree is a red flag every single time. Real code doesn't need to be scrambled, so when it is, something's off. - npm install and npm start both run code you didn't write, install hooks first and then the app entry point. Skim before you run, and run unknown code in a VM or container. - Actually read the git history, merge commits included. Boring titles hide interesting diffs. - If something ran that shouldn't have, assume every secret in that environment is compromised, rotate all of it, and scan the machine. Be careful out there. It's easy to assume the code you inherit is clean, and sometimes it's fucking not.
- 40
@ibuildthecloud ·
I'm absolutely fascinated by the fact that frontend developers accept typescript. That means it's possible to build a better language for frontend. Everything frontend people have rejected about compiled and statically typed languages they have brought to JavaScript. So it's definitely possible to create a statically typed compiled language for frontend that would be ridiculously fast compared to typescript. It's a times like this I wish I didn't have a job.
- 41
@ibuildthecloud ·
One of the biggest recent issues of full stack dev was to blur the lines of client (browser) and server. Before JavaScript on the server the lines were self evident. With JavaScript going server side and the desire to use the same language for both we broke the boundaries and are paying the price.
- 42
@foley_seo ·
A HUGE amount of the web is becoming less accessible to AI and search engines because a HUGE amount of vibe coders are not understanding that VIBE CODING produces APPS by default. Apps do not need to be indexed, so they aren't built for "SEO" or "indexability" they're built for performance and functionality. So - there's a good chance if you vibe coded a website prior to 2026 that you've got a REACT SHELL that Google (and AI bots) cannot render/index/access properly. I've tested them all: ✅ Lovable ✅ Cursor ✅ Bolt ✅ Claude Code ✅ Codex and their DEFAULT out of the box configurations are MOSTLY NEXT.JS based - some are REACT/VITE. Nearly ALL produce websites as apps (CLIENT SIDE RENDERED) and that is abysmal for SEO. Google is one of the few BOTS that supports JAVASCRIPT rendering but, even so, Googlebot DOES NOT interact with JS elements and therefore if any of your websites content is CTA based - you can kiss that goodbye in terms of accessibility. I've seen ENTIRE websites uncrawlable because the NAV and FOOTER were JS event based - even with a Sitemap Google gave up. If you VIBE CODE websites - take a read of this: https://t.co/N2yh4E7jYE It's all well and good chasing after rankings and AI CITATIONS, no good if bots cannot actually access any of your website content. Long story short - Avoid CLIENT SIDE RENDERING Avoid using REACT SHELLS Avoid using JS loaded content / JS event triggers Yeah - all looks good on paper when pages load super quick, no good when Google can't index anything.
- 43
- 44
@leeschmidt123 ·
Founders: This is why you shouldn't aim for 15k LOC per day and "let the tokens rip", despite how cool it sounds. Here's a real bug I encountered today: a page in our app was being pushed up by 50px or so, leaving a white strip at the bottom and cutting off the top of the page content. The vibe coded fix: 18 lines of unmaintainable, messy, duct taped javascript The real fix: changing ONE CSS property It's tempting to spend 15 seconds telling cursor to fix it (using both GPT 5.5 and Opus 4.7). Both models concluded that a reasonable fix was 18 lines of code, accessing the Radix viewport, calling getBoundingClientRect(), manually calculating scroll offsets, and replacing scrollIntoView with a manual scrollTo, and adding an additional dependency to a useEffect(). If you've spent any time as a dev prior to AI, you read this code and immediately know it's wrong. Worse, if you've never been a dev - you might think this looks normal! Next you have two choices: (a) you spend a few more minutes thinking in depth on your own or pushing back on the LLM, or (b) you commit, push, and deploy. The vibe coded fix is at the wrong layer, inside the individual page instead of the shared layout components. It leaves the same bug possible in every other page of the app - so would need to be duplicated on every page. It addresses the symptom, not the root cause. If your app becomes filled with this code, I can virtually guarantee you it will eventually become hard or impossible to continue building on (or the tokens required will become out of hand because changing something simple becomes hundreds or thousands of lines - this burns tokens and uses up context, requires more rounds of inference, etc). A messy and unmaintainable 18 lines of code doesn't sound bad. But the same slop magnified by 10-12 hours of prompting and vibe coding every day? Now you have an unmaintainable mess of code that eventually LLMs will be unable to work on, and neither will a human. If your startup's value is delivered in the form of a software product, this is a recipe for failure. Technical founders, technical CEOs, and experienced devs already know you need to read the code to avoid piles of slop that turn into immovable walls. For new founders, or anyone new to development or product building - if you want to build anything beyond a fun prototype or barely working MVP, you *need* at least one technical founder/cofounder, or you need to be learning real engineering.
- 45
@ThePracticalDev ·
A backend team used AI to convert a Python class to JavaScript — and it failed. Not because the translation was wrong, but because the AI didn't know how to handle a 5GB zip file in the browser without crashing it. This dev did, using IndexedDB as an async workaround. { author: @OlumideSamuel_ } https://t.co/EUv88au50W
- 46
@MPorterBridges ·
Do you have a group of related data in your JavaScript? You can avoid multiple variables by using objects. JavaScript objects are one of the most important concepts to learn because they show up everywhere in real codebases. I’m talking APIs, frameworks, browser data, and more. If you’re new to JavaScript, you’ve likely bumped up against a problem organizing your variables, especially if you’re dealing with a lot of data. For example, if we wanted to create variables to manage the data that describes a car, it starts becoming a little messy - especially if we mean to keep this data all grouped together in some way. const make = "Chevrolet"; const model = "Malibu"; const year = 1999; const odometer = 10000; const used = true; const tirePsi = [100, 90, 95, 97]; A JavaScript object is a collection of related data and behavior, stored as key-value pairs. const objectName = { key: value }; A good visualization for a JavaScript object would be a box and label. The box being the object with the label containing detailed contents of the box. For example, this might be a box that’s shipped to a local bookstore. const bookBox = { multipleGenres: true, genre: ["non-fiction", "romance", "comedy"], amount: 3, value: "$500 CAD" }; This example highlights that the values in our key-value pairs can contain various types of data including booleans, arrays, numbers, strings. Beyond the example, our values can also be other objects and even functions (referred to as methods inside an object). If we rewind to our original example, we can take our car variables and place them inside a single object. const car = { make: "Chevrolet", model: "Malibu", year: 1999, odometer: 10000, used: true, tirePsi: [100, 90, 95, 97] }; Now that we know how to create an object with various data types, what about accessing that data? We can access the data inside an object in two ways - dot notation and bracket notation. Bracket notation being especially useful if the key is dynamic. Using our car example, let’s grab the year value using both of these methods: //Dot Notation console.log(car.year); //Bracket Notation console.log(car["year"]); And finally, what about updating our object’s data? Let’s say we need to correct our odometer reading from 10000 to 9999, we can update our key value pair by doing the following: car.odometer = 9999; And if we want to add a new key-value pair describing the transmission, we can do this: car.transmission = "automatic"; There’s a lot more we can do with objects in our JavaScript that we haven’t covered in this post, but I hope it was a good introduction for anyone getting their JavaScript coding journey started!
- 47
- 48
@did0f ·
LinkedIn was accused of testing thousands of Chrome extensions installed in users’ browsers. But the point is not “LinkedIn reads your computer.” The point is more technical: some extensions expose resources that a web page can try to load with JavaScript. If they respond, they become signals. One signal means little. Many signals can become browser fingerprinting. This is called resource probing. And the important part is that the issue goes beyond LinkedIn. Any page running JavaScript can try to observe technical signals from your browser. Not always. Not everything. No magic. But enough small signals can make a browser recognizable.
Watch video
- 49
@Dominus_Kelvin ·
Stop navigating with onClick={() => router.push(...)}. Every time you do, you're opting out of browser behavior and signing up to reimplement it yourself. You are sacrificing: cmd-click open in new tab accessibility browser semantics prefetching SEO for absolutely no reason. HTML solved this before JavaScript existed. If it goes somewhere, it's a link.
- 50
@donnfelker ·
This weekend I removed a substantial amount of JavaScript from one of my Rails applications. I replaced all the JavaScript with Turbo frames and Turbo streams. In the end, I gained more testability, an easier development experience, and less context switching than I or the AIbagent had to do previously.
Best Tweets by Topic