Temporal provides a unified backend for automatically managing implicit application state that is normally stored in transient queues, databases etc. Furthermore, Temporal does this without explicitly requiring the developer to think about and manage the state themselves. This means developers spend way more time building stuff that actually matters, and less time writing buggy reliability code.
I personally find the best way to explain it is with an analogy. Back in the late 90s many developers built applications with C and therefore had to manage their own memory. For a long time, this was not wasted effort as it was the only real option. But then, Java came around and offered an experience where developers didn't have to manage their memory. And for the majority of apps, the performance and capabilities of Java were more than sufficient. At this point, writing the average application in C meant you were doing a serious amount of undifferentiated work. Furthermore, most developers weren't that great at memory management so choosing to do it by hand meant more work for a worse result.
The value proposition of Temporal is nearly identical, but instead of manually managing memory with C, developers are manually managing state using queues, CRON services, databases and more. The result is a bunch of time spent doing undifferentiated things that a computer would have done better anyway.
A language runtime that runs your code in durable way (every step of program execution is persisted so that if there’s a failure—even the machine running the program losing power—execution can be continued), and a service that enables that durability in a scalable way.
Manually is writing code to read and write to the DB. Automatically is writing code, and all the code state (local variables, execution progress) is persisted for you.
Temporal provides a unified backend for automatically managing implicit application state that is normally stored in transient queues, databases etc. Furthermore, Temporal does this without explicitly requiring the developer to think about and manage the state themselves. This means developers spend way more time building stuff that actually matters, and less time writing buggy reliability code.
I personally find the best way to explain it is with an analogy. Back in the late 90s many developers built applications with C and therefore had to manage their own memory. For a long time, this was not wasted effort as it was the only real option. But then, Java came around and offered an experience where developers didn't have to manage their memory. And for the majority of apps, the performance and capabilities of Java were more than sufficient. At this point, writing the average application in C meant you were doing a serious amount of undifferentiated work. Furthermore, most developers weren't that great at memory management so choosing to do it by hand meant more work for a worse result.
The value proposition of Temporal is nearly identical, but instead of manually managing memory with C, developers are manually managing state using queues, CRON services, databases and more. The result is a bunch of time spent doing undifferentiated things that a computer would have done better anyway.