7 ms·

1. How does this compare to MightyApp [0]? Does Mighty work on the UI side automatically, while Drifting in Space requires that the app has some kind of data l

1. How does this compare to MightyApp [0]? Does Mighty work on the UI side automatically, while Drifting in Space requires that the app has some kind of data layer separation to allow acceleration of just the data processing? 2. Is the data processing stream or batch? 3. Could Mighty + DiS work together to completely accelerate a data- and UI-heavy application? Context: I have been working recently with a reporting-heavy company that is continually using data analysis to understand risk, combat fraud, and identify key patterns in user actions and data. [0]: Mighty Makes Google Chrome Faster (YC S19) -- https://news.ycombinator.com/item?id=26957215 https://news.ycombinator.com/item?id=26957215

paulgb 5y ago
1. Mighty has some similarities in that they run a (Chrome) process for each user session, but it's quite different in that we are something that SaaS companies can build into their app, whereas Mighty is something that the end-user subscribes to and the SaaS provider doesn't need to know exists. I think Mighty is pretty neat, but it doesn't get around fundamental limitations of browsers, e.g. a WebAssembly process running in Mighty can't address more than 4GB of memory regardless of how beefy the machine Mighty runs it on is. Since our product is built directly into the SaaS app, it's up to the app's developer to decide at what level they want to split the work between client and server. Doing everything on the server and streaming pixels is one option, but I suspect most applications will want to take a hybrid approach where they do some CPU/memory-intensive work on the server, stream the data to the client, and use the client's GPU (via WebGL/WebGPU) to render it. So that's the approach we're currently optimizing for, but better support for pixel streaming is on our radar too. 2. It's up to the application layer; we just provide a way to run a container and the data layer is up to the app. 3. Yes, an app served by DiS is just a regular web app so you could use it in Mighty. Our hope is that because we shift some of the heavy computation to the server there are less use-cases where this makes sense, but there could be cases where you want to do GPU-heavy rendering which we don't yet provide.

paulgb 5y ago

1. Mighty has some similarities in that they run a (Chrome) process for each user session, but it's quite different in that we are something that SaaS companies can build into their app, whereas Mighty is something that the end-user subscribes to and the SaaS provider doesn't need to know exists. I think Mighty is pretty neat, but it doesn't get around fundamental limitations of browsers, e.g. a WebAssembly process running in Mighty can't address more than 4GB of memory regardless of how beefy the machine Mighty runs it on is. Since our product is built directly into the SaaS app, it's up to the app's developer to decide at what level they want to split the work between client and server. Doing everything on the server and streaming pixels is one option, but I suspect most applications will want to take a hybrid approach where they do some CPU/memory-intensive work on the server, stream the data to the client, and use the client's GPU (via WebGL/WebGPU) to render it. So that's the approach we're currently optimizing for, but better support for pixel streaming is on our radar too. 2. It's up to the application layer; we just provide a way to run a container and the data layer is up to the app. 3. Yes, an app served by DiS is just a regular web app so you could use it in Mighty. Our hope is that because we shift some of the heavy computation to the server there are less use-cases where this makes sense, but there could be cases where you want to do GPU-heavy rendering which we don't yet provide.