For years, my go-to frontend framework was React. I started using it professionally around 2015 and so it was a natural choice to use for my personal projects as well since I was already in the mindset.

Of course, I have also dabbled around with others since then, particularly with Vue, but they never really stuck. I always just ended up using React in the end for whatever project I wanted to pursue.

So why would I suddenly want to start using Angular when nothing else stuck?

Note: I know that some developers call React a library rather than a framework. That is probably more accurate, but I’m going to continue calling it a framework in this article because when I say “React”, I’m referring to the entire ecosystem rather than just React itself.

A New Job

Earlier this year, I started a new job. I was hired as a frontend developer, but the project called for using Angular rather than React. When I applied for the job, I figured it would give me a good opportunity to truly try out another framework and see how it works, looks and feels for me. What I discovered blew me away.

Now, I know Angular isn’t the most popular framework amongst developers and particularly not amongst frontend developers. I’m pretty sure that is because it forces you to think much more like a backend developer than frameworks like React or Vue.

It is a strongly opinionated, object-oriented framework and you have to think in terms of classes (not the CSS variety!), services, components and modules. React and Vue are much more flexible in terms of how you can compose your components and structure your code. Both have their pros and cons, but as a full-stack developer, I’ve found I rather like having to write object-oriented code.

Why Angular?

After having used Angular professionally for several months now, I have decided that React just can’t compare to Angular in a number of different ways. I’ll sum them up here in no particular order.

Services

I love services in Angular. They are the primary way data is handled and are simple, intuitive, easy to unit test and ideal for handling large amounts of data.

So how do they work in Angular? I won’t go into a huge amount of detail because that is beyond the scope of this article, but I will give a very quick overview. Essentially, they are injectable classes that are used to fetch and store data in the application.

Angular treats each one of them as a singleton and therefore the data stored in the class is persisted during entirety of the user’s session. To use them, you just inject them into your component classes by importing it as a variable in the constructor and then you have access to all public functions and variables, including the data they hold.

When comparing Angular services to the closest thing in the React world, you get a combination of the native Context API and a third-party global store such as Redux. The Context API allows you to avoid prop drilling, but has to be used with caution because every time a change happens, React re-renders all of the rendered components that use it. Data is only persisted as long as the component containing the provider is still mounted.

Redux and other stores are globally available throughout the application and data is persisted throughout the entire user session. Re-rendering isn’t as much of an issue here, but all of that comes at a cost: massive amounts of boilerplate code. Writing reducers and thunk actions in Redux is powerful, but tedious and painful, especially if you use TypeScript. Getting the types right can have you pulling your hair out in frustration.

Angular services solve all of those problems and are as easy to use as writing any other class in TypeScript. That’s it. That’s literally it. No boilerplating, no re-rendering problems. It just works.

There are constantly new libraries and frameworks coming out on the market. Most are open source and some even become popular very quickly. While this might seem like a great thing since it continuously pushes what technology can do, there are some darker sides to it that no one seems to talk about.

Staying On Top of Things

First of all, developers have to constantly keep up with the latest developments. While this isn’t a problem in itself, the rate at which new technologies emerge makes it very difficult, time-consuming and often stressful to do so.

Personally, I love to play with new frameworks as they come out. I love to experiment with them and see what they can do. In fact, I feel like I read more documentation than I do books. Sometimes I fall in love with one and want to immediately abandon the codebase for whatever project I’m currently working on and start over again with that new tech. Most of the time though, I try it and the excitement quickly fizzles out.

I do this in my free time which, since having my first child, has been significantly reduced and I am no longer able to experiment and play as much as I could before. Fortunately, I have no pressing need to learn anything new at the moment that isn’t for work (which I use work time for), but it also means I am going to fall behind.

Decision Time

Even if you are able to keep up with the latest technologies, that doesn’t mean you don’t have any more problems. In fact, one of my greatest problems stems from the fact that I have experimented and played with a significant number of libraries and frameworks: what the heck do I use for my projects?

