Category: Web Development

Why Use TypeScript?

TypeScript is a free and open-source programming language that was developed by Microsoft. It is a superset of JavaScript that enables developers to write cleaner and more maintainable code. In this blog post, we will discuss why it is beneficial to use TypeScript in your next project.

Improved Code Quality

One of the main advantages of TypeScript is that it provides a type system that enables you to catch errors and improve your code quality. By defining types for your variables, functions, and classes, you can catch errors during development time rather than runtime. This helps you to avoid common bugs, such as null or undefined errors and improves the overall reliability of your code.

Better Tooling

Another benefit of TypeScript is that it provides better tooling support than JavaScript. TypeScript has a rich set of features that enable you to write code faster and with fewer errors. For example, TypeScript provides code completion, which helps you to write code faster and with fewer errors. It also provides better error messages, which helps you to debug your code more easily.

Improved Maintainability

TypeScript makes it easier to maintain code over time. By providing a type system and better tooling support, TypeScript enables developers to write code that is easier to maintain and refactor. This is especially important when working on large projects with many developers. TypeScript’s type system enables developers to understand the codebase better and helps them to make changes more confidently.

In conclusion, TypeScript is a powerful programming language that provides many benefits over JavaScript. It offers improved code quality, better tooling support, and improved maintainability. If you are starting a new project or considering a migration, TypeScript is a great choice that will pay dividends in the long run.

The Anatomy of a Great Typescript Book

If I was to write a TypeScript book, I would aim it at web developers who have started using TS, but come from a JavaScript background and have now been put on a TS-based project.

I wouldn’t aim at a certain web framework like React, or Angular, but how a web developer can start to use all the more advanced features in TypeScript so they can write good, type-safe code for their application, no matter the framework they are using.

In this ‘book,’ I will cover briefly what TypeScript is and its aim. I think it is clear now what TypeScript is and what its original aim was, but if someone is coming to this ‘book’ without knowing anything about TS then a brief introduction is needed. Try to explain to someone who’d be asked or just started using TypeScript why it’s so good and why they should be using it over JavaScript.

I’d then move on to introduce Types, and the primitive types that you have in TS (string, number, boolean) then move on to how to define your Types and the various ways you can do this. How you can create Types from other Types, how to use the utility Types and build up the Types for your project. All the time I try to keep it framework agnostic but relate it to a web developer who is now working on a TS-based project for the first time. So they can see that there are primitive Types, but they aren’t all you have (not everything needs to be a string). How you can start to build your Types that are more descriptive and applicable to your application.

Then I’d start looking at classes and modules and how they can be used along with Types to create a common library that you can use within the components of the framework you are using whether it’s Angular, Vue or React. Building this library of domain-specific Types that describe the data of your application and how you can use classes and modules to structure this library.

After introducing this concept of building a library for your application, which is more domain-specific and provides the business logic your UI components need. I’d move on to using Generics and how they can improve the re-usability of this business logic library.

I found Generics in TypeScript a complex topic to understand, especially if you’ve come from something like JavaScript. They are a powerful concept to understand and to start making use of, when you do it takes the re-usability of your code to another level. I feel that as a web developer who has used a couple of UI frameworks, concepts like Generics and Type manipulation are features I know about but haven’t used much in my applications because so much is handled by the framework. If I learnt more about these advanced concepts of TypeScript they’d improve my code so much.

I would then start to finish the book by looking at the compiler, how it works, and how to make use of the TSConfig settings and compiler. Again through using UI frameworks a lot of the TS compiler settings are set up as part of the framework CLI tooling. Knowing more about this area can lead to more efficient code.

After all that I’d spend a little time looking at the various TypeScript libraries that are available which can be used along with the framework to improve Type safety and maintainability within an application. Libraries like ZOD and tRPC, for example.

Finally, I would then take this concept of learning to build an internal library of business logic for an application and go through how external libraries can be built that can be used to share business logic across multiple applications. If you are a web developer who works for an organisation who have more than an internal application that uses TypeScript and how using features like classes, modules and Generics a Type safe domain-based library can be built and used across all these applications.

I think the aim of this ‘book’ would be to show that, yes TypeScript is used by all the main web frameworks, but there is more to it than just writing the code behind your framework’s components. We learn a lot about frameworks but not so much about the language behind it

Dealing With CommonJS based dependencies

