TW was THAT far ahead of the game?

#1

+++
Building apps is too hard. Even skilled programmers who don’t specialize in app development struggle to build simple in
teractive tools. We think that a lot of what makes app development hard is managing state: reacting and propagating changes as the user takes actions.

We’re exploring a new way to manage data in apps by storing all app state—including the state of the UI—in a single reactive database. Instead of imperatively fetching data from the database, the user writes reactive queries that update with fresh results whenever their dependencies change.
+++

If you have peaked under the hood of TW5s javascript code, this feels very similar (key point is this is all “client side”/in the browser). Interesting takeaways in the article:

5 Likes
#2

This is describing low-code I think. TW is an awesome plugin-based low-code engine.

But tw is more text-based, there are other visual editors that can be used to make tiddler editing drag&drop.

I think in the future, there can be two types of tiddlers, one is using the WYSIWYG editor and for inputting 1D text. Another is using drag&drop to build 2D mini-app or form (for example using GitHub - alibaba/lowcode-engine: An enterprise-class low-code technology stack with scale-out design / 一套面向扩展设计的企业级低代码技术体系 and serialize its json to wikitext)

Oh, its about React + reactive database…

React itself is Reactive, for example in FlowTiwi - a Multi-column draggable resizable sidebar (beta release) I assign new props to multi-column react component when widget refresh, and React will map the new data to the new UI, and save some CPU by using diff algorithm.

And using reactive database is very convenient today, seems they don’t know GraphQL, you can write nested graph query with subscription to get graph result on real time. And GraphQL and React are all introduced by Facebook, so they work together naturally.

So getting all data on client side is not the best way to get reactive, GraphQL can use websocket to subscribe latest data.

For TW, I think it is better that we can have data in the nodejs side lazily, and get all rendered tiddler content from the server side.

#3

A very interesting article. … From my point of view the “Where we are going” section is the most important one.

It seems they are on the right track, but they are still caught in a very complex mental model, that only works for programmers and IT scientists.

I think they have a long way to go, to reach a state, that works in production for TiddlyWiki5 users since 2014

Where we’re going

We started this project wondering how the local-first availability of an app’s data could change and simplify app development. At this point, we’re left with more questions than answers. However, we see the outline of an approach where user interfaces are expressed as queries, those queries are executed by a fast, performant incremental maintenance system, and that incremental maintenance gives us detailed data provenance throughout the system. Together, those ideas seem like they could make app development radically simpler and more accessible, possibly so simple that it could be done “at the speed of thought” by users who aren’t skilled in app development.

Also interesting is: View templates as queries … I think, that’s right.

IMO there is still 1 important step missing. All your data has to be the same “thing”, following the same rules. … We call it a “tiddler” :wink:

They didn’t even mention multi-language support and human readable data-stores.

3 Likes
#4

TW was/IS THAT far ahead of the game!

Years ago I was involved with building a system that reported the history of aircraft parts as they where manufactured, purchased, warehoused, transported, installed, inspected, etc.

Backend data normally in Oracle, MS, SQL-lite, ColdFusion, Mongo databases depending on manufacture, warehouse, transportation, or aircraft maintainer companies. Used Node-Red. Drag-drop nodes that contained/constructed the sequence of queries to be sent to remote servers for processing.

The results - good, bad, or ugly - were formatted for TW and inserted into the tiddler-store of a slightly modified ‘empty.html’ file. The info requester was notified with a link to the TW file - and there you go - a tiddler story of the resulting data, links, pdf, worksheets, etc. Which they could update/store locally.

Once the Data Analysis Department got used to the system - they were building their own ad hoc Node-Red nodes and TW filters/macros. Which is really the goal of low-code, the user builds it! If I needed to have a complex TW filter made (I suck at it); would get with ‘Jenny’ who was an expert. ‘Roger’ became the go to guy with Node-Red and both moved on to careers in IT.

The FAA revamped, centralized, and standardized the reporting requirements of aircraft part movements - so the system died as no longer needed. I didn’t shed too many tears as it was a PITA to maintain.

The fundamental key for these systems to work is that there is only one single ‘primitive’ data type. For Node-Red is the node in/outbound ‘message’ - everything (current state) is in the format of a message which updates as travels through the system. Similarly, TW has the ‘tiddler’ - everything is in the format of a tiddler. As long as built-in tools are available to (de)serialize data of differing formats in/out of the primitive type - life is good.

Low-code systems are more storage, network, and processor intensive - cases where some templates are injected when not really needed. But so what? - we go back to doing everything in C language? You think you got memory leeks now - go back to the good old days :slight_smile:

Both Node-Red and TiddlyWiki were ahead of their time - and quite frankly - still are ahead of their time!

8 Likes
#5

I can perfectly relate to that working with both especially using the node js version of tiddly - which provides a nice REST API to read / manipulate and query tiddlers.

In my setup adding a specific tag to any tiddler has a NodeRed scanner pick it up and send a rendered version of the tiddler to a specified email (and then resets the tag).
Work in progress are maintenance features to tiddly like moving old tiddlers to an archive.
The combo is extremely powerfull and flexible