I am constantly coming up with new development projects to keep myself entertained and, once I have the initial idea, the first hurdle to getting started is deciding what technologies I want to use. Since I have played with several of them, I know a lot about their pros and cons. This might seem like a good thing, but it means I have to think a lot about what to use before I begin.

This usually takes the form of first sorting out the technologies that I either don’t want to work with or that aren’t suitable for the project. Then, I weigh the pros and cons of each of what remains until I finally come up with a reason to pick one.

Of course, it isn’t necessarily a bad thing at all to carefully choose technologies that are most suitable for your project. The problem with it lies in the fact that so many technologies are so similar with only nuanced pros and cons that several of them would be equally as good for the task at hand.

For example, if you are going to create a web application, do you choose React, Vue or Angular? Or something else entirely? Svelte? Would it make more sense to just skip a frontend framework entirely and go with good old-fashioned server-side rendering?

All of them will get the job done just fine, so what do you choose? Whatever happens to be your favorite at the time? In my case, I have professional experience with all but Svelte, so I know their ins and outs pretty well and am equally as efficient in terms of development time with all of them.

The same goes with backend technologies. Should I build a TypeScript-based backend? If so, do I use Nest.js? Or do I just use Express or Fastify? Or do I go with something even more mature and feature-rich such as Symfony for PHP or Spring Boot for Java?

I have experience in all of them and could easily work with any one of them. Because of that, I often end up spending days getting wrapped up in the decision and often don’t even start the project because I exhaust myself just deciding what to use to make it!

This isn’t a problem that exists for work, however. Usually, you work with a team of people and the technologies are already established. If you are starting a new project, there is usually some sort of consensus amongst the developers about which technologies to use and it usually quickly becomes obvious what the choice is going to be.

Conclusion

I have discussed this issue with other developers and it seems like I am not alone with these problems. Some either fight to keep up with what’s new on the market or they are stressed out because they don’t have time and are unable to.

Surprisingly few seem to have the problem of deciding which technologies to use as I described above. That is because they just simply have a set of technologies they always use for personal projects and, even if they experiment with new ones, they still use their favorites for everything because they know them best and are most comfortable with them.

I have always thought that having a set of favorite technologies I can fall back on would be ideal, but that starts the loop all over again: which ones do I choose?!?

Do you have a problem deciding which technologies you want to use for your projects? How do you keep up with emerging technologies? Let us know in the comments below!

Vue.js makes it easy to implement router-level code splitting. Page loaders are a great way to indicate that your application is loading.

Vue.js combined with Vue Router makes it easy to implement router-level code splitting. For this post, I’m going to assume you know what I am talking about. If you don’t, please see the Vue Router documentation for Lazy Loading Routers.

When code splitting at the router level, however, it means that the user downloads a new JavaScript file every time the route changes. As the user browses the website, these files will be cached and the browser won’t have to download them again, but the initial load may take a little while before it is finished which is why it is important to give the user feedback to let him or her know that your website is still actually doing something.

That is where page loaders come in. A page loader is nothing more than some sort of indication that a page is loading. They come in many forms from simple text (“Loading…”) to fancy animations. For this example, we are going to use a Google-style loader that will look like this when it is done:

Our page loader is an animated bar (in Vue.js’s green!) that runs across the top of the screen. This is a convenient way of displaying a loading status as it is non-blocking and universal.

So how do we do that?

Fortunately, Vue.js makes it easy. I also tried to implement this example using React and React Router, but gave up at after two days of fighting with it. It only took me a couple of hours to implement it in Vue.js and most of it was spent trying to get the bar animation the way I wanted it. The actual logic that shows and hides the page loader was done in only a few minutes.

At this point, if you would just like to get straight into the code without the explanation, see the GitHub repository I created for it.

Code Splitting

The first thing we need to do is add the code splitting at the route-level by lazy-loading the views. When you create a Vue.js app using their init script, the About page will automatically be lazy-loaded. We will modify this slightly to lazy load the homepage as well using the import() function:

import { createRouter, createWebHistory } from 'vue-router'

