An exploration of the the future of Pyro and AshAdmin

Ash Forum Ash Chat
,
1

An exploration of the the future of Pyro and AshAdmin

I’ve been playing with ash _admin.
from my point of view, pyro and ash_admin try solve the same “technical” problem.

But allow me to describe a market perspective:

Solution Space Perspective

In web frameworks (Laravel and Django) the problem is called admin panel
In ERPs (Odoo, Frappe) it’s called interface builder

Sexy Sass - have the best looking UI

in most ‘Sexy SaaS’ (think AirBnb, Spotify, Netflix) admin panels are not customer facing . and are mostly used for back-office. Mostly because the UI is branded and the UX is crafted starting from figma, and designers like to have more freedom building their design system.
I would tag ‘Sexy’ any saas where the business decision is to have appeal as key success factor.
In a UI design project, appeal is achieved by 2 factors:

  • beauty : this can be subjective but human are naturally drawn to ‘harmonious’ designs.
  • and uniqueness. if something is beautiful but not rare, it becomes less appealing

Sexy SaaS is mainly built using Figma and custom design system from the ground-up (examples: Projects | Component Encyclopedia | Storybook)

ERPs interface builder - are well architectured and are implementation complete

In ERP Interface Builders is what is used to build customers facing screens. In an ERP it is common to have a few thousands screens.

So Interface Builders are more battle tested and more feature complete than ‘admin panels’

So personally as an engineer I like to ‘steal’ from Odoo because their GUI paradigms are old and ahead of everybody else IMO.

But as product designer, ERP can be ugly to my eyes (even if Frappe and Microsoft dynamics doesn’t look bad)

Admin panels from web frameworks - are junior Interface builder

The architecture paradigm on admin panels from web frameworks is the the same as ERP interface builders.

And the best looking admin panels don’t inspire me either.
IMO an interesting approach is retool.com
retool was a backend agnostic admin panel, I just rechecked to day I see they pivoted to a low-code app builder. wow. I will revisit them.

No-code / low-code App Builders have the best ergonomics

So where I do find better (ergonomics and looks) Interface builders. Well it’s in No-Code solutions. My benchmark and inspirations are Fibery and DirectUS (I have to recheck retool)

Gartner Style magic quadrant.

So here is my opinionated summary

  • Sexy Sass - have the best looking UI
  • ERPs interface builder - are well architectured and are implementation complete
  • No-code / low-code App Builders have the best ergonomics

I don’t have a “magic quadrant” yet. And there are more than 2 axes of classification:

  • Sex Appeal
  • Coverage
  • Ergonomics
  • Backend Agnostic

But regardless of targeting a niche or mass markets, I feels that these criteria can segment the space pretty well.

Disclaimer: This is an opinionated post, not a study. Ash is great.

What about Tools and Skills

  • Sexy SaaS: World class Designer in Figma, mastery of graphic design. (Design System), Handoff to Front-End engineer (a JS fanatic most of the time :wink: haha). The output is a Design System that can be shared to the public.

  • ERP Interface builder: Just compose the interface in a “Studio tool”, the old school way, with drag and drop. Or use an XML syntax, well documented. No graphic design skills necessary. But Just good copywriting and good common sense. High level knowledge of UI design is welcome. The Design system is build once, and reskinned every few years. But most of the time it’s locked in the past. Opportunities for Redesign are rare.

  • No-code: they target entrepreneurs. So these tools have the best ergonomics and are the easiest to use. These tools can make a lot of money (can be billions$)

  • Admin panels from web frameworks: these are built using DSLs by nerds like you and me. People who enjoy vim or vscode. Most of us are bad ui designers and prefer keyboard to mouse. These tools are mostly free or make a few money < 10M$

Is it Business Opportunity for Ash ?:bulb:

What about a product called “Ash Studio” similar to retool.com / fibery.io / directus.io
I would call it just Ash (one word) and rebrand the framework as “Ash Framework”. The UI DSL will stay open-source and free forever. Nerds like me will stay happy :wink:
The UI code will be payed for, open-source, with hosting options. The UI code can be self hosted and hosted on our cloud, and does connect to your backend.
Nerds hate making good UI so they can ask their boss to pay for UI.
I did pay for tailwind UI and I am happy.

With an open core model. This will bring more money to the core team, and thus allows for a better velocity and exposure while still staying small.

2 Likes
2

Some context on my personal intentions for AshAdmin:

After 3.0 and UX improvements, I plan to focus on ash_admin for a while, very potentially in conjunction with @frankdugan3’s work on pyro. The goal will be to invert the current configuration style from living in the resource to instead be its own separate DSL. Currently it is built as basically a “super admin UI”, and it needs to be rebuilt with the specific intention of being distributable to end users.