An Angular quick tip I discovered today was if you have an application with many third-party libraries that use CommonJS instead of ES modules. You can add the names of these libraries to the "allowedCommonJsDependencies" option in the builder settings in Angular.json.
This helps remove all the warnings in your build, it is basically telling Angular that these libraries are ok to use CommonJS for now until they are updated.

This is great if you are updating an Angular app, but don’t want to go through and update all the dependencies that are still using the CommonJS approach. Then over time as you update these libraries they can be removed from the "allowedCommonJsDependencies" array.

Here’s a link to the official Angular docs on this – https://angular.io/guide/build#configuring-commonjs-dependencies

Using third party libraries are useful as long as they are maintained

There’s no denying that the open-source movement has helped move web development forward. Before open source was so prevalent on the web everything had to be built from scratch, there was no searching on NPM for a library that could help fix an issue you had or a framework to structure your application.
But one of the downsides I see with using third-party libraries in your application is if this library is no longer maintained or updated and your work relies heavily on this library it can easily become a maintenance nightmare.

I’ve worked on a few Angular apps now and many are using third-party libraries every time a new version of Angular is released I have to check if these libraries work with the latest version, which on the whole they do. But if one of these libraries is no longer maintained or worked on, then you are stuck with the choice of either not upgrading your Angular version (something I don’t recommend) or refactoring your code to remove this dependency (something I do recommend).

So when it comes to adding third-party libraries to our codebase we need to make a few decisions. First, is it regularly maintained? Checking the history of the library on GitHub can answer that. If there have been no updates within the last year I get worried. Second, if it is maintained how crucial is this library going to be in my application? If it’s core to how the app works how would I maintain the app if later this library is no longer updated? Will it break my application? Can I easily refactor my code to remove this dependency if I need to? These are all questions that need to be considered before just adding a library.

One tip I have used is if you are using a third-party library or component in your application to wrap it within your own library or component then use this ‘wrapper’ throughout your codebase. So if you need to remove the outdated component/library all you need to do is refactor your ‘wrapper’ to either use another third-party library/component or your own version.

Open source is fantastic, it provides so much but I think that in large-scale applications we need to be defensive in how we use open-source code. Third-party libraries are created by some excellent and hardworking developers, many of whom do this work on top of their own, so I think we should be thankful for their work, but just be aware of how much we are using these libraries.

Back in the Angular World

After a year-long contract with Vue, I’m just starting a new contract working with Angular again.
It’s strange coming back to Angular from Vue, the Angular eco-system is far more mature than Vue. Angular is more of a platform than Vue, so when you start working with Angular, you find that the framework provides you with a lot more ‘out of the box’ than Vue does.
Does this mean that Angular is ‘better’ than Vue? Well no, they offer different things. Angular is ideal for larger-scale applications and teams, while Vue is great for applications that might not need an entire platform to get started.

Show Some Love for the Angular CLI

I’ve recently listened to the latest episode of Adventures in Angular, a great podcast. In this episode they were discussing the merits of the Angular CLI, what it does for us as Angular developers, how much is saves a company on time and money.

The Angular CLI makes writing Angular applications so fast and easy. Before the CLI we had to handle all the build steps ourselves, using tools like Grunt than Gulp. Both fantastic build tools, but having to fight our way through JSON config files was not easy, especially if you wanted to create the ideal setup for your project. It would take days of tweaking the config settings working on the ideal build process.
Then you had to share this build setup with your other team members, and if one thing was different on their system, then the build would fail for them, it was a nightmare.
Thankfully the CLI has taken all that away from us, now there is one universal way of building and running an Angular application locally, which works the same for all members of a team.

Another great benefit of having a CLI is that we no longer have to worry about what build system a project is using. Whether it’s Grunt, Gulp, Bazel or Rollup, this is all handled behind the scenes by the CLI. So as new build systems are coming out, the CLI team can add them to the CLI and we as Angular developers can either accept the new build system the team have added to the CLI or make some changes to our angular.json file and choose the build system we want for our projects.

I think one of the greatest benefits of the CLI is how easy it makes running Unit Tests. Before Angular, in AngularJS, setting up Karma and Jasmine was a painful experience. Again, tackling JSON files, making sure all the paths were correct, spending hours searching for answers to errors when we finally tried running the tests. Reading blog posts where someone showed us a few ‘simple’ steps to making it all work first time, and finding that after following these ‘simple’ steps Karma still didn’t work for us, then trying to figure out where we went wrong. Setting up Unit Tests was a painful and long process, but now with the CLI it’s all handled for us. All we do is run a simple command, and boom all our Tests are run.

