Hello, Welcome to Adventures in Angler, the podcast where you keep you updated
on all things Angular related. This show is produced by two companies, Stop
and'devs and Onboard Top and deves is where we create top and devs so get
top and pay and recognition or working on interesting problems and making meaningful community contributions.
An Onvoid which offers remote design and web development services on a task basis,
so clients only pay after tasks are delivered and approved. In today's episode,
we will talk about ignite UI for Angling. My name is Lucas Paganini.
I am one of the hosts in the podcast, and joining me in
today's episode is the other amazing host Sibarette Mishra, Hello Bays, and our
special guest Constantine Dinev, which is director of product development and one of the
main contributors of ignite u I. Hello, guys, nice, this is
Sunstantine. It's really nice to be on the show. It's great to have
you. Thanks for joining. You're welcome. Okay, So let's get into
it. So, Constantine, before we talk about the differences between ignite u
I and other libraries, let's actually start by saying what is ignite u I.
So could you give a quick pitch to the audience, Sure, Lucas,
Now, ignite you y is actually a product family. Ignite Y for
Angular is one of the products in this product family. All of the products
under the ignite to I hat are UI component libraries which primarily target you know,
heavy data uses, enterprise price uses, but all of them also have
all of the small atomic components which are next for you to build a full
application or a full commercial website or a customer website, whatever you want to
build. So ignite you y for Angular is, as I said, one
of those products. The other ones that we have target pure web components.
React. We used to have a jquer well we still have a j Quaer
product, but that's kind of legacy, you know at this point. You
know, ten years ago we had a nast bit of network web forms product
under the ignite y So yeah, is that enough or do you want me
to expand more on the UI component library side? No? No, that
that does make sense. So there is this family of other products, but
more specifically, so ignite y is UI library which has a distribution available for
Angular and also other distributions available for other frameworks. Is that correct? That
is correct, and you know, each of each of those products is an
individual product, So don't consider this to be one Tommy code base that is
then being wrapped for different libraries. Ignite Wife for Angular was built from scratch
to be Angular native, and we started it with you know, some of
the initial versions of the Angular two alphas. I think it was at the
beginning. It was kind of a pain back then because from alphas to betas
and then from RC to RC things were changing drastically. They were like tons
of breaking changes. I remember when between RC five or r C and RC
six I think engine modules were introduced. We had to change everything completely from
two rcs. And back then I was like, you know, really mad,
because yeah, how can you call something release candidate when you make breaking
changes from one version to another. Yeah. So you know it's a native
uh, component set. Everything is built natively for Angular, which you know
then gives us the benefit of it's free shakable. Uh. You know,
code splitting works. You know, all of all of the features that Angular
provides, we we take benefit and when you know you can use the components
neakey with nice nice interesting. So I'm actually curious about what are the other
distributions. Of course we're going to focus just on the Angular one in this
episode, but I'd be curious just to know in how many other platforms you
make this product available. So the modern ones are for it's Angular, Laser,
web components, and React the rest. Like I said, I mentioned
j Query, I mentioned web forms, gotcha, gotcha. So the web
component can be used with different different filmwork casuality. Right, So the web
components they can also be used with in an Angular context or within a React
context. And you know they can be used in a framework less context or
library less context context. So those are standard ones. Yeah, when when
you are saying about the large breaking changes, does this new signal and the
new defail like the new changes in Angular affecting the lot or if it is
like non navigating the framework development in a different direction, or how how it
is? So it the answer to this is, uh, like it's not.
It's not straightforward. Now we cannot adopt something that is still in development
developer preview. Uh, similar to standalone components for example in Angela, Uh,
signals are something that we still do not utilize and ignaged wife or anywhere.
Why because it's not something that is definitively marked as stable UH, and
we cannot rely on this and change the way component said, for example,
behaves UH based on a development preview, because if if there are subsequent drastic
changes that are implemented to signals themselves, then we may release something that will
afterwards have to be used in a different way or rewritten for customer context.
For us, it's important that people can migrate semlessly from version to version.
That's why there are migrations with with each eng update. That's why we we
release schematics for UH. You know, anything that is supported for from the
English CLI ng AD NG update. As I already mentioned, so standalone components
for example, UH, we did migrate the framework to have all of our
components stand alone and to be distributed to stand alone with a I believe ignite
Why for Angular sixteen which corresponds to Angular sixteen as a major version, but
in fifteen we still didn't have it even though it was available in anger.
As I said, something needs to get out of development preview and that's when
we actually implement. Now. The other difficult thing is we also have to
keep backwards compatible. Right, so even though we now ship send the one
components. We still ship those wrapper engine modules, which basically important export the
components so that people using the engine modules can still continue using the product in
the same way. I think if you like, if you have a large
user withs who are using it, they might not be willing to like go
for like that spend that amount of its alsays to always update, so it
makes sense to always have a backward comparatibilities. But with that increasing the like
the loading time or burn side to have a backward compar they will do it
just like a different uh No, So we totally we we always try to
avoid increasing bundle sizes. Actually in the latest releases, all we've done is
decreased the bundle sizes by you know, improving the three shapeability of the right
library and other parts of it. But that's why I said so backwards compatibility,
for example, for Engie modules is just keeping the modules, but no
longer having them declare components which are not which are not standablee No, they're
just you know, imports of standbal components and exports of the same components.
Actually, the Angular material components did the same thing in their latest release.
We were done with that one release. Uh one one major lesa go and
we basically took the same approach that they did, uh you know with their
latest release for anglers. Interesting. Nice. So let's start going into what
makes ignite youI different, because now that we all understand what it is,
then I think the most popular comparison that people are going to make is between
ignite you I and material y just because material y is the most popular UI
library for Angular developers. So that ends up being the comparison that everyone makes.
And how what would you say is the difference between them and I think
even more importantly than in a them from a product perspective, from a target
user perspective, like, what's the type of person that would care about ignite
you Y? Well? Sure, so material components has all of the Angular
material or Angular components. I don't know if you even know what to call
at this point, but they have all of the basic necessary components for you
to build a website, right a web application, and ignite y Frangular also
has the same set of components. Now, where it gets tricky is whenever
you have to use Whenever you have to build the UY which is for example,
more data heavy and you need a component to consume that. Now,
material components do have a table component, right, But if you pull adjacent
which has three hundred and fifty thousand entries inside of it, can you render
this and have the page running smoothly with material components? And the answer to
that is, actually, you know, I don't. I doubt anyone has
even tested it. Now, if you paginate the data on your server side
and then use some paging in the front end table, maybe, but out
of the box dumping the data and having the UI handle that, that's not
possible. Igniti for Angular is built for data heavy usage, not only for
the simple, uh, you know, page application usages, but also for
very data heavy scenarios. Now, think about back office for applications, think
about financial trading, think about CRMs, think about you know, all of
these types of applications where you would need to populate your UI with really a
lot of data. Now, uh. IGNITUI for Angular does this without any
additional effort. So, for example, the grids that we ship compared to
the material table, they're all virtualized. Don't virtualized by default. They have
exposed all of the functionalities for easily hooking up server side operations through your service
where you know, you pay pageing data, or you sort data on a
server, or you filter data on a server and so on a software.
But also the same types that UIs are built for you and ready to use
on the front end, So Excel style filters for example, data summaries for
for the tables. UH. Pivoting, we have a pivot grid, uh
and you don't have anything remotely close to that. Uh. And material components,
charts and I'm talking all different types of charts, uh, financial charts
with candlesticks, with lines, with bars with uh you know, pie charts,
bullet graphs. Uh, you know, just whatever, whatever type of
chart you can think about. We have it other uh, like very large
components that usually are not in those uh more like UH baseline component libraries are
things like a dock manager. A dock manager is, if you think about
it, is an application, right. It's a way for users to reorganize
layouts into windows and then dock and redock them, resize the different panels and
you know, put content inside of those. We have a component for that
we ship are ready to use documentaure. So the difference is that we just
add a lot more components which are very complex right, And those are combinations
of other components they are being reused inside, but those are built for data
heavy scenarios and are ready gotcha? Gotcha? Okay? And what are we
talking here in terms of licenses, Because most of the libraries there provide those
very powerful features, they they generally have some pricing, right, because you
have to maintain all those works. We're not just like there's a company behind
it putting professionals to work and maintain those components. So is that free for
use or is that freemium? How does it look like? So ignit Y
for Angular is fully open source and is on a dual licensing model for usage
for non commercial usage. Is fully free for commercial usage. The heavy components
like the grids and the charts do have a watermark, but if if you
don't own an enterprise license, But for all of the rest they don't,
they're not water marked. So all of the small components are actually free to
use, and you know they're they're going to be free, free to use
forever. As long as it's not water mark. You can use it.
You can get it on mp mgs, the packages available there. Uh,
and you know that's why I said it's on a dual licensing model. If
if, however, you want to use the data heavy component without the watermark,
then you pay a license. Okay, that does make sense, and
I think it's the right way to go about this. And why did this
library? Why did you build this library? Not just you but everyone else
behind it, Like, was it always the intention to just create something to
commercialize and you just felt that there was space for this or what drove this
decision? So that's an excellent question. Traditionally, in Logistics, which is
a company that produced Signito Wife for Anguler, has always been a component vendor,
So you would think Igniteo Wife for Angler is just the next set of
components targeting the most modern framework at the time, which was Anglar. It's
actually very very modern even now. But that's actually not the reason why we
started to Ignito Wife for Angler. Ignity for Angular was started to power a
SaaS application that we wanted to build, which is actually an app building and
we wanted to use it for the shell itself and also for the app building
experience for the components that you dropped from a tool box and then you know,
lay out or to build other applications. Now and that was back in
I don't know, twenty fifteen, something like that, maybe twenty fourteen fifteen,
whenever Angular tool was still in data or alpha. Then you know,
we started building the atomic components in order to use them in the SAS.
But over time the SAS kind of fell down in priority and we ended up
having a nice component library, which which at the time we said, why
not just release it for people to use. There was no grid even at
the time, because for component libraries, if we started as a component library
that we want to sell, we always start with a grid because it's the
data heavy component. It's the one that sells the library. And we didn't
have a grid at the time. I think ignite Wife for Angular it was
initially called zero Blocks. It was called zero blocks because our code name for
the SaaS project was project zero. And then afterwards when we released it as
a library, we renamed renamed to Ignite You Wife for Anywhere. Now the
SaaS we ended up building and it's now available. It's available since twenty twenty.
We constantly developed new features for it. It's called a builders. But
you know, it's funny. We started to ignite you for Angular to build
the SaaS. We built a library without abandoning the SaaS temporarily, and then
we ended up building the SaaS and now the SaaS generates applications, generates repositors
with ignity friendler components as you are in the views. Yeah, as you
as you said about like you have to are you monitoring something like which component
in terms of angular I'm saying, so a particular component is used most than
the others, like for example, greed is used eighty percent or something.
No, that's impossible to monitor. Now in an app builder, we can
monitor that. But you know, in a in a library that we distribute
on mp MS and a private MPM that we cannot send any data back anywhere.
I mean that would be a breach breach, right, So yeah,
Now I was just wondering, like if you can get insights of like which
components are used mostly from the from a library, then you can get and
do more things. But it makes sense have a like it's not a partical
Yeah. The only relevant data that we have is comes from the issues that
are submitted and the getab repository and from the support requests that are coming in
through the private support channel that we have. And this is still not data
that is uh. That is very relevant, right, because most of the
support requests and the issues that are coming in are for the very complex components
like the grid. Because it's a very complex UI, it has to work
in uh like hundreds of scenarios, thousands of scenarios, and that that's that's
a component where it's easiest as a user to get into an issue or to
think that you're getting into an issue. And at the same time, the
checkbox may be the most used component, but we don't know that because the
checkbox is very simple and people would not lock cases for it, because if
we we have a broken check box, then there's something wrong with us,
right, we're not building it right. And let's get back to some of
the other things that ignite youI does really well because we didn't even mention something
that, at least to me, is very important. And unfortunately many UI
libraries don't take this into consideration or they just don't take it as seriously as
it should, which is internationalization and accessibility. So I was really glad while
going through the dogs for ignite y to see that this is a main concern
that the library authors have to make it accessible and translated to many languages.
So perhaps if you could tell us a little bit more about the support for
accessibility and internationalization. Sure, So for I'm going to start with internationalization and
localization. So with all of our products, not just ignite ye angular uh.
It has always been a priority for us to ship first of all,
components that are localizable, and second as many languages as possible with pre existing
strings. So there are the UI in a lot of cases has some default
strings, right, which are let's say a title in a two bar or
a hint in a paginator button, or you know something else in the drop
down of a paginator and so on and so forth, grit summaries for example,
like you know some min max average, so on, and so all
of those strings we don't just provide in English. We have twenty two languages
that we provide and you can easily swap between those. So if your application
targets the it's Howian uh population, for example, we do have Italian strings.
Or if you want to shift something that is specific to our Romanian market,
we have Romanian strings out of the box. So that that that has
always been important to us to have as many as possible naturally nightlife for angular
ships the most strings of all of our products, as I said twenty two,
which include also simplified and traditional Chinese for example. Uh now for uh.
The other the other aspect of the internationalization is not just the strings,
but also regional formatting for example for numbers, for dates, for what else
was like a region specific, Like you know, all all of those things
that are regions specific. We also need to comply with those and have built
in mechanisms how you can dynamic switch between these without for example, an application
reload. So yeah, I mean all of these ships out of the box
with with all of the strings, and uh, you know it's it's also
important to us that you know, when you build an application, we don't
serve you all of the strings even though you don't use them, So so
those are served only on demand. They are tree shakable. The accessibility,
that's that's a really like I think this topic is so important that every library
nowadays needs to be accessible. Every UY nowadays needs to be accessible because disabled
people, visually impaired people, they still need to be able to use the
UI. They cannot like just be left behind and not use a computer because
the UI is not accessible and not to mention it's a requirement for you know,
uh, whenever you're doing business with government, for example, because government
cannot afford to deliver non accessible UIs. So we do comply with the way
are you standard with section five away, Like we have all of those things
on our website and our documentation that you can read. But that's not even
the important part. So meeting all of the accessibility criterias as checkboxes is one
thing. Testing with the actual screen readers and getting a feel of what's the
experience for people who are going to use the screen reader is the really important
part. And I gotta say I'm actually a little drawn back by, you
know, the state of the screen readers at this point, because if you
try a few different ones, you will notice immediately they read different things,
they read them in a different way. Different screen readers decide what attributes to
honor and whatnot. And sometimes, if, for example, you comply with
all of the checkboxes, the screen reader can be really a pain to listen
to because it repeats one and the same things several times just because you complied
with certain checkboxes. So it's really important for you to also be testing with
the screen readers, and now for our components, all of our specifications for
the components are also freely available openly available on our gift coup re possor they're
in the wikis. Everyone can open and breathe the specifications. We want to
be as open as possible with that, and you will see that even in
the specification template. Accessibility is a major point in every specification for every component.
Yeah, I have to make sense. Like previously, very number like
Dicta seven back, very few websites have accessibility. But nowadays very very small
website are able to make accessible ten thanks to like you guys are helping small
companies with small resources with their package so that they will be easier for them
to achieve it, so that a lot of people can use it. And
and I currently in my company we are also using some accessibility feature. And
I was there with some Huger testing and you can feel feel the feel a
digable person while using it and how they're happy because they are able to use
a phone or a website. Yeah, it's a pretty precisely that's really good
and I know it's very hard to do, so it's something that unfortunately a
lot of people don't notice the importance, and the ones that that do consider
it, they go through a lot of work to make it to execute this
properly, so thank you. By the way, it's it's some and that
is usually not as noted, but it definitely deserves a lot of attention because
it's very hard to do properly, and as you said, if you're targeting
enterprise use cases, you're targeting governments, then they need to have that.
That's not even just the nice to have, it's really a necessity so nice.
Do you think there are any particular components that deserve a bit of highlight
that you think would be worth mentioning them here, Like you already said that,
it really shines on data heavy data heavy UIs. But other than that,
is there anything any other parts of the library that you would like to
highlight? Well, yeah, so the library is pretty large. I think
we have over sixty components at the moment, and we do try to satisfy
the needs for every type of UI, so from from the basic layouts,
building a form UH building a presentation layer for for a website, so even
things like a carousel component you need that too in order to UH present some
highlight on a late landing page. For forms, of course, you need
to have all of the different form components for you to build the different types
of forms. So inputs, selects, radio, buttons, check boxes,
switches, uh, buttons, of course, I mean that's that's the most
basic one, you know. Uh, and then more more uh uh,
more complex scenarios like multi select, which is we call a combo with filtering
and uh you know, searching inside and on software which can actually take a
lot of data points surrender and then to be able to select from. We
even have components like we call it a stepper some some people call wizard.
You know that that that component is really nice because it's very easy for you
to uh to enable your users with a multi step process, which is then
you know, tracked and you can stop them at certain points, require certain
actions to be completed for for them to move to a next step. I
mean, yeah, the grids charts, dock manager, those are the heavy
hitters. But we even have a like a small Excel library and then a
ginormous Excel library which which actually reproduces the entire Excel object model. So the
small one is for you to be able to easily for example, export and
a grid data into an Excel uh worksheet and then preserve things like groups like
uh, you know, collapse and expand some some styles and so on and
so forth. Now the heavy one is, uh, you can do anything.
You can even do charting within the like self spreadsheet that you produce.
What else, like there is really a lot. I mean we we really
have put a lot of work into every single component. Have a calendar,
we have a slider, we have you know, whatever you can think of.
Name a component and we probably have it. Have really nice cards because
cards nowadays are actually building blocks for a lot of the US and a website.
Have you noticed that, I mean it's a trend. People use a
card card sometimes to even lay out an entire page. So you know that
that that's really important to have. Yeah, date pickers, time pickers.
That seems very very extensive. I was just curious, like how like you
know how many developer designers you have to build a library this big with multiple
framework So right now my organization is around sixty people, all of them on
one point or another work on Ignite wife for Angular, but also on the
other component libraries. Now at this point, probably half work on the app
builder SaaS. But the app builder SaaS is also powered by these components,
so it's kind of you know, back and forth between the the SaaS and
the component library, and then the SaaS code generates. It's a local tool,
so it code generates Ignite wife Angular or web components or React or Blazer,
whatever you choose as a target. But so I would say sixty on
and off full time at the moment is probably around fifteen something like that.
Really nice, Like yeah, and also let the way you describe accessibility.
I know that you whom you have a lot of user testing and those things
are going on so combinedly everything. Maybe it's to a user who were like
listening or watching us, it seems like it's just library. But developing this
kind of big library is a lot of effort. Like if you just try
to design a dat picker and you will see how many variables you need.
You need if the viewpoart is down, you need to get put in the
tough A lot of things are there. So simple date picker is so hard.
I think about greed. It is like it will take a month to
this, So I want to thanks thank you for that. Yeah, Well,
it's not easy. It definitely not easy, but it's very satisfying,
especially you know, after you're able to produce a reusable component and then people
start using it and actually start using the different modes or variations that are supported
by the component. And it's actually even nice when you get an issue.
You know that people are using it, you know that you know they dug
in found a scenario that you know doesn't work precisely how they expected it to
work, and then you know there's a better issue. That's really nice.
Nice, Okay, cool. So it doesn't seem like it because everything,
like the conversation was flowing so easily, but we're actually at thirty five minutes
talk about uh ui, So I think we should probably start wrapping up before
people start complaining. We can probably talk for two more hours. So yeah,
you got maybe two more days. Yeah maybe? Yeah. Do you
do you have anything constantine that you would like to mention before we start wrapping
up and talking about like doing some promos and et cetera. Well, well,
yeah, sure, I mean I mentioned that builder a few times throughout
our conversation. Now, just say, for Angular, the most used tool
alongside Angular is the Angular Cli right, because it simplifies the word for you.
It makes the project set up no brainer. It then helps you through
adding new items to your project structure and so on and so forth, helps
you migrate projects. Now, the app Builder is I would say a step
further or several steps further, because it not only generates projects for you,
generate CUI and the code for you, but it allows you to build your
applications in a visual way to a very sophisticated level. Actually, because we
have things like variable support, state in context binding within the the application that
you you're building, connecting to UH data sources that have open API descriptions and
then redially using them within the app builder app building experience. Now, ignite
you y for Angular by itself simplifies building applications, simplifies building us. Ignite
you wife for Angular with app builder makes it like it completely reduces the time
for you to from from start to finish with an application, and it eliminates
the handoffs that you usually have between designers, development developers and product managers product
owners. So you know, if you haven't tried it out, I mean
you guys should. And yeah, I'm open to any feedback that that you
have for the SaaS application that we have just one question that it just came
to my mind that as you have an app builder, is there are you
guys are planning to have like integer dnai. So that's like, well it
will be yes, we are we are so uh. The the thing about
gen a I at the moment is uh, it is a marketing hype for
everyone to integrate it. Right to us, the important thing is what would
really be the useful scenarios? So uh, it's not as simple as us
uh enabling a prompt which will then spit out some things which you know in
most cases are not even verifiable and testable whether whether they work one hundred percent
of the time. So the most important thing for upbuilder is that it always
produces a code that will not only compile, but is uh, at least
to our standards, is optimal up to the level that we can generate it.
So jen ai is not really there. You have to customize a model
a lot, which actually reduces the quality of the results that that that you
get out of it. So we are definitely uh uh, well, we
are already working on scenarios that we think are potential potentially useful, but we
are going to release uh a jen Ai feature for app Builder when when we
feel that it's really something that adds value to the users. Yeah, completely
makes sense. Cool, okay, nice, So let's start wrapping things up.
So, super Brad, it's been a while that we don't have you
on the show. What what have you been working on? Do you have
any promos you like to talk about? Yeah? So I think Grant came
to Societ the stelling and haven't done anything, but I will. I will
try to promote my channel YouTube channel, which is fun of heuristic, so
please go and watch them. Was the videos like, yeah, that's all
nice? Nice? Okay? Uh, Well, in my case, is
not really gonna promote anything this time. Nothing new that I've been working on.
And well, Constantine, we talked a lot about Ignite you y and
also at Builder today. Would you like to promote those two or do you
have something else in mind that you'd like to mention? Well? I think
I already took probably thirty five minutes promoting those two. Yeah, I don't
have anything else to add Okay, okay, all right, Yeah, it's
kind of like saying, yeah, lookas we talked about this for thirty five
minutes. But do you want me to say but yeah, definitely definitely.
Well, Constantine, thank you so much for being on the show. It
was really nice having you here, and I really appreciate all the effort that
you and all the other contributors are putting into Ignite you y. It is
really a very very interesting work and there I can see there there's a lot
of effort put into all those details. So I really appreciate putting out this
quality product out there and it was really good. Have you on having you
on the show. So I feel free to to connect and join the app
joined the podcast again, you will definitely be very welcomed. Well, thank
you very much guys for having me on this podcast. I mean kudos to
you for spending the time to actually put those together that that's really beneficial,
I think, to the community. And it was really nice to be with
you. Nice. Okay, all right, so thank you and I'll see
you in the next one.