V8 Optimization: Object Shapes and Performance

I spent an entire day and night debugging a React error that wasn't even a React error. Here's what happened. I migrated my project from scratch using the latest setup, Vite 8, fresh install, all packages updated. Everything compiled fine. Then this showed up in my editor: // 𝗘𝗿𝗿𝗼𝗿: 𝗖𝗮𝗹𝗹𝗶𝗻𝗴 𝘀𝗲𝘁𝗦𝘁𝗮𝘁𝗲 𝘀𝘆𝗻𝗰𝗵𝗿𝗼𝗻𝗼𝘂𝘀𝗹𝘆 𝘄𝗶𝘁𝗵𝗶𝗻 𝗮𝗻 𝗲𝗳𝗳𝗲𝗰𝘁 𝗰𝗮𝗻 𝘁𝗿𝗶𝗴𝗴𝗲𝗿 𝗰𝗮𝘀𝗰𝗮𝗱𝗶𝗻𝗴 𝗿𝗲𝗻𝗱𝗲𝗿𝘀 𝘂𝘀𝗲𝗘𝗳𝗳𝗲𝗰𝘁(() => {  𝗶𝗳 (𝘀𝗰𝗿𝗼𝗹𝗹𝗗𝗶𝗿 === "𝗱𝗼𝘄𝗻") 𝘀𝗲𝘁𝗜𝘀𝗩𝗶𝘀𝗶𝗯𝗹𝗲(𝗳𝗮𝗹𝘀𝗲);  𝗶𝗳 (𝘀𝗰𝗿𝗼𝗹𝗹𝗗𝗶𝗿 === "𝘂𝗽") 𝘀𝗲𝘁𝗜𝘀𝗩𝗶𝘀𝗶𝗯𝗹𝗲(𝘁𝗿𝘂𝗲); }, [𝘀𝗰𝗿𝗼𝗹𝗹𝗗𝗶𝗿]); Same code. Same logic. Worked fine before the migration. I searched everywhere, YouTube, Reddit, Stack Overflow, ChatGPT. Nobody was talking about this specific error with any reliable answer. Someone suggested replacing useEffect with a plain if statement. Tried that. New error: // '𝘀𝗰𝗿𝗼𝗹𝗹𝗗𝗶𝗿' 𝗶𝘀 𝗰𝗼𝗻𝘀𝘁𝗮𝗻𝘁 𝗶𝗳 ((𝘀𝗰𝗿𝗼𝗹𝗹𝗗𝗶𝗿 = "𝗱𝗼𝘄𝗻")) { 𝘀𝗲𝘁𝗜𝘀𝗩𝗶𝘀𝗶𝗯𝗹𝗲(𝗳𝗮𝗹𝘀𝗲); } I was confused. scrollDir comes from a custom hook. Hook exposed states can't just be constants. At this point I genuinely thought React changed how hooks and state work. It didn't. What actually changed is 𝗲𝘀𝗹𝗶𝗻𝘁-𝗽𝗹𝘂𝗴𝗶𝗻-𝗿𝗲𝗮𝗰𝘁-𝗵𝗼𝗼𝗸𝘀 𝘃𝟳. This version bundles React Compiler lint rules by default, including a brand new rule called 𝘀𝗲𝘁-𝘀𝘁𝗮𝘁𝗲-𝗶𝗻-𝗲𝗳𝗳𝗲𝗰𝘁. When you scaffold fresh today, the Vite template pulls in the latest packages, and these compiler rules come along silently. No announcement, no migration guide, no warning that your existing patterns will now be flagged as errors. This rule is not saying your code is broken. It is saying: this state can be derived directly during render. You do not need useEffect here at all. The fix is called derived state. A pattern React always recommended, just never enforced until now: // 𝗻𝗼 𝘂𝘀𝗲𝗦𝘁𝗮𝘁𝗲 𝗳𝗼𝗿 𝘃𝗶𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆, 𝗻𝗼 𝘂𝘀𝗲𝗘𝗳𝗳𝗲𝗰𝘁, 𝗷𝘂𝘀𝘁 𝗱𝗲𝗿𝗶𝘃𝗲 𝗶𝘁 𝗰𝗼𝗻𝘀𝘁 𝘀𝗰𝗿𝗼𝗹𝗹𝗗𝗶𝗿 = 𝘂𝘀𝗲𝗦𝗰𝗿𝗼𝗹𝗹𝗗𝗶𝗿𝗲𝗰𝘁𝗶𝗼𝗻(); 𝗰𝗼𝗻𝘀𝘁 [𝗶𝘀𝗙𝗼𝗰𝘂𝘀𝗲𝗱, 𝘀𝗲𝘁𝗜𝘀𝗙𝗼𝗰𝘂𝘀𝗲𝗱] = 𝘂𝘀𝗲𝗦𝘁𝗮𝘁𝗲(𝗳𝗮𝗹𝘀𝗲); 𝗰𝗼𝗻𝘀𝘁 𝗶𝘀𝗩𝗶𝘀𝗶𝗯𝗹𝗲 = 𝗶𝘀𝗙𝗼𝗰𝘂𝘀𝗲𝗱 || 𝘀𝗰𝗿𝗼𝗹𝗹𝗗𝗶𝗿 !== "𝗱𝗼𝘄𝗻"; If you recently scaffolded a fresh React project and are seeing errors you never saw before, check your 𝗲𝘀𝗹𝗶𝗻𝘁-𝗽𝗹𝘂𝗴𝗶𝗻-𝗿𝗲𝗮𝗰𝘁-𝗵𝗼𝗼𝗸𝘀 version. If it jumped to v7, the React Compiler rules are now active in your project whether you opted in or not. Most tutorials haven't covered this yet. The npm package itself was updated just days ago, at the time of writing. So if you're confused, you are not alone and you are not doing it wrong. One full day lost. But I now understand React's rendering model better than I ever did from any tutorial. #ReactJS #Frontend #WebDev #ReactCompiler #ESLint #JavaScript #LearnInPublic

