Alternative UI Framework for Daml Smart Contracts

Questions
, , ,
1

I note that most of the official Daml examples use the React UI Framework as do the community tutorials, plus some Typescript/Javascript support. When I get to the point of writing a non-trivial Daml smart contract while I could in theory use React UI however after working through the Daml Rental application b @fabio.tudone I see there is at least a degree of medium level competence required to build that example.

Fabio has had substantial React UI experience, while I have not, and any mods to the UI assets that I will need to make will involve Copy&Paste, Trial&Error which in my mind is a terribly inefficient way to learn.

Does anyone know of an existing UI framework that adheres to the following specs:

  • Platform agnostic
  • Light-weight
  • Extensible
  • Mature
  • Very low barrier to entry

I do not have the time or the willingness to become competent in an UI frame work like React or Flutter as I would prefer to expend my energy in learning the core language and ledger technologies. I am looking for something super simple, that can be hacked up and encoded with the correct Daml assets, templates and concepts.

At this point I’d use Scratch if it worked. Comments? Thoughts?

After extensive consultation with Me, Myself and I, it seems that learning the Daml/React UI components is really the most pragmatic decision that I can take, in moving forward to become a Daml professional.

Thank you @cocreature @gyorgybalazsi for giving me pause to think :+1:t2:

1 Like
2

I am not that knowledgeable about UI frameworks so I can’t recommend one in particular or even judge how well they adhere to your criteria. But the @daml/ledger package that underpins our React library is a good library that you can use with regular JS (or any framework). It has a pretty faithful representation of our JSON API so I highly recommend that you use it with any other framework.

2 Likes
3

You can find two examples of using @daml/ledger outside of React in @gyorgybalazsi’s blogpost on using it with Elm and @anthony’s o_beer app which uses Vue.js.

That said while both Vue.js and Elm are perfectly valid options, I don’t think any of them are fundamentally easier than React if you don’t have prior experience with any of them. And on the other hand, chosing something other than React drastically reduces the number of Daml apps you can use as a reference so you might end up making your life harder not easier.

4 Likes
4

That is a great point, about the reuse-ability of existing React UI code, thanks.

2 Likes
5

If you are still curious about alternatives, there is the the ReasonReact / ReScript/React project.

Reason was created by the inventor of React, and Facebook has already migrated substantial parts of their code base, originally written in React. Reason is OCaml on the surface (OCaml is a functional language like Haskell/Daml) and compiles to JavaScript.

It has all the advantages of functional languages which are also what we like in Daml so much, like static typing, easy debugging and refactoring, applied to the React way of thinking. You can even mix and match with traditional React.

3 Likes
6

Thank you, that’s interesting. Read more on this, I shall :thinking:

2 Likes
7

@quidagis Did you settle on a front-end UI framework that you liked?
I have been reading through this thread and have the exact same dilemma. I have nor the energy nor the willingness to learn React yet much of my DAML code that I need is well complete.

I did however discover many visual builders for React which reduces the need to write code by a good 50-80% and they give you a code export option which means you can just copy and paste the code in once it’s been generated by the builder, see divjoy as an example, however, the code exports to JS and not to Typescript which is a major bummer.

There is also Chakra UI which isn’t a visual builder but provides a really healthy amount of components as building blocks that again reduce development time. Another major advantage is that with this you can get Typescript code out of the box.

The whole thing is a dilemma however. I can’t decide how to move forward on this myself.

Anyone else welcome to chime-in here.

1 Like
8

Hi @krmmalik long time no see :wave:t2:

I took @cocreature advice and have stayed with React UI framework however … once I get past the Utterly Clueless and transition to Partially Clueless (Am there), I will think about an alternative UI for future development. However @cocreature makes an extremely enduring point that React UI by default works, and accordingly many of the internal developers and a lot of external developers will use it.

So if you were ever in the position of having to integrate into, or take over, or even maintain an existing React UI project, not being functionally competent could be detrimental both performance and employment wise.

I think your exploration of further options is a really good way to confirm/deny our view, and since Typescript is key to Daml’s models, then any non-React UI tool that can output Typescript or Typescript-compatible code is well worth a further look.

I cloned the Chakra UI repository and are going through it now

Thanks for the update :+1:t2:

1 Like
9

Using Typescript instead of Javascript offers some advantages, but I do want to clarify that the Daml tooling absolutely works with Javascript and does not require Typescript at all. We simply support Typescript, i.e. our code generators generate, separately, fully-standalone Javascript code, and Typescript type definition files.

2 Likes
10

Thanks @Gary_Verhaegen for some reason I had taken it to mean that Typescript compliant code was the policy. Not sure where that came from, but appreciate the clarification.

1 Like
11

So can I drop ordinary javascript into the .tsx files created by create-daml-app for me, or do I need to do a new configuration setup or some sort?

I have a significant amount of DAML written already so would prefer not to have to start a new template.

12

I don’t think that will work, no. The code generated by the codegen is JS-friendly, but the code in the template might not be, out of the box.

TypeScript can work in two modes. In one, you have separate pure-JS (.js) and “type definitions” (.d.ts) files. That is entirely “backwards” compatible with JavaScript, as JS tools can just ignore the type definition files (while TS tools can still use them to type check the JS code). If you look inside the code generated by the codegen (daml.js folder), you’ll see that the files we generate follow that convention.

The code we provide as part of the create-daml-app template, though, is not built that way: type annotations are directly in the .tsx files, and the build is configured to actually check them. If you start adding “plain” JavaScript, the build will complain that it is missing type annotations.

One thing you can do, if you really don’t want to use TypeScript, is to rename the files from *.tsx to *.jsx, and that should “just work”, albeit with warnings in VS Code along the lines of “type annotations can only be used in TypeScript files” (npm start and npm run build seem to happily ignore them, though).

Of course, at that point, the type annotations are not checked, so they’re at best distracting and at worst complete lies, so you’re better off removing them.

You can, to some extent, mix .tsx and .jsx files, so you don’t have to change all of them at once, but since some of our files refer to types defined in other files, you might be better off changing it all at once anyway.

Note that this is focused on “plain JS” as opposed to TypeScript; if you instead meant “plain JS” as opposed to “using React”, then there’s not much you can do other than scrap the entire ui/src folder and start that one over. (Probably with a fairly deep overhaul of the ui/package.json file, too.)

1 Like
13

OK thank you. Food for thought at least.

14

It’s a bit unclear to me what the cost to your Daml code would be of switching templates. (Also, which template you’d switch to?)

In most cases our templates provide either initial Daml code, which you’re free to delete and replace with your existing code, or additional things like the UI code in create-daml-app, which should have no impact on your existing Daml code, which you can still just put in the daml folder. You might have to tweak the daml.yaml file a bit, but overall, if all you have is the Daml code (as opposed to extensive changes to the UI code of create-daml-app, for example), switching template seems pretty inexpensive to me.

1 Like
15

Oh yes, that’s a good point. I think I am overthinking this.
Thank you.