Low code development — developer’s view
I’m writing this article from the point of view of a software engineer and developer with 10+ years of experience. My experience with software varies from designing and building smaller web applications, through web UI frameworks, to larger SaaS applications. I consider myself having decent experience and I claim that I’m a skilled developer and know my way around. I don’t need tools that produce code for me, because I would produce better code myself. But would I really, and are low-code solutions producing suboptimal code? In this article I’m going to build a case for a specific low-code solution: App Builder. The solution currently outputs Angular, Blazor, and Web Components applications. The examples would be with Angular specific concepts.
Starting from scratch
Starting an Angular application from scratch has never been easier. The Angular CLI prepares a repository for me with a single command and allows me to subsequently produce new components, directives, services, modules, pipes, etc. with a single command. This saves time from manually creating files and populating the bootstrapping code by hand. It also sets everything up for unit testing, static code analysis, e2e testing, building, etc. This is a good example of a tool that produces code with the same quality, if not better, than I would produce myself. I use it all the time and given the number of installs the Angular CLI has on NPM, other developer use it too!
Let’s take the Angular CLI one step further, though. We have produced our own CLI called the Ignite UI CLI, which not only produces project structure and blank components, but also allows you to scaffold preconfigured UI components for different scenarios. This saves even more time from writing out component configuration code by hand, but still requires manual configuration changes to achieve the specific scenario we’re aiming for in an application.
What if we take the CLI and add some GUI on top of it? Well, Nrwl have already done that with the Angular Console. It’s still a tool, which produces container files with configuration in your project repository. Anything further needs to be coded by hand.
In any case, after creating the structure of our applications, we need to add lots of code to create a functional app with UI that matches the designs that we have created, or have been handed off to us.
So what if we could actually start from the point where we have the designs laid out in components for us?
Creating POCs
How does a concept get to a proof of concept (POC) in my experience? We have a high level vision or target and designers start conceptualizing this vision in screens they create using the tools they are used to. Designers I’ve worked with mostly have preference for Sketch and Adobe XD (depending on their choice of Mac vs. PC). Then those high fidelity screens are presented and handed over for coding, so the POC can come alive. At this point I not only have to bootstrap an Angular application, but also have to visualize everything that comes from these high fidelity designs into actual functional components, so the POC can be presented to stakeholders in order to get approval for full implementation. Implementation of the POC can take up to a day per screen, depending on how detailed or how complex the screens are. Having the Angular components helps, since they are ready to use and things like lists, avatars, grids, etc. are ready to use with simple configuration, but I still have to lay them out, configure and tweak in order to get as close to the design as possible. However, very often POCs get scrapped or reworked several times after they have been evaluated, because stakeholders tend to like static screens, but once they see them in an interactive POC, they notice issues they have not been able to discover in the initial designs. This creates a lot of waste!
Now, what if I can get the design to be interactive, or at least represented by real Angular components. Wouldn’t this eliminate tons of waste for me and my team and wouldn’t this speed up the POC creation and evaluation phase tremendously?
Starting from scratch with App Builder
The App Builder platform lets me do precisely what I asked for! When I first open it up, I see that it lets me start from scratch, from premade layouts or applications and it also lets me upload a Sketch file or use Figma UI plugin.
As I mentioned, I already have Sketch files to start from, so my starting point is from a Sketch design. This is what the sketch design I’m going to work with looks like (visualized in XD, since I work on a PC):
Let’s see what the App Builder produces when the Sketch screens are uploaded and processed by the tool.
So far it looks like another design canvas visualization of what we have in Sketch, which is pretty similar to what Adobe XD does when opening Sketch designs. However, it’s not! Let’s see why by going into preview mode and inspecting the code view:
As you can see, each view has a generated Angular component for it, and inside there’s pretty clean component template and definition, which is composed of other components. The four screens produced in the App Builder from the Sketch design are also completely independent components in the App Builder. There’s no routing between them, or interactions that connect them. This is so, because the Sketch design doesn’t define any dependencies between the screens and the tool has no metadata to work off of. I will go ahead and download the generated application from the App Builder by clicking the “Generate App” button in edit mode and this is what I get:
As you can see, I did nothing after uploading the sketch design in order to get a running Angular application produced with Ignite UI for Angular components used in the Sketch design that I have received. This is what I was looking for! I just eliminated the waste and made my starting point with the app be much more developed than simply scaffolding my application through a CLI. In fact, the base repository that the App Builder generates is scaffolded using the Ignite UI CLI and then components are generated on top of this repository. I already see an issue though — what if I change the code in the generated application? How would this sync with the App Builder? Well, the answer is that the App Builder provides integration with GitHub, which allows me to not just download the generated code repository, but to be able to put this code into a GitHub repository and to pull new updates from the App Builder to the GitHub repository.
NOTE: The sample design is created using the Ignite UI Kit for Sketch, which is important because this is how the App Builder knows how to deterministically convert Sketch symbols into corresponding Ignite UI for Angular components.
Advanced App Builder Usage
There are UI patterns that I often reuse between applications. My usual approach is to create a small internal library of components and to reuse it across different applications. Example of such patterns would be a login and registration screen. Let’s see how I can do the same thing using the App Builder. I have created an App called Common UI Patterns, which contains different components I reuse often across applications.
Now I’m going to copy my Login view and I’m switching to a different application I’m working on where I want to add it. I’ll add a content dialog window and I’m going to paste my login view into the dialog content.
You will notice that the color of the login button is different. Did I change it after pasting? No. The pattern automatically adjusts itself to the theme applied to the application that I’m working on because of the powerful theming engine that Ignite UI for Angular offers. I can demonstrate this through the theming pane.
The code generation of the App Builder will take care of generating the Sass for the color palettes and the necessary theming mixin calls.
I have the login view now, but I need to make the application spawn it. I will replace the avatar in the navbar with a login button and will attach an action to it, which spawns the login dialog.
As a final step, let’s generate the application to see what we will get. I download the repository and open it in VSCode.
I was able to produce this within a few minutes using a ready-to-use app template and a UI pattern project, which I’ve created earlier. Isn’t this amazing?
NOTE: In the example I give, I use a separate application project where I keep my UI patterns. The upcoming feature updates of the platform will include UI patterns as items users can develop and add directly into their own toolbox, so they don’t have to switch projects.
Conclusion
My initial opinion on low-code solutions was somewhat skeptical, but after looking at the code the App Builder produces, which I don’t have to redo myself, but can instead build on top of, I think that low-code solutions can actually be a really helpful mechanism for streamlining the app development process and for reducing and eliminating waste during hand-offs. Also, the fact that I can use the App Builder to generate the same applications that I just created as Blazor applications, by just switching the target from a drop down, make it even more useful, as I’m not locked to a target framework. Regardless of the fact that this is a platform I’m heavily involved with, I have been looking at it entirely from an external developer point of view.
The App Builder platform and the Ignite UI for Angular component library can be tried out for free!
Additional Resources
Read more on low-code development
Read more on Angular code generation
