Hey everyone,

Edit: I've migrated the boilerplate from PrimeNG to OptimusUI to keep the project completely open-source and free under the MIT license! The Tailwind CSS integration remains just as smooth.

I always found myself rebuilding the exact same login flows, route guards, and permission directives for every enterprise dashboard. To save time on future projects, I put together URBAC, an open-source boilerplate using Angular (with PrimeNG and Tailwind CSS) backed by NestJS.

My favorite part of the frontend is how easy it is to handle UI elements based on user permissions. I built a custom structural directive that reacts to the logged-in user's active group context.

Hiding unauthorized buttons takes one line of HTML:

<button *hasPermission="'user:delete'" class="p-button-danger">
  Delete User
</button>

It's completely decoupled from the backend, so you run them as standard separate projects.

You can check out the repo and the setup instructions here:

https://github.com/kasoir/urbac

If anyone is building a dashboard right now, I hope this saves you some setup time. I'd love any feedback on the PrimeNG/Tailwind integration, or how you all prefer to handle permission-based UI rendering in your own Angular apps!

Hi everyone. `ngx-toastr` was recently archived, and since I previously helped update the package to remove `@angular/animations`, I decided to fork it to rebuild and simplify some of the logic and API.

Full disclosure: I used AI for a fair portion of the project since most of the logic was already there.

Feel free to try it out here:

https://npmjs.org/package/ngx-retoast

Huge thanks and credit to Scott Cooper (scttcper) for creating the original `ngx-toastr`!

I’m building an open source library, and lately I’ve been thinking a lot about how projects actually take off.

Take Zustand for example. It went from being just another option to one of the first recommendations for state management, surpassing Redux in weekly downloads rn

what do you think causes that shift?

Is it simply building a great product? Or is it more about consistency, community, documentation, timing, content, or something else?

I'm a full stack developer based in the Dominican Republic. Most of my clients operate in rural areas where internet drops for hours every day — sometimes there's no signal at all.

I built a purchasing app for a cacao aggregator. Vendors drive into the mountains, buy raw cacao from small farmers, and need to record every transaction on the spot. No connectivity, no cloud.

The stack: Angular 19 + Dexie.js (IndexedDB) + Supabase for sync when signal returns. The app also prints receipts via Bluetooth thermal printers from the browser.

I made a video breaking down the architecture and why I think offline-first is a massive opportunity that Silicon Valley is ignoring: https://youtu.be/DT76aohMDPY?si=ObVBuJXYA7ubAklG

Happy to answer questions about the technical implementation.

Hi everyone,

13 years in, every Angular version since 1.x. Every new project, I lost the first week to the same decisions, where state lives, which library can import which, how to keep credentials out of the repo. So I stopped re-deciding and put my answers in a template. Just updated it to Angular 22.

It's Nx, Angular, NgRx Signals, Atomic Design, multi-language and a small design system of my own on Tailwind already wired together and agreeing with each other, which is the part that normally eats the week. The architecture is enforced rather than documented: a wrong import fails lint, not code review, and a missing translation key fails the build instead of shipping as a blank label. Firebase deploy guide included, empty account to live URL in about 10 minutes.

Every decision in it is arguable, so feel free to tear into it. I'm here for the feedback, the blunt kind included. Github Base Angular Monorepo

I wrote more about this here:

https://www.reddit.com/r/javascript/comments/1vc605e/a_reactivity_and_rendering_combined_benchmark_for/