The Adventures in Angular episode really did show how much time and effort the CLI now saves us, not only as developers, but the costs it saves companies. No longer do companies have to pay developers for setting up their local build systems, now an Angular developer can be up and running in no time.

If, as an Angular developer, you’ve gotten use to having the CLI around, take a minute to think about all the benefits it brings us. The CLI is really an amazing tool, it really helps separate Angular from the other front-end frameworks out there.

When enough is enough,

There is a time when writing code that you need to say to yourself, enough is enough. I’m not talking about giving up coding, what I’m talking about is when you’ve been adding so many features to a section, that the code is unmanageable. There is a point where cramming in another feature to a section, means that the code behind will need to be re-written in order to make it easier to read, easier to manage and easier to test.

One of the big problems with AnglarJS, when it first became popular was developers didn’t know the best practices for how to write good clean AngularJS applications. The main problem was with the controller. The controller is a great concept, having a JavaScript file that sits behind your HTML template, which has access to all the elements in the template was amazing, but soon developers started to go crazy writing everything in one controller, at the time there wasn’t a ‘style guide’ that showed us a better way. Slowly over time, better practices were shared in the community, there were more examples of how to structure our AngularJS apps.

Recently I’ve had to work with an AngularJS project that has a controller where the structure of the controller has become unmanageable. Currently, the file has over 1200 lines of code, it is full of functions all doing different things, nothing grouped together in a logical structure, the use of both $scope and VM models is throughout the file instead of using one approach consistently. It is hard to work with this controller, and it is important of the functionality of the application.

Now I can see how this controller has gotten into this situation. It’s clear that at the beginning of the development this core piece of functionality that the controller manages was not fully planned. So the developer probably thought, this section doesn’t have a great deal of functionality I can keep it all within one controller.
Soon the features for this section grew and became more and more complex, the demand to get them delivered also grew, so the time for refactoring was not available. Now we are in a situation when we have a 1200 line controller that is hard to work with, nearly impossible to add new features too and is still buggy.

In order to stop this type of situation, developers need to be able to say to the PMs and stakeholders of a project, that they need to spend some time, refactoring the existing code in order to make it so new features can be added easily.

When a team successfully uses Scrum there is this time to raise issues like this, to let the PMs know that a bit of time is needed in order to tidy up the code before tackling a new feature. As part of the standard sprint planning, this can be raised. Without it the team just keep ploughing on building onto of existing code, adding feature after feature until everything is nearly unmanageable.

So what can developers and teams do in order to stop this happening:

  • Have regular sprint planning meetings to discuss the work coming up and not keep ploughing along without reviewing
  • Set out from the beginning a style guide, how the team will approach the development of the application
  • In PR reviews, don’t just have a quick look over the code and accept it, discuss with the developer if there are problems or code smells and how they can restructure their code to avoid these types issues later
  • Teach the more junior developers good practices on structuring code
  • Tell the managers and stakeholders why having good code quality is important to their project, why cutting corners, will only come back to haunt a project later on

Keeping your skill set up to date

As part of life as a contractor one of the most important things it managing to keep your skillset up to date. This was fine when all you had to worry about was just HTML, CSS and maybe jQuery, but now with the explosion of JavaScript frameworks keeping your skill set up to speed is getting harder and harder.

When you look at a job description you usually see a whole list of ‘technologies’ that are required for the role. Angular, Node, React, Sass, CSS, UX/UI skills and maybe ‘if you also know PHP, that’ll be an advantage’. But keeping up to date with all these different technologies is nearly impossible. Two of these are entire platforms and not just frameworks.

So how is a lonely developer supposed to know all these frameworks, platforms and technologies inside and out, as well as work fulltime?

Well one way, and what a lot of freelancers are doing now, is niching down to a certain skill set or role. For example, is being known for creating offline first apps using Angular or creating Progressive Web Apps using Node or front-end development using HTML and Sass. These are all examples of how a freelancer/contractor can narrow down what they do in order to really understand well the technology they use.

Of course, the first thing that goes through peoples mind when thinking of narrowing down their skill set, what we use as contractors to get work, is the fear of missing out on work. If I don’t have the skill set for a certain job, then I can’t go for so many roles, I’ll miss out on work. But if you do a quick search on Google for ‘niching down + freelance’ one of the first articles you’ll find is ‘Overcoming the Fear of “Choosing a Niche”‘ by Brennan Dunn.

