Fork me on GitHub
#pathom
<
2022-06-04
>
JAtkins03:06:26

Short tome: Has anyone thought about using Pathom Resolvers + Mutations + Specs to define the API of your service, then letting the computer generate the UI? I've had the idea in the back of my mind for a long time that UI sucks. It's bad for us as programmers when we have to build an app across 5+ form factors (more when you consider the possibility of AR, VR, or voice assistant applications). It's bad for the consumer when we develop a subpar UI. It's bad for the consumer when we build a good UI, but it's not talored to how individuals use it. For example I use about 5% of the potential functionality of my IDE, but it's extremely tedious ranging to impossible to customize the UI for myself. Yes, keyboard bindings exist but for the most part let's ignore that. Most casual users won't learn keybindings. And, that ignores that I'd like to customize the application state I can view. OK, the problem established, here's a possible solution: stop writing UI. Instead, write api descriptors so an agent can design a UI for you, knowing the capabilities of your application. Early versions of an agent will require massive amounts of hints, but that's probably still easier than writing UI. Having an agent (ai maybe?) would also allow input from individual users to the system with hints as to how they want to view the app. "show the buttons in this order. " "show the status of this in that box." etc. Pathom + Specs might be enough information on the API side, but maybe it still comes up a bit short on the static analysis side.

👍 1
nivekuil03:06:00

sort of sounds like hyperfiddle?

JAtkins04:06:37

That looks sick. It sounds like this, but with all the extra bits I though might be insane :) (e.g. UI components as resolves)

nivekuil05:06:20

I think using pathom for this is more interesting though, since hyperfiddle is afaik coupled to datomic's schema

dvingo15:06:00

YES YES YES I've had very similar thoughts but replacing spec with malli (https://github.com/dvingo/malli-code-gen) The main reason being that in order to programmatically and dynamically generate and parse specs you need macros. Malli schemas are easily parsed at runtime (and since starting work on that repo there is now malli.core/ast which makes this trivial ) The direction I was thinking is having a public DB/hashmap of malli ref schemas (like :com.twitter/tweet) to a fully qualified symbol representing a function that can take a hashmap that validates against the schema and produces a ReactNode type (or output for other UI libs) https://github.com/dvingo/malli-code-gen/blob/main/thoughts.md#visionary-ui-idea The pathom part is that the malli schema would generate the output vectors for pathom and then you have a handful of generic resolvers and mutations that interact with specific storage (same idea fulcro RAD uses). I've been iterating on this a little bit since, in an app but not fully there yet.

JAtkins17:06:53