𝗘𝗿𝗿𝗼𝗿𝘀-𝗮𝘀-𝘃𝗮𝗹𝘂𝗲𝘀 𝗽𝗮𝘁𝘁𝗲𝗿𝗻 𝘃𝘀 𝗘𝗿𝗿𝗼𝗿𝗦𝗰𝗿𝗶𝗽𝘁 Today, the only safe way to handle errors in TypeScript is to use errors-as-values. 𝗘𝗿𝗿𝗼𝗿𝗦𝗰𝗿𝗶𝗽𝘁 opens a different possibility – make the exception channel visible and type-safe. Let’s see how this affects our code. ✅ 𝗪𝗵𝘆 𝗲𝗿𝗿𝗼𝗿𝘀-𝗮𝘀-𝐯𝐚𝐥𝐮𝐞𝘀 𝘄𝗼𝗿𝗸𝘀 𝘄𝗲𝗹𝗹 Libraries like ErrorE explore this style by making failures explicit in the return type, so the caller can see, compose, and handle them safely without relying on an invisible exception channel. When a function can fail, that possibility is represented in the value it returns. The failure is not hidden somewhere outside the normal type flow – developers are forced to handle it. The trade-off of this forced locality is that the error path becomes part of the happy path. You must unwrap, map, branch, return early, or compose results through each layer, which adds visible plumbing. With multiple error paths, this plumbing can obscure the intent of the happy path. 🧪 𝗪𝗵𝗮𝘁 𝗘𝗿𝗿𝗼𝗿𝗦𝗰𝗿𝗶𝗽𝘁 𝘁𝗲𝘀𝘁𝘀 ErrorScript explores a different trade-off: what if failures could propagate naturally, but remain visible to the compiler? Instead of pushing every modelled failure into the returned value, ErrorScript treats exceptions as typed effects. The goal is to preserve code readability while the main flow stays focused on the successful path, and the failure path is impossible to ignore. You cannot do this safely in TypeScript today. You can write code where failures propagate through exceptions, but TypeScript will not prove that the caller handled them. It will not infer a precise thrown type at the call site. It will not give the catch block a type connected to the function that failed. ⚖️ 𝗧𝗵𝗲 𝘁𝗿𝗮𝗱𝗲-𝗼𝗳𝗳 With ErrorE-style code: • failure is explicit in the returned value • only local reasoning is possible • TypeScript can already enforce the model safely With ErrorScript: • failure can propagate outside the returned value • happy-path code can remain cleaner • handling boundaries can be chosen higher up the call stack • the cost is non-local reasoning and a more complex type model That non-locality matters. With ErrorScript, a function’s behaviour depends not only on what it returns, but also on what the functions it calls may throw or reject with. The compiler makes that visible, but the reader still has to reason across call boundaries. The interesting question is about language design: do we want to enforce locality, which encourages more verbose plumbing, or allow non-locality, which allows error paths to be grouped in a different place to the main path, but may encourage some extra complexity?

𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗦𝘁𝗿𝗶𝗻𝗴𝘀 𝗹𝗼𝗼𝗸 𝘀𝗶𝗺𝗽𝗹𝗲. 𝗧𝗵𝗲𝘆'𝗿𝗲 𝗻𝗼𝘁 Here's the short version: Strings power almost every real-world app: form validation, APIs, text processing, i18n, frontend rendering. Yet most developers never look under the hood. Here's what changes when you do • Strings are immutable Every "modification" creates a brand new string in memory. No in-place edits. Ever. • UTF-16 encoding explains the weird .length behavior "😀".length === 2, not 1. Emojis and many Unicode characters use two code units — not one. • Primitive vs Object — they are NOT the same "hello" and new String("hello") behave differently in comparisons, typeof checks, and method calls. Mixing them up causes silent bugs. • charCodeAt() is the wrong tool for Unicode Use codePointAt() and String.fromCodePoint() instead. They handle characters outside the Basic Multilingual Plane correctly. • Tagged templates are massively underused Template literals aren't just cleaner concatenation. Tagged templates power SQL sanitization, CSS-in-JS libraries, and GraphQL query builders. • Intl.Segmenter exists for a reason Splitting text by spaces breaks for many languages. Intl.Segmenter handles proper word and grapheme segmentation — essential for i18n. • V8 doesn't store strings the way you think Internally, V8 uses ConsStrings, SlicedStrings, and String Interning to avoid redundant allocations and boost performance behind the scenes. 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆 Understanding strings deeply = cleaner, safer, more performant code. The smallest data type often teaches the biggest engineering lessons. What's a string behavior that caught you off guard? Drop it below #JavaScript #WebDevelopment #FrontendDevelopment #V8Engine #Programming #SoftwareEngineering #LearningInPublic #DeveloperJourney #ECMAScript

