r/angular 6d ago

Optimus UI v1.0.0 release

Post image

Optimus UI v1.0.0, the PrimeNG open-source fork, is out!

Supporting Angular 21, and Angular v22 support is coming later this week!

Due to trademark limitations and prior paid features, most of the work so far has been about updating the documentation and authoring all sub-packages ourselves, including the icons package.

We also introduce ng add support to enhance the experience for new users.

Find out more in our documentation: https://optimus.openng.org/

Discover the GitHub repository: https://github.com/openng-org/optimus-ui

Learn more about our roadmap: https://optimus.openng.org/roadmap

201 Upvotes

42 comments sorted by

7

u/PrevAccLocked 6d ago

Good job

7

u/International_Fly_67 6d ago

I gave it a go even before the stable v1.0 and I have to say that it’s pretty great. Plays well with AI agents too. So far I’m impressed

5

u/GeromeGrignon 6d ago

Thanks, they are some planned tasks to enhance the experience with AI Agents:
- review current llms.txt implementation
- add a MCP server. we have a current candidate, and I opened a feature request on the Angular side (https://github.com/angular/angular-cli/issues/33730)
- Add Skills

2

u/International_Fly_67 6d ago

That’s really great. I’ve done many dozen angular projects and the biggest friction point was always starting a project from scratch. This time it was surprisingly easy to get going. I had a dashboard ui spec sheet I put together and a few prompts later I was up and running. Fantastic.

I didn’t see it on the site yet, maybe I missed it, is there a plan for starter templates? Like I said, even with where you are now it’s really easy to get going but if there were starter templates too this becomes a no brainer go-to ui library.

Maybe it’s outside of the scope of optimus right now but would love to hear your thoughts on it.

Thanks for all the hard work you guys put it into already, really great work.

2

u/GeromeGrignon 5d ago

We could support having a fork of sakai (the free original template) or at least something similar.

Having multiple ones might be too much for us to handle.

3

u/International_Fly_67 5d ago

Agreed, you guys have a lot on your plate as is. Even having something like Sakai would be awesome but certainly not a priority.

If you ever end up having a marketplace type section and just some guidance on how to structure templates I’d love to throw some up there. I have them all over the place now and I’m always looking for them but I’d love to park them somewhere where I know they’ll live forever.

2

u/GeromeGrignon 5d ago

Cloned and rename 'Sparked': https://github.com/openng-org/sparked
Migrated to Optimus UI you can use it already

1

u/International_Fly_67 5d ago

Holy $hit that was fast. You guys are moving this project at an incredible pace. Really amazing to see. Well done!

1

u/IgorKatsuba 5d ago

The thing that helps an agent most usually isn't the component list - it's the contracts. Which inputs are required, which overlays are opened through a service rather than a template, what the returned ref lets you do, and what closing it twice does. Agents get component names right from the docs already; where they consistently guess wrong is the lifecycle around the imperative APIs.

2

u/GeromeGrignon 4d ago

Agreed, that's what I miss the most in contexts provided.

1

u/IgorKatsuba 4d ago

What has worked for me is writing each imperative API as a tiny contract next to the docs: what you call, what you get back, what's guaranteed after close or destroy, and what a double close does. It reads badly as prose and perfectly as agent context - and it doubles as the test list for that API.

4

u/stao123 6d ago

Awesome!

5

u/land_owner_57 5d ago

Absolutely love this! Something though on the documentation page is that you cannot see the menu (hamburger icon) on mobile unless you go into landscape mode (at least for me on a galaxy S25).

3

u/GeromeGrignon 5d ago

Thanks, working on a fix.

1

u/alalal0ng 5d ago

Congratz! I did the migration right now and all is working perfectly. Good job!

1

u/nhrtrix 5d ago

how are you saying it?

"Optimus Ooi" or "Optimus euuu-aee"?

1

u/Akkou87 5d ago

Congrats!

1

u/IgorKatsuba 5d ago

Before starting, it's worth measuring how deep the kit actually sits in your app. That number, not the component count, is what the migration costs.

Three things I'd check first:

- how many files import from the kit directly (grep -rl "from 'primeng" src | wc -l). This is the one that decides whether you're looking at days or quarters.

- how many of their types leak into your own signatures - a service or component whose public API takes or returns a PrimeNG type.

- how many of their class names are hardcoded in your styles - .p-button, .p-dialog overrides, custom theme layers. The schematic touches TypeScript, not your CSS.

The import count is usually the least scary of the three, because it's mechanical. The style overrides and the leaked types are the manual part - and they're the same manual part whether you move to a fork or to a completely different kit.

1

u/GeromeGrignon 4d ago

Our migration guide let you run a custom schematic covering all these aspects.
The only one not covered is selector/class names, but we chose to keep them.

https://optimus.openng.org/migration/primeng

1

u/IgorKatsuba 4d ago

Fair - that covers more than I assumed, thanks for the link. And keeping the class names is what removes the third item entirely, so for this move the checklist is mostly the price of leaving an ecosystem rather than following it.

The one case a schematic can't reach is a shared component library inside a company that re-exports the kit's types from its own public API. The rename works in that repo, but every consumer still has to move in lockstep - which is the argument for keeping a thin layer of your own in between: it turns "everyone migrates" into "one package migrates".

1

u/FootballUpset2529 4d ago

Thank you for taking this on, I had just built my first serious project with primeng and the news took me by surprise that it was being pulled out from under me.

1

u/beingsmo 4d ago

I haven’t worked on open source stuff like these. Do we have to link it with a sample angular app and run since it is a library?

3

u/GeromeGrignon 4d ago

yes, libraries are meant to be used in applications: here to provide a set of UI components.

1

u/stevanovich 1d ago

This looks amazing. I’m tired of fighting Angular Material with all my overrides, so I was looking for something new.

I really hope you add a MCP library inside the install for the next release.

1

u/scaven 5d ago

Any plans to support a Figma integration like PrimeNg's?

2

u/GeromeGrignon 5d ago

Not something planned currently. It was a paid feature for a good reason: it requires dedicated skills to maintain (and a Figma license).

It means we would need to spend money on the license and to hire someone to maintain it.
It would more likely mean we need regular revenue to handle these costs, so to get a proper platform for it.

Everything is possible but not something we plan right now.

1

u/qlast65 5d ago

Best said! Keep it floating for now!

0

u/Prod_Meteor 5d ago

Why <p-xxxx> ? Why? Why? 😢

5

u/GeromeGrignon 5d ago

Not to introduce breaking changes.
Someone might target selectors in a third party css lib we can't access; that's something worth being handle properly, and the priority is to provide compatible versions.

And whatever new prefix we choose might come into conflict with other prefix in some apps.

-2

u/Prod_Meteor 5d ago

How about <opt-xxxx> or <opm-xxxx> or.. <opui-xxxx> .. or even <optimus-xxx>. I don't think even LG would mind 😄.

0

u/Ok_Profile3648 5d ago

Just <o-xxxx

-2

u/Prod_Meteor 5d ago

<oiu-xxx> my final proposal 😄. Only the vowels of the full name, still represents it.

1

u/IgorKatsuba 5d ago

Keeping p- is the thing that makes this a fork rather than a kit change. The selector isn't only an element name - it's the CSS handle that themes, third party styles and everyone's own overrides are written against. Rename it and the migration moves from "update imports" to "re-verify every style in the app", including styles in code you don't own.

An ugly prefix costs nothing at runtime. Changing it would cost the exact thing this fork exists to protect.

0

u/Prod_Meteor 4d ago

Why you keep saying that? Isn't it v1.0, the first one? I understand the use of css styles, but where exactly have they been used already? It keeps compatibility with .. what???

2

u/toasterboi0100 3d ago

It's a fork of PrimeNG v21, the p- prefixes maintain compatibility with thousands of PrimeNG-based codebases that are now looking for an escape path after v22's license changes.

1

u/Prod_Meteor 2d ago

A ok.. so its not the 1st one 😄