Quiver have many features that are different from traditional web frameworks. In particular:
Composabile Components - Quiver components are small snippets of plain functions that can easily be reused and composed into larger applications.
Functional Programming - Quiver makes use of many advanced functional programming concepts borrowed from Haskell. As a result Quiver code base is simpler, cleaner, composable, and more maintainable.
CSP Channel - Quiver data streams are implemented as CSP-like (Communicating Sequential Process) channels. This simplifies the channel implementation and decouple it from raw data sources/sinks. Quiver also introduce the concept of streamable object to allow optimization when transferring data between raw sources and sinks.
Standard Input/Output Streams - For back end API components, Quiver specifies a Unix-process-like interface with an argument map, input read stream, and returning result stream.
Functional Reactive Programming (FRP) - For front end UI components, Quiver provides an FRP-like signal construct and virtual DOM to map between the change in application state and resulting layout.
Quiver is a solo work by Soares Chen started in 2013 and is still in active development.
The back end implementation of Quiver is stable but not battle tested. A major rewrite of the back end is planned once the Quiver type system is fully implemented.
- Is there any documentation?
Some documentation were written few years back. Since then I have acquired more knowledge in functional programming and made many major changes to Quiver. No documentation is planned until the new version of Quiver is done. But I am more than happy to explain in detail if anyone is interested.
- Should I try out Quiver myself?
- Should I use Quiver in production for my company?
You should only consider Quiver if: 1) Your company is large enough to afford experimentation and risk, 2) Your team of front end / back end developers are proficient in functional programming, 3) You are the team leader, trust me enough, and want to hire me to be part of the team.
- When will Quiver be ready for use?
Not for another few years time. I can only work on Quiver on my personal time because it is too much risk to let a company depend on a framework only one person know, only to leave the company few years later. It also takes time because I am still learning advanced programming language theory topics such as dependent type to be added to Quiver.
- Is Quiver better than other web frameworks?
Technically, yes. Popularity wise, no. Functional programming is a double edged sword in that it is technically superior but is never likely to gain mainstream adoption. The learning curve is steep and not everyone will find Quiver easy to use.
- Why not TypeScript / ClojureScript / PureScript / Elm / other transpile-to-JS languages?
Same reason as above. Additionally, I like static type system but I want the power of full fledged type systems like Haskell, which not many language provide. But writing Quiver in JS also enables choice. Users of Quiver can choose to write their application either in JS, or any of their favorite language that transpiled to JS.