Rust Rewrites: Are they worth it? A rewrite only pays off when the bottleneck is structural, not just messy code. P99-style field reports still shape expectations:  - Datadog's Go: Rust Lambda extension cut cold starts ~80% and memory ~50% - Turso/libSQL cites: 500× gains in narrow SQLite scenarios.  But does that justify a rewrite? Classic consultant answer: It depends specifically on the use case. Basically, you can read time and again here on LinkedIn and across the web: 1. The ownership system prevents entire classes of bugs. 2. The type system forces you to resolve errors at compile time, not in production 3. No garbage collector, no runtime pauses 4. Zero-cost abstractions 5. Fearless concurrency Most of the time, this means that the performance, robustness, and maintainability of the codebase increase. Now to the actual question: What is your use case? Java / C# / Go / Server Backends Suitable for CPU-intensive hot paths, GC pauses, if you want to scale vertically instead of horizontally, or for long-term domain logic. Not suitable if your team needs to iterate quickly and the domain is still changing significantly. Embedded / System-level programming Rust is becoming increasingly important here. No GC, no overhead, memory safety without a runtime. C is the classic comparison here. Rust wins in the medium term as the codebase grows. Ferroscene is also a good choice for use in areas subject to certifications such as ISO 26262 or IEC 62304 - mind re-cert costs! WebAssembly / Web Frontends Rust generates smaller WASM modules; only Zig might be a viable alternative. This offers a real advantage for performance-critical browser logic, cross-platform apps, or edge computing. The JS glue code is a pain, but that’s improving too. Mobile Rust works flawlessly as a common logic layer for iOS and Android, e.g., with Crux. The effort is particularly justified when the business logic is complex and stable enough to be written well once and for all. Desktop Tauri instead of Electron/Qt bindings/GPUI, Slint; smaller bundles, less RAM. However: The ecosystem for desktop GUIs in Rust is still young, so integration into Tauri and existing native UI technologies like WinUI3, SwiftUI, or GTK is the most worthwhile approach. Tooling No runtime overhead, no GC, statically linked binaries that just work on all major operating systems. Tools like ripgrep, uv, fd, or bat show what’s possible: native performance, minimal dependencies, instant startup. In short: it's always worth it. … Seriously: A rewrite is worth it when three things align: 1. The codebase has a long lifespan ahead of it 2. Performance or security are structurally limited, not just poorly implemented 3. You have experience with Rust or are willing to view the learning curve as an investment that will definitely pay off Have you completed a rewrite? What convinced you, and what did you underestimate? #Rust #SystemsEngineering #SoftwareArchitecture #WebAssembly #Embedded

⚠️ alias_method vs alias_method_chain in Ruby — and the hidden memory trap Most Rails devs use them interchangeably. They're not the same. —————————————————— alias_method — the clean, Ruby-native way Simple. It creates a new reference to an existing method. No magic, no overhead. alias_method :name, :full_name Both point to the same method. Clean, zero cost. —————————————————— alias_method_chain — the Rails legacy pattern Introduced in Rails to allow "wrapping" a method with extra behavior. Looks convenient. But here's what actually happens: Every chain adds TWO new method entries into the class's method table. Do this 5 times → 10 ghost methods living in memory. Forever. —————————————————— The memory problem 🧨 Chain it 3 times across modules: → alias_method_chain :full_name, :prefix → 2 methods → alias_method_chain :full_name, :logging → 2 more → alias_method_chain :full_name, :caching → 2 more = 6 method table entries for 1 original method In large apps with dozens of models doing this across initializers and concerns, method table bloat becomes real. Ruby's method cache gets invalidated more frequently, lookup slows down, and memory climbs. This is exactly why Rails 5 deprecated it entirely. —————————————————— The modern replacement: prepend ✅ module WithPrefix def full_name "Mr. #{super}" end end class User prepend WithPrefix end prepend inserts the module before the class in the method lookup chain. super calls the original. No ghost methods. No symbol pollution. —————————————————— Quick comparison: ✅ alias_method → native, memory safe, still supported ❌ alias_method_chain → deprecated Rails 5+, memory bloat ✅ prepend → native, memory safe, stackable, modern —————————————————— The golden rule: If you're reaching for alias_method_chain in 2025, you're solving a modern problem with a legacy tool. Use prepend. Still maintaining a Rails 3/4 codebase full of chains? Now you know where that memory is going. 👇 Drop a 🔥 if this just explained a bug you couldn't find for weeks. #RubyOnRails #Ruby #Backend #Performance #WebDevelopment #SoftwareEngineering

