Our Blog
Insight, thoughts and trends from our team.
A Little Twisted
Dana sends us a WTF that'll turn your head. She was shopping for new hard drives, and was doing it from her phone, a fairly reasonable tool to use for online shopping these days. She opened the website of one vendor, and it was rotated 90 degrees. Or half-pi radians, for those of us that are more used to sensible units. This was irrespective of any rotation settings on her phone, the website insisted on showing itself in landscape mode. This created quite the unusual appearance when she held her phone in portrait orientation: the browser chrome surrounding the content was in portrait mode, but the page itself was in landscape. Obviously, this is a terrible design choice. But Dana wanted to know more. So she started digging in. There was no sign of this behavior on a desktop, which sure, I'd hope not. Attempting to use wget to download the page caused a 403. Using curl downloaded a JavaScript challenge. Fine, they didn't want bots, but Dana wasn't a bot. Poking around in the network tab of the desktop browser's debugging tools helped Dana learn a few things. First: the line endings in the files were all CRLF, implying that all development happened on Windows machines. Maybe that's not interesting, but in 2026, it feels unusual. Second, the page is setting a PHPSESSID cookie, so clearly the backend is written in PHP. But most important, Dana is able to piece together what she needs to successfully use curl to download the page, once pretending to be a desktop browser, and once pretending to be a mobile browser. With that, she ran a diff to see what changed. The desktop version started with 42 blank lines. The mobile version started with 41. The rest of the pages were substantially the same, with two exceptions. First, the mobile page also added a stylesheet called stylesheet-responsive.css. I assume that name was chosen because irony is dead; nothing about this site is responsive. Second, there was a subtle difference in the body tags. You see, both pages had a body tag like this: <body marginwidth="0" marginheight="0" topmargin="0" bottommargin="0" leftmargin="0" rightmargin="0" bgcolor="#FFFFFF"> But the mobile page, continued from there:
Designing a who-pays-the-fee interface
I still walk around with cash in my wallet. Not a lot of it, but enough to pay for at least a meal plus a drink. Where I live today, most people can get by their day with just their mobile phone. I’ve had friends lose their wallet and not realise until a few days later because they simply didn’t need it. If they misplaced their phone, it’d be a different matter, I’m sure. Paying for stuff and giving other people money happens mostly digitally these days. Not a major deal these days, especially within a country. India has UPI, Brazil has Pix, the Southeast-asian countries have their own digital payment systems often tied to either a national ID or mobile number. Usually, within a country, these systems don’t incur extra fees. If I send my friend SGD10, my friend receives SGD10. Straightforward. Things get more complicated when you’re dealing with cross-border payments. For myself, until 2023 when I ran into some friends I hadn’t seen in a while in Spain during WeyWeyWeb, we were still having trouble paying each other after a meal.
Getting Started With The Popover API
What happens if you rebuild a single tooltip using the browser’s native model without the aid of a library? The Popover API turns tooltips from something you simulate into something the browser actually understands. Opening and closing, keyboard interaction, Escape handling, and much of the accessibility now come from the platform itself, not from ad-hoc JavaScript. Tooltips feel like the smallest UI problem you can have. They’re tiny and usually hidden. When someone asks how to build one, the traditional answer almost always comes back using some JavaScript library. And for a long time, that was the sensible advice. I followed it, too. On the surface, a tooltip is simple. Hover or focus on an element, show a little box with some text, then hide it when the user moves away. But once you ship one to real users, the edges start to show. Keyboard users Tab into the trigger, but never see the tooltip. Screen readers announce it twice, or not at all. The tooltip flickers when you move the mouse too quickly. It overlaps content on smaller screens. Pressing Esc does not close it. Focus gets lost. Over time, my tooltip code grew into something I didn’t really want to own anymore. Event listeners piled up. Hover and focus had to be handled separately. Outside clicks needed special cases. ARIA attributes had to be kept in sync by hand. Every small fix added another layer of logic. Libraries helped, but they were also more like black boxes I worked around instead of fully understanding what was happening behind the scenes.
React 19's Compiler Changes Everything
The patterns that separated senior React developers from their junior counterparts for half a decade are disappearing. The React Compiler automates away the expertise behind useMemo, useCallback, and React.memo boundary placement. Here's what the compiler does under the hood, what senior developers can safely stop doing, and what new competencies define performance expertise in modern React architecture. The End of Memoization as a Skill The patterns that separated senior React developers from their junior counterparts for half a decade are disappearing. The React Compiler automates away the expertise behind useMemo, useCallback, and React.memo boundary placement. This is not an incremental improvement to React performance optimization. The React Compiler (released as a separate opt-in beta package alongside React 19, formerly known as React Forget) replaces manual hint-based optimization with automated static analysis. Rather than asking developers to hint where to optimize, the compiler analyzes component code at build time and inserts memoization automatically. It memoizes at the expression level, which most developers wouldn't do manually across a large codebase. The React Compiler is a separate opt-in tool released alongside React 19, not part of the React 19 package itself. Installing react@19 does not enable the compiler. You must install and configure it separately. Here's what the compiler does under the hood, what senior developers can safely stop doing, and what new competencies define performance expertise in modern React architecture. What the React Compiler Actually Does Under the Hood From Runtime Hints to Compile-Time Optimization A widespread misconception among even experienced React developers is that useMemo and useCallback guarantee memoized results. They never did. These hooks were always hints: React's documentation notes the runtime may in the future discard cached values under memory pressure. React never contractually guaranteed memoization, though current React 18 does not discard cached values in practice. Developers placed them strategically, sometimes correctly, often defensively, and the runtime decided whether to honor them. The React Compiler upends this model entirely. Instead of relying on runtime hints scattered throughout application code, it performs static analysis of component functions and custom hooks during the Babel compilation step. It identifies values, functions, and JSX expressions that can be safely memoized based on their actual dependency relationships, then inserts granular memoization instructions into the compiled output. The critical difference: developers guessed where memoization mattered; the compiler knows, because it traces data flow through every render path at build time. The critical difference: developers guessed where memoization mattered; the compiler knows, because it traces data flow through every render path at build time.
JavaScript Security
I don't know about you, but I started my career as a front-end developer working in a small agency, where no one cared about security. When I changed to work with bigger projects in bigger companies I kept not caring about security because no one had taught me better, and it led me to trouble. Understanding how to secure your JavaScript code can change that and help us to protect our applications and users. This article will explore some security practices that couldn’t hurt JavaScript developers to implement whenever they make sense. Some of the topics above I learned while studying the topic, but there are more ways to make your code safe. I am just sharing some simple ones to get you started.. P.S. Yes, I asked questions to an AI and asked it to help me with examples. P.S.2 Yes, IA created the cover image as I know my weaknesses LOL 1. Keep Your Dependencies Up-to-Date Outdated libraries can expose your applications to security vulnerabilities. Keeping everything up-to-date helps you avoid known issues that have already been fixed. Use a Package Manager: npm (Node Package Manager) is a great tool that helps you manage and update your libraries. Regular Checks: Run npm outdated to see which packages are outdated. Update Regularly: Use npm update to upgrade your packages to the latest versions. npm update # Updates your packages Automate Security Updates: Tools like npm audit identify and suggest fixes for security vulnerabilities. npm audit fix # Fixes packages with known vulnerabilities 2. Use Simple Security Headers Security headers tell the browser how to behave when handling your site's content, which helps prevent some types of attacks like cross-site scripting and data injection. We can use Content Security Policy (CSP), a security header that helps stop unauthorized scripts from running on your site, which can prevent many attacks. Start Simple: Add a basic CSP header that only allows scripts from your site. <!-- Add to the <head> section of your HTML --> <meta http-equiv="Content-Security-Policy" content="script-src 'self';"> This line means only scripts that are part of your website can be executed, not any from elsewhere. 3. Sanitize User Input User input can be dangerous if not handled correctly. Malicious users might try to input data that could harm other users or your site. We should always treat input as untrusted, cleaning the data coming from users to make sure it's safe before using it in your application. When updating the web page with user input, use textContent instead of innerHTML to avoid executing harmful scripts. const userInput = document.querySelector('#user-input').value; document.getElementById('output').textContent = userInput; // Safely add user content to your page And we are safer now friends… These three steps are a great starting point for securing your JavaScript applications. I hope you will take a moment today to review your JavaScript projects. Check for outdated libraries, ensure you're using security headers, and verify that all user inputs are sanitized. Small steps can make a big difference in the security of your web applications., plus, knowing these things will be a differential in your next interview ;) Speaking of Front-End… We have this super cool project we are building that will change the way you do web development 😯
React 19
Lorem ipsum is placeholder or "dummy" text used in printing, graphic design, and web development to fill space where final content will go. It is a distorted, non-sensical Latin text derived from Cicero's 1st-century BC work De finibus bonorum et malorum, used to demonstrate visual layouts without distracting readers with