Interview with Danny Koppenhagen: Vue.js, Angular Buch, Scully and web components

Interview with Danny Koppenhagen: Vue.js, Angular Buch, Scully and web components image

Posted by Tim on 24 Jul 2020 in Angular,Community

Agiledrop is highlighting active members of different open-source communities through interviews focusing on their projects and initiatives, as well as trends and innovations in the digital sphere.

This time we covered a variety of subjects in the Angular and JavaScript ecosystems with Danny Koppenhagen, German developer and co-author of Angular Buch. Read on to learn more about how Angular compares to Vue.js, the making of the German Angular book, the capabilities of the Scully static site generator, and more.

1. Please tell us a little about yourself. What’s your role in the Angular community and what do you do professionally?

When I got started with web development in the first year of my studies, I first got in touch with AngularJS (I studied Communication and Media Informatics, and we had some modules where we learned programming). I really loved AngularJS, and then one day I heard that Google was working on a new Angular which would be a huge change.

Then I got the offer from Gregor Woiwode, one of the co-authors of our German Angular Book in the first edition and my fellow student at the time, to start working on the book about Angular together with him, Ferdinand Malcher and Johannes Hoppe.

It was a really great opportunity, it was forcing me to get very deep into Angular and to think about the context and things like that. It was really cool.

When we worked on the first edition of the book, we re-wrote some parts of the book a couple of times, as at this time Angular was still in an early development phase and there were a lot of breaking changes all the time, so we had to rewrite a lot of stuff again and again. It was interesting in part, but also funny.

Since last year I’ve now been working for DB Systel, a subsidiary of Deutsche Bahn (German Railway). I’m working there in a user experience-focused team with a lot of UX experts as a “UX developer”; my team is called and our mission is to develop great UX-centered web applications in the company. I think UX doesn’t end with the concept or design but also includes the development and a very good teamwork within those disciplines.

We have a wide area of web applications. So, in some parts of the company, they used to write applications using React, some are using Vue and some Angular. I’m currently working on a project with Vue, cause I got the opportunity and I think it’s a good idea to not just go deep into Angular, to see the other sides and the pros and cons.

Right now I’m enjoying some off-time until mid September, to enjoy the first time with my just born little son.

2. Can you tell us a little bit about working with Vue? Now that you have first-hand experience with both frameworks, how would you say Vue compares to Angular?

It’s hard to compare them, because you can achieve the same things with Vue, React, Angular, it’s more a question of taste in my opinion. I don’t like it when I read in some threads stuff like “Angular is better than Vue or React”, and the other way around.

In my opinion Vue is really great if you have, for example, a WordPress blog or some existing application where you just want to use it as a library to add new features without just plain VanillaJS. So, Vue is pretty good because that’s one thing you can’t really achieve with Angular (or at least it’s not that easy).

Angular is more like a whole ecosystem; you need to write it in TypeScript, of course, and you have to compile everything, it’s not an easy library to add to something already existing just to extend the functionality. If you start on a plain level and if you need a lot of features, however, then Angular is a great solution.

One good thing on the other side of Vue is that it’s a really small library, you don’t have things out of the box, such as form validation, HTTP interceptors and things like that. That’s something Angular brings out of the box, which makes it a little bit bigger, you don’t have to pull in the dependencies inside - but you can.

But, in the end, it depends on the application. So, if you work on a big enterprise project and you already know you’re starting from scratch, and you will need form validation, interceptors or complex routing and stuff like that, then I would say Angular is probably the better choice. I would personally use Angular, but you can totally achieve the same thing with Vue and some extra libraries.

If you want to have a decoupled CMS site, it’s easier with Vue. It’s the same with React, both work with plain JavaScript, it’s just another library layer. Angular has a different approach, you have to use the Angular ecosystem (and you should); you can still add libraries to an Angular application.

Another criteria for the right framework selection is of course your team and the skills inside the team. So in my opinion it doesn’t make sense to start with Angular if your whole team is experienced in working with Vue and the other way around. So you won’t give a plumber a tool they can’t use, will you?

3. You also mentioned “Angular Buch”, the German Angular book you co-authored. Can you tell us a few words about that?

When we started writing the Angular book, it was clear that it should be a German book because there were already some books on the market which were written in English, so we saw that we had to focus on the German market.

And, one thing we always had in mind was to not just document the Angular features one by one, basically just translate the official documentation. We realized that, if you’re a junior developer and want to learn Angular, you need a big example application you want to build, and that was our main idea.

So, in the book we start to develop, along with the reader, an app called “BookMonkey”, like an online library where you can store books in a list, and you have a detailed view and stuff like that.

