The High Renaissance, David Welker

In today's sprawling JavaScript ecosystem, Svelte was designed to be a simpler alternative to the React.js front-end framework, and SvelteKit follows the same path, setting out to be a backend framework like Next.js but with fewer headaches and even better support for dynamic content. The new-ish SvelteKit 3.0 release candidate includes an experimental feature called remote functions that rethinks how data is delivered to the browser. “Remote functions make everything else look a bit clunky, including SvelteKit’s load functions and actions,” the project team enthused in the release candidate announcement page. A slender stack U.K. journalist Rich Harris, then a graphics editor at the New York Times, released Svelte 1.0 in 2016 as a JavaScript component builder that didn’t carry all the boilerplate that lumbered React.js. He needed an easier way to build graphical components for NYT online stories. Unlike React, Svelte compiled its code ahead of time, and shipped to the user without much accompanying framework. The fact that Svelte builds components from standard HTML elements also lightens the cognitive overhead for the developer. SvelteKit grew from Svelte to manage back-end chores, such as routing, rendering, and streamlining pages, all in a manner befitting Svelte’s simplicity. SvelteKit has been nipping at Next.js’ heels for a while. A recent benchmark found that SvelteKit’s Server Side Rendering (SSR) function returned an HTML payload three times smaller than Next.js for an equivalent product page — great news for performance-minded web shops. SvelteKit’s remote functions is another method that minimizes overhead – one so radical that adherents say it could disrupt the landscape of remote procedure calls (RPCs). It has been an experimental release since SvelteKit 2.27, though the upcoming v3 will embrace remote functions alongside its traditional load functions as equals (assuming the remaining bugs are sorted). Type-safe data fetching, no page refresh required Remote functions provide a way for individual components on a web page to update their data from the server, without refreshing the page as a whole. This limitation has been a real bummer for coders, who have had to come up with various ways around this issue, but their solutions have tended to be hacky and they often lose type safety in the process. “This is our take on RPCs,” explained Vercel Svelte core developer Simon Holthausen, in a Svelte Society podcast. Server-side, SvelteKit does the typical RPC stuff: validating incoming data requests, querying the database or other data source, and routing the serialized results back to the requesting component. The remote function, written in JavaScript or TypeScript, and compiled beforehand into a lightweight client-side RPC wrapper, performs a fetch call to the server from within the component itself. No special routing or additional boilerplate is required. “You don’t have to worry about where this code is running,“ said developer Scott Tolinski in an episode of a Syntax developer videocast enthusiastically entitled “SvelteKit has solved data loading.” The videocast hosts offered as an example a case where all the content on a site is static, except for a footer on the bottom of each page, which requires updated information. With remote functions, the footer component fetches and refreshes its own server data directly, keeping the data fresh. Traditionally, this would require the whole page either to be marked as dynamic (computationally costly, slow to load) or require the developer to write a top-down route loader (more brainwork, keystroking). “From within a normal Svelte component, you can just straight up import that query or mutation as a function, then call that function in your code,” Tolinski explained. The call is coming from within the client To be fair, the maintainers of Next.js have also addressed part of this problem with Server Functions (formerly called Server Actions), which allow client components to invoke server-side mutations directly. However, unlike SvelteKit's remote functions, Next.js Server Functions were primarily designed for writing data rather than fetching or querying it. Harris now works at Vercel, which sponsors Svelte but owns Next.js. Nonetheless, Vercel supports both approaches, each of which reflects “a broader convergence toward typed, server-side functions callable from the client,” a Vercel spokesperson told us. For Tolinski, though, the upside to Svelte’s remote functions is how seamlessly they fit into the overall Svelte framework. “I’m not saying no other RPC systems have done it as good as this, but it better be as good as this if you want me to use it,” he said. ®