So, another interesting thought is if you have specs (malli or otherwise), it might be useful to give the agent building blocks to work with. For example, you might say the :int spec maps to a :slider. Even cooler, you can say [:int {:min 1 :max 9}] -> [:slider {:min 1 :max 9 :step 1}]. To achieve max coolness you can totally have more than 1 UI element mapped to types. e.g. {#{:int} -> #{:slider :text-input}}, or you can have that type -> ui mapping handled by pathom. The true advantage would arise when you have stuff like maps or graphs that could have many different implementations for views of the same data. Also, if you put in data source translation pathom resolvers (e.g. resolver [::graph1/location] [::graph2/location] ), the UI suddenly has way more options for what it can show.

JAtkins18:06:10

Have used it. Not quite what I want. It has too much manual code still. But similar vein I guess

dvingo21:06:19

Regarding concrete implementations: This talk has a code snippet showing an idea of how you can abstract over UI implementation: https://youtu.be/BNkYYYyfF48?t=1321 This talk about reusable re-frame apps landed on a similar pattern using integrant https://youtu.be/b_uum_iYShE?t=1594

👀 2
tony.kay17:06:26

Much bigger fish (i.e. Microsoft, Apple, and many many many others) have been trying to crack this very nut for decades. Not only would you like to not be writing it over and over again, companies would like to not be paying you to write it over and over. So, I think it should be sobering to you that: A. If we’re ever successful at that, a lot of us will be out of work. B. Every corporate interest on the planet would gladly pay for such a system, because it would be way cheaper than hiring us to write it. I’m not trying to discourage you, but this is not a trivial problem. “Let’s just configure it via this thing (XML, json, malli), and we’ll magically have UI!” It is the dream (or nightmare if you like having a job writing UI 😄 ) When I wrote RAD I just accepted at face value that this is a very hard problem, and that the results (starting with things like Visual Basic and drag-and-drop UI builders, all the way through modern-day things like XCode’s app building tools) always require a lot of customization. Your business is going to want to skin it this way or that, and there are going to be real performance problems that require trade-offs and tweaks. IMO, you need a system that can dump out something useful, but also not get in your way when you need to customize it (and you will need to customize it). Saying that RAD requires “too much manual code” is puzzling. It literally allows you to configure common UI as pure declarations, but then gives you an escape hatch when simple code generation is insufficient. From my perspective what you’re saying is “the generated code isn’t good enough, so I have to keep customizing it”. Yep. That’s the problem. The solution from my perspective is: make it easy to do that customization. RAD has huge amounts of room for improvement (including making something that can generate complete applications from data, which it is designed to allow, but I’ve not had time to write). But I don’t have the illusion that it’ll ever not suck in some way. It’ll suck in plenty of ways, just like all the other stuff out there. You’re right to say “can’t we do more with this declared data/schema than we’re doing?“. Yes, we can. Yes, we should. The complete solution, I guarantee you, isn’t in data and API specs. You have to say, somewhere, things like what color something should be, and how many things to put on a row, and what to do when the text doesn’t fit in a box. Declaring those overrides and customizations at their location of use (e.g. the report, form, etc.) is a good solution, IMO, because you will have different opinions of what those overrides are based on their contextual use. I.e. say I have an address entity in my database. In one context (perhaps using location from browser or phone) I can fill in most of the address for them, so I only want to ask them for their street. In the UI, how do you tell it that you don’t need all the fields in that context? How do you make the validation understand that an address, in that context, needs only the street? Do anything but the most trivial thing and you’ll find that the database context very often differs from the usage (UI) context. Anyway, just my 2 cents. I do actually hope you make some inroads or improvements, but I would suggest you study prior art with more serious intention, lest you just end up re-inventing the same old crap that didn’t work last time 😄

👍 2
💡 1
JAtkins17:06:41

Oh, lol. It's spit balling. IMO it would require "ai magic," which I have little to no skill in.

JAtkins17:06:55

The only real "shortfall" in rad is that it's not really very user customizable. What triggered this vein of thought was seeing smalltalk systems of yore where the client could change OS code to add buttons to their apps live.

JAtkins17:06:20

But, I dunno how to solve that. Merge conflicts alone would be a pita.

tony.kay17:06:30

“Isn’t very user-customizable”??? That is a surprise to hear you say that, given that the entire system has customization escape hatches everywhere. You can take over the rendering plugin, the db integration, etc. Yeah, the rendering plugin I wrote isn’t very “tweakable”, but that’s because it is a small amount of code you can copy and paste, and then plug in exactly what you want. It’s intended to demonstrate how to make a UI builder for RAD, not be the all-encompassing solution itself 😄 The biggest shortfall, IMO, is the lack of good docs. But I’m too busy at the moment.

JAtkins17:06:13

No, it's programmer customizable. Not client customizable.

tony.kay17:06:30

AH, well isn’t that just one step removed? RAD is all run-time capable.

tony.kay17:06:53

making a user-driven interface to emit runtime UI is something I’m doing with it, just not in the open-source space.

JAtkins17:06:35

True that. Maybe rad with those runtime facilities is the dram. Requires some thought.

tony.kay17:06:38

Just because RAD defaults to having you define artifacts in code doesn’t mean they aren’t data 🙂

tony.kay17:06:48

Clojure is, remember, just data

tony.kay17:06:01

But the hard problems in that space, IMO, turn out not to be the UI generation. Data is the problem: allowing the user to build arbitrary schemas and queries, which have unpredictable performance impacts, is the real quandry. You give me a predefined schema, and a GUI builder for users isn’t all that hard. But users want more: they want the data model itself to be customized.

JAtkins17:06:47

It'd be fascinating to see what codox copilot trained on schemas and the business description would spit out

tony.kay17:06:31

Yes, there are all sorts of fascinating and interesting problems here. Let’s say that you have sophisticated enough users to make a good schema (Sales Force users manage to make ends meet), and you give them a reasonable way of getting a UI around it, again, a problem that has been solved many times with varying degress of “success”. Now you faced with the next hard problem: Users start dumping large amounts of data into the system, and now they want a report, which requires churning through millions of records in some way. They don’t understand indexing or search engines, but they want to ask a complex question that requires one or both. I guess you’re just wanting to spit-ball around generating UI, but from my perspective the UI is always tied to the data processing, not just the schema. So, now you’ve got to give them knobs (and implementation) for saying “index that”, and “make that full-text searchable”..or else the UI doesn’t ever function to meet their needs.

tony.kay17:06:43

But I guess I’m off on a rant 😄

JAtkins17:06:17

Haha 🙃 Yes, there's a reason like you said M$ hasnt announced this product

tony.kay17:06:22

But I’m on the rant because these are the things I was thinking about when designing RAD. Making an open and extensible system where you can plug in solutions to problems like these is what I see as a good solution to the real combinations of problems that real-life systems run into.

tony.kay17:06:57

The old “If you design a system that any idiot can use, then only an idiot will use it”

JAtkins17:06:04

That's a saying? How literally is it intended? Tis new to me.

tony.kay17:06:38

It’s a quote. I don’t remember who it is attributed to

tony.kay17:06:47

I didn’t make it up, though

JAtkins17:06:32

It sounds like a saying that would spread, so I dont doubt that 😂

tony.kay17:06:01

But anyway, if you give me a system that can emit a UI, even a good UI, it is dangerous to me (because it leads to vendor lock-in and development drag) unless I can easily customize it in pretty much any arbitrary way. This, IMO, is why most GUI builders are not great: they get you up fast, then choke you to death. They have tons and tons of knobs to make things “look pretty”, but no easy way to affect things that really matter. Oh, and few of them that are good are remotely usable by an end user. The end-user stuff is being done by places like SF with good success, but they have a target audience with focused constraints, and billions of dollars.

tony.kay17:06:29

It is also why RAD is a challenge for new (and even Fulcro) users: I haven’t supplied enough “batteries” to make it a clear win on the initial take (my personal apps have tons of custom local add-ons to cross that line), the documentation isn’t complete, and most ppl won’t dig into the source to really understand how to escape from (or augment) what it generates. If they have experience with the other failures in this space it feels too risky to even try, because why go down a hard path that is possibly as bad or worse than the last thing like it you tried? I don’t blame them.

JAtkins17:06:15

that happened to me :). We went for a rewrite with a relatively new-to-fulcro team. Rad didn't make the chopping block sadly.

