Sign in Subscribe
blog

TypeScript 3 Projects: What's next?

An appendix to my TypeScript book

Sebastien Dubois

Sebastien Dubois

— 15 min read
TypeScript 3 Projects: What's next?

In my upcoming book about TypeScript, the last chapter is called “What’s next?”. This blog post should be considered as an appendix to the text of the book. It’s going to be quite long, so be prepared! ;-)

I’ll soon publish another article to tell you more about what you can expect in the book and why you should definitely get your own copy!

The thing is that our editor has requested us to get rid of 50 (!) pages in the very last days of the project. This was really hard for us (especially so late in the process), but there was no alternative.

So we ended up removing the resources that I’ll be listing in this blog post; that is a list of pointers and resources about interesting things to learn about TypeScript, modern Web development and software development in general.

The list is long, but to be honest I feel like it’s really just an appetizer! There are soooo so many things to learn or at least be aware of.

So without further ado, let’s dive in!

TypeScript

Believe it or not, but we have covered maybe fifty percent of TypeScript’s complete feature set (and that’s an optimistic guess). There is just so much to say and so many details to cover, that we couldn’t possibly go through everything.

At the start of the project, our goal was to create a practical book, not a comprehensive reference. We also didn’t want to introduce tons of features without putting them in perspective and showing them with actual use cases. Another factor is that TypeScript evolves incredibly fast. Between the start and the end of this project, many versions of TypeScript have been released and, by the time you read this, some more will have come out.

The first thing that you can do next is to take a look at the release notes of TypeScript every once in a while to stay aware of the changes made to the language. You can find those here: https://github.com/microsoft/TypeScript/releases. Usually, these come along with great examples.

Apart from that, you can also keep an eye on the roadmap of the language over at https://github.com/Microsoft/TypeScript/wiki/Roadmap.

Also, here is a list of features/tools that we would’ve liked to cover in this book.

TypeScript 2.1:

TypeScript 2.4:

TypeScript 2.6:

TypeScript 2.7:

TypeScript 2.8:

TypeScript 2.9:

TypeScript 3.0:

TypeScript 3.1:

TypeScript 3.2:

TypeScript 3.4:

TypeScript 3.5:

TypeScript 3.6:

TypeScript 3.7:

Of course you don’t have to learn all of this right away. Nevertheless, it is useful to at least be aware of the existence of some features. Oftentimes though, you can simply learn things as you go and keep improving your code over time.

Throughout this book, we have tried to introduce and use features that we needed when we saw an added value to their usage and you should probably do the same with your own applications. Never let the new and shiny drive your technical choices.

Angular

Angular is difficult to master and we certainly haven’t covered all that much about it in the book.

Here are some resources that you might find useful:

Vue.js

One thing that was proposed near the end of the writing process of this book is a new function-based component API: https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs/0000-function-api.md

As it turns out, the Vue.js maintainers are willing to introduce a more React-like approach with functional components in Vue. This is really interesting as it shows that the benefits of the functional approach are also appealing to Vue developers. This should become clearer in the coming months, but might have a big impact on how Vue applications are written!

Also, Vue 3 will be written in TypeScript and should come out in 2020. At that point, things will change quite a lot! Evan You and his team are making great progress towards Vue 3 and it looks really interesting: https://twitter.com/youyuxi/status/1192096909957193728

