Hyperfiddle takes the messy, complicated world of database programming and web development, and flattens it into a real-time editor.
The interactive editor has three facets:
1. Database query and form
All your fiddles have a Datomic query. Datomic is a new kind of database designed for 2020-era business applications, competitive in use cases with SQL and GraphQL. Datomic is the key ingredient that makes Hyperfiddle possible.
From your Datomic query, Hyperfiddle generates
complete working API
user interface and forms
cloud backend and database
2. View – Markdown or ClojureScript
Out of the box UI scaffolding:
Automatic typed widgets
Recursive tables and forms
Automatic CSS classes
Reasonable defaults for everything a real app needs
We say “UI scaffolding” because the automatic UI is just a jumping-off point. Add some flavor — only when you need to — with a dash of ClojureScript, or throw the whole thing away and bring your own frontend.
3. Hyperlinks to other fiddles
This lets you weave individual fiddles into larger hyperfiddles.
They work like HTML:
Anchors navigate between fiddles
Buttons submit transactions
Iframes embed one fiddle inside another
Links have a small number of properties which combine to describe an arbitrary database transaction. Every-day transactions like parent-child references are automatic. Sophisticated business transactions can be coded in Clojure.
Automatic backend and web-service
Designed for Datomic Cloud: serverless enterprise database tech for the 2020s.
Hyperfiddle's backend is smart. It uses the fiddle-graph to optimize data loading behind the scenes, like how Chrome optimizes web page loading. Today the optimizer is simple, but over time your apps will get faster — without you doing any work!
Users and security (experimental)
Fiddles are real multi-user applications, suitable for the open internet as well as internal tools.
Authentication, users, profiles
Opt-in security models for permissions and access control
Slot hyperfiddle.jar into your existing Datomic infrastructure and start making internal tools today. (Coming Soon)
hyperfiddle.jar is a CLJC library that supports many I/O configurations, depending what you want to do:
Datomic Cloud and Ions
Roll your own
Business model and pricing
hyperfiddle.jar, which includes the server and everything you need to self-host your apps, is free and open source (pending cleanup asap).
Hyperfiddle Editor needs a license for on-prem use. This business model will let us make Hyperfiddle IDE as mature as Excel. We are happy to provide access to the editor's "source" to licensees, it is actually a database containing EDN, Reagent views and CSS.
The Editor is of course optional; developers are welcome to git clone hyperfiddle && lein new --whatever and code your fiddles into .cljs and .edn files, which is common in mature projects like Hyperfiddle itself.
Hyperfiddle can do anything Rails can do. Enterprise app with sophisticated backend integrations? No problem: Hyperfiddle is a jar file. Fork it and integrate it with your JVM codebase.
Invisible data sync. Hyperfiddle loads just the right data, automatically. Your app specification captures your API inter-dependencies as a graph, so data sync reduces to a graph partitioning problem. Hyperfiddle optimizes your service dynamically in ways hand-coded backends cannot.
Immutability and functional programming. Hyperfiddle is made possible by unique capabilities of Clojure/Script and Datomic, including immutability in the database and code-sharing across platforms.
Server rendering and static sites? Yes, all hyperfiddles are progressive web apps. Even API responses are served Cache-Control: Immutable – check the network tab as you navigate our docs!
SQL? No, not without an adapter, an immutable database is necessary. For example, interactive undo/redo — of database transactions! — falls out of immutability for free.
Foreign REST APIs? Yes, and this is important to us. Today this is experimental and undocumented, there is more work to be done here.
GraphQL? Eventually, this is a great fit.
Re-frame, Hoplon, Rum, etc? We have no hard dependency on Reagent, other than the out-of-box forms library. Note that Re-frame doesn't support server side rendering.
Proper frontend dev workflows? Eventually, this is important to us.