I just stumbled onto something that might change how we think about Ruby performance. 💎 I was digging into my usual Rails workflows when I came across Spinel, a new experimental project by Matz. It’s an AOT (Ahead-of-Time) compiler, and the philosophy behind it really caught my eye. Instead of the usual "magic" we love in Ruby, Spinel compiles a strict subset of the language directly into native C. I took a look at the benchmarks, and the numbers are honestly hard to ignore: 🚀 Logic & Loops: 20ms vs 1,733ms (86x faster) 📊 Data Structures: 24ms vs 543ms (22x faster) 📦 JSON Parsing: 39ms vs 394ms (10x faster) What’s the catch? To get this kind of speed, you have to embrace a more disciplined, minimalist style of engineering. No eval, no send, no dynamic metaprogramming. It’s Ruby, but stripped down to its raw, high-performance core. Is it ready for our Rails apps? Not yet. Our favorite gems and Rails features still depend on that dynamic "magic." But seeing Spinel in action makes me realize that we don't always need every dynamic feature for every task. Sometimes, stripping away the noise is exactly what’s needed to unlock the next level of performance. For production today, I’m sticking with YJIT, but Spinel is a clear signal that Ruby is heading toward a very fast, very interesting future. https://lnkd.in/dxuxypP5 #Ruby #Rails #RubyOnRails #RoR #SoftwareEngineering #Spinel #Performance #MinimalistEngineering #BackendDevelopment #Ruby4

The backend was working. The 𝐀𝐏𝐈𝐬 were tested. But it was still just 𝐉𝐒𝐎𝐍 𝐫𝐞𝐬𝐩𝐨𝐧𝐬𝐞𝐬 in a terminal. So I built the 𝐟𝐫𝐨𝐧𝐭𝐞𝐧𝐝. 𝐇𝐓𝐌𝐋, 𝐂𝐒𝐒, 𝐚𝐧𝐝 𝐉𝐚𝐯𝐚𝐒𝐜𝐫𝐢𝐩𝐭 — served directly by FastAPI — connected to every endpoint I'd built: browse products, add to cart, place an order, make a payment. The whole thing now runs locally as one unified app. No React. No separate frontend server. FastAPI mounts the static files and serves the HTML pages directly — which meant I could 𝐬𝐞𝐞 𝐞𝐯𝐞𝐫𝐲 𝐀𝐏𝐈 𝐜𝐚𝐥𝐥 hit my routes in real time while clicking through the UI. What made this click: → The 𝐚𝐮𝐭𝐡 flow actually works end-to-end — login returns a 𝐉𝐖𝐓, the frontend stores it, and protected routes enforce it. → The 𝐩𝐫𝐨𝐝𝐮𝐜𝐭 𝐬𝐞𝐚𝐫𝐜𝐡 𝐟𝐢𝐥𝐭𝐞𝐫𝐬 (price range, keyword) respond instantly. → The cart persists correctly across page navigations. → The 𝐚𝐝𝐦𝐢𝐧 𝐩𝐚𝐧𝐞𝐥 is only accessible after role validation. As an AI student, I usually live in notebooks and model files. Building a UI from scratch that talks to a backend, felt different. It made the whole system feel real in a way that Postman tests don't. 𝐍𝐞𝐱𝐭 𝐬𝐭𝐞𝐩: converting the project into a 𝐋𝐚𝐧𝐠𝐆𝐫𝐚𝐩𝐡 𝐂𝐋𝐈 and Automated 𝐀𝐠𝐞𝐧𝐭 deployment. What's your go-to stack when you need a quick frontend for an AI project — plain HTML, Streamlit, or something else? #FastAPI #WebDevelopment #Python #FullStack #BuildInPublic