It's an open secret that the major cloud providers don’t actually design their custom silicon from scratch. There's not much value in reinventing the wheel, so they often outsource big and undifferentiated chunks of chip design to IP houses like Broadcom, Marvell, Arm, and others. Google's partner of choice for its Tensor Processing Units (TPUs) has largely been Broadcom — though the chip giant's involvement was only made public earlier this year. However, Google's relationship with Broadcom was apparently never monogamous. In an SEC filing this week, Marvell entered the chat, announcing that the Chocolate Factory had tapped the IP house to develop custom silicon for the search and advertising giant. Among the products slated for development were “custom silicon programs that attach to the TPU ecosystem” including AI inference accelerators, storage controllers, network interface controllers, memory interface controllers, and near memory compute. The SEC filing doesn't go into specifics as to which technologies Google will adopt, nor does it offer any insights into the cloud provider’s relationship with Broadcom. All of the technologies listed in the filing are ones Broadcom is more than capable of furnishing. It also doesn’t mean that Broadcom will stop building TPUs for Google, it simply means Google isn’t putting all its eggs in one IP basket. It's not unusual for cloud providers to acquire technologies from multiple vendors to ensure they're always getting the best deal. Networking is a prime example. Of course that didn’t stop Wall Street from dumping shares of Broadcom Wednesday, sending its stock price down about 4% as of late afternoon trading. Marvell clearly expects this deal to be a major revenue driver for the company going forward, and it issued Google a warrant to acquire nearly 59 million shares worth roughly $12.2 billion. Whether Google will actually exercise the warrant is an open question. Doing so would embroil the company in a years-long chip design collaboration. But, looking at Marvell's tech stack, it's not hard to see why Google might be interested. Over the past few years, Marvell has developed a comprehensive suite of hardware IP, including high speed SerDes used in network switches and NICs, multi-die XPU reference designs, CXL memory controllers, and silicon photonics interconnect. Google could have licensed all these things from Broadcom, but now they're in a position to pit the two companies against each other on price and performance. So where might we see Marvell's tech appear first? If we had to guess, Google's interest in Marvell may stem from the photonic memory tech it acquired from Celestial AI late last year. Unveiled earlier this month, Marvell's new Photonic Fabric NIC and Photonic Fabric chiplet technologies allow multiple racks up to 50 meters away to share a common memory pool. Google's TPUs rely on high-speed optical circuit-switched links to talk to one another. One could imagine Google using this tech to dynamically reallocate additional memory to different TPU clusters based on the workload rather than needing to attach memory in a fixed ratio. And because the link is optical, the memory in question doesn't need to be in the same system or rack; that memory becomes a fungible resource. Of course, this is all speculation. Marvell has no shortage of IP that Google might be interested in, including SSD and CXL controllers and XPU reference designs. Or could simply be that Alphabet CEO Sundar Pichai wants to avoid becoming overly reliant on Broadcom lest Hock Tan get any ideas like hiking up prices the way he did on virtualization tech following the VMware acquisition. Or could be that Marvell’s tech is just better for the specific use cases Google is currently developing for. ®

There's a new and very helpful use case for AI coding agents: designing drivers for devices, such as old printers, that were never meant to work with a particular operating system. Kuber Mehta, a New Delhi, India-based developer and founder of PolyThink, has published an account of how he coaxed Anthropic's Claude Code into creating a macOS driver for his HP Laser 1008a, for which HP offers only Windows and Linux drivers. "My HP Laser 1008a is a rebadged Samsung host-based printer that speaks a proprietary raster language (SPL3), and it has no macOS driver and no AirPrint," Mehta explained in a blog post. "So on paper it just does not print from a Mac. This is the (lightly redacted) transcript of me and Claude Code getting it working anyway." The GitHub repo for the driver – published under an open source MIT license – outlines the problem, which is that none of the common connection options work. There's no support for AirPrint, PostScript, or PCL (Printer Command Language), and SPL/QPDL drivers didn't work. What Mehta and Claude did was create a patch to SpliX, an open source driver for SPL2- and SPLc-based printers made by Samsung, Xerox, Dell, Lexmark, and Toshiba. Mehta's series of social media posts about the project appears to have touched a nerve. The discussion elicited appreciation for what people see as a positive use of technology, one that recognizes the finicky nature of printers and offers hope that old devices are potentially salvageable. Mehta's conversation with Claude Code took around 30-40 prompts and cost about 4 percent of his monthly usage. It's worth reviewing for anyone unfamiliar with AI model interaction because it illustrates how the model – Opus 4.8 in this case – makes confident statements that have to be corrected and often characterizes its remarks as "honest" (a behavior drilled into Opus 4.8). The project also serves to validate one of the often-cited benefits of AI tools – that they allow people to participate more broadly in the way they use software. Writing a device driver traditionally required specialized programming knowledge, and Mehta, by his own admission, "knew very little about macOS drivers but learned along the way." While it's fair to say that AI assistance encourages people to tackle tasks they're not really prepared to manage on their own, the sense of enablement is clearly catching, despite the technical debt being generated. Others have also used AI coding agents to come up with ways to make their printers more functional. Vercel CEO Guillermo Rauch articulated the sense of possibility that animates the AI-pilled in a social media post about the general utility of AI. "Every idea you shelved as 'too ambitious' is now back in play," he said. Indeed, every shelved idea is becoming software. There were about 1 billion commits to GitHub in 2025, according to Kyle Daigle, chief operating officer at GitHub. If current trends continue, that figure could reach 14 billion by the end of 2026. Enjoy the abundance while it lasts. ®

Why a debate over a hit cartoon is more than culture-war madness.

ZAGREB (ANP) - De Nederlandse turners zijn er bij de EK in Zagreb niet in geslaagd zich te plaatsen voor de finales. Elijah Faverus, Jordi Hagenaar, Amine Abaidi, Jermain Grünberg en Loran de Munck kwamen tot een totaal van 238,928 punten en de negende plek in het landenklassement. De beste acht teams plaatsten zich voor de finale. De negende plek van Nederland levert de ploeg wel een teamticket op voor de WK in Rotterdam, in oktober dit jaar. Daarvoor was een plek bij de beste dertien landenteams vereist.

