> You may ask yourself: "Web applications can already use third-party services through remote API calls, how is Qworum better?". The answer is that currently third-party services can only provide business logic through their APIs (whether they are REST-based or not), whereas Qworum services can also bring the UI that goes along with the business logic. This lightens the workload of Web application developers.
Can't services already provide UI? Eg a server sending React components to the client.
If I were to guess, the whole "service web" idea seems to imply that services can run within a client browser, and talk to other services in other user browsers. I admit that could be quite cool, and enable easier development of p2p apps
RELEVANCE FOR P2P:
I take it you are into P2P, but Qworum really isn’t a P2P technology, at least in its current state. What Qworum is doing is simply define a new type of web content (the Qworum script) that browsers know how to handle in order to support modular and distributed web applications.
REST-QWORUM COMPARISON:
Imagine a REST end-point for processing payments. It receives an amount and currency, and returns the transaction details. But the end-point should ask the end-user for a payment method. How does it do that? It can't, but a Qworum end-point can! This is where Qworum shines.
So a Qworum service is comparable with a REST API in that it has a set of end-points. A Qworum end-point in turn is similar to a REST end-point in that it has a URL and it receives (optional) data and returns some data.
But the big difference compared to REST is that Qworum end-points are not obliged to return immediately a result. In other words, a Qworum end-point call can involve more than one HTTP(S) request-response pair. So Qworum end-points can return 2 types of responses during a call:
1. HTML pages for interacting with the end-user,
2. Qworum scripts for making nested calls to other end-points (recursion is also supported), and for returning a result to end the call. Qworum scripts can be sent as XML to the browser, or they can be generated in web pages on the browser using JavaScript.
REACT-QWORUM COMPARISON:
React components are really parts of web pages, not really services in the way a REST API is a service. Qworum services are more comparable with REST APIs than React components.
In terms of UI, one big difference between Qworum services and React components is that a Qworum service has access to the whole page within the browser tab regardless of the nesting depth of the call. As a result there is no upper bound to Qworum’s nesting depth. In contrast, React components can't really nest beyond 2-3 levels, because with each nesting level the screen real estate that the component has access to becomes vanishingly smaller.
So this thing allows easier integration of UI-driven external services into a web app (auth, payment, ecomm).
In terms of elevator pitch:
Qworum's mission statement could be something like "Premium web browser features for business and consumer applications". So this would involve adding Qworum's modularization technology to browsers, along with some other features. The result would be improved developer productivity and better integration between web applications.
In a more general sense, what I think is lacking on the web right now is a commercial entity that can augment the baseline capabilities that are provided by Chrome, Safari etc. If the browser is the web's operating system, then what we have right now is Linux on the desktop, not Windows and not macOS. So that's the opportunity I am seeing.