In the article he shows why having a niche or being a specialist is actually a good thing for your business/career:

When you go from being a generalist — that is, a provider of some commodity service, like web design — to being a specialist, who solves a specific type of problem for a specific kind of client, three things almost always happen:

  1. You’re able to charge more.
  2. Your clients give you more creative latitude and freedom, and a lot more respect.
  3. It’s easier to close deals.

In the rest of the article, Brennan goes through all the different issues with niching down, about the fear people have of doing this, the fear of picking the wrong niche to work in, dealing with the boredom that might come with only working with one technology.

If you want to read about how other people have found their niche and what it has done for them, this article Top 16 Freelancers Tell You How They Found Their Niche gives some interesting insight.

There are also some great books on this:

 

So in order to keep your skill set up to speed in today’s ever-changing web industry, instead of trying to be a master of everything and ending up a master of none, it might be work just narrowing your focus a little. Finding out what you enjoy working with, what projects you have enjoyed working on and becoming a specialist in those types of projects, using that type of technology in order to really learn and know that skill set.

It something I’m going to focus on doing over the next few weeks months.

 

30DWC Week 1

First week of the 30 Day Writing Challenge is up, so far doing ok, I managed to get a post out everyday. I haven’t set any plans to write for at least 30 minutes every day, the main goal I had was to get a post out which so far I have.

For this years challenge I decided instead of just writing whatever came to mind, I’ve tried to have a couple of theme subjects to write about. They are learning NodeJS and updates on an ExpressJS app I’m working on, but now into the 2nd week I think these may change.

The reason for the change is one, the project I’m working on at work may switch to using Angular 2.x from Angular 1.x, so I will have to spend a bit of time outside work brushing up on Angular 2.x. This means my plan to focus on Node for the next few weeks will have to wait. Unfortunately this is the way contracting can be at times, you need to have the skillset for the project. As we could be mirgrating to Angular 2.x I’ll need to know about migrating an Angular 1.x app than I will ExpressJS.

The other topic I have been enjoying writing about is productivity and Todoist. I’m a big fan of Todoist and I’m always looking on ways to use it in order to improve how I work and how to use Todoist to work towards the goals I have, both business and personal.

One think I have found this year is that by having themes for your blog it makes it easier to come up with ideas of what to write for a post. I’ve also written a list of blog post titles for the 30 days of the challenge, this has helped when it comes to writing a post. I look at the list of titles pick anyone I think I can write about and get going.

Anyway week 1 is done and I’m enjoying writing for the blog again.



Using Todoist to manage software development

I’m a big fan of Todoist as I’ve already mentioned but one area it does fall down on for me is how to manage software development projects within Todoist.

Normally a software project is managed in a team with tools like Jira or Trello with their column approach. These are both great products (some people aren’t the biggest fan of Jira, but I think it’s ok). It is going to interesting to see what affect Atlassian has on Trello now that they own it, will they move Trello into Jira?

So while I’ve found Todoist a fantastic tool for my day to day tasks, I’ve always struggled with it when it came to managing any personal software projects I had. The column approach that Trello and Jira give really help set out what tasks you’ll need to do, what ones are in progress and which ones are complete.

The answer to this I think is the use of filters and labels, both of these features in Todoist can really help you set up a project with views of how the project is going.

Thinking about it when working on a software project there are a few things you need to see:

  • What tasks/features need to be implemented
  • What features are being developed now
  • What needs to be tested/review
  • What is waiting on someone else
  • What is complete

You can set this up by first creating a Project, then add Labels for the various states of the project and finally create filters to give you the different views you want of the project.

So for example I may want to create a project for building a new mobile app

Then I’ll create some new Labels for each ‘column’.

 

I’ve given them all the same colour to make it easier to see them connected. I’ve also created one for the Project name (My_Mobile_App) this is so I can add that label to each task as well as the state of that task. Finally you can create some custom filters to give you an over view of the project. Filters like

  • @My_Mobile_App & @Feature
  • @My_Mobile_App & @Feature & In_Progress
  • @My_Mobile_App & @Feature & For_Review
  • @My_Mobile_App & @Feature & Signed_Off

With the labels and filters in place you can setup a great overview of the project. Another great feature of Todoist is you can invite others to that project. This can either be others working on the project or the client themselves who can get a view of how the project is going.