Individueel kwamen de Nederlandse turners ook tekort voor een plek in de toestelfinales. De Munck, tweevoudig winnaar van EK-zilver op voltige (2022 en 2024), had aan 14,200 punten niet genoeg voor de voltigefinale en is tweede reserve voor de finale. De Italiaan Gabriele Targhetta plaatste zich ruimschoots als eerste voor de finale (15,200).

Grünberg is aan brug eerste reserve voor de finale (13,966). Martijn de Veer, die individueel in actie kwam, is tweede reserve voor de eindstrijd aan rek (13,900).

For many artists, designers, and writers, the daily project is a fruitful, if not invigorating, exercise. Whether it emerges in the form of a morning sketch or collection of objects gathered during walks, disciplined creativity has a certain allure, and many of us long for a regimen that pushes through blocks, demanding that we make even in the most uninspiring conditions.

This is true for Damien Hoar de Galvan, who embarked on a daily sculpture project at the beginning of 2024 from his home studio in Milton, just outside of Boston. He decided that, for the next 12 months, he would fashion a small wood assemblage each day. “I thought it would be a good way to change up how I was making things, new materials, work faster, etc.,” the artist writes, adding that he had been challenged by raising a teenage daughter during COVID and making and selling work through it all. The habit might bring the joy and play back into his process, and if one piece wasn’t his favorite, he could try again the next day.

At the beginning, Hoar de Galvan didn’t plan to exhibit the works but rather focused on leaning into his intuition and pushing himself in a new direction. “I wasn’t sure if I’d be able to stick to the whole year and had no plan as to what to do with all the sculptures or how to show them all,” the artist says.

Rarely sketching a composition before gluing and painting scraps of reclaimed wood, he would begin by selecting a shape or color that interested him and progress from there. “There might be a feeling or impulse that pushes me in a general direction when starting a new one… I’m usually surprised along the way as they inevitably start dictating what they want to be,” he adds.

A trip to Barcelona waylaid the project for a few days, and at the end of 2024, Hoar de Galvan had amassed 362 sculptures, just four short of the leap year total. It wasn’t until ICA Boston curator Tessa Bachi Haas asked for a studio visit that Hoar de Galvan began to think about showing the works, and he later received the 2025 James and Audrey Foster Prize, a biannual award that includes an exhibition at the museum.

Titled I don’t think I’m ever gonna figure it out after the Elliot Smith song, the complete collection appeared atop five long shelves. Presented together, the individual works appear diverse yet cohesive, featuring vibrant fragments of reclaimed wood fanned into pointed geometries, unusual comb-esque shapes fitted together like a puzzle, or radial lines that sweep outward like a starburst.

Standing just a few inches tall, each piece is a sort of record of a moment, while together, they capture a year of devotion and experimentation. “Thinking back to the sculpture a day, I made so many that sometimes an idea would pop up, and I knew there wasn’t time to change what I was working on for that day, but I would try it at some other point. There were some invisible connections running through them all,” Hoar de Galvan shares.

Currently, the artist is working toward exhibitions at Tokyo’s Gallery Side2 and Gallery Naga, where he’s represented. Keep up with his latest pieces on Instagram.

Do stories and artists like this matter to you? Become a Colossal Member today and support independent arts publishing for as little as $7 per month. The article Damien Hoar de Galvan Puzzles Scraps of Reclaimed Wood for a Daily Sculpture Project appeared first on Colossal.

As I mentioned in my post on the 2.0 anniversary, what you knew of as "3.0" had internally been slated to be the "2.1" bugfix release, to be soon followed by a 3.0 release based on the Collabra rewrite, but that new team face-planted so badly that we had to pretend this bugfix release was a feature release instead, and the Collabra shitshow eventually became the disastrous "4.0" release (with intervening "3.01" and "3.02" bugfix releases nearly a year after the 3.0 release!)

Anyway, go read that post instead for the juicy gossip. No need to re-hash it all here.

We can see from the release notes that 3.0 contained such exciting new features as background colors in table cells, the <FONT FACE> attribute, and <SCRIPT SRC>. Plus better uuencode support! For porn!

Oh yeah, and I think 3.0 was the first release with "Gold", the WYSIWYG HTML editor, but Gold only worked on Windows and Mac. This was the first violation of what had been, until then, two of our guiding principles, which I was unable to stop:

• Simultaneous feature parity on all platforms;
• Never allow C++ into the cross-platform code base.

You get one guess why there was no Unix version. If you listen carefully, you can hear Ghosts of JWZs Past howling down the cubicle farm hallways, "I fucking told you so, did I not fucking tell you??" But Lloyd thought the way you write cross-platform code was to write for Windows and then port it once you were finished. "It'll be fine," he said. (Narrator: It was not fine.)

Previously, previously, previously, previously, previously, previously, previously, previously, previously, previously, previously.