Last week was a very big one at Web Directions.
We launched Web Directions To Go, that brings our conference experience to your team’s conference room. Premium content, professional production, zero travel.
And we announced that performance.now() the world leading web performance conference is headed to Conffab–you can stream live on October 30 and 31 for just €129 (or the equivalent in your currency). 2 days of the best web performance speakers for a ridiculously low price.
And we’re full steam ahead on 3 end of year conferences–Dev Summit for front and and full stack development teams, Next for Product …
Last week was a very big one at Web Directions.
We launched Web Directions To Go, that brings our conference experience to your team’s conference room. Premium content, professional production, zero travel.
And we announced that performance.now() the world leading web performance conference is headed to Conffab–you can stream live on October 30 and 31 for just €129 (or the equivalent in your currency). 2 days of the best web performance speakers for a ridiculously low price.
And we’re full steam ahead on 3 end of year conferences–Dev Summit for front and and full stack development teams, Next for Product Designers and Product professionals, and Enqueue, something brand new for the WordPress developers and technical pros. The full programs are announced, the seats are filling up (the real ones and the virtual ones).
And of course there’s a huge round up of articles on all things Web, AI, Design and more.
Web Platform & Progressive Web Apps
Why NetNewsWire Is Not a Web App
But what if I wanted to do a web app, in addition to or instead of a native app? I can picture a future, as I bet you can, where RSS readers aren’t allowed on any app store, and we’re essentially required to use billionaire-owned social media and platform-owned news apps. But there are issues with making NetNewsWire a web app.
Source: inessential: Why NetNewsWire Is Not a Web App
I’ve long admired and was in the early days a user of NetNewsWire (originally a Mac and then later iOS app) for reading news feeds, that is, RSS. I’ve long since been using a web-based feed reader, but, for 15 years or more, companies and developers have chased native apps. They’ve been seen as vital when the web has been right there all along. So why wouldn’t somebody simply build a web app instead of a Mac or Windows or iPad or iPhone app? After all, you’ve got one codebase with perhaps a few little variations as opposed to three or four or more. The answer is certainly in some situations not as straightforward. Here Brent Simmons, the long-standing developer of Net News Wire, talks about why it is not a web app.
Why I Gave the World Wide Web Away for Free
I was 34 years old when I first had the idea for the world wide web. I took every opportunity to talk about it: pitching it in meetings, sketching it out on a whiteboard for anyone who was interested, even drawing the web in the snow with a ski pole for my friend on what was meant to be a peaceful day out.
I relentlessly petitioned bosses at the European Organization for Nuclear Research (Cern), where I worked at the time, who initially found the idea “a little eccentric” but eventually gave in and let me work on it. I was seized by the idea of combining two pre-existing computer technologies: the internet and hypertext, which takes an ordinary document and brings it to life by adding “links”.
I believed that giving users such a simple way to navigate the internet would unlock creativity and collaboration on a global scale. If you could put anything on it, then after a while, it would have everything on it.
Source: Why I gave the world wide web away for free | Technology | The Guardian
Tim Berners-Lee radically transformed the world through an act of enormous generosity and vision. It wasn’t the creation of the technologies of the World Wide Web. At the time, in the late 80s and early 90s, hypertext was an area of great interest and excitement both amongst researchers and in terms of commercial applications. Indeed, Berners-Lee’s initial World Wide Web proposal wasn’t met with tremendous enthusiasm by the hypertext community. But in no small part due to the generosity of his, and CERN’s and a much less well-known Robert Cailliau’s act of radical generosity, the world got an open and free set of technologies (initially HTML, HTTP) that transformed the internet into something that reached almost everyone on earth. It has reformed—not always for the better—everything from commerce to politics to the way we interact across the street and around the world. I won’t lay any of the bad that’s come from the web at Berners-Lee and CERN’s feet.
They are the actions of individuals and organisations who took this immensely generous gift and enclosed it, using it for their own particular purposes. Here Berners-Lee describes why he gave away the World Wide Web for free. Many, many, many people have benefited financially far more than Berners-Lee, but none of those have had the impact for good that he has had. The ancient Greeks had the concept of eudaemonia—”a life of meaning, purpose, and virtue rather than mere pleasure or fleeting happiness”. I hope and expect Berners-Lee to have many more years with us. He’s still working on very interesting ideas, like Solid. But I think even at this point of his life, we can look upon it as a life of meaning and purpose and we can only hope, certainly I do, to emulate it at least in some small way.
Tim Berners-Lee Invented the World Wide Web. Now He Wants to Save It
Tim Berners-Lee may have the smallest fame-to-impact ratio of anyone living. Strangers hardly ever recognize his face; on “Jeopardy!”, his name usually goes for at least sixteen hundred dollars. Berners-Lee invented the World Wide Web, in 1989, but people informed of this often respond with a joke: Wasn’t that Al Gore? Still, his creation keeps growing, absorbing our reality in the process. If you’re reading this online, Berners-Lee wrote the hypertext markup language (HTML) that your browser is interpreting. He’s the necessary condition behind everything from Amazon to Wikipedia, and if A.I. brings about what Sam Altman recently called “the gentle singularity”—or else buries us in slop—that, too, will be an outgrowth of his global collective consciousness.
Source: Tim Berners-Lee Invented the World Wide Web. Now He Wants to Save It | The New Yorker
Tim Berners-Lee may be one of the most consequential humans, not just in the last few decades, but ever. Certainly in comparison to his fame or lack thereof. The inventor of the World Wide Web, of HTTP and HTML, and I think as much if not more importantly, the fundamental principles of the World Wide Web embodied in the “World Wide” part of the name. I’m sure Sir Tim is materially very comfortable, but he never strove to convert the success of his technology into monumental wealth.
This is a very New Yorker-style profile which I highly recommend.
AI & Software Engineering
Vibe Engineering
AI AI Native Dev software engineering
I feel like vibe coding is pretty well established now as covering the fast, loose and irresponsible way of building software with AI—entirely prompt-driven, and with no attention paid to how the code actually works. This leaves us with a terminology gap: what should we call the other end of the spectrum, where seasoned professionals accelerate their work with LLMs while staying proudly and confidently accountable for the software they produce? I propose we call this vibe engineering, with my tongue only partially in my cheek.
Source: Vibe engineering
I’m very much with Simon Willison about my dislike of the use of the term “vibe coding,” especially in the broad sense it’s come to be used. When he initially coined the term, Andrej Karpathy meant something quite specific—code generation where the person generating the code didn’t know or care about the code itself, just about the output.
But it has quickly come to be used for essentially all code generation with large language models. But I genuinely believe there is something quite different about a software engineer using these tools under some sort of supervision, perhaps with test harnesses and other processes to ensure the quality of the output, compared with folks who had written little if any software before using them to generate applications whole cloth.
Simon Willison here has coined the term “vibe engineering” to apply to the more judicious and careful use of these tools than simply YOLOing the generation of code. To be quite honest, I am not entirely comfortable with the term “vibe engineering” either, because I think the problem with the term is the word “vibe”.
And if you are optimistic about the capability of code generation tools and their continued improvement (as Simon and I both are), then “Vibe Engineering” will, in short order, simply be “engineering”.
I’m certain when power tools were first introduced, there was quite some scepticism about their use by. many experienced carpenters. These days, we don’t distinguish between a carpenter who uses hand tools and a carpenter who uses power tools. It’s all carpentry.
90%
AI Native Dev LLMs software engineering
Three months ago I said that AI changes everything. I came to that after plenty of skepticism. There are still good reasons to doubt that AI will write all code, but my current reality is close. For the infrastructure component I started at my new company, I’m probably north of 90% AI-written code. I don’t want to convince you — just share what I learned. In parts, because I approached this project differently from my first experiments with AI-assisted coding.
Source: 90% | Armin Ronacher’s Thoughts and Writings
When we hear about AI writing significant percentages of the code in a codebase right now, lot of that has been coming from people selling coding tools, which we can take with at least a grain of salt.
When we hear people sceptical about large language models writing code, very often this comes from a place of belief rather than significant experience.
When I first started using large language models as a software engineer, the better part of three years ago, I found them both astonishing and not particularly good. Often infuriatingly terrible. But the bit that was astonishing gave me a sense that the infuriating part would over time diminish. Which is as it has played out
What I saw, as others around me that I respected did, was something that showed genuine promise. Something that you needed to learn to work with and something that very quickly started to improve. So I think the people best to listen to when it comes to this question of how well large language models can help develop software are the people who are doing it at scale — people who are very experienced software engineers, and who may well have started as being quite sceptical about LLMs for software development, but who have seen the results of using them.
One such person is Armin Ronacher. Armin is the developer of a number of significant open source projects, including Flask. So he’s someone who has earned the right for us to take what he has to say seriously. When he says “AI is writing 90% of the code I was in charge of” then this is something to pay attention to.
Getting AI to Work in Complex Codebases
AI AI Native Dev context engineering LLMs software engineering
It seems pretty well-accepted that AI coding tools struggle with real production codebases. The Stanford study on AI’s impact on developer productivity found: (1) A lot of the “extra code” shipped by AI tools ends up just reworking the slop that was shipped last week. (2) Coding agents are great for new projects or small changes, but in large established codebases, they can often make developers less productive.
The common response is somewhere between the pessimist “this will never work” and the more measured “maybe someday when there are smarter models.”
After several months of tinkering, I’ve found that you can get really far with today’s models if you embrace core context engineering principles.
This isn’t another “10x your productivity” pitch. I tend to be pretty measured when it comes to interfacing with the AI hype machine. But we’ve stumbled into workflows that leave me with considerable optimism for what’s possible. We’ve gotten Claude Code to handle 300k LOC Rust codebases, ship a week’s worth of work in a day, and maintain code quality that passes expert review. We use a family of techniques I call “frequent intentional compaction” — deliberately structuring how you feed context to the AI throughout the development process.
I am now fully convinced that AI for coding is not just for toys and prototypes, but rather a deeply technical engineering craft.
Source: Getting AI to Work in Complex Codebases
One of the themes that emerged at our Engineering AI conference recently was how important context is when working with large language models as a software engineer. We’ve moved far past thinking that prompts are all you need.
There are still many who think that while one day large language models may be useful for software engineers, today it’s useful at most for vibe coding prototypes or toy applications. Meanwhile, some software developers are exploring how we can make best use of these technologies today, and importantly, sharing what they have learned.
If You Are Good at Code Review, You Will Be Good at Using AI Agents
AI Native Dev LLMs software engineering
Using AI agents correctly is a process of reviewing code. If you’re good at reviewing code, you’ll be good at using tools like Claude Code, Codex, or the Copilot coding agent. Why is that? Large language models are good at producing a lot of code, but they don’t yet have the depth of judgement of a competent software engineer. Left unsupervised, they will spend a lot of time committing to bad design decisions.
Source: If you are good at code review, you will be good at using AI agents
Perhaps one day, perhaps even soon, autonomous coding agents will write code for us unattended, will meet the needs we specify for them, and produce perfect, secure, performant, and maintainable code that implements the features we want.
In my experience, and the experience of many, that isn’t the case today. Sean Goedecke gets it right here, I think. He observes that if you are good at reviewing code, you’ll work well with agents. The thing is, reviewing code is something a lot of developers aren’t particularly good at.
AI Coding Hype Overblown, Bain Shrugs
AI Native Dev LLMs software engineering
Software development was one of the first areas to adopt generative AI, but the promised revolution has so far delivered only modest productivity gains, and Bain says only a full rethink of the software lifecycle will shift the dial.
As things stand, generative AI in software development has failed to live up to the hype, the wide-ranging Technology Report 2025 from management consultants Bain & Company says. Two-thirds of software firms have rolled out GenAI tools, but developer adoption is low among those, and teams using AI assistants report a productivity boost of perhaps 10 to 15 percent.
Source: AI coding hype overblown, Bain shrugs • The Register
It should be clear by now that I’m optimistic about the impact of AI and large language models on the process and practise of software development. But as this article in The Register reports, results from surveys and studies often are less positive.
So, what’s going on here? Are the folks like me and many others, many experienced developers, deluded? Caught up in the hype? Well, it’s possible, but based on my conversation with dozens of developers who are using this technology in real-world situations, I’d suggest that certainly doesn’t explain everything. So, what then?
One possibility is that we’re still very early in terms of learning how to best use these technologies, and it is the folks with both considerable experience as software engineers who are also putting very significant amounts of work into developing patterns and practises and processes who are seeing significant gains, while the reflexive and not deeply thoughtful use of these technologies probably won’t lead to particularly positive outcomes.
The 5 Levels of AI Agent Autonomy: Learning from Self-Driving Cars
AI Native Dev autonomous agents LLMs software engineering
How autonomous can AI agents become? We’re keen to access their power, but afraid of their unpredictability. Fortunately, it’s not the first time we’ve faced this problem. Self-driving cars have been grappling with autonomy for a while, and the industry developed a model to describe the different levels.
The autonomy spectrum runs from Level 1 (mostly manual, with some assistance) through Level 5 (full autonomy), giving car makers clear milestones while helping everyone understand where the industry stands.
This framework also works surprisingly well for AI agents, with “Level 0” representing the pre-AI era, and Level 5 being complete automation.
Source: The 5 levels of AI agent autonomy: learning from self-driving cars | AI Native Dev
Guy Podjarny uses the framing of the levels of autonomy from self-driving vehicles for thinking about autonomy and AI agents. Where are we at currently? Where might we end up?
I wasn’t alone 4-5 years ago in thinking that Level 5 autonomy for self-driving vehicles was at least within reach, but that has proven to be illusory.
So, where might we end up in five years’ time when to comes to autonomous agents? Those who are bullish suggest that fully autonomous agentic systems are just around the corner. The lesson we might draw from self-driving vehicles is that might be further off than we think. As the saying goes, the first 80% of the work takes 80% of the effort, the last 20% the other 80%,
AI Ethics & Critical Perspectives
Against the Protection of Stocking Frames
I think it’s long past time I start discussing “artificial intelligence” (“AI”) as a failed technology. Specifically, that large language models (LLMs) have repeatedly and consistently failed to demonstrate value to anyone other than their investors and shareholders. The technology is a failure, and I’d like to invite you to join me in treating it as such.
Source: Against the protection of stocking frames. — Ethan Marcotte
There’s much here I agree with Ethan, which might sound curious given that we focus a lot on AI and large language models on Conffab and at our conferences and in many of the things that I write and the things we collect here at Elsewhere.
Much that Ethan observes about how AI has been positioned and sold are undoubtedly correct. I think they are often overhyped. I think often they are imposed top-down in organisations. I think a lot of the technologies we’re seeing broadly are solutions in search of problems. We hear the word “imagine” a lot of the time from keynotes and elsewhere when CEOs and “though leaders” are attempting to get people to adopt these technologies.
But at the same time, there is no doubt that in the field of software engineering at least, these technologies are already being transformative. Yes, there are stories of inefficiencies, there are studies that seem to demonstrate that these tools may make developers feel they’re more productive than they actually are.
But there are also many extremely experienced software developers who attest to the value these tools bring to their work — not least of which is a newfound enthusiasm that as developers with decades of experience they have found perhaps for the first time in many years.
I think it’s important to engage with these topics. I think it’s important not to be rhetorical, not to cherry-pick the things that suit our position and ignore the ones that don’t. I think it is important to listen to the actual experiences of accomplished software engineers (like Simon Willison and Armin Ronacher).
That’s also why, in particular, I amplify this essay by Ethan, because I think, he is attempting to genuinely grapple with these technologies and their implications and consequences.
Underneath it all, I think, is an observation by Ted Chiang that I keep coming back to. Chiang, the science fiction author, perhaps best known for a short story “The stories of your life”, the foundation for the marvellous Denis Villeneuve movie Arrival.
Chiang observes that fears of technology are in essence fears of capitalism, something that resonates with me and which I largely agree with. Our problem with technology (and this very much applies to AI) is often in reality a problem with capitalism. How many of us are willing or able to stand up and articulate that, and then articulate a project to re-imagine, reshape, and reform capitalism toward better outcomes?
Design & Product Development
Open Social
I believe we are at a similar juncture with social apps as we have been with open source thirty five years ago. There’s a new movement on the block. I like to call it “open social”. There are competing visions for what “open social” should be like. I think the AT Protocol created by Bluesky is the most convincing take on it so far. It’s not perfect, and it’s a work in progress, but there’s nothing I know quite like it.
(Disclosure: I used to work at Bluesky on the Bluesky client app. I wasn’t involved in the protocol design. I am a fan, and this post is my attempt to explain why.)
In this post, I’ll explain the ideas of the AT Protocol, lovingly called atproto, and how it changes the relationship between the user, the developer, and the product.
Source: Open Social — overreacted
Dan Abramov is the co-author of Redux and the creator of Create React App. Someone who has thought deeply about open source software for many years. Here he looks at the parallels between open source and open social, in particular the AT Protocol that underpins BlueSky, but which promises to enable federated social applications in a way that is not beholden to centralised services, the way that traditional social media like Twitter, Instagram, and so on were (and continue to be).
If you haven’t been paying a lot of attention, there is definitely something very interesting happening in this space, with AT Protocol and with Mastodon. It’s hard, given how dominant traditional, centralised social media platforms (which are really products) have been, to break out of thinking about social media in that way. Re-imagining what social media could be in an age of distributed protocols is potentially extremely interesting.
Everywhere.tools
Everywhere.tools is a living collection of open-source design resources. It gathers the experiments, utilities, and side-projects that usually stay hidden in personal repos — and gives them a stage.
Source: everywhere.tools
A great collection of free tools for designers.
Selling Lemons
At this point, it should be obvious how the market for lemons applies to ill-considered AI-generated content. I’ll let you sketch out that argument yourself since it’s fairly straightforward, and this thing is already long enough. Instead, let’s zag and revisit my point earlier about system-gaming becoming the most viable playbook instead of focusing on the product. As a consumer and as a designer, I hope this is a temporary state before a massive recalibration. The primacy of meta-activities—optimizing for algorithms, visibility theater, consumer entrapment, externalization of costs, performative internal alignment, horse-trading amongst a set of DOA ideas—is poison. It is a road to nowhere worth going.
Source: Frank Chimero · Selling Lemons
In an online world where everything promises to be measurable, then it’s only logical that what we measure is what we ultimately optimise for. Frank Chimero here observes these are the outcomes rather than the outputs of the process of developing products.
Our products are merely a tool to achieve those outcomes, not the end in itself. But while it may not make us immensely wealthy, focusing on great outputs, great products, great design, great engineering is something to aspire to.
In the Economy of User Effort, Be a Bargain, Not a Scam
A model with surprising predictive power is to treat user effort as a currency that users are spending to buy solutions to their problems. Nobody likes paying it; in an ideal world software would read our mind and execute perfectly with zero user effort. Since we don’t live in such a world, users are typically willing to pay more in effort when they feel their use case warrants it.
Just like regular pricing, actual user experience often depends more on the relationship between cost and expectation (budget) than on the absolute cost itself. If you pay more than you expected, you feel ripped off. You may still pay it because you need the product in the moment, but you’ll be looking for a better deal in the future. And if you pay less than you expected, you feel like you got a bargain, with all the delight and loyalty that entails.
Source: In the economy of user effort, be a bargain, not a scam • Lea Verou
Drawing lessons from Alan Kay and elsewhere, Lea Verou shares some thoughts on product design and the trade-off between simple and complex user actions and outcomes.
What Is Going On with the Australian UX & Product Design Job Market?
career development Design Product Design UX
I’ve been doing a lot of mentoring last week and the question I keep on being asked is if I understand what is happing in the job market. Which I don’t definitively but I do have some hypothesis.
(warning this turned into a very long article)
Australia’s user experience (UX) and product design job market has shifted since the hiring boom during COVID-19. In 2020–21, organisations invested heavily in digital products to meet lockdown-driven demand, rapidly expanding design headcount.
The technology job market has certainly seen better days, not just globally, but locally here in Australia as well. What’s going on here in Australia, particularly in the UX and product design job market? That’s something Ben Gilmore turns his attention to here.
Web Components & UI Libraries
About This Project · Quiet UI
Quiet is a source-available user interface library for the modern Web. It features 88 accessible, performant, localized, and interoperable components along with an optional CSS reset to streamline development of websites and apps.
You might be curious to learn that Quiet’s components aren’t built with React, Vue, or any other framework. They’re custom HTML elements, or Web Components, which means you can use them in plain ol’ HTML and with your favorite frameworks. Every modern browser has the APIs necessary to support interoperable components that work everywhere. As a result, it makes little sense to continue building UI components in a specific framework. That just promotes lock-in. Many of the world’s largest companies have been using Web Components in production applications for years.
With Quiet, you no longer need to learn a new UI library when you switch frameworks — just take it with you! And since it’s built on top of stable platform APIs, it will continue to work for many years to come.
Source: About this project · Quiet UI
Quiet is a new comprehensive component library for the web which has a very particular foundation. It is built using web components and as such is not tied to a particular library or framework and indeed can be used across a wide variety of modern front-end frameworks. Free for use in open source non-commercial applications, educational settings, and elsewhere. Very reasonably priced for commercial projects. It’s something I will definitely be exploring more for a significant UI overhaul at Conffab that is long overdue.
Design Systems & Process
Design Attractors
This is what I call a design attractor. In chaos theory, an attractor is the stable state toward which a system evolves over time. In design, for a button to be a button, it must also be interactive. This is a design attractor. From there, users expect some visual treatment to distinguish it from non-interactive elements. Exactly what that treatment looks like depends on the local agreements within an organization, but once settled, that’s another design attractor.
Source: Design Attractors
Don D’Amato here uses the analogy of complex systems to get a better understanding of how design systems adapt and evolve.
Engineering Leadership & Management
The Power of Emergence: Why Leaders Shouldn’t Prescribe Every Solution
Engineering Leadership management
As engineering leaders, it’s tempting to prescribe solutions. It feels efficient: you’ve seen this problem before, you know how to solve it, and it seems faster to give the answer than to wait for the team to figure it out. But complex systems don’t reward prescription. They reward emergence. Some of the best ideas don’t come from the top — they surface unexpectedly when people are given the trust and space to explore. Research supports this finding: teams that report higher psychological safety exhibit stronger innovation and higher-quality outcomes, precisely because people feel empowered to take risks and suggest new ideas.
I learned this lesson years ago, in a way I never could have planned.
We’re fans of the idea of emergence here at Conffab, as is David Lewis in the context of engineering leadership. Hear how he thinks good leadership is often about standing back and letting solutions emerge rather than be enforced.
The Promotion Problem in Engineering
Engineering Leadership management
There’s something that’s been bothering me about how we promote engineers.
As an industry we seem to have this default assumption that technical excellence automatically translates to leadership ability. The best coder becomes the senior developer. The person who knows the most about the system becomes the tech lead. The tech lead who can solve the hardest problems becomes the engineering manager.
But somewhere along the way, we forgot that, well, leading people is actually about leading people.
Source: The promotion problem in engineering
All industries struggle with the challenge of finding management and leadership. Clearly, capability within a field is required to lead people well within that field. But do the best individual contributors make for the best managers and leaders? Here Gemma Croad weighs in.
CSS & Frontend Development
The Best CSS Unit Might Be a Combination
There are many articles and established CSS best-practices that rely on determining the correct or best units to use. Now that comparison functions are well supported in CSS, we don’t have to choose.
Source: The Best CSS Unit Might Be a Combination | OddBird
Which units to use for font sizing has been a point of debate and consideration since the earliest days of CSS. For the longest time, pixels were units to be avoided since in at least some browsers, zooming the page (where font sizes were set in pixels) meant the text remained fixed in size. Times have changed, so how should we think about units for text size these days? Miriam Suzanne explores that here, and of course, the answer is “it depends”.
What You Need to Know about Modern CSS (2025 Edition)
We published an edition of What You Need To Know about Modern CSS last year (2024), and for a while I really wasn’t sure if only a year later we’d have enough stuff to warrant and new yearly version. But time, and CSS, have rolled forward, and guess what? There is more this year than there was last. At least in this somewhat arbitrary list of “things Chris thinks are valuable to know that are either pretty fresh or have enjoyed a boost in browser support.”
Source: What You Need to Know about Modern CSS (2025 Edition) – Frontend Masters Blog
Keeping up with developments on the web platform sometimes feels like a full-time job. That’s as true of CSS as it is of JavaScript or DOM APIs. Here the crew at Frontend Masters brings you up to speed with everything new in CSS this year.
Security & Development Practices
Authentication Security in Web Applications: A Comprehensive Guide for Developers
Authentication vulnerabilities remain the leading cause of data breaches in 2025, with 22% of all breaches beginning with credential abuse and an average cost of $4.88 million per incident. As AI-powered attacks and sophisticated threat actors evolve their techniques, understanding both traditional and emerging authentication threats has become critical for developers implementing secure systems. This comprehensive analysis examines the current authentication threat landscape, from OWASP top vulnerabilities to cutting-edge AI-enhanced attacks, providing practical guidance for building secure authentication systems. The research reveals that while traditional vulnerabilities like session management flaws and JWT misuse persist, new threats including Computer-Using Agents and supply chain compromises are fundamentally changing how attackers approach authentication systems.
Source: Authentication Security in Web Applications: A Comprehensive Guide for Developers
Authentication is often one of the weak points or vulnerabilities for web applications. This guide looks comprehensively at different points of weakness and how they can be addressed.
Open Source & Development Tools
JSON Is Not JSON Across Languages
JSON (JavaScript Object Notation) was designed as a simple, lightweight, and human-readable data interchange format, often positioned as a more accessible alternative to XML. It has become the de facto standard for web APIs and system integration. However, while the specification itself is straightforward, different programming languages and libraries can interpret certain aspects of JSON differently. What appears to be a uniform format can, in practice, lead to subtle inconsistencies, edge cases, and implementation details that developers need to be aware of when working across diverse platforms.
Source: JSON is not JSON Across Languages | Dochia CLI Blog
Any front-end developer will use JSON as part of their workflow. So it’s worth this reminder that JSON can have subtle inconsistencies between different platforms.
Why Cloudflare, Netlify, and Webflow Are Collaborating to Support Open Source Tools like Astro and TanStack
Open source is the core fabric of the web, and the open source tools that power the modern web depend on the stability and support of the community. To ensure two major open source projects have the resources they need, we are proud to announce our financial sponsorship to two cornerstone frameworks in the modern web ecosystem: Astro and TanStack.
Critically, we think it’s important we don’t do this alone — for the open web to continue to thrive, we must bet on and support technologies and frameworks that are open and accessible to all, and not beholden to any one company. Which is why we are also excited to announce that for these sponsorships we are joining forces with our peers at Netlify to sponsor TanStack and Webflow to sponsor Astro.
The web is built on open source and the often unpaid labour of people working on standards, as well as countless bloggers and communicators who share their expertise and knowledge about developing for the web and web technologies. We have long, and continue to dramatically undervalue all of these, when we even stop to give them any thought.
So, huge props to Cloudflare, along with Netlify and Webflow, for this new initiative to fund some of the open source projects that empower so much of the web, particularly its front-end.