The web is now JavaScript. Not just desktop browser-based web – but also native mobile and desktop app web. It is, no doubt, the predominant language of choice for many frontend and backend developers. However, JavaScript on its own can turn into an unstructured mess. Numerous frameworks and libraries have spawned over the years, some more popular than others.
But there’s a little thing called TypeScript that’s taken a segment of the JavaScript community by storm. Ever since its adoption and integration into Angular, it is now a staple for many developers.
So what is TypeScript? Why does it matter? Is it better than JavaScript? and which one should you be using?
This is exactly what we’re going to find out.
To understand TypeScript’s inception and importance, you need to rewind the clock and imagine a few things.
Imagine a world where JavaScript did not have declared types, classes, interfaces, namespaces, arrow syntaxes, modules, and namespaces. That’s what JavaScript was like almost a decade ago. JavaScript software development was exploding everywhere but the scripting language was nowhere near as robust or ready as its traditional programming counterparts like Java and C++.
JavaScript, after all, was created in 10 days and no one really saw it as a major player in web development. The rushed Netscape commissioned scripting language was created to just work. There was no forward-thinking about the long-term structural and architectural growth of the code. For a long time, JavaScript was a kitschy 90s snowflake effect until Apple eventually killed Adobe Flash and any other proprietary software that tried to make itself the leader of the web.
JavaScript’s popularity grew due to its widespread support and implementation in browsers. This led to the growth of sites using JavaScript to create server connections and interfaces. However, over time, the complexity grew but JavaScript’s development still had a long way to catch up.
By the time the 2010s rolled around, developers saw a need to structure JavaScript or risk losing the agility and flexibility that the scripting language offered. But several things were missing – mostly support for implementation ideas that existed in other object-oriented languages such as classes and typing. Without these seemingly simple things, JavaScript was prone to fall into chaotic code within a few sprints.
This is where TypeScript came in. Microsoft created TypeScript to sit on top of JavaScript, a superset scripting language that compiled down into JavaScript but offering the additional benefits and ability to implement structural and architectural integrity.
In essence, TypeScript is JavaScript – but with added functionalities that may not be available in JavaScript yet. For example, at the time of TypeScript’s inception, the class keyword did not exist in JavaScript and was not supported until 2015 – almost 3 years after TypeScript was originally released.
In a way, TypeScript can be seen as what the future of JavaScript can look like. It is often a few steps ahead of JavaScript and offers developers tools and implementation methods of ideologies borrowed from other object-oriented programming languages that work.
But is TypeScript better than JavaScript?
This is a loaded question because TypeScript is JavaScript. It sits on top of JavaScript and acts more as structural support for developers. For many, TypeScript and JavaScript are so seamless that they are almost indistinguishable. You are essentially writing JavaScript code but with additional meta-information available, such as typings and scopes, for the scaffold to create structural checks against.
Vanilla JavaScript, however, is something that many developers aren’t quite as versed in. Many JavaScript developers tend to start their coding journeys by working with libraries and frameworks such as node.js, React, Vue, and Angular. These libraries and frameworks have their own methods of using and implementing JavaScript.
React uses JSX, which is another JavaScript syntax extension like TypeScript – but the syntax implementation is very different from how TypeScript works. While TypeScript was inspired by Java, JSX leans closer towards PHP.
This brings us back to our original question, is TypeScript better than JavaScript?
The answer to this is – depends. The context, frameworks, and libraries used can influence the final architectural and structural outputs. For many projects, a traditional object-oriented structural approach can be beneficial and this is what TypeScript offers as a JavaScript extension.
The perks of using TypeScript comes in when it is used as a structural and communication tool between developers. Code, after all, is just an encapsulation and translation of business rules.
Google’s Angular framework uses TypeScript as its structural and architectural basis. This is because TypeScript enables the framework to leverage the module approach to structuring frontend applications. In order to create a robust and consistent application, JavaScript’s untyped nature needs to be typed. There is no easy way to do this in JavaScript. TypeScript allows developers familiar with object-oriented to uplift ideas and transpose them over to the JavaScript project.
For example, here is a simple Angular TypeScript file for an empty login component.
| import { Component, OnInit } from ‘@angular/core’; @Component({ selector: ‘app-login’, templateUrl: ‘./login.component.html’, styleUrls: [‘./login.component.css’] }) export class LoginComponent implements OnInit { constructor() { } ngOnInit(): void { } } |
This is what it would look like if we were required to write it out in vanilla JavaScript.
| import { async, ComponentFixture, TestBed } from ‘@angular/core/testing’; import { LoginComponent } from ‘./login.component’; describe(‘LoginComponent’, () => { let component: LoginComponent; let fixture: ComponentFixture<LoginComponent>; beforeEach(async(() => { TestBed.configureTestingModule({ declarations: [ LoginComponent ] }) .compileComponents(); })); beforeEach(() => { fixture = TestBed.createComponent(LoginComponent); component = fixture.componentInstance; fixture.detectChanges(); }); it(‘should create’, () => { expect(component).toBeTruthy(); }); }); |
Here is another example of a barebones TypeScript file in Angular.
| import { Component } from ‘@angular/core’; @Component({ selector: ‘app-root’, templateUrl: ‘./app.component.html’, styleUrls: [‘./app.component.css’] }) export class AppComponent { title = ‘AngularFirebaseAuth’; } |
Here is what the vanilla JavaScript looks like to achieve the same effect in Angular.
| import { TestBed, async } from ‘@angular/core/testing’; import { AppComponent } from ‘./app.component’; describe(‘AppComponent’, () => { beforeEach(async(() => { TestBed.configureTestingModule({ declarations: [ AppComponent ], }).compileComponents(); })); it(‘should create the app’, () => { const fixture = TestBed.createComponent(AppComponent); const app = fixture.componentInstance; expect(app).toBeTruthy(); }); it(`should have as title ‘AngularFirebaseAuth’`, () => { const fixture = TestBed.createComponent(AppComponent); const app = fixture.componentInstance; expect(app.title).toEqual(‘AngularFirebaseAuth’); }); it(‘should render title’, () => { const fixture = TestBed.createComponent(AppComponent); fixture.detectChanges(); const compiled = fixture.nativeElement; expect(compiled.querySelector(‘.content span’).textContent).toContain(‘AngularFirebaseAuth app is running!’); }); }); |
By comparison, vanilla JavaScript appears much more verbose than its TypeScript counterpart. The TypeScript version is much more comprehensive by nature and provides a basic implementation of traditional object-oriented syntaxes for developers and enforcing it in JavaScript when it gets compiled and translated over.
The object-oriented roots of TypeScript allow for predictability, readability, and leverage into a lot of object-oriented ideas that are not easily accessible in vanilla JavaScript. This is not to say that implementation of such ideas is impossible – it is just cumbersome to achieve in an effective and efficient manner.
TypeScript, overall, looks great. But where does it fall over?
The major drawback is that you still need to compile your TypeScript file into a JavaScript package. It needs to be transpiled first before it becomes useful. This is because browsers only support JavaScript and TypeScript sits on top of JavaScript.
Another thing to note about TypeScript is that it doesn’t implement true static typing. It is just a feature that sits on the TypeScript layer. This is because JavaScript itself doesn’t have this feature.
For those unaccustomed to object-oriented programming, TypeScript’s code structure can feel bloated. While it slims down the task of writing JavaScript, it is replaced with a lot of syntax sugar. It is also an extra layer of JavaScript to learn, in addition to also learning JavaScript itself.
The quick answer is yes.
TypeScript is not required to be attached to frameworks and libraries like Angular and Nest.js. The JavaScript extender can exist as its own project. The only additional thing that you have to do is transpile it into JavaScript if you want to deploy and run it in your chosen JavaScript supported environment.
Overall, TypeScript is JavaScript but with added benefits for developers. These benefits include the ability to create better structural and architectural integrity in the JavaScript code and reduce the amount of vanilla JavaScript you need to write. The trade-off is that you will have to write more code than needed for smaller applications and transpile it before deployment.
Explore recent posts
//Explore recent posts
//
2 -min read
7 -min read
4 -min read
More Guides
//2 -min read
4 -min read
6 -min read