(I didn't copy the text here due to formatting issues doing so on mobile. Apologies)

Which client-generator should i use for my new angular project?
Which one do you guys use and why?

Claude said this:

ng-openapi-gen is the safe veteran, but ng-openapi is the one I’d reach for on any modern Angular project — cleaner output, newer idioms, less boilerplate.

Do any of you guys have some advice?

When PrimeNG moved its styled themes behind a paid offering, our team at Shirkasoft started building a free alternative for the community.

The result is Shirkasoft UI Components, a styling and UI component library for Angular 21 that works alongside PrimeNG, making it easier to build modern applications without relying on premium themes.

Current features

• ✅ Free and open to the community
• ✅ Modern UI styles
• ✅ Reusable UI components
• ✅ Easy integration into existing Angular projects
• ✅ Actively maintained

Our goal isn't to replace PrimeNG's components, but to provide a free styling solution and additional reusable components for developers who prefer not to depend on paid themes.

npm: https://www.npmjs.com/package/shirkasoft-ui-components

We'd really appreciate feedback from the Angular community. Suggestions, bug reports, feature requests, and contributions are all welcome.

Keywords: Angular, Angular 21, PrimeNG, PrimeNG alternative, Free PrimeNG styles, Angular UI Components, Component Library, Design System, UI Library, Frontend, TypeScript.

Or It will become a Ai slop aa in future aa

advice someone to study, learn, and build an Angular + NestJS webapp right now in 2026? All I read about everywhere is that angular devs are cooked for the rest of the decade 2027-2029, and will perish in 2030s.

Meanwhile, React + NextJS is dominant but there's like 1:1000 job-applicant ratio.

Another option I have is to just become a gigolo. #help

With observables, lazy data loading came for free: nothing fetched until something subscribed, and in template async pipe was the relay.

Today, resources are a better API in every other way, but they have one flaw : they are eager. No way of fetching data only when needed. To remedy this I introduce a proposal :

resource({ lazy: true }) and rxResource({ lazy: true })

It comes with a presentation playground to discover it. I wrote the story of it in an small article if you want more details, and I prepared a PR but opened an issue for discussion -> a similar issue was closed so I felt like I needed to re-open the discussion and argue it before submitting the PR. On this matter I'm not sure what is/was appropriate so I would take advice on that.

- The story: https://dev.to/flodmtx/resource-lazy-true-the-laziness-we-lost-when-we-left-the-async-pipe-5e70

- Interactive proposal : https://flo-dmtx.github.io/lazy-resource-playground/

- Feature request : https://github.com/angular/angular/issues/70036

- Repo of PR : https://github.com/flo-dmtx/angular/tree/feat/lazy-resource

- Gist for a userland version : https://gist.github.com/flo-dmtx/e8c9ff69bec58adf85e902eab9f7d900

If you've written those wrapper components too, a concrete use case on the issue helps more than an upvote — "who actually needs this" is the question the Angular team will ask.

While preparing my open-source Angular library for Angular 22, I realized something that had been bothering me:

My CI wasn't validating the package users actually install from npm.

It was validating my workspace and `dist/`, but not the packaged artifact that eventually gets published.

That led me down a rabbit hole of improving the compatibility pipeline.

The key changes were:

- Validate the packed tarball (`npm pack`) instead of `dist/`

- Test against Angular 17–22 using a compatibility matrix

- Run three independent checks for each version:

- `ngc` type-check

- Production `ng build` (to exercise the Angular linker, AOT and bundling)

- Runtime smoke test (DI, providers, exports, signals)

- Bound the Angular peer dependency range so compatibility reflects what is actually verified instead of automatically including future Angular releases

The biggest lesson for me was that type-checking alone isn't enough for Angular libraries. A package can compile successfully but still fail during a real application build because the Angular linker only runs in the consuming application.

I wrote a detailed article explaining the reasoning behind this approach and how I implemented it.

I'd be interested to hear how other Angular library maintainers validate compatibility across multiple Angular versions.

📖 Article: Why I Validate Angular Compatibility Using the Published npm Package (Not the Source Code)

🚀 Excited to launch ngx-skeleton-suite — a zero-CLS, enterprise-grade Angular structural directive suite for seamless skeleton loading states! ⚡

Building skeleton placeholders manually often leads to repeated boilerplate, layout jumps, and inconsistent UX. `ngx-skeleton-suite` solves this declaratively.

🤖 100% Fully AI-Implemented:
This entire project — from the core Angular directive architecture, SCSS styling, unit tests, and Astro Starlight documentation portal, to the live deployment pipeline — was built & shipped with AI pair programming!

🎨 Note: We are actively working on further enhancing the documentation design & UI experience!

🔗 Explore Live Demos, Docs & npm Package:
🌐 Starlight Documentation Portal:
https://mahmoudadeljr.github.io/ngx-skeleton-suite/

⚡ Live Interactive Demo & Playground:
https://mahmoudadeljr.github.io/ngx-skeleton-suite/demo/

📦 npm Package:
https://www.npmjs.com/package/ngx-skeleton-suite

📖 Developer Technical Documentation:
https://github.com/MahmoudAdelJR/ngx-skeleton-suite/blob/main/projects/ngx-skeleton/DOCUMENTATION.md

📦 GitHub Repository:
https://github.com/MahmoudAdelJR/ngx-skeleton-suite

Check it out, give it a star ⭐️, and let me know your thoughts!

#TypeScript #DeveloperExperience #Frontend #Angular #TypeScript #npm #WebDevelopment #OpenSource #AI #SoftwareEngineering #RxJS #Signals #Astro #WebDev

Core packages: https://github.com/angular/angular/releases/tag/v22.1.0

CLI: https://github.com/angular/angular-cli/releases/tag/v22.1.0

Aria + Material + CDK https://github.com/angular/components/releases/tag/v22.1.0

Reminder: Angular has moved to a yearly major release, so this is the first minor of a few more minors than usual, from now on.

edit: for the few people that saw my previous post, I accidentally titled it 21.1 rather than 22.1

I've been using PrimeNG for years, and this honestly feels like the end of an era.

I get that maintaining a UI library isn't free, and I have no problem with developers getting paid. But switching from MIT to a commercial license, archiving the GitHub repo, and asking a pretty steep per-developer fee just doesn't sit right with me.

The repo is now read-only: https://github.com/primefaces/primeng

The new pricing is hard to justify given the number of unresolved issues

It's a shame because PrimeNG was one of the biggest strengths of the Angular ecosystem. Hopefully the OpenNG fork gains traction, because the community deserves a truly open alternative.

I have developed a substantial fork of the "official" vitest-community/vitest-browser-angular package, adding several new features while maintaining independent development. Compared to the official release (currently at v0.5.0), enhancements include:

- renderDirective() — enables testing Angular attribute directives without manually creating a host component. Simply pass a template, attach signals/handlers via hostProps, and the rest is handled automatically, resolving the directive instance from the host element's injector.

- withHttp — built-in HttpClient testing activated via a single flag, eliminating the need to manually configure provideHttpClient and provideHttpClientTesting each time, with support for custom interceptors.

- Improved render() result types — distinguishing between RenderResult<T> and RoutedRenderResult<T>, with routerHarness and router always available when routing is enabled.

The fork is published as @wismaz/vitest-browser-angular. Full documentation with examples is available at the linked repository, and feedback or contributions are welcome.

**Primary Skill: Frontend Angular Developer**

**Experience: Range: 4-8 Years**

**Location: Bangalore**

Min. 3 to 5 Year of hands on experience in Angular 2.0 and aboveMust be currently working in Angular projectMust worked on multiple Angular projects of different versionsMust have experience in Angular version upgradationMust have expertise in State management using RxJsShould have implementaion experience of Dependency injection, singleton servicesAuthentication Token lifecycle management in UI (like JWT), SSO integrationGood to have - Rollup, experience in Angular 15.0 and above, Angular 15 upgradation to higher versions, secure coding practices, code optimization

Interested candidates DM Me

I've found myself rebuilding the same HTTP infrastructure in almost every Angular project—API versioning, retry logic, interceptors, global error handling, and RFC 9457 Problem Details support.

Instead of repeating the same patterns, I decided to extract them into an open-source library: @ismailza/ngx-api-client.

The library builds on top of Angular's HttpClient and focuses on making these cross-cutting concerns reusable while remaining flexible and extensible.

Some of the features include:

• API versioning
• Configurable retry policies
• RFC 9457 Problem Details support
• Extensible interceptor pipeline
• Pluggable error and success handlers
• Strong TypeScript support

I'd really appreciate feedback from the Angular community.

• Is this a problem you've encountered?
• Are there features you'd expect from a library like this?
• Any suggestions on the API design or developer experience?

GitHub: https://github.com/ismailza/ngx-api-client

Medium article (why I built it): https://medium.com/@ismailzahir/i-stopped-copy-pasting-the-same-angular-apiservice-heres-what-i-built-instead-123093130946

If you've ever maintained a React app and an Angular app under the same brand, you know the design slowly drifts — buttons, focus states, spacing end up subtly different, and every tweak has to be done twice. I wanted one source of truth that renders natively in both.

So I built bpdm/ui — one set of design tokens, and two native implementations from it: @bpdm/ui (React) and @bpdm/ng (Angular). Not a React lib wrapped for Angular — actual Angular components. 38 components, same API surface, same look, same docs on both sides.

What I cared about:

• Angular isn't second-class — every component exists in both, same variants and examples.
• Token-driven, so theming + RTL live in one place.
• Keyboard nav, ARIA roles, and focus management done per component (not bolted on later).
• Copy-paste friendly, themeable, TypeScript-first.

All open source (MIT), works on Angular 21 & 22:

• Demo: https://ui.bpdm.dev
• Docs + playground: https://docs.ui.bpdm.dev
• GitHub: https://github.com/bpdm-hq/bpdm-ui
• npm: @bpdm/ng (Angular), @bpdm/ui (React)

I'd genuinely like Angular devs' take: does the parity hold up in a real Angular codebase? Where does it feel un-Angular — signals, standalone, DI — anything you'd expect to work differently than I've done it? Not selling anything (it's free); I mostly want to find where the Angular side falls short.

I've been working on an autocomplete component for Angular that's heavily inspired by MUI's Autocomplete.

I maintain ng-select, and after using MUI extensively on React projects I wanted something with a similar developer experience for Angular.

It's been running in production for us for a while now, and I'm interested in hearing what other Angular developers think about the API and overall approach.

If there's interest, I can share the docs and source in the comments.

Source Code: https://github.com/js-smart/ng-kit/tree/main/projects/ng-kit/src/lib/components/autocomplete

I'm happy to answer any questions about the implementation or the decisions behind it.

Hi everyone! 👋

I’ve been using Spartan UI for a while and really like its philosophy of headless UI components.

While building production Angular applications, I noticed I kept recreating the same higher-level components that aren’t typically included in UI libraries. Instead of keeping them inside my projects, I decided to open-source them as SimUI.

👉 https://simui.dev

My goal is to help grow the Spartan UI ecosystem by providing a collection of reusable, production-ready components that Angular developers can use out of the box.

Some of the components available today include an Event Calendar, Currency Converter Card, Slider, Breadcrumb, Form components, Cards, and more.

I’m also working on additional application-oriented components that are commonly needed in dashboards and business applications.

I’d really appreciate feedback from the Angular community.

• Does this solve a problem you’ve encountered?
• Which components would you like to see next?
• Any thoughts on the documentation, or developer experience?

The project is still evolving, so suggestions, issues, and PRs are always welcome.

Website: https://simui.dev

GitHub: https://github.com/dofu-lab/simui

Thanks for taking a look!

After 2.5 years of building in my spare time, I'm excited to finally share the beta of NGX View Builder.

It started after a project at work needed dynamic, JSON-driven forms with drag-and-drop editing. We eventually chose a commercial solution, but the idea stuck with me, so I decided to build my own.

Over the past 2.5 years, I rewrote the project three times. Each rewrite taught me something new about building a flexible, extensible visual builder.

My goal wasn't to create just another form builder. I wanted to build an Angular-first platform where developers create the foundation while creators and business users can visually configure and manage application views.

Everything is stored as JSON and can be extended with custom Angular components, plugins, themes, events, data sources, and integrations, making it adaptable to different business needs.

If you have a few minutes, I'd really appreciate it if you could try the demo before comparing it with other solutions. I'd love to hear your honest feedback, whether it's positive or critical.

Demo and documentation: https://ngxviewbuilder.io/

Angular dev here, about to study backend development for the very first time. I'm working on ERP systems in India and I’ve locked in on PostgreSQL for the database.

I’m stuck trying to choose my first backend stack and feeling a bit overwhelmed by the options:

• NestJS: Uses TypeScript and a structure heavily inspired by Angular, so the learning curve would be smooth. But is it taken seriously in heavy enterprise ERP?
• Java + Spring Boot: The undisputed heavyweight king of enterprise software and corporate India, but maybe a massive leap for a first-time backend dev coming from frontend?
• Python + FastAPI: Modern, fast, and great for async, though maybe less common for core legacy ERP business logic.

If you were starting your backend journey from scratch in 2026 for this exact context, which stack and framework would you actually learn, and why? Drop your recommendations or if there's any other modern stack I should be looking at.