About one year ago I posted about a starter kit for temporal web applications (web4th: time as the fourth dimension) – i think it’s fair to say that nobody really understood what i was trying to do 
Yesterday, I published an article to show how to build a “real” web app using that starter kit: How to build a web4th app — teawaterwire
hopefully you find something interesting in it – otherwise i’ll come back in one year with another attempt 
Seems like time passing is an important part of what you’re doing 
I suspect a lot of people got to the crypto/web3 stuff and went “oh, another one of those grifters…” and tuned out (see stuff like Web3 is Going Just Great (web3isgoinggreat.com)).
I started to read your new article and tuned out as soon as I saw NFTs, sorry.
Looking at the code, it seems to be a re-frame app – can you explain (without reference to crypto or web3 or NFTs or wallets) what sets it apart from a “regular” re-frame app?
the starter kit itself has nothing to do with crypto - it’s a web framework adding temporality
so i cannot blame crypto for people not being interested unfortunately 
the code of the app i built as an example of a web4th app is a regular re-frame app, except that instead of thinking in terms of navigating between pages, it’s more about having a conversation with an app.
The app developer has to think at the component level (react components) and the user will interact with these components in a “conversation”
i think you can see it the screenshot of the support section in the article ( 6. Set up support ) - no worries, there are no mention of the forbidden words you mentioned above 
Right, but both your original article and this new article talk about crypto/web3/NFT stuff and that obscured what the unique selling point of web4th was in the article 
(and the name suggests it builds on web3 so…).
I think this is the part you need to focus on in your explanation. If I build a re-frame app, it’s already all about React components (and events and effects and subscriptions). I’m trying to understand what’s different about your library – it seems to have a wrapper around dispatching events but I can’t understand from either article or the project README what it adds…
really interesting stuff. what’s the goal of this besides making a tut? nothing wrong with ‘grifting’ btw, especially if you’ve done the work and can differentiate yourself and your solution. This is especially important in software where everyone is looking to sell their own magical solution. Agile anyone?
why use your starter kit over X?
agree that agile people are the real grifters 
to answer your questions:
my claim is that this way of building web app is better because of the metric “how fast users are succeeding” ( 9. Compare with a normal web app )
but that’s just a claim, and i don’t have enough data to prove it.
i don’t have a specific goal in mind, just deep curiosity in the topic of temporality in web application. my main point being that the dynamic nature of our interactions is not matching the static reality of current web apps.
i took another look at the post and the code base. what are your thoughts on the following solutions?
looks like these libraries are providing what we get for free with ClojureScript no? immutability, atoms, etc.
that’s one way to look at it. isn’t reframe ‘just’ a wrapper around react?
yes via Reagent
my point with those libraries was that management of application state over time can be done a number of ways, without needing immutability. In memory history may be an issue if the application is large or if there is alot of history.
Most of the time, undo/redo state need to be saved to the cloud or localstore. It’s the solution that matters more than the technology being used.
ok got it. yeah in that case the history is saved in the conversation, technically messages in a room on the matrix protocol with the user, the app-id and the support agent (if invited)
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.