tldr;

I recently rebuilt my personal site using Analog. This article will talk a little about what Analog is, as well as some of my notes on the experience and things that you should look for. Overall, though, you should know that Analog is a really cool project that I think will bring a lot of value to the ecosystem. It’s approachable, so you can use what you need at first and then adopt more of the features later on. Check it out, for sure!

What is Analog?

Analog is a powerful meta-framework for Angular that enables developers to build Angular apps with some of the latest and greatest JavaScript ecosystem features. In addition, you get things like server side rendering and static site generation with very little effort on your part.

Analog is like meta frameworks for other frontend frameworks like Vue and React. In many ways it’s just like the Angular you are familiar with. There are just a handful of different conventions that you pick up as you go along. We’ll talk about a few here, although I’m sure I’ll encounter more as I go along.

File-based Routing

The first thing I ran into that’s done differently from a standard Angular app is the file-based routing convention. In a normal Angular app, you would configure the routing module and declare routes and which component a particular route uses. In an Analog app, you use a file layout that automatically creates the route and ties it to the component in the file.

In the app’s folder structure when you generate your Analog app is a pages directory. Any component that is created and placed in that folder and ends in .page.ts will be turned into a route. The component in the folder will be generated for that route. You can have static and dynamic routes defined in the folder. You can also have nested routing configuration.

You can view more about routing in the documentation here. As someone who doesn’t care that much about routing, and doesn’t have an issue with the normal Angular router and way of declaring routes, I still found that I liked the file-based routing. It makes it very clear what component handles which route. That can be a little hard to determine in a normal Angular app.

Content Routes/Pages

A major use case for Analog is creating sites with static or server-rendered content. Think of a marketing page or a blog. A comfortable, convenient way to write blog posts is by using Markdown. Analog has support for these types of pages built in. You can create normal routes in Markdown (like an about page or something) or blog posts. For blog posts, for example, you put the files in a content folder inside the app’s src folder. These will automatically be picked up and rendered when you define a route to the pages.

In my case, the main use of my site is for my blog. I added all my blog posts to /src/content/blog. I then defined a blog listing page at /app/pages/blog.page.ts. That page lists the blog posts. Each individual post is rendered by defining the /app/pages/blog.[slug].page.ts route. The [slug] part of the route is a route parameter, and the slug is used to find the particular blog post.

The markdown for the blog posts is rendered using an analog-markdown component that’s provided for you. If you use a Markdown file as a content route, it will be automatically rendered without any other needed configuration.

Another great feature is that you can have many different types of content files (i.e. blog posts) in the src/content folder, just organized in different subfolders. I’ve seen examples of blog posts, speaking opportunities, and code snippets all being saved in and rendered from the content files folder.

Other Notes on Analog

I was a little nervous about getting started with Analog. This had nothing to do with Analog, but because I have not done really any framework work outside of Angular in my ~10 years of being a professional developer. I have become very comfortable with how to develop apps using the Angular CLI or, more recently, Nx. So picking up something new made me a little nervous. But I really didn’t need to be. Working in Analog feels very much like working in a normal Angular app. Here are some things that I noticed that I liked while working with Analog:

• First and foremost: it’s fast. There is very little time between saving the file and it reloading in the browser. This is nice because any time saved debugging issues is nice.
• Self closing tags (<app-my-page />) is a nice touch. I don’t think this is unique to Analog, I remember hearing some talk of this in Angular recently, but I had forgotten about it. It is a nice tough, although not a huge time saver.
• Not setting up the router and only using standalone components simplifies development a lot. Standalone is another thing that’s not unique to Analog, but combined with simplified routing makes getting your app up and running that much quicker.
• I like the flexibility of being able to use Markdown. I write a lot of blog posts, and not needing to write the HTML myself for the blog posts, or do a lot of complicated setup, is really nice.
• I still need to learn the best way to organize my app. I have been very used to doing it the way Nx prescribes, so learning a new organization standard is leaving me feel a little lost. However, this is not an Analog problem, it’s a me problem. And it’s really not a problem either. But I ran into it on an Ionic project recently as well.
• It’s young. There are still some features that exist in other meta frameworks like Next or Gatsby that aren’t in Analog. So it might not have everything you need right away. But it seems to have most of it. And contributors are always welcome to work on new features.
• I think Analog will be a big benefit to companies using Angular that want to use a headless CMS and provide their marketing department tools to update the website. I haven’t seen any examples yet of using Analog and a headless CMS but I’m sure they’ll come.

I have really liked the experience of learning Analog so far, and am excited to learn more. The server routes are interesting, though I haven’t dove in to that yet, and there’s probably more with more to come. But it’s already at a good point right now. I’m not sure if the core team would recommend using it in production yet or not, but it seems stable at least for small projects.

Contributing to Analog

If there are some things you want to see Analog add, or if you find a bug, you should consider getting involved and contributing to the framework. Brandon is really patient and good at helping you contribute. And as with any open source project, the community will help drive it forward.

There are many types of contributions you can make. If you or your company can sponsor the project financially, that money will go a long way. If you can’t do that, use the framework and help the team work out any issues or bugs. Try and fix a bug, or submit enhanced documentation. There are a lot of ways that you can help, and they’re all appreciated.

Conclusion

In conclusion, re-writing my site in Analog has been a thoroughly pleasant experience. There is a lot of promise in the framework, and I’m excited to see where it goes. Make sure to follow Brandon on Twitter, or Analog’s twitter account. You can also join the Discord community and chat with others there.