datastack

I agree it seems more common. However back-up time and data movement should be equivalent if you follow the algo steps.

According to chat GPT the forward delta approach is common because it can be implemented purely append only, whereas reverse deltas require the last snapshot to be mutable. This doesn't work well for backup tapes.

Do you also think that the forward delta approach is a mere historical artifact?

Although perhaps backup tapes are still widely used, I have no idea, I am not in this field. If so the reverse delta approach would not work in industrial settings.

Exciting!

Yes, the deduplicated approach is superior, if you can accept requiring dedicated software to read the data or can rely on a file system that supports it (like Unix with hard links).

I'm looking for a cross-platform solution that is simple and can restore files without any app (in case I didn't maintain my app for the next twenty years).

I'm curious if the software you were working on used proprietary format, was relying on Linux, or used some other method of duplication.

Nice to realize that this boils down to copy on write. Makes it easier to explain.

Great resource in general, will look into it if it describes how to implement this backup scheme

This sounds more like a downside of single site backups

You can see in step 2 and 3 that no full copy is written every time. It's only move operations to create the delta, and copy of new or changes files, so quite minimal on IO.

Thank you for bringing this to my attention. Knowing that there is a working product using this approach gives me confidence. I'm working on a simple backup app for my personal/family use, so good to know I'm not heading in the wrong direction

In this algo nothing is rewritten. A diff between source and latest is made, the changed or deleted files archives to a folder and the latest folder updated with source, like r sync. No more IO than any other backup tool. Versions other than the last one are never touched again

Nosql doesn't solve the schema migration problem. It just means you don't formalize your schema. But your code will implicitly require a certain schema anyway. Changing the schema means changing the code and migrating data. You'll have to write migration scripts and think about backward compatibility. Same problems as in sql.

Nice, thanks for sharing. Curious what your motivation was for making it. Perhaps include a "why" at the start of the repo. As evidenced by some comments, depending on whether the goal was to write HTML with a lisp compatible syntax, vs, a more concise but simple xml alternative, it creates different expectations. Personally I'm just interested from a parser/ compiler perspective.

Interesting take. Haven't heard the argument before that it saves server costs. Not convinced that this is the case, but perhaps, for a google.

Reflecting, I suppose that businesses relying on Php/Laravel or Ruby are probably still enjoying simple SSR development. I've personally transitioned to Java and then .NET, and haven't seen SSR since. Which corner of software are you in, where you see SSR still being dominant?

that's the point, glad you understood

Lot of bashing of this idea, not sure why. The entire industry has shifted from "web developer" to frontend/backend developers. What used to be a web developer is now called full stack.

It seems like a big deal to me and the entire shift is an indicator of how much the IT community is behind front end clients talking to a separate back end. Server side rendering is no longer considered normal. Server site rendering now means something entirely different. It is about running your frontend code on the back end, So you still have the separation, but instead running it on the same machine. Now the same ui code has to be compatible with two different run times. This is much, much more complex than traditional server side rendering.

I'm glad we now have things like single page apps and client site interactive applications, because some apps were really not possible with server side rendering unless with a lot of Jquery hackery that quickly becomes unmaintainable...

However, I do think that front end technologies are overused, so I agree with the author, And I also think this is objectively a contrarian opinion, considering my initial point.

A thought experiment on a new AI assisted programming paradigm. Your ideas are welcome.