Building a Web App With Angular From Scratch

DZone 's Guide to

Building a Web App With Angular From Scratch

If you're looking to adopt a new technology to create an app, read one team's experience doing the same with Angular before it was so widely used.

· Web Dev Zone ·
Free Resource

Going the farthest where not many have ventured before is a very challenging but rewarding feat. As part of the first platforms to have tested developing a web app in Angular’s beta version (a chatbot interface), it is interesting to look back at our experience. Why did we choose to develop our web app in Angular’s beta version? Why did we decide to go even further by using the Angular Universal module (for server side rendering) and then later integrated into Angular (in the v4 precisely)?

It is also worthwhile to note that we are talking about the newest versions of Angular here - AngularJS is an older version of Angular and all of the versions that come after it are named Angular (Angular 2, 4, and so forth). For the sake of this post, we’ll just refer to Angular.

At present, there are many others that are using Angular to build their apps and most likely have fun stories to share.

Here is ours.

The Risk

At the time, it may have been seen as “reckless” to have done what we did - using a very new framework that hadn’t been widely used yet (which is understandable, as it was in "alpha" version at the time).

It was definitely risky because there was not much documentation available. The evolution of the framework changed enormously with “breaking changes,” meaning that with the newer versions available, there was a risk that the application you built with the older version would no longer work.

We had to constantly adapt to the newer versions of Angular because there were always new things coming into the picture. Some things we even had to start again from scratch!

So Why Is it That We Decided to Take the Risk in Building Something on This Technology?

Well, firstly, because it seemed promising to us and carried by the team that built AngularJS. They made the choice to start from scratch rather than upgrade AngularJS, which was exciting!

Another reason was the ability to use TypeScript - a typed superset of JavaScript, that compiles to plain JavaScript and that allows you to build large JavaScript applications in the safety of compiled languages. In other words, it allowed us to make fewer errors than if we had coded purely in JavaScript. Using this subset language of JavaScript is great for those of us who want to build complex applications. It helped us to iterate and kept our code clean.

Nevertheless, as with everything that is brand new, we were limited because we had to learn new a syntax and had to put many new configurations in place.

But the rewards that we had, in the end, were worth it. We have now developed the habit of coding in TypeScript outside of the Angular Framework, for instance as part of our backend system, because the engineering team finds it so useful.

At this stage, some developers may wonder why it is that we opted to use the Angular framework rather than React. Yes, React is “lighter,” easier to use (and to learn), and to put in place. Although it’s not important to compare, the team felt that Angular would be better suited when developing big websites or applications like Heek.

It was definitely challenging in a technical point of view without experts on hand that we could go to, but taking matters into our own hands and developing our application from scratch allowed us to understand the framework more in depth.

Going Further

When the 4th version of Angular launched around March, Universal (which initially started as a side project) was integrated as a plain Angular module.

Before going into why the team wanted to adapt the whole application and website to run on Universal, it’s important to note that this decision was also one that was not taken lightly. The process was equally difficult, if not more so because, at that time, there was zero documentation.

Our full-stack dev's mission was to learn how to use Universal before applying it to our product. 80% of the work on Universal was done solo in a month and 20% of it took around 3 weeks to adjust with the rest of the team. With very few tutorials out there, every time we encountered a bug we had to find a way to deal with it, because there was no way to ask around for help.

Unlike Angular, where, even though the community was quite small a year ago, you still had good support on GitHub and StackOverflow.

With Universal, there was very little support - meaning that at one point when the team encountered a bug in the module, they had to directly suggest a correction. Well, to be honest, it’s not like our developers were unhappy to be part of an open-source community.

So Why Universal?

This was purely for SEO reasons. To give you more context, we have developed a website builder around an AI powered chatbot. Our users make websites with us, and in order for their websites to be ranked higher, Angular Universal enables server side rendering. This meant that when somebody (or something) visits a Heek website, they would be able to instantly see the page, and avoid waiting for Angular to load. It was important for us to adopt Universal to allow search engine bots to crawl a website's content and not an ugly and unmeaningful blank page.

On the UX end, it allows our users to have a more fluid and faster experience making their websites on Heek. Pages are displayed quicker and the time lag is decreased significantly.

Was It Worth It?

Looking back at it, if we had the choice to do it all over again, we would. What’s great is to see more and more developers using the Angular framework to develop their apps.

As for Universal, I believe that it is very important if you are concerned with SEO. It may currently be a bit too soon to use this module, but if you have time and resources, it’s worth it.

Building our app on Universal was a very big challenge, but in the end, we’re very happy to have succeeded.

angular, web application development, web dev

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}