const router = createRouter({
  history: createWebHistory(import.meta.env.BASE_URL),
  routes: [
    {
      path: '/',
      name: 'home',
      component: () => import('../views/HomeView.vue')
    },
    {
      path: '/about',
      name: 'about',
      // route level code-splitting
      // this generates a separate chunk (About.[hash].js) for this route
      // which is lazy-loaded when the route is visited.
      component: () => import('../views/AboutView.vue')
    }
  ]
})

export default router

That is all that needs to be done in order to code-split at the route-level. As you add more routes to your application, you just use the import() function to lazy-load them.

Adding a UI Store

Before we get to the page loader component, we need to add the ability to control when the page loader should be shown. To do this, we are going to use Vue.js’s default store, Pinia. In this example, I have created a store called “UI”, but you can put this logic in any existing store you might have depending on what makes sense for your application.

Having been employed as a developer in one form or another for the past couple of decades, I can thoroughly relate to what this blogger has written about how little work actually gets done and why.

“I’ve been employed in tech for years, but I’ve almost never worked” — that is the title of a blog article I came across today that rang so true in my ears that I immediately had to write a blog post about it myself.

Having been employed as a developer in one form or another for the past couple of decades, I can thoroughly relate to what this blogger has written. Frankly, it is shocking how little work actually gets done in programming teams.

That isn’t to say that programmers are lazy or aren’t willing to work, but rather the companies that employ them often prevent them from working. Either management does not give them enough to do or processes irrelevant to their actual work prevent them from getting anything done. In most cases, it’s a little bit of both.

The Agile Way of Working

The author of the article also includes scathing criticism of the popular Agile way of working. He argues that not only is “productivity […] sacrificed in the name of predictability”, but also that it leads to “task bloat” where people make tasks much more difficult than they actually are, as well as the fact that “agility”, in practice, makes companies much more rigid rather than “agile”.

Essentially, he puts into accurate words what I myself have experienced as a developer at various companies. Proponents of the Agile Method will argue that it streamlines processes and promotes communication. In my experience, that means the opposite: more “meta-work” (i.e. managing Jira, physical boards, paperwork, demos, estimating difficulty, etc) and more meetings, most of which are irrelevant for me and my job at any given time.

The Agile Method is an enormous distraction from your actual work as a developer. It’s a system designed to make managers feel good and in control and they do so by preventing developers from getting their jobs done.

That is, at least, my experience and I would argue that articles like this one prove that I am not alone in my opinion of it.

Hype About New Technologies

In the world of programming, new technologies are constantly emerging and being hyped. It seems like every month there is some great new library, framework, AI chat bot, programming language, software architecture, compiler, packager, etc that will improve the lives of developers and companies alike.

However, the opposite is frequently true. Not only does management frequently jump on the bandwagon of whatever is currently trendy and order products be built around it, they do it in a way that demoralizes developers.

They may, for instance, hire extra developers specifically to work on it which leads to more “task bloating” since there isn’t enough work to go around. Even worse is when developers are forced to build a product that no one wants or uses. It was just built at the whim of some manager who thought the latest and greatest was going to solve all of their company’s problems.

Again, I’m not alone in having frequently experienced that in the workplace. The blogger also talks about his own experiences with it.

Conclusion

I am not going to summarize everything he says in his article as that would be pointless. Suffice it to say that it is extremely well-written and makes a huge number of valid points about the work experience as a developer.

There is also a German translation of this blog article available from Golem.de:

Wir arbeiten nicht. Null.

This article originally appeared on Alex’s Notebook.

What has your experience been with working as a developer or with developers?

One of WordPress’s greatest strengths is its positively huge plugin ecosystem. There are plugins for just about everything you can think of out there. At the same time, however, it is also its Achilles’ heel.

Anyone can write a plugin and publish it on the official WordPress repository for anyone else to install. On the one hand, that’s a wonderful thing. It brings an enormous amount of freedom to the platform, but on the other hand, it also has the potential for serious security risks to your WordPress installation.