5 Likes
3

I am very glad to hear this. I very briefly looked at pyro and my immediate reaction was omg, no way will I bake UI into a resource.

Please don’t take this as any kind of criticism, I think you’re doing fantastic work on Ash.

Seeing pyro UI made me somewhat question where is Ash heading because resources should not be trying to solve everything such as taking on UI. My thoughts also consider JsonApI and GraphQL and Authentication as out of place within a resource. Despite these being useful features of Ash it feels wrong having too much baked into the resource, code APIs, web APIs, and web UIs should in my view live outside the resource frame.

My suggestion would be clear layering on top of the resources for UIs and web ApIs perhaps even higher, through our Ash code APIs (with access to the meta data/DSL so the derivation continues to be high value) may make Ash more approachable rather than appearing like a “kitchen sink”. It would also facilitate use cases that cut across more than one resource, like UIs, reporting and dashboards, and potentially break free of what I think of as the resource pigeon hole.

I also wish Ash code APIs were not called “APIs” and embraced the familiar Phoenix concept of “context” which would help people conceptually coming to Ash as well as mixed code bases with regular Ecto schemas and queries, and also to clearly disambiguate from web “APIs”.

4

I’ve made that suggestion too :slight_smile: They will be likely getting renamed in Ash 3.0, but not to Context - probably to something more neutral like Interface.

1 Like
5

Yeah, our current line of thinking is that Context is too vague of a term. The “context” is really just the folder/namespace. What is currently the Api is the interface to the context. It isn’t itself a context.

1 Like
6

I see different level of separation between UI and Data

[1]. File Separation - One Author - One language
UI on top of Resources - resources in Ash are mainly attributes and actions). Strong integration of resources and UI. opaque interaction and it just works. The Ruby and Rails/Phoenix way.

[2]. Technical Stack Separation - One team 2 authors (Backend skills/ FrontEnd skills)

[3]. Server Separation (client/server) - Many Authors
UI app as a consumer of Resources - sources are Rest API, GraphQL, Google Sheet - whatever data source. Consume anything approach.
My benchmarks here are https://ballerina.io/ the language and https://retool.com/ the no-code solution.

I feel that:

  • Ash does not have to follow phoenix choices. Having SparkDSL is paradigm shift. RoR and Phoenix are mainly [1]. But ash can easily do [1] [2] and [3]
  • I have an FMAO. The best UI systems (Spectrum, Carbon UI, BlueprintJS, Shadecn/UI) cost a lot to build and they are build with react. We have to consume React components or at least Web Components.
  • Imagine a DSL (built with spark) that builds the frontend and that uses React or webcomponents. It can look like this: Thermostat | Qt 6.6
7

Honestly, there is an almost zero chance that we (or I) will build an admin interface using React (definitely going to use liveview). I have “other plans” in the long term, but in the near term that is definitely the best option. But, its an open community and there is no reason why others couldn’t take an alternative approach :slight_smile:

1 Like
8

FWIW, Zach has already suggested to me the possibility of modifying the Pryo DSL such that it could be used either in a resource or separately. I like the idea, and it would be trivial to make that possible down the road.

My use case for Pyro is in building an ERP, which has hundreds of resources. The coupling makes it simple to keep track of things for me, but I completely understand that many would not like to do it that way and would like to accommodate both ways of doing things. It also makes sense to make room for other contexts, like LiveView Native or Scenic.

2 Likes
9

I am keeping an eye on this thread. it’s the hotest one to follow.

10

hey @frankdugan3 whats happening with Pyro? active?

11

Yeah, I’ve been dogfooding it at work and experimenting with some new ideas. Can’t promise when, but a new release will be coming sometime this year with a pile of improvements.

12

Do you use pyro as an alternative to ash admin?
You use pyro for an erp?
How many resources do you have?

Would it be performant to have public facing landing pages generated like this?

13

I would say Pyro is orthogonal to AshAdmin. Pyro is meant for userspace UI, AshAdmin is more of an admin UI.

Yes, I originally designed Pyro to be used in an ERP with 90+ and growing resources.

The page performance is good as I make it a point to do the heavy lifting at compile time, but I would have to admit that adding UI DSL to the resource itself was a mistake as it creates a ton of heavy recompilation for every change to the UI. Part of my work has been to move the UI DSL outside the resource files.

The AshPyro part is actually pretty easy, and you could easily roll your own solution using your components. What has been super challenging has actually been the designing the component library with the level of customization I’m aiming to achieve.

2 Likes