It just provides a different API for storage. You could say the same thing about IndexedDB being added when LocalStorage already existed - it's just a different API with some different performance characteristics.
And no, it's not for the benefit of you the user, but it's not to your detriment either. It's mostly for the benefit of the web developer. (It might be good for users indirectly if web developers make good use of it)
Although I think it's extremely unlikely, I almost wish subversion would have a resurgence. I like git, personally, but I've seen so many people struggle with it, and the problems of putting large/binary assets into the repository are real. Yes, there's LFS now, but (as far as I know) you then need to make up front decisions about what to store directly and what to store indirectly as LFS objects.
Subversion was much better than anything existing before, but a very fundamental problem is that it treats branches and tags, which are conceptually different, the same way. This results in branches not tracking well their history and tags behaving like moving targets.
I'm no fan of Musk. However, building companies is generally considered to be a good thing. Doing it with taxpayer money is only bad if it's somehow fraudulent - if you make a company and get a government contract and you actually fulfill that contract, that's neutral or good.
Spreading misinformation is definitely bad, but I don't think I'd class it as terrorism.
Regardless, I don't see any chance of the US throwing Musk out.
This is pretty cool, but if you're rewriting resource names server side then you need some machinery to rewrite references to those resources. I see the example you linked shows the root HTML being generated server-side from a template so content hash names can be injected into the template. Looks reasonable. Not so great for dealing with things like `import` calls in javascript (for deferred loading of script modules), if those need to be rewritten as well.
Your JS bundler (if you use one!) might be effectively rewriting imports anyway so it can be convenient to do the content-hash-named-files rewrites in the same place. But not everyone wants to use a bundler for that.
Clace can also run containers, where the UI is served by the container. For example, Streamlit/Gradio based apps. In that case, Clace acts like an app server and reverse proxy to the container, no file name rewrites are done.
> Transactional Updates : This is the main benefit. Updating multiple files can be done in one transaction. Isolation ensures that there are no broken webapps during the update.
Your server on its own, whether it uses SQLite or the filesystem, cannot save you from having broken webapps during an update. Each page in the browser is a _tree_ of resources, which are fetched with separate HTTP requests and therefore not subject to your server-side transaction/atomic update system. You can change all resources transactionally on the server side but the browser can still observe a combination of old and new resources.
The common solution here is to ensure that all sub-resources of a page (javascript bundle(s), stylesheet(s), media, etc) are named (ie, in the URL) using a content hash or version. All resources (from the root HTML document down) need to refer to the specific content-hash or versioned name, so that if the browser loads version X of the root HTML document then it will load the _corresponding version_ of all sub-resources. Not only that, but if you're updating a page from version X to version Y, all the version-X sub-resources need to remain available after you start serving page version Y, until you're confident that no browser could reasonably be still loading version X of the page, otherwise you can break page version X while someone is still loading it.
This means you actually specifically don't want to put sub-resources for a page into one atomically-switched-out bundle along with the root HTML document, because if you do that you'll be removing the previous versions of sub-resources while they may still be referenced.
Also of course in some cases there might be some sub-resources (e.g., perhaps some media files) that you want to be versioned "separately" from the HTML document that contains them, so that you can update them without busting caches for all of the page/app structural elements like your javascript blobs and stylesheets and so on, and you _might_ need to take that into account in your page build system as well.
For Hypermedia driven web apps, interactions within a page return small HTML fragments. For larger UI changes, a full page update is recommended (the Multi Page Application MPA style). The scenario of a user staying on a page for long and getting broken links is more of a SPA issue.
I agree generally with your comment. Transactional updates prevent only one category of update related issues. There can be other issues at the app level which can cause a broken experience. Continuing to serve older versions of static content when referenced by content hash is possible, it is not currently implemented by Clace.
This helps with front end caches and CDNs as well.
The main trick is upload all of the non-html changes before the html changes, so that no file is referenced before it exists. If you want to make the app as complex as possible you do a depth first search for upload. But if you value your sanity you relax the problem and have assets-first in your app.
Although, yes, this sounds absurd, it's worth noting that the TV licence pays for the BBC and the BBC has extensive radio (and web) offerings not only television.
Of course, that still doesn't make sense because to the best of my knowledge you don't need a license of any kind to listen to the radio.
Anyway, perhaps blind people want to listen to the TV. There are a lot of programs that could make sense even if you can hear but not see them.
I'm no fan of national broadcasters as a concept, but I have to say, the UK is excellent when it comes to audio description, much more so than any (English speaking) country I'm aware of. It's not just the BBC either, Sky and other private broadcasters also have relatively high standards.
For years, the only English AD you could get for extremely popular HBO shows, like Game of Thrones for example, were pirated British rips from Sky, as HBO famously refused to provide the service.
> you don't need a license of any kind to listen to the radio.
I believe you did once upon a time, but I guess they were phased out as TVs became more popular.
>The first supplementary licence fee for colour television was introduced in January 1968. Radio-only licences were abolished in February 1971 (along with the requirement for a separate licence for car radios).
And it doesn't have to be the direct domain+path of the repository, it can be some URL where you put a metadata file that points to the source repo.
reply