An unusual effort. Apparently you created new HTML tags. And they have semantics. What i don't see anywhere which baffles me is your data structuring. Programs = Algorithms + data structures according to Prof. Wirth, and where are the data structures? What are the primitive types of your system? If there are no data structures, then how would you do a tic tac toe game for example, where you track the mutable state of the game as it progresses? Or do you intend the game to be a custom module. JSON is a highly limiting data storage format, it only has boolean, string, and numeric data, and meta data is quite awkward to embed.

I did like that you had students build little test apps.

Components can act as data structures - and transformations can accomplish a lot

if a component acts as a data structure, how would component B access the contents of component A's data structures? If you only have JSON, how does one import a sound or bitmap? are you using explicit RAM pointers like JS? If so how do you then serialize your data for transport over the net? How does one introspect the contents of a component? If you have no meta data structuring, then each component author may adopt a different protocol. The devil is in the details as they say.

I have yet to look at this closer, but it sounds very interesting!

Edward, you should try declarative programming, you may enjoy it

It’s not clear to me who this is for and what problem are you solving? You mention concepts like objects, id, inputs, outputs,, events, components, classes, and properties which are pretty strong terms — all requiring explanation of domain and constraints. The foundation of the UX is also quite complex which will turn-away most people.

Additionally, the problem you are solving is not clear. Instead of comparing to other apps (which I think is not a good approach) I rather ask what specific problem this is solving? Internal or external tools? What department?

“the dollar sign means its coming from the parent in the Deja Ju language; which you don’t need to know - your designer will, unless you want to type it out yourself” — That statement is revealing to my comment above.

Edward de Jong To answer your question about the tic-tac-toe game, we would expect that to be a separate concept. The goal of Déjà Vu is not to be a general-purpose programming system, and it will not be well-suited for some types of web applications like games. That said, in our HTML extension, you can write expressions for the input/output bindings between components, and we have some concepts like “Property”, which are quite generic and can be configured to support different use cases.

Steve Peak the goal is to make it easy for people to develop web apps that are a mix of commonly found functionality, with little custom behavior. For example, a basic Yelp clone for your community, or a social app for planning events on campus, etc. The audience is people that know HTML/CSS (if they want to use our language and get absolute control of the layout/styling of the page) or people that don’t necessarily know how to code, which is what the graphical environment is for.

Steve Peak I agree that the tool is more complex than it should be 🙂 This is a research project with little funding and we focus our efforts on validating our approach instead of doing a ton of engineering work to build an enterprise-ready shiny version of our tool

Steve Peak to add a bit more on the question about who is this for: today you have many people using CMSs like WordPress/Drupal to build medium-complexity apps that go beyond a regular blog. You can do a lot with plug-ins in CMSs, but plug-ins lack a generic composition mechanism, so composing them often requires a lot very complicated glue code. In Déjà Vu, our plug-ins (the concepts) can be combined together more easily through the declarative synchronization of the server-side actions of components. Essentially what we did is build a generic composition mechanism for plug-ins.

HTML/CSS is coding though. It may be the basics, but it’s certainly already in the realm of complexity that most people don’t know and may have learned out of necessity. Figma, Notion, Fibery, Airtable, and several other nocode platforms that already exist today feel more appropriate for these types of use cases. They may not fit perfectly, but that is not the point and the user won’t know that until they try various solutions.

Steve Peak I read it as.. > The audience is (A) people that know HTML/CSS ... or (B) people that don’t necessarily know how to code, which is what the graphical environment is for. So yes, HTML/CSS is coding — that's the point. Deja Vu seems to be intended for people who are right near the dividing line between "comfortable with basic forms of coding" and "not" — which is an interesting space, because clearly Deja Vu is a coding tool too, so it's pushing that boundary a bit.

Figma, Notion, Fibery, Airtable, and several other nocode platforms that already exist today feel more appropriate for these types of use cases. They may not fit perfectly, but that is not the point and the user won’t know that until they try various solutions. I don't understand your point here. Are you arguing that these existing tools are already doing the work that Deja Vu aims to do? What should Santiago take away from this?

Figma, Notion, Fibery, Airtable, and several other nocode platforms that already exist today feel more appropriate for these types of use cases You might be able to build some of these apps using no-code tools, but it’s more work than using Déjà Vu. If you use something like Bubble, for example, you have to write all the end-user behavior yourself (when a user clicks on this button, do this, etc) and if you use a plug-in like Discord for comments, you still need to write back-end triggers for things like when a new comment is created, do X, etc, to get the compound behavior you want. In Déjà Vu, you can get compound behavior by synchronizing server-side actions (you only put components inside a <dv.tx> tag).

For more about this, see section 1.2 of the paper: https://spderosso.github.io/onward19.pdf

Ivan Reese I’ve been chatting with Santiago in DM with much more content. I’m more interested at poking at the foundational questions of WHO and WHY before we get to the HOW. And yes, I do believe existing tools today solve the problems at hand. It remains unclear to what DejaVu is focused on (who/why? not how yet) which is what I’m DM’ing him about.

So, the idea is to structure the web application as set of pre-defined concepts? Then these concepts are composed together declaratively as a html tree data structure (coded by someone or generated by composer UI). And under the hood, there is something that coordinates the client-server communication (by handling eval/exec), with possible transaction like synchronization for certain events?

I did not fully understood the part about composing concepts. I think of concept as a "process" (that runs on frontend/backend) with eval and exec operations. So if I have two concepts, how can I combine them?

Will it mean that for combined concept conceptC I will get the conceptA.UI and conceptB.UI somewhere in the UI of combined concept. And both data from conceptA and conceptB will available on eval step (like in a graphql query). And for the exec step — the A.exec and then B.exec will be executed in some order?

i like this. it seems like you might want a fuzzy search over a lot of the lists in the app just as a ux note. but particularly it’s nice to see apps in this space being used relatively rapidly instead of at a snails pace. when i’m using eg airtable i often find myself knocked out of my flow state by like 67 different dialog boxes