tony.kay18:06:06

Not surprising. Adopting new technologies is risky. I’ve been told by more than one SW developer “Why would I want to take a job in Clojure? That’s a career killer!” Non-popular things are, well, um, not popular 😄

tony.kay18:06:48

What’s funny is that adding RAD to a Fulcro project is one of those “you’ve already adopted the core…why not put it in and use it when you see a good spot for it” kinds of things…It isn’t like you have to have it do any UI for you, or any db stuff, or any resolver stuff. But, where it makes sense, it can help you with any of those. But I know a lot of people see it as a thing that you add and then have to use for everything…another PR problem that I have no energy to solve.

JAtkins18:06:00

It's an empty promise till I have time (hah), but adding docs and features to RAD is next on my OSS help list.

tony.kay18:06:58

always happy for the help. Let me know when you have time and I can probably help direct your efforts more productively

👍 1
wilkerlucio23:06:15

@U5P29DSUS are you familiar with https://www.appgyver.com/ ? this is the closest thing I found around the kind of no-code dev environment

1
wilkerlucio23:06:50

one of the things that make it complicated its because its not a single problem, but a bunch of them that we are trying to make a silver bullet for

wilkerlucio23:06:00

design is a big issue on itself, where things go, how things respond to size changes... I think XCode does a good job on this area

wilkerlucio23:06:52

but them there is the "make it alive", integrations, loading, performing operations... those have to have integrations with the UI, and have an implementation for the actual behaviors

wilkerlucio23:06:30

I believe pathom+fulcro is a good combo to design the primitives of such system, by making EQL the de facto layer between the UI and the underlying systems (that may be a server, but could also just be local stuff, the point is that it shouldn't matter for the UI layer)

wilkerlucio23:06:09

them, to make it "non developer friendly" we need a whole ecosystem of things on top of it, some people can make packages of UI's (bootstrap, bulma, blueprintjs...), other people make packages of server integrations (pathom resolvers and mutations) and finally someone else can use the codeless IDE to plug all together