I wanted a clock that, annoyingly, didn't seem to exist.

Since childhood, my bedside clocks have been a series of red, seven-segment LED clock-radio specials from Walmart or Target. They are invariably cheap, simple, and long-lived—but they require manual intervention at the start and end of Daylight Saving Time and whenever the power flickers. After a recent power flicker, as I found myself standing by the sideboard holding down "TIME" and mashing the "HOUR" button, frustration boiled over, and I thought to myself, "We're a quarter of the way through the 21st century. There has to be a better way!"

My perfect clock would be self-setting. It would offer auto-DST adjustment (or not, depending on how this bill fares!). It would manage drift and always show the exact sub-second time. It would show that time on a red seven-segment display—not blue, not green, not yellow, and absolutely not white. And I shouldn't have to install any privacy-destroying garbage apps to make it work.

Read full article

Comments

© Lee Hutchinson

If there is a driving theme to The Java Story documentary, which debuted Friday on YouTube, it would be that even some of the most important and popular technologies come from humble beginnings. In this case, we're talking about a language that started life as a failed attempt at set-top box dominance and required a massive rewrite just days before its big conference debut. Today, Java consistently hovers near the top of the TIOBE programming language popularity index and remains widely used for large enterprise applications. But at one point in 1994, Sun Microsystems was just about to abandon the effort. Tim Lindholm, who was hired to polish up a virtual machine runtime for what would become Java, told The Register, “I was one of the last people hired before the whole thing fell apart.” It wouldn’t be the last time Java outlived its detractors. Java chronicled If the idea of a professionally produced documentary about a programming language sounds familiar, then you’ve probably seen the ones on C++, Python or React. These were the work of tech job site Honeypot.io, which funded the documentaries to build a user base. In 2019, Honeypot was acquired by XING (which rebranded as New Work SE). However, founder Emma Tracey was more interested in the documentary side of things and bought the production shop back from New Work, reuniting the original gang and rebranding their efforts as Cult.Repo (short for Culture Repository). The Java Story is the first product of the newly liberated media company. The documentary features many of Java’s prime movers, including creator James Gosling and senior Oracle Java architects Mark Reinhold and Brian Goetz. While it may have taken a Hollywood-style effort to construct a Hero’s Journey around the plodding progress of Python, Java is a veritable Love Island of dramas, some of which were this documentary captured. The project that almost wasn’t Lindholm strayed into the computing field only as a result of the brutally cold winter of Minnesota, where he was living in a tent. He realized he would need someplace warmer and so scored an internship at Argonne National Laboratory in Illinois. There, he gained early experience with virtual machines thanks to the lab’s use of Prolog. His goal was not to be a programmer, but a mathematician. “Computer science was for people who couldn't be real mathematicians,” he said. But he learned the craft of implementing Prolog. “I learned to write to very high-quality virtual machines with things like garbage collection and embeddability,” he said. The VM experience led him to subsequent jobs at Xerox PARC and eventually Sun. When Lindholm arrived 1994, it was to work for an experimental “spin-in” subsidiary called FirstPerson. At the time, Sun made bank selling high-end workstations to engineers, but it wanted to build software for devices outside the typical workstation and PC market. FirstPerson’s chief concern was a bid from Time Warner to provide the interactive video-on-demand software for television set top boxes. Gosling wrote a language and runtime for the project, called Oak. The contract ultimately went to late bidder Silicon Graphics – a Sun rival commonly known as SGI. In a lesson of not always getting what you want, the Time Warner project struggled for a few years before the plug was pulled in 1997, which didn’t do the already-struggling SGI any financial favors. But at the time, Sun took the defeat hard, laying off most of the FirstPerson staff. Lindholm had been there for only a month and wasn’t overly invested in the set top box. “I'll do whatever comes next,” he recalled. Sun kept only 12 engineers to work on Oak, including Gosling and project manager Kim Polese. But for Lindholm, the future didn’t look promising. “We were like refugees in a bombed-out bunker,” he said. Those who were laid off tossed their office gear out into the hallways. Lindholm felt like “dead meat” at the Sun office, just waiting to get laid off himself. Pivot to the Web It was purely serendipitous that the project moved to the then-nascent web. One of the surviving engineers had been playing with the recently released Mosaic browser and suggested the World Wide Web should be Oak’s next target. This was a year before Windows 95 brought the internet and web browsing to the masses. The team built a Mosaic clone called WebRunner on Oak that would run animations. It would be the precursor to what would become Java applets. After that, events moved quickly, Lindholm recalled. Oak was renamed Java in early 1995, supposedly as a nod to the engineering team’s coffee consumption. “It took off like a friggin’ rocket. It was just crazy. We were all stressed,” he said. An early wave of web developers was rapidly discovering the limits of creating web pages using HTML, which, after all, is a markup language. Gosling and the crew had assembled a rough prototype, but it fell to Lindholm, alongside fellow new hire and Lisp expert Frank Yellin “to make this thing actually work.” The pair were in charge of the commercial grade implementation, ensuring that the advanced concepts Gosling had outlined, such as threading and garbage collection, functioned in the real world. Lindholm and Yellin later co-authored the original JVM specification. Threading at the time was particularly new. There were no libraries they could use to implement the idea, and Lindholm knew relatively little about the concept. The company planned to introduce Java at the 1995 SunWorld convention, the precursor to JavaOne. But the runtime was crashing badly. After much sleuthing, Lindholm figured out Java’s threading model was “fundamentally broken. It was totally screwed up,” he said. The problem was that system interrupts were being issued while the SPARC processor was executing an instruction. This proved disastrous because the system could not recover the state that had been flushed from memory and would therefore “die horribly.” Lindholm realized you could only have the interrupts happen at certain points. So, three days before the conference, he rewrote the entire threads package. At the conference, when then Sun CEO Scott McNealy showed off Java, Lindholm sat in the audience dreading the worst. Thankfully, the rewrite worked. Before open source Lindholm was also in charge of the language’s first attempt at open source, years before Eric Raymond made the term common. The company offered the binary Java runtime as a free download, but the company gave away “the sources,” as Lindholm put it, to anyone who requested it. Thousands did. The documentary retells a story that the Java Internet domain was getting so much traffic – more than Sun.com itself – that the Java team ran a pirate T3 line into the office. Such were the days before the cloud. At the time, Lindholm viewed giving away the source as a good career move. Should he ever get the ax, perhaps some other company would pick up the code and run with it. They also found outsiders could fix bugs and even extend the software to other platforms. The “source” program wasn’t formalized, however. Sun did have Richard Stallman come to talk, but he seemed “too radical” for the Sun execs, Lindholm recalled. Sun would not actually decide to officially release Java as open source for another decade. Ironically enough, Java applets were only modestly adopted for the web, as other technologies such as ColdFusion and Netscape’s JavaScript project ended up doing the heavy lifting for Web programmers. But applets were a gateway to the real action, namely powering the back-end servers. The evil empire Then, Microsoft started paying attention. It saw the runtime as a potential threat to Windows itself, particularly for the fledgling Windows NT, which was starting to make headway into the enterprise. For today’s younger generation of IT pros, it is hard to overstate how aggressive and hyper-competent Microsoft could be at that time. In 1996, the company licensed Java for Windows, but then added some additional APIs and declined to support a few others (Anyone remember Microsoft’s J++?). Sun alleged that Microsoft’s changes were intended to undermine Java’s cross-platform compatibility and steer developers toward Microsoft’s Windows-specific implementation. The years-long court case zapped the development team's energy, diverting resources away from Java. “I spent days in deposition talking about this under oath,” Lindholm recalled. The disputes ended with Microsoft paying Sun nearly $2 billion through a series of settlements. “It was personal for us,” he said. A wild ride The documentary goes on to cover the following decades of the language’s growth through to the present day, including the over-engineered era of J2EE and Java EE 5, the glimmer of hope provided by the Spring framework, Sun’s implosion and subsequent acquisition by Oracle, and the flourishing of JVM languages following the release of OpenJDK. Java continued to be a success for Sun, even as its chief business of selling SPARC-based Internet servers fizzled thanks to the influx of low-cost Linux x86 boxes. Lindholm noted that the Java team grew so large that it took over Sun’s headquarters and eventually had to move into the old Apple headquarters. But Lindholm’s passion for Java evaporated by the early 2000s, swamped by the increasingly corporate environment, and so he left for Google, where he would spend the next 20 years until his retirement earlier this year. Looking back to his early involvement, Lindholm admitted “it was kind of a random thing. You can never tell what parts of your life will end up being really significant for whatever reason." Others agreed that Java has been a wild ride. As Java creator James Gosling said in the doc, “What excites me most about the future is the unknown. Lots of things happen, and mostly the interesting ones are the ones you could never predict." ®