In fact, we frequently see that in the tech news. Headlines about security vulnerabilities found in plugins are not a rare sight in the tech news. It doesn’t matter whether the programmer was acting maliciously or not, many are simply not secure. The WordPress plugin ecosystem is rife with security holes.

As such, I have always been very cautious about installing plugins in my WordPress installations. My first rule is that I only install plugins from trusted sources and with a lot of installs. Anything from Automattic (the company behind WordPress), for example, is generally a safe bet.

Not only will going with a trusted source with a lot of installs make the likelihood higher that the quality of the code is higher, the plugins are also more likely to receive updates if there is a security vulnerability found. Others may never see another update even if there is a severe security hole. It is entirely up to the developer.

Other than that, I regularly go through the few plugins I do have and see if I can’t somehow get rid of another one of them. Newer versions of the WordPress Core will sometimes bring features that you previously had to rely on plugins for. Other times, you just stop using whatever functionality they offered, so you can uninstall them.

As a programmer, I also don’t install plugins that perform a simple task. Instead, I just add the functionality to my theme or I program a plugin myself so that I know I can trust it. I know exactly what it does. While I run the risk of unwittingly introducing a security hole myself, it at least won’t be so widespread that bad actors are likely to take the time to actively exploit it.

Plugins will also potentially slow down your website by loading unnecessary JavaScript files, fonts, images, CSS files, or other resources. They may be needed for the plugin to work, but if you either don’t need the functionality anymore or only need a fraction of what it loads, it may not be worth the performance trade-off.

In any case, plugins can be a wonderful way of expanding the functionality of your WordPress website, especially if you aren’t a programmer, but they also have a negative side to them. In my opinion, you can absolutely enjoy the massive plugin ecosystem, but they are to be enjoyed with caution.

This article originally appeared on Alex’s Notebook.

What are you experiences with WordPress and its plugin ecosystem? Have you ever had any security or incompatibility issues with them? Let us know in the comments below!

Today, I am happy to announce that Developer’s Notebook is being relaunched with lots of exciting stuff on the way!

When I founded Developer’s Notebook back in 2020, it was with the intention of running a blog with content specifically of interest to developers and tech enthusiasts. Unfortunately, life came in between and I wasn’t able to find the time to create any more for it.

Since then, however, my priorities have changed and I am happy to announce a relaunch of the website. While it will be with the same goal of creating great content for developers, there are going to be a couple of changes.

First of all, you may have noticed the new design. I have spent the past couple of weeks creating a new WordPress theme for the website which I will still be tweaking here and there, but it is far enough along that I can proudly show it off.

The next change is that I am not going to continue with the podcast. It was an interesting experiment at the time as it was my very first attempt to create one, but I have decided to focus more on text and programming examples instead which are difficult to translate into a podcast. The two podcast episodes are still available on the old Podcast page.

The last change is that I have closed the Twitter account. I did this a while ago, but I have no plans to recreate it with Elon Musk at the helm and the blocked API I was using to automatically post to it from the blog. The other accounts still exist though and you can find links to them in the footer below.

Otherwise, the content will heavily focus on what it has up to this point: nerdy, programmy, geeky, good stuff. I have a lot of new content already in the pipeline and am looking forward to hearing what you guys think about it!

There are valid reasons for choosing WordPress to power your website, but there are also many good reasons for creating a custom-made website. In this article, we will explore some of them.

When I first started working on Developer’s Notebook, the website was originally going to be a completely static website based on the React framework Next.js. The plan was to write articles as Markdown files which would be committed into the project’s repository. When the project was built, they would then be made into static pages by Next.js. A simple enough concept.

In fact, the code I wrote for this concept I set up as an open source project which is still available on my GitHub account today.

I wrote a generator that automatically put together the RSS feed as well as a sitemap.xml file when the project was built. I also spent time pouring over the schema.org specs and implementing a strategy to automatically add the correct data for posts for SEO. 

It was a ton of work and I put a lot of time into it. And yet, in the end, I still decided to go for WordPress to power Developer’s Notebook. Why did I do that?

Use-Cases