We go step by step with the reader, with every chapter introducing a new feature - first we start with properties and event bindings, and then we come to Dependency Injection, Services and HttpClient, and later on routing as a feature of Angular. That was our goal always, to take the readers through the journey until they have the final application.

Then we have some extra chapters where we will introduce decoupled things like how you can use NativeScript Progressive Web Apps, NgRx and Server-Side Rendering. These are all benefits you don’t need every time in Angular, but you can add them.

And we are also going the same way with introducing these features in our example application, that’s the main idea.

Just now we finished working on the 3rd edition of the book which will be available in September this year.

4. I noticed that, just like me, you’ve been interested in Angular’s new SSG Scully basically right from the start. What about Scully excites you the most?

I was quite excited when Scully was announced in December. Before, my own website and blog was based on WordPress, and I was always thinking that there was so much stuff I didn’t need.

Basically, I just wanted to have a blogging site and some info about myself, that was all I needed. Some years ago, WordPress was the easiest thing I saw, but it came along with a lot of spam mails and an overdimensioned control panel where I didn’t need most of its functions.

I thought about rebuilding the site, but I didn’t want to use just plain JavaScript, so I thought about doing it with server-side rendering, which is also a feature in Angular.

But then I heard about Scully, and I was thinking I would just try it out, and I think after two or three hours I had a first basic blogging site with styles and everything. Adding Scully to my Angular application was quite easy, it took me like 30 minutes, and then I had my blogging site, and with markdown files I can easily just write my blog posts in markdown syntax like I used to do it.

So it was really great to have this out-of-the-box blogging feature inside Scully already, and I also had my first blog post because I basically just wrote what I did with my blog.

I always keep track of the changelog as Scully is still in an early version and sometimes things change a bit, but now it’s quite stable and I’m still happily using it for my site.

Compared to classical server-side rendering I think Scully is easier to add to an Angular application; one really great thing is you don’t have to care about using the window object or document or other browser specific objects.

Because, when you use Angular and classical SSR, you have to always keep in mind that it’s rendered by NodeJS and there’s no window object existing.

With Scully, it’s another approach, because it’s not rendered by Node, it just starts a headless browser in the background, which visits every page you have and then downloads the generated HTML.

So, that’s the way Scully generates the static pages, and as a bonus it starts the “normal” Angular app in the background and refreshes the static page content with the Angular app. So in the end you will have a fully functional Angular app but with SEO-friendly static pages.

Their team is still improving the static site generator and you’re able to write your own plugins, so it’s definitely still getting better - actually, there was a beta release just recently.

5. In addition to these, are there any other projects or initiatives in Angular that you’re particularly proud of or excited about?

What I like about Angular is that it’s really easy to turn your Angular app into a progressive web app (PWA). Unfortunately progressive web apps are not that popular currently; they are gaining popularity, but for example the support from iOS is still not good.

Another really good thing about Angular is the power of the Angular CLI. The CLI gives you a lot of possibilities in terms of generation, you can just generate your components for a lot of code, then add skeletons and services.

You can even use Angular Schematics in, for example, enterprise projects to create your own code scaffolding, to add common features to applications much easier.

The coolest thing about Angular is that the release cycle is quite regular, they release a new major version every six months.

It’s a really good thing because you don’t just have a good changelog documenting the breaking changes, you also have migration scripts for each major version that will take the workload from you and you will just migrate the old component, the old code into the new one. That’s really powerful, and the Angular team is working continuously on these migration scripts.

6. Lastly, do you have any thoughts on what the world of Angular and front-end development will look like beyond 2020? What are some trends you’re expecting?

I already mentioned the progressive web apps, I think they’ll be getting more and more popular, and I also hope that iOS support will get better soon, because currently you can have PWAs on iOS, but push notifications won’t work.

Another bad thing is that you currently have no good possibilities to get your PWA into the app store. On Android, it will work, you can create a “Trusted Web Activity” (TWA), so basically a progressive web app trusted for the Google Play store, so that will already work, but unfortunately not on iOS.

I think in the future we’ll see more and more use of progressive web apps, and we’ll hopefully see them land in every store, that would be great.

Another big thing I hope for the future is that we will be able to just use Angular, Vue, React and maybe other frameworks to create native web components without any overhead.

I think web components are really powerful, and you already have the ability to create them with Angular, Vue and React. But you will almost always have a slight layer of the framework on top that acts like a small converter.

In the future I think it will be possible to just take your application and convert all of its components into web components without any overhead, and then use Angular components in React or Vue, or the other way around.

Components give you a lot more possibilities, making it possible to work in a mixed team, where you have for example React, Vue and Angular developers, all creating components and then basically just using them together - that could be really cool.