Unpopular opinion: that useCallback you wrote "just to be safe" is probably not doing what you think it is. I've been poking around a few codebases lately, and I keep finding the same thing — layers of manual memoization added with good intentions, slowly becoming a trap. Stale closures, wrong deps arrays, functions re-created on every render anyway because someone upstream changed something. Classic. And look, I was doing the exact same thing when I started. Wrapping everything in useCallback felt responsible. Turns out it just felt that way. Here's the thing: React Compiler has been stable for a while now. It figures out memoization at build time, and honestly? It's better at it than most of us are. It doesn't get lazy on a Friday afternoon and forget to update the deps array. The before/after is kind of humbling — same component, same behavior, about half the code. Check out the snippet below. I still write useMemo by hand when I'm doing something actually expensive — big data transforms, heavy sorts, that kind of thing. But wrapping every callback "just in case"? I've made peace with letting the compiler handle that. If you're on React 19 and haven't flipped the switch yet, you're writing more code to get worse results. That's a rough deal. What's the first thing you deleted after enabling React Compiler? I'm curious if anyone else had that "wait, this whole file?" moment. #React #Frontend #WebDev #TypeScript #ReactCompiler

Eighteen months after React 19 introduced the stable compiler, the biggest win for engineering teams has not been about raw performance, but about the permanent eradication of an entire class of human error. When the React Compiler initially shipped, the industry largely anticipated massive benchmark improvements and instantaneous rendering speeds. However, a year and a half into its lifecycle, the true impact of the compiler has proven to be far more architectural than purely performant. The compiler has effectively automated the cognitive overhead of memoization, quietly eliminating notorious bugs caused by forgotten dependencies and stale closures. Instead of developers spending countless hours debugging dependency arrays in hooks, the compiler handles these intricacies reliably under the hood. This shift has sparked ongoing debates within the community regarding whether the Rules of React should be treated as a strict, hard contract rather than a loose set of best practices. While some argue that this strictness removes flexibility, others recognize that offloading complex mental models to a compiler leads to substantially more stable codebases. Ultimately, the compiler's legacy is defined by its ability to protect developers from themselves, ensuring that applications scale with far fewer subtle runtime errors. This evolution represents a critical shift in how we deliver value. When foundational tools like the React Compiler automate away the tedious, error-prone aspects of state management, it drastically reduces the time spent on bug-hunting during the QA and client review phases. This allows teams to redirect their engineering bandwidth toward solving complex business logic and architectural scaling challenges rather than fighting the framework. For clients, this translates into faster feature delivery, lower long-term maintenance costs, and a higher baseline of stability for their enterprise applications. Furthermore, as the broader tech ecosystem increasingly adopts strict compilation contracts, the industry as a whole is moving toward a standard where code correctness is guaranteed by the tooling itself, raising the bar for what clients should expect from a finished product. Have you noticed a measurable decrease in state management bugs since your teams adopted the React Compiler #SoftwareEngineering #ReactJS #WebDevelopment #DeveloperTools https://lnkd.in/emmpHBT9

I've built production backends with both FastAPI and Express.js. Here's my no-BS comparison for 2026. FastAPI (Python): → Auto-generated API docs (Swagger/ReDoc) — zero extra work → Type validation with Pydantic — catch errors before they hit your DB → Async by default — handles concurrent requests beautifully → Perfect for ML/AI backends (Python ecosystem) → 3x less boilerplate than Flask Express.js (Node.js): → Massive ecosystem — middleware for everything → Same language as frontend (JavaScript/TypeScript) → Websocket support is more mature → Easier to find developers who know it → Battle-tested at massive scale (Netflix, PayPal) My decision framework: Choose FastAPI when: • Your app involves ML models or data processing • You need auto-generated documentation • Type safety is non-negotiable • Your team knows Python Choose Express.js when: • Full-stack JS/TS is your goal • Real-time features are core (chat, live updates) • You need maximum middleware flexibility • Your team is JavaScript-first My current default? FastAPI for AI-heavy backends. Express for everything else. What's powering YOUR backend in 2026? . . . . #FastAPI #ExpressJS #Python #NodeJS #BackendDevelopment #APIDesign #WebDevelopment #TypeScript #Pydantic #SoftwareEngineering #FullStack #REST #WebFramework #TechComparison #Programming #DevCommunity #AsyncProgramming #MLOps #BuildInPublic #TechStack2026