In the meantime, a great library (or actually framework?) that you can use on top of Vue.js is called Nuxt.js (https://nuxtjs.org ). We can’t say much about it here, but make sure to explore it on your own if you like Vue, as it makes it even greater!

Here are some additional resources to go further with Vue:

React

React also deserves way more than two chapters to go over all of the nitty-gritty details. Library or not, there is really a lot more to know to become proficient with it. Although we have shown that with a short introduction, we could quickly get started with it.

As time goes on, it is also obvious that React is becoming more and more opinionated, as the ecosystem matures and as better solutions start to stand out.

Here are some links that you might find useful:

Other Web frameworks/libraries

Our choice of frameworks was rather arbitrary and based on current trends, but there are many alternative solutions out there.

Here are some alternatives that you might want to take a look at:

Web components

One area that you might want to invest some time in is web components.

The basic idea behind web components is to extend the set of standard HTML elements with custom ones through the custom elements (https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements) standard API. Web components also rely on other web standards such as the Shadow DOM (https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM).

Each web component encapsulates functionality and can be used as a black box, a bit like the standard video tag. Web components can be created using vanilla JavaScript, but also using many different frameworks and libraries, including Angular, Vue, and React.

If you read between the lines, this actually means that you can make an Angular web application that uses web components created using React or vice versa. There are ongoing experiments in the community around this idea to create so-called Micro frontends. You can find a nice explanation about the ideas behind this concept here: https://micro-frontends.org/

Web components are appealing and interesting because they provide a way to create truly reusable components. Here is an interesting article to dive into the subject: https://medium.com/javascript-in-plain-english/could-web-components-actually-compliment-javascript-frameworks-5-reasons-why-i-think-so-971eee82ee85

At the same time, there are also important drawbacks to consider, including a lack of support in some modern web browsers and issues for accessibility, as explained in Martin Hochel’s recent presentation: https://speakerdeck.com/martin_hotell/the-real-state-of-web-components

Here are some useful links about Web components:

ES modules and Pika

In the book, we have spent quite some time discussing the different module types and what module loaders/bundlers do for us. But, of course, technology moves forward all the time, at light speed, really.

In the past, when you wanted to add a library to a web application, you would simply add script tags in your page. During the last few years, we have transitioned to using module loaders, bundlers, and other tools to assist us.

We needed those partly because we wanted to be able to use modern ES2015+ features even if the client web browsers only supported good old ES5 syntax. Also, because there was no native module system, meaning that managing dependencies was overly complicated.

But we aren’t in 2015 anymore. Many modern web browsers already support ES2019 syntax natively (in other words, without requiring polyfills!). Also, as we’ve explained in the book, ES modules are now officially part of ECMAScript. As a matter of fact, they’re natively supported in all modern web browsers and can be loaded using the type=”module” attribute of the script tag.

Because of this rapid evolution, it is hard to give good advice, but one thing is for sure: the landscape is morphing as we write these lines and what was true yesterday might not be tomorrow. We have moved from the simplicity of the web toward a rather complex ecosystem in which tools such as Webpack are heavily used. Although, we might (hopefully) come back to simpler solutions in the future. If we don’t, then we might end up creating a higher barrier to entry for junior developers or aspiring ones and this is not good!

At this point in time, most packages published on the official npm registry use CommonJS, with require calls and module.exports , but things will probably change.

One thing that you could look into is Pika (https://www.pika.dev ), a project that attempts to move the JavaScript ecosystem forward. As stated on their About page (https://www.pika.dev/about ), Pika aims to put standard ECMAScript Modules (ESM) forward.

Pika offers a CDN that exposes ES modules for thousands of npm packages, making it really easy to get access to them in your applications without requiring a module bundler.

Here’s how the Preact library can be loaded using the Pika CDN:

import {Component, render} from '[https://cdn.pika.dev/preact/v8'](https://cdn.pika.dev/preact/v8%27);

How cool is that?

Being part of ECMAScript, we believe that ES modules will rapidly gain popularity and tooling will certainly evolve to make it easier for us to leverage those.

Here are some links about ES modules and Pika:

The standard JavaScript library and built-in

web modules

Quite recently, a TC39 proposal made a lot of noise: JavaScript might be getting its very own standard library.

Historically, an issue in JavaScript has been the lack of a (large enough) standard library, which partly explains why there was such an explosion of the number of packages on npm . By integrating more and more features in a standard library, the JavaScript community could probably get rid of a really large number of small utility packages and start reusing code more elegantly.

Standard libraries are quite common and much denser in some programming languages, so it would be great for ECMAScript to also provide more out of the box. For instance, some functions that are currently part of the awesome Lodash library (https://lodash.com) might be added to JavaScript’s standard library.

You can find that proposal here: https://github.com/tc39/proposal-javascript-standard-library and should definitely keep an eye on how it evolves, as it will most certainly impact us all over time.

Aside from that, modern web browsers have started integrating built-in modules, allowing web applications to reuse functionality without having to bundle it along with their own code. A first notable example is the Key Value storage API integrated into Google Chrome: https://developers.google.com/web/updates/2019/03/kv-storage

Once again, in the future, this might have a big impact on how we create our applications and how we think about our dependencies and “weight”.

Full-stack applications with Nrwl NX

A tool that we could have used in the the last application of the book (a React frontend + a Nest.js backend) is Nrwl NX (https://nx.dev ). We did not want to introduce it because it would simply have been too much for a single chapter, but it is definitely a tool that you should take a look at if you develop a multi-tier JS/TS application in a monorepo (that is, a source code repository containing both backend and frontend code, or even different projects and libraries).

Nrwl NX is interesting because it makes it a breeze to reuse code between applications and libraries part of the same NX workspace. Also, NX helps to optimize builds, tests, and other operations thanks to its knowledge about the dependencies between the different elements. For example, if a project depends on a library and that library changes, then NX will know that it needs to rebuild it.

The advantages of NX are not limited to facilitating the development of full-stack applications, but we cannot cover any more details here.

Check out these links to resources on full-stack applications with Nrwl NX:

Testing

Even if we did dedicate an entire chapter to it, testing is one of the subjects that we would have loved to go a lot more in-depth about.

Here are some resources to go further on that front:

There are also many great books about testing and code quality.

Style guide, formatting and linting

Code quality is not only a question of correctness but also one of homogeneity. Conventions, style guides, and tools can help with these aspects. For this, Nrwl NX can also help as it provides support for linting and code formatting (using Prettier) out of the box!

Throughout the book, to be honest, we could’ve made an effort on that front, but we had to choose our battles!

Here are some useful links:

If you don’t know about it already, please note that TSLint (currently the standard for linting?) is going to be abandoned/merged into ESLint, which will become the de facto standard in the coming months/years.

Documentation

Documenting code is very important to help other developers to find their way inside of your code base. This is especially true for shared libraries, but it is also relevant for all kinds of projects.

Here are some tools that you can use to document your APIs:

Good documentation is certainly not only about tooling. The seminal book, Clean Code, by Robert Martin (ISBN: 978–0132350884) shares great advice about how to properly document code.

And more…

Voilà, that was the main part of the content that we had to leave out of the book. We hope that you’ll find at least some interesting things in there!

In any case, whatever you do, just keep learning and sharing!

But there’s more to come. In the coming days/weeks, we’ll publish another part of the content that we had to remove at the very end of the process.

Stay tuned!

Subscribe to the newsletter

Read more