dogaar

The Web is still fundamentally a platform for content not applications. And it's even less an AI-native application platform.

Qworum is a new Web variant that was built for application use cases. It's the only application platform (or OS) that is AI-ready, in the sense that applications are structured the right way for full AI enablement.

Bug-free text can indeed be nice to look at.

Speaking of bugs: the Unicode-art at the bottom of the mentioned page isn't showing correctly.

No single web font can display all Unicode code-points, and using a suitable font for that Unicode-art would fix it.

More on that here:

https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/...

This article seems to suggest that atomic application updates at the server side is by itself a solution to application versioning, which it isn’t. As long as client-side asset caching is enabled, which it is by default for all web applications, then the neatly separated application versions will get all mixed up in the browser. One solution would be to serve each application version under a different path prefix.

Supply-chain attacks are big problem for the JavaScript ecosystem. In this short post I will outline a straightforward security measure that can be implemented by all JavaScript runtimes, both in-browser and off-browser. This will prevent most of the supply-chain attacks that are plaguing the JavaScript ecosystem today.

One thing this blog does not question is whether package managers are needed at all. Look at how Deno does it: packages are imported from URLs and downloaded to a local cache at run-time. This allows CDN-based package distribution, but you still need a package search engine.

The world’s most unfalsifiable digital certificate counts for nothing if the data in it isn’t authoritative. A person can’t be identified by his/her name. It can change, and so can the name of the birthplace, not to mention people having the same name.

REST is for data transfers not executions. One of these would have been a much better choice: JSON-RPC, XML-RPC, gRPC.

Hi, I have recently launched a B2B software startup (qworum.net) and I am looking for salespersons. Compensation is commission-based: 20% recurring commission on realised sales. If you want a $80K revenue, selling 80 Qworum Alloy subscriptions will get you there. Your recurring commission will keep coming in as long as the subscription is live. Feel free to drop me an email at d.armangil@qworum.net. Best.

[TRENDING ON INFOQ]

Qworum is a front-end PaaS that brings all the benefits of microservices to the UI layer, and makes web UIs fully compatible with microservices architectures.

Qworum is positioned as an alternative to micro front-ends. As you may know, the rate of adoption for micro front-ends have been tepid so far, and as a result monolithic front-ends remain a significant impediment for microservices architectures. Qworum is a solution to this issue which plagues large-scale software systems.

Qworum is pioneering several industry-firsts: ▶ a new type of microservice (the interactive microservice), ▶ a new type of web API (the multi-phase web API), ▶ a platform for distributed web applications, ▶ a new type of web (Qworum’s Service Web is about interlinked microservices, whereas the World Wide Web and the Semantic Web are about interlinked content).

Presenting Qworum’s service web, the first web conceived for applications and the 3rd web after Tim Berners-Lee’s document web and W3C’s semantic web, both content webs.

Microservices architectures are all the rage these days amongst enterprise devops teams, but web frontends have largely remained monolithic (micro frontends have found little adoption so far), so the UI layer isn’t really compatible with microservices architectures.

Enter Qworum, a Platform-as-a-Service that fully supports microservices architectures by making web UIs modular and distributed.

Hi, the "lack of focus" feeling is due to the fact that Qworum is still a work in progress, although the specification itself is stable.

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.

Hi, I am the author of Qworum, which is a work in progress. If my answer seems too long, a coffee pause always helps :)

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.