I don’t love WordPress. I feel I need to start off by saying that right away. I don’t hate it either, but it isn’t always my first choice. PHP is not my favorite language and I have enough experience with WordPress to know how unstable it can become if you don’t treat it properly, but I also know it has its strengths and sometimes a WordPress website can even be advantageous when compared to a custom-made website.

Small Projects

Let’s start off with small projects. When it comes to WordPress, it is important to distinguish between small and large projects. For our purposes here, we can define a small project as being a simple application. I’m not talking about scale here, but rather simplicity. A fairly simple website without much custom logic is a great candidate for WordPress regardless of scale.

A few examples of this could be a blog, a basic website such as for a restaurant, a personal portfolio, a shop with WooCommerce, a forum with bbPress, a self-hosted social network with BuddyPress, a news website, an online magazine and so on. The list is very long.

These are ideal candidates for WordPress because it provides most of the functionality out of the box. For some of them, you have to install extra plugins, but the point is that it doesn’t involve a lot of complex, custom business logic.

Large Projects

On the other hand, we have large, complex projects. A lot of businesses start with a WordPress website just to get online as soon as possible. This makes perfect business sense as they can get started without much hassle.

However, it is often the case that their business-needs outgrow what WordPress was originally designed for. At that point, it doesn’t make much sense to keep WordPress around and it is usually advisable to switch to a custom-made website since maintaining an outgrown instance of WordPress will generally cost more money, time and effort in the end than just simply rebuilding it.

This problem isn’t just specific to WordPress, but could be applied to most pre-made software that offers certain functionality out-of-the-box. This sort of software isn’t inherently bad for businesses, but it just isn’t possible for a single platform to cater to every specific need.

Despite what a lot of application developers think, changing a user interface too often is bad for users. It confuses users and generally generates distrust in your product.

It is often said that one of the major benefits of developing a web application is that users don’t have to download updates since they are always using the latest version of the software every time they visit the website. As we developers are well aware, users are fickle when it comes to installing updates.

But why? There are, of course, numerous reasons ranging from “too lazy” to “don’t care” to “not aware” to “I’m afraid something is going to change”. It’s that last reason that this article is going to address.

The User’s Perspective

As developers, we are used to interfaces being changed. We usually keep all of the software we use up-to-date and are, of course, used to changing the interface of whatever application(s) we’re working on.

That means we encounter changed interfaces at a much higher frequency than most other users warping our perspective on how difficult that can be for some people. That means it’s important to take a step back and also have a look at it from a “normal” user’s perspective.

Do regular users want a constantly changing interface? Do they want to have to find that button again that was once on the left and is now on the right with a different label? Why is that element now green instead of black? Does that mean something?

Changes make users nervous and unsure about how to use an application. That is particularly true if they are regular users and they rely on your application to get work done. They become apprehensive about accidentally doing something wrong because the button now says “Apply” instead of “Save”.

Constant Tweaking

When developing an application, it is common practice to constantly tweak its interface. This is particularly prominent on the web where it is cheap and easy in comparison to a native application. 

Developers and even the entire development team including product owners, UX designers, managers, etc, think that because it is easy to deliver updated user interfaces, they are doing their users a favor by continually messing with it or they just simply don’t think about it at all.

However, this is primarily a developer’s perspective. I haven’t talked to many developers who turn the issue around and ask themselves about the user’s take on it. Of course several UX designers do something similar to that by getting user feedback, but I’ll get into that in a moment.

The constant tweaking frustrates the normal user. They want a familiar, consistent interface they know how to use. Most of the time, they don’t care about what color a button is as long as it stays consistent. In fact, quite a few users will simply stop using your application if it changes too often or too radically.

In order to avoid radical changes that cause users to abandon your application, it is important to collect user feedback.

Getting User Feedback

As I mentioned above, it is common practice amongst UX designers to get user feedback for interface designs. This is great not only because it means they can optimize a design before it gets sent into development, but it also means users have a say in how the application they use looks and feels.

This truly is a great thing, however, from my experience, a lot of them simply ask users about updated user interface designs rather than about whether or not they want an update or think it’s necessary.