Another day, another programming language feels the heat from AI. A prominent Haskell-based software platform is shifting new development to Python, with its founder arguing that Haskell's tooling and ecosystem have been slow to adapt to AI-assisted development. “Haskell is in real danger,” warned Scarf founder Avi Press, in a post entitled “After 7 years in production, Scarf has reluctantly moved away from Haskell.” “AI is here to stay. The people and ecosystems that use it well are going to move much faster than the people and ecosystems that do not.” Press’ post set off a firestorm of controversy within the Haskell community, which is small but vocal, and likely felt the sting of one of its most prominent users defecting to the comparatively toy-like Python to better serve the needs of agents. “Trying to change the language to work better for some metric of ‘better’ with AI is foolish for many many reasons,” wrote one user on Reddit. “It's foolish to try to change to LLMs in a kneejerk fashion because no one knows what's on the horizon.” Putting the fun into functional programming Haskell, a functional programming language that debuted in 1990, may not appeal to fast-moving startups. It ranks No. 46 in the latest TIOBE index of programming language popularity, with a rating of less than half a percent. Favoring recursion and immutable data over conventional imperative loops and mutable state, the language's mathematical underpinnings can intimidate even experienced developers. Nevertheless, it has attracted a highly dedicated following, particularly within academia. Press has been one of Haskell’s most vocal proponents, and has even served on the language’s foundation board. “Learning it made me a much better programmer,” he admitted. Press used Haskell to build Scarf, which provides usage analytics for open source software. In a 2023 talk entitled “Why Haskell is a Terrible Choice for Startups (and why we picked it anyway),” Press admitted it was difficult to find Haskell programmers, yet the language’s rigorous type safety comes with other benefits. Refactoring is a cinch, which is valuable as business priorities change. Also, documents can be auto-generated from data types. Plus, once you get the hang of it, programming in Haskell is downright fun, Press argued. Because AI But going forward, Scarf’s new features will be added in Python instead. “At Scarf, we started doing all new API work in Python,” he wrote. “New API routes go into Python, existing Haskell code keeps running, and over time the new server becomes the main path and our Haskell footprint will shrink.” Press said Python plays better with AI, which is the direction he sees development heading. A huge part of the problem is Haskell's sluggish compilation times. “If an LLM can produce a working implementation in a few minutes, but your compile step takes dramatically longer, then your language and build system have become a bottleneck in the development loop,” he wrote. Long compilation times, once a minor annoyance, become prohibitive when running multiple coding agents at once. Caching can help, but incurs its own overhead to manage. “I want to spin up multiple worktrees, fork off different lines of work, let agents try things, review the results, and keep the useful ones. In that world, cold start time matters a lot,” Press wrote. Rigor for runtime Using Python with AI practices immediately improved the Scarf production team’s workflows, allowing them to fix bugs with minimal oversight, Press noted. In some cases, AI can fix a bug “before I get off the call with a customer,” he noted. “Resisting this kind of productivity is not an option anymore,” Press wrote. Yet, Press doesn’t feel that the Haskell ecosystem is addressing the shift to agentic-led development. Many of the language’s maintainers focus more on restricting the use of AI, or restricting its use on Haskell entirely, rather than looking for ways Haskell can better serve AI, or vice versa, he argued. Agents have different bottlenecks than human code jockeys, he noted. “They are cheap at generating code and expensive when blocked. They benefit from fast feedback, clear examples, low setup friction, and errors that help them repair the code quickly,” he wrote. Press listed ways Haskell could be made easier for agents to use: Better documentation with actual copy-and-paste industry-targeted examples (rather than “beautiful types”), more informative error messages, and – most importantly – faster build times. Optimize and chill Press’ missive set off a firestorm of discussion across Hacker News, X, Reddit and Haskell’s own message boards. Many questioned the move from Haskell to Python, given Python’s own arguably inferior typing. They also questioned whether it would have been a simpler move to optimize the Haskell compiler for faster builds than switching languages altogether. Other Haskell fans voiced more philosophical concerns. It was as if they were taking the language’s tongue-in-cheek motto, “Avoid success at all costs," seriously. Longtime UK-based Haskell programmer Chris Done questioned the motivation of making Haskell more AI-friendly, given that production use is only one way that people use Haskell. “I don’t subscribe to this growth mindset anymore,” he wrote. “I’ve come to accept Haskell on its own terms. If it dies out and becomes irrelevant like Elm or PureScript, I’ll be fine and still enjoy it.” “It leaves a bitter taste in my mouth,” wrote another contributor on the Haskell forum about Press’ post. “I don’t feel like you take our concerns about the harm of AI seriously at all.” Another accused Press of having a financial stake in AI companies (to which Press replied, “Nope”). Haskell Foundation Executive Director José Manuel Calderón Trilla urged folks to chill in an X message. Haskell is a community that prides itself on doing things “the right way,” he noted, but that shouldn’t “let that blind you into thinking that your way is the only ‘right’ way, and then attacking someone for violating your idea of what the party line is.” ®

