Which I actually agree with, as the Wasm ecosystem is trying to be yet another UNCOL outside the browser, bringing CORBA back while pretending it is some great new idea.
Nice! I'm working on a similar language in some ways.
One decision I made is to specifically not compile to JS. JS/Wasm interop is good enough with Wasm GC that I made the choice to focus on Wasm-only constraints and semantics and not worry about how things like the types being wrong, or how ints translate to JS, how to handle null vs undefined, etc. JS GCs collect objects and cycles across the Wasm boundary, and with the JS string built-ins you can handle strings efficiently.
Please explain the legitimate uses. Not once I have ever encountered a website that does something useful by modifying the behavior of my browsing history.
Youtube doesn't implement a back function. A real back function would take you back to the same page you came from. If you click a video from the Youtube home page, then click the back button, Youtube will regenerate a different home page with different recommendations, losing the potentially interesting set of recommendations you saw before. You are forced to open every link in a new tab if you want true back functionality.
Well, if I wanted to return to the parent screen in a single page application, I'd click on the back button in the app itself. No need to prevent me from back tracking in the exact order of my browsing should I need it.
I especially hate YouTube's implementation, I can never know the true state on my older PC during whatever it's trying to accomplish, often playing audio from a previous video when I backspace out. I resort to opening every link in a new tab.
The spec kind of goes into it, but aside from the whole SPAs needing to behave like individual static documents, the big thing is that it's a place to store state. Some of this can be preserved through form actions and anchor tags but some cannot.
Let's say you are on an ecommerce website. It has a page for a shirt you're interested in. That shirt has different variations - color, size, sleeve length, etc.
If you use input elements and a form action, you can save the state that way, and the server redirects the user to the same page but with additional form attributes in the url. You now have a link to that specific variation for you to copy and send to your friend.
Would anyone really ever do that? probably not. More than likely there'd just be an add to cart button. This is serviceable but it's not necessarily great UX.
With the History API you can replace the url with one that will embed the state of the shirt so that when you link it to your friend it is exactly the one you want. Or if you bookmark it to come back to later you can. Or you can bookmark multiple variations without having to interact with the server at all.
Similarly on that web page, you have an image gallery for the shirt. Without History API, maybe You click on a thumbnail and it opens a preview which is a round trip to the server and a hard reload. Then you click next. same thing. new image. then again. and again. and each time you are adding a new item to the history stack. that might be fine or even preferred, but not always! If I want to get back to my shirt, I now have to navigate back several pages because each image has been added to the stack.
If you use the History API, you can add a new url to the stack when you open the image viewer. then as you navigate it, it updates it to point to the specific image, which gives the user the ability to link to that specific image in the gallery. when you're done. If you want to go back you only have to press back once because we weren't polluting the stack with history state with each image change.
Thanks for the detailed and thoughtful reply! I agree that in both of the scenarios you mentioned, this API does provide better usability.
I guess what feels wrong to me is the implicitness of this feature, I'm not sure whether clicking on something is going to add to history or not (until the back button breaks, then I really know).
FAIR has a very interesting architecture, inspired by atproto, that I think has the potential to mitigate some of the supply-chain attacks we've seen recently.
In FAIR, there's no central package repository. Anyone can run one, like an atproto PDS. Packages have DIDs, routable across all repositories. There are aggregators that provide search, front-ends, etc. And like Bluesky, there are "labelers", separate from repositories and front-ends. So organizations like Socket, etc can label packages with their analysis in a first class way, visible to the whole ecosystem.
So you could set up your installer to ban packages flagged by Socket, or ones that recently published by a new DID, etc. You could run your own labeler with AI security analysis on the packages you care about. A specific community could build their own lint rules and label based on that (like e18e in the npm ecosystem.
Not perfect, but far better than centralized package managers that only get the features their owner decides to pay for.
We didn’t give up! We’ve pivoted efforts - focussing more on the technical part of the project, and expanding into other ecosystems. We’re currently working with the Typo3 community to bring FAIR there, as well as expanding further.
(AMA, I’m a co-chair and wrote much of the core protocol.)
That would be a really interesting platform for an npm alternative. I think the incentives are a little better aligned than in the WordPress ecosystem, but maybe not enough.
Assuming that the majority of repositories will be malware with SEO hooks, how would one locate a safe directory using only a search engine (as opposed to whispered tips from coworkers, etc)? I don’t see how proliferation of repositories improves things for users. (Certainly, it does serve up the usual freedom-from-regulation dreams on a silver platter, but that’s value-neutral from a usability perspective.)
The aggregators can choose who to index, and we operate one at fair.pm - the idea being that you only federate repositories that meet requirements, and can defederate those which are bad actors. (End users can install directly from repositories though, and can always switch the aggregator if they find the rules too restrictive - no lock-in.)
What aggregators? How would I locate fair.fm? Is there a Whole Earth Guide to Repositories that’s human-curated? What is the published malware incidences and non-responses rate for each repository?
An "aggregator" is the thing that discovers and lists repositories - the equivalent of a search engine. Anyone can operate one themselves, and we (the FAIR project) operate a canonical one on our website, which is fair.pm.
Currently the reference implementation is for WordPress, but we’re working to bring it to Typo3 and other software at the moment too. The protocol is comprised of a core plus per-software extensions when needed.
I see. Are there other similar projects for other ecosystems? I guess more broadly I'm intrigued by the idea of the decentralized supply chain concept, the way you described it sounds like it was more broadly applicable.
You can check out the protocol at https://github.com/fairpm/fair-protocol - anything WordPress or Typo3 specific are in the extensions, and the core protocol is self-contained. We'd love to work with more ecosystems to bring FAIR to them, and we've already had some discussions with others including maintainers of popular (dependency) package managers.
What is up with so many people doing weird capitalization now? Is this some Bay-tech flex? Alok writes their own name, and other names, with leading caps, but not the first word in sentences? It makes it so uncomfortable to read.
Wow, I read the whole thing without noticing that.
But as someone who came of age in the AIM / ICQ / IRC days, it feels pretty normal. That's just how we wrote. I still fall into it by accident when the context is right and I'm not thinking about it (eg Slack at work). I hope youngsters aren't judging me for it.
I think this is just applying the same informal writing style used in, for example, online chats with friends, to a relatively-informal blog post. I don't think this has anything to do with the Bay Area or its tech industry in particular.
YES, THIS (capitalized on purpose). Folks, please use reasonably correct writing syntax. You CAN do better .. At least think of the AIs consuming your writings.
i notoriously ignore using my shift key when im typing informal stuff (comments, chats to coworkers, friends, etc). big ol emails = you'll see me using my shift key.
most of this comes from me noticing how funny sql looks with all the people trying to use caps all over the place as if anyones working in a place without syntax highlighting in 2026. sql is the wild west and everyones sql looks like shit there is no shame. i was told i needed to use caps more early on in sql and i lmfao'd, but i was new to the career and that scarred me. i write lower case sql just to spite others now and if you see something capitalized you know i meant it, but for the most part you have to pay me to use my shift key.
Only you can stop generational SQL abuse. Capitalize keywords, indent grouped syntax, and use prefix commas on newlines. Write readable code, for God’s sake, you filthy heathens.
I use Eleventy for nearly all of my static sites. Almost every project of mine has at least an 11ty internal docs site. I'm very happy that Eleventy has a home and Zach a job.
But my only thought on this is: Eleventy is an awesome name.
Agreed, it's not those, it's the fact that we went from JS being a little sprinkling of dynamism on a document to an entire build process with massive numbers of dependencies and browser shims. The web feels like a mistake as a platform...
Counterpoint: classes are a great way to bundle state and logic - which is exactly what UI components are - and components models should use classes more, not less.
React's "functional" components are simply poor approximations of classes. Instead of easy to read and reason about class fields, you put state in useState() function classes that are effectively named by their appearance order in source and who's current state you can't introspect with dev tools!
The component function mixes one-time setup (which should be a class constructor) with repeated render calls (which should be a method), so those of course have to be separated by putting the one-time work inside of a closure inside of the repeated should-have-been-a-callback function. Event listeners and other callbacks are another huge mess. Don't forget useMemo() or useCallback() (but which?).
It's actually quite mad.
And the differences between classical and prototypal inheritance basically don't even pop up under normal class usage in JS: just use class fields, don't mess with the prototype chain, and don't dynamically add or delete properties - all things that are how classical inheritance works - and things just work like you expect.
They're modeling reactivity, not classes. It's a well established pattern in functional programming
The one time setup mixed with repeated render calls is odd, but it's a design decision they made. It reduces boiler plate, though I don't necessarily agree with it because it is a leaky abstraction
It's a shame they don't seem to try to address the divide between CMS's and static sites.
Most WordPress sites could just be static, but WordPress has a nice editor interface, so they're not - unless you use a SSG plugin. Building that into the core workflow (which I believe Astro supports) and giving users a nice hosted editor that produces a static site would be welcome innovation.
I've been migrating a few Wordpress sites from Wordpress to Astro + Strapi recently, working in 'hybrid mode' so the entire site is static except for post previews in Strapi (only that one route is SSR).
Editing content in Strapi, once customized with CKEditor and such, is Wordpressy enough for the human Editors familiar with WP.
I don't even think the WordPress editor is very nice. It's completely separated from how the actual results look. There are CMSs which lets you edit directly in the web page exactly as it will look when published.
As do most productivity software, like MS Office, Photoshop, Apple's iWork, etc.
Imagine making a document in Word, and it looks completely different when published.
EmDash with some aggressive caching and SWR is effectively this, and we're getting closer to that every day. When the cost of maintaining the data part of the CMS is effectively free, you're basically working with a static site anyway.
I haven’t used Wordpress for a few years. But with WP Super Cache (1) we also always did pretty much that: On saving a post/page the static HTML would be written to a cache directory and be the default content served to visitors.
Depends what you would call that architecture then I guess!
I run my local theatre website by writing the posts in markdown, and then have some github actions which use Hugo to turn it in to a static site and then uploads the content to an S3 bucket. The site itself has dynamic content like within-website ticket buying from eventbrite and a contact form that sends email using an external service. It also calls in things like google analytics.
Does this still count as static? Personally I think so, Even though there are 'dynamic' elements.
IMO static refers more about how the content is served rather than saying that the content can’t be ‘dynamic’ as lots of Wordpress sites have static/non interactive content but still regenerate the html on each page load.
I love this, but I really wish it were structured as a "Hot or Not" type of round robin system rather than a bracket.
Some fonts are close enough that I don't know if I'd choose one over the other consistently, and I'd be curious to see a percentage score of how much I like a particular font.
Totally agreed -- there are so many different factors involved in each comparison, and I feel like I'm easily paying attention to different things on each comparison.
Unfortunately, I don't believe there's any established algorithm for how to repeatedly sample pairwise preferences to convert them into a strict ranking, which would ideally be with an active learning component to really drill down into the comparisons that are the closest. Would be a fascinating thing to try to develop, though.
reply