Of course that has its place when, for example, there’s a new feature or page being added to a website. The question of whether a change is necessary or not is moot as something that wasn’t there before is being brought to life.

For pages that exist, however, I think a lot of users would appreciate being able to give their input about whether or not they want a changed interface. You’d probably be surprised at the number that say no.

I’m happy to announce that Developer’s Notebook is now on Patreon. If you would like to support this website, then please head on over and take a peek!

As a subscriber, you get the following benefits depending on which tier you subscribe to:

• Exclusive merchandise including stickers, t-shirts and mugs
• Commission articles or podcast episodes
• Live chat with me
• You can ask me questions that I will answer via an article or podcast
• Access to polls that will influence upcoming content
• Access to downloadable PDFs of articles
• Access to works-in-progress and drafts

For more details, click on the banner below:

As always, I appreciate your support for Developer’s Notebook and I am looking forward to reading your questions and commissions as well as to all of the other interactions with subscribers!

If you have any other questions, please don’t hesitate to contact me.

Because I’m a developer, I like easter eggs in software. I have therefore decided to include one on Developer’s Notebook.

Most web developers are probably familiar with the dinosaur game from Google Chrome. I found a WordPress plugin that allows me to include in on this website and I couldn’t resist.

It will now appear at random intervals in random places on the website. Have fun with it and let me know in the comments below when and where you find it!

Whether you like it or not, software as a service (SaaS) has become extremely popular amongst both individuals and companies. But how good of an idea is it?

The past decade or so has seen an ever-increasing number of people turning towards software as a service (SaaS) providers to meet their computing needs.

Popular examples include Gmail, Google Drive, Google Docs, Jira, etc., but hundreds if not thousands of other companies both large and small have started offering SaaS. Some of their offerings are free and others require the user to subscribe.

This all sounds fine and dandy and there are certainly a lot of benefits, but is it all rainbows, fairies and roses? Or is there a darker side to it as well? Should everyone jump on the bandwagon or are there still reasons for sticking with more traditional applications installed locally on a user’s machine?

Those are some of the questions we are going to be exploring here.

The Basics

First of all, let’s start by establishing a few of the basics of SaaS.

What is SaaS?

For the purposes of this article, we will be looking at the offerings that provide full-fledged applications on the internet. They run in a browser and/or as an app on a smartphone or tablet and are available from any modern device with an internet connection.

The data produced in or by the application is saved on a server and is only accessible by the user through the application itself. In most cases, an internet connection is required to even use the application at all.

Here are some popular examples:

• G Suite (Google Docs, Gmail, etc)
• Jira Cloud
• WordPress.com (not WordPress.org)
• Blogger
• Salesforce
• DocuSign
• Slack
• etc

There are, of course, examples of SaaS that are more open such as WordPress.org or Jira Server which allow you to download the software and install it on your own server. However, we are only going to focus on the closed systems for now.

Who Uses SaaS?

Users range from private individuals looking for an easy and convenient way to get stuff done on their digital devices to large, multi-national corporations who are looking for a way to outsource part of their IT expenses as well as a way to provide a secure, consistent, centralized way for their employees to do their work and collaborate online.

The new and sudden challenges faced by companies to keep their employees productive and working during the current COVID-19 pandemic has driven even more to use SaaS.

So now that we’ve covered some of the basics, let’s get to the good part.

I’m excited to announce that the first episode of The Developer’s Notebook Podcast has made its debut and that this officially marks the beginning of the podcast.

The Developer’s Notebook Podcast is a show that will cater to a nerdy crowd. Much like the website, it will feature topics related to computers, programming, workplace advice for developers, retro computing and more, but will be a bit more conversational and casual.

How to Subscribe

The podcast is available on several different common channels such as:

It is also available as a standalone RSS feed here: https://www.developers-notebook.com/feed/mp3/

For those of you who use YouTube, you can also subscribe on the Developer’s Notebook YouTube channel.

Of course, subscribing to this website either by using its RSS feed or by email (below in the footer) will also get you all of the latest podcast episodes as well as the latest articles.