As AI workloads drive soaring cloud bills, more companies are weighing whether to move computing out of public clouds and into their own data centers. But building and operating AI infrastructure is far more complicated than simply buying servers — networking has become one of the biggest technical hurdles.

That’s the opportunity Seattle startup Hedgehog is chasing.

Founded in 2022 by CEO Marc Austin, a Cisco networking veteran, Hedgehog develops open-source software designed to make private AI data centers operate more like hyperscale clouds. It has raised $11 million in seed funding, with plans to raise a series A financing round.

We caught up with Austin for the return of GeekWire’s Startup Spotlight to learn more about the 20-person company, the AI networking boom and what surprised him most about building a startup in one of tech’s fastest-moving markets.

In 50 words or less, give us your elevator pitch?

Hedgehog is open-source software that makes AI networking simple. AI clouds and enterprises use it to run GPU networks the way hyperscalers do — deployed in hours instead of months, operated by DevOps teams instead of armies of network engineers, on open hardware with no vendor lock-in.

What problem are you obsessed with solving?

Time to GPU value. A GPU cluster is the most expensive asset most companies will ever buy, and every day it sits idle waiting on the network is money burning. That wait is rarely the hardware — it’s the fabric: weeks or months of scarce network engineers hand-designing, cabling, tuning, and validating it across proprietary CLIs and locked-in vendor gear.

Meanwhile the people told to “own the network” usually aren’t network engineers at all — they’re platform and DevOps teams. We’re obsessed with collapsing that timeline: declare your network like intent in Kubernetes and go from racked GPUs to inference in hours instead of months — on open hardware, no lock-in, no room full of specialists. Cloud-grade networking without hyperscaler headcount.

What surprised you after talking to customers?

How rarely the buyer is a network engineer. It’s platform and DevOps teams, often at AI clouds who just took delivery of thousands of GPUs who are told “you own the network now.” They don’t want to learn BGP; they want a network that behaves like the rest of their cloud-native stack. The other surprise: they don’t just want to run the network, they want to sell it by carving up capacity for their own customers, like a cloud provider does.

How has AI changed the way you build your company?

Twice over.

Our product exists because AI broke traditional networking. Training and inference traffic melts networks designed for web apps.

And AI changed how we build: we use it heavily across engineering, testing, and go-to-market, which lets a small team continuously test every supported device and configuration in our lab and ship with hyperscaler-grade rigor. AI raised the bar for what a startup-sized team can deliver.

What’s one thing people misunderstand about your startup?

That “open source” means hobbyist. The opposite is true: openness is the enterprise feature. Our customers can audit every line of code that runs their fabric, extend it, and never get locked in. Nearly every competitor markets “open networking” while shipping a proprietary controller. Hedgehog is the only one that actually publishes the repo.

What’s the toughest decision you’ve made in the past year?

Betting entirely on Ethernet. We decided open, standards-based Ethernet would win AI networking and put everything behind it. Watching the industry’s largest AI operators now standardize on that same approach makes us feel good about the call — but saying no was hard.

What’s the one piece of advice you give to other entrepreneurs?

Pick the wave, not just the surfboard.

Product decisions are recoverable; betting against a structural industry shift isn’t. Find the standard, the architecture, or the buyer behavior that’s inevitable, align everything to it early, and be patient while the market catches up to your bet.

We’ll know our company has made it when…

Networking is boring again. When a platform engineer stands up a multi-tenant GPU cloud and the network is just a few lines of declared intent that nobody thinks twice about. When “network like a hyperscaler” describes every AI cloud, not just the giants running on Hedgehog, then we will have made it!

An AI rewrite of a popular Anthropic-owned JavaScript runtime and toolchain has sparked praise for the speed of its execution, but also criticism of the coding practices behind the project itself. Last week, Bun creator Jarred Sumner announced that he ported Bun from the Zig programming language to Rust in only 11 days, using a fleet of Claude agents running in parallel. The work cost an estimated $165,000 at API pricing, suggesting that software revisions previously considered too large to undertake could actually be feasible now with AI. Sumner said the port was necessary given the growing number of bugs Bun users were finding, including one implicated in the recent Claude Code source leak. But the creator of Zig, Andrew Kelley, didn’t want his project to be seen as the culprit behind Bun’s woes, which he blames on Sumner’s bad programming practices. For Kelley, the move to Rust was not about the feature differences between the two languages, or even the use of AI, but rather “the diverging value systems of the two projects,” he wrote. Bun in the oven Bun is a JavaScript suite consisting of a runtime, package manager, bundler and test runner. Some developers like it because it is a fast one-stop shop that plays well with Node.js. To make Bun speedy, Sumner used Apple's low-memory fast-start WebKit JavaScriptCore (JSC) engine, rather than Google’s stock V8 engine. He used the up-and-coming Zig because he appreciated its performance and low-level control. Anthropic acquired Bun in December 2025. The company built its core state machine on Bun. By then, Sumner had also grown to appreciate AI’s coding abilities, and was using it heavily in the upkeep of Bun. By the time of acquisition, a Claude Bot called RoboBun had been doing a lot of the heavy lifting in the Bun repo. It supplied the most merged PRs of any contributor, fixing bugs and remediating test failures. But as Bun’s user base grew, more cracks started appearing in the code. Users found issues across the software. Anthropic’s 512,000-line code leak in March? That was Bun’s fault, thanks to a bug in the bundler that generated source maps during builds even when told not to, NodeSource reported. All these bugs weren’t Zig’s fault, Sumner explained in a blog post last week detailing the migration. Bun’s architecture mixed garbage collection and application-driven memory management. Sumner admitted that Zig wasn’t designed for that task. Rust was just better at automating memory management. The Rustification of Bun Rewriting 500,000 lines of Zig into another language would be a gargantuan undertaking if done by hand. “A rewrite in another language would take a small team of engineers a full year. It would mean freezing bugfixes, security fixes or feature development for that time,” Sumner wrote. Instead, Sumner went with Claude. He spun up about 50 dynamic Claude Code workflows, reaching a peak of about 1,300 lines of code per minute and generating over a million lines of Rust code. The job took 11 days and cost about $165,000 at API pricing. Claude Fable did most of the heavy lifting. The Rust-based Bun was then subjected to Bun's exhaustive test suite of more than one million assertions. According to Sumner, it passed 100 percent of those tests across all supported platforms without skipping or deleting any. “There’s absolutely no way an engineer with that salary would’ve been able to achieve the milestones Claude did in 11 days,” an impressed HashiCorp co-founder Mitchell Hashimoto noted on X. Zig zags But does Bun’s speed of execution betray the core tenets of good software development? One person not impressed has been Zig’s Kelley, who shared his misgivings in an impassioned post entitled “My Thoughts on the Bun Rust Rewrite." Even before the Anthropic acquisition, “we became increasingly horrified at the programming practices we saw in Bun's codebase,” Kelley wrote. Bun was one of the largest and highest profile projects using Zig and, up until the Anthropic acquisition, a regular financial contributor to The Zig Software Foundation. In Kelley’s view, the project aggressively released new features, resulting in piled-up bugs, bad error-handling code, and technical debt. Sumner “was already writing slop well before he had access to LLMs,” Kelley quipped. He speculated that Sumner may have been under pressure to meet business objectives rather than technical ones, a pressure that increased with Anthropic’s acquisition. In fact, Bun’s codebase had grown so suspect in Kelley’s estimation that Bun parting with Zig was good news. As he put it, no longer would “the publicly presumed poster child for Zig programming language actually [be] the prime example of How Not To Write Zig Code,” he wrote. The Bun team also tried to upstream some of its AI-assisted work to Zig, to no avail. Leading up to the Bun rewrite, the team maintained a fork of Zig that it said improved debug compilation speed fourfold, as eagle-eyed Reg reporter Tim Anderson revealed in May. But the Zig project would not accept Bun’s changes, citing a policy of not accepting AI-based contributions. Zig had been getting an influx of LLM-generated submissions, most of dubious quality. This lack of engineering oversight around AI-generated code would lead to countless problems down the road, Kelley reasoned. Kelley pointed out that if Bun’s tests missed these bugs in Zig, how would they be caught in unsupervised Rust code? “The argument for shipping all the million lines of unreviewed code is that the test suite is good enough to catch everything,” he wrote. “It's not sufficient to catch bugs in Zig code but it is sufficient to catch bugs in [a] million lines of unreviewed slop?” ®

"Idempotent" may be jargon, but the term performs an important job in HTTP as a hall pass that gives reverse proxies and gateways the go-ahead to cache complex query responses and automatically retry failed requests. HTTP has long allowed automatic retries for idempotent methods, but complex queries are often sent using POST, which intermediaries cannot safely assume is retryable. Developers have worked around that limitation for decades. The Internet Engineering Task Force (IETF) has published a new HTTP request method, QUERY (RFC 10008), joining familiar methods including GET, POST, PUT, and PATCH. In development since 2021, the QUERY request method provides a way for an HTTP client to make an idempotent request to an HTTP server. An idempotent request has the same intended effect whether it is sent once or multiple times (so retrying it should not charge a user's credit card again). The specification defines QUERY as safe and idempotent, and the solution was surprisingly simple. "Thanks to QUERY, we finally have functional HTTP caching for complex requests. Proxies, CDNs, and browsers can now cache requests with a body. This is huge for performance," writes developer Elie Treport in a recent blog post. Query operations have traditionally used the GET method. HTTP defines GET as safe and idempotent, as it made no changes to the server itself, but GET becomes awkward when the query data is too large or complex for a URI. The idea behind GET was to load all the necessary query parameters onto the form's URL, resulting in a very long string that the browser sent to the server. Many search services still work this way, appending query parameters to the URL after a question mark. Those URLs can expose sensitive data through browser histories, server logs, and bookmarks. Festooned with nested filters, sort rules, date ranges, and other database flotsam, GET URLs can become unwieldy. HTTP recommends support for URIs of at least 8,000 octets, but there is no universal maximum, so an oversized URL may be rejected by any of the systems it passes through. Long query strings are also a pain to read and debug. Faced with these Franken-URLs, many developers turned to POST instead. POST can carry query data in the request body, but its semantics do not tell intermediaries that the operation is safe and idempotent. The method is more commonly associated with operations such as submitting form data, uploading a PDF, or creating and modifying resources. For a basic HTML form, switching to moves the encoded form data from the URL into the request body. Crafty developers soon began placing complex query payloads, often encoded as JSON, in POST request bodies and having their applications process the responses. Many APIs adopted the pattern; GraphQL, for example, commonly uses POST for queries, although it also supports GET. It was a hack, though. This was not what POST was designed for. HTTP defines POST as neither safe nor idempotent by default. A POST request could change the server's state. And this is why internet networking software treats POST far more delicately than GET. Intermediaries generally cannot reuse POST responses for later POST requests or automatically retry POST without knowing the operation is idempotent. If the message fails, the browser or gateway will not resend it, necessitating intervention from either the user or the app. QUERY's long road to adoption So basically, QUERY combines request content similar to POST with explicitly safe and idempotent query semantics. No longer will the query URL need to be appended beyond recognition, but, like POST, apps and browsers will get a dedicated space to put their complex query data. Unlike POST, QUERY is a read-only operation, and hence receives the IETF's blessing as idempotent, freeing up HTTP clients and intermediaries to cache and resend QUERY requests after a connection failure. A QUERY request does not ask or expect the server to change the state of the target resource. It's just there to ask a question. Cloudflare and Akamai engineers co-wrote RFC 10008. Both companies provide edge caching for large clients. German internet engineering firm greenbytes also contributed. As a new standard, QUERY still has limited support. The HTML forms standard still only understands GET and POST for ordinary form submission, so it will need to be updated even before the browsers get on board. The good news is that the Web Hypertext Application Technology Working Group is already on the case. However, a whole ecosystem of network software still doesn't understand QUERY and may reject requests using an unfamiliar method. Reverse proxies, load balancers, content delivery networks, API gateways, firewalls, and web frameworks will all need to be updated. "The pattern one would expect is the same seen with other HTTP methods and headers that became standard over the last twenty years: first server-side adoption and dev tools, then consolidation in frameworks, and finally, more slowly, native browser support and JavaScript APIs like fetch()," wrote open source developer Daniele Teti in a blog post. Teti noted that Node.js is adding support in its HTTP module, and the Go programming language is ahead of the game because it can already send custom HTTP methods. Elsewhere, the PHP framework Laravel is already ingesting QUERY. But, as with IPv6, the IETF faces an uphill battle to get the HTTP ecosystem on the same page. ®