Archive

The Dulin Report

Browsable archive from the WordPress export.

Results (43)

Strategic activity mapping for software architects May 25, 2025 The future is bright Mar 30, 2025 Comparing AWS SQS, SNS, and Kinesis: A Technical Breakdown for Enterprise Developers Feb 11, 2023 Should today’s developers worry about AI code generators taking their jobs? Dec 11, 2022 Scripting languages are tools for tying APIs together, not building complex systems Jun 8, 2022 Java is no longer relevant May 29, 2022 Best practices for building a microservice architecture Apr 25, 2022 TypeScript is a productivity problem in and of itself Apr 20, 2022 In most cases, there is no need for NoSQL Apr 18, 2022 A year of COVID taught us all how to work remotely Feb 10, 2021 What programming language to use for a brand new project? Feb 18, 2020 Microsoft acquires Citus Data Jan 26, 2019 The religion of JavaScript Nov 26, 2018 Teleportation can corrupt your data Sep 29, 2018 Let’s talk cloud neutrality Sep 17, 2018 What does a Chief Software Architect do? Jun 23, 2018 TypeScript starts where JavaScript leaves off Aug 2, 2017 Node.js is a perfect enterprise application platform Jul 30, 2017 Design patterns in TypeScript: Chain of Responsibility Jul 22, 2017 Rather than innovating Walmart bullies their tech vendors to leave AWS Jun 27, 2017 TDWI 2017, Chicago, IL: Architecting Modern Big Data API Ecosystems May 30, 2017 Copyright in the 21st century or how "IT Gurus of Atlanta" plagiarized my and other's articles Mar 21, 2017 Online grocers have an additional burden to be reliable Jan 5, 2017 Don't trust your cloud service until you've read the terms Sep 27, 2016 In search for the mythical neutrality among top-tier public cloud providers Jun 18, 2016 What can we learn from the last week's salesforce.com outage ? May 15, 2016 JEE in the cloud era: building application servers Apr 22, 2016 Managed IT is not the future of the cloud Apr 9, 2016 JavaScript as the language of the cloud Feb 20, 2016 Our civilization has a single point of failure Dec 16, 2015 IT departments must transform in the face of the cloud revolution Nov 9, 2015 We Live in a Mobile Device Notification Hell Aug 22, 2015 What Every College Computer Science Freshman Should Know Aug 14, 2015 Book Review: "Shop Class As Soulcraft" By Matthew B. Crawford Jul 5, 2015 Attracting STEM Graduates to Traditional Enterprise IT Jul 4, 2015 Your IT Department's Kodak Moment Jun 17, 2015 Big Data is not all about Hadoop May 30, 2015 Smart IT Departments Own Their Business API and Take Ownership of Data Governance May 13, 2015 What can Evernote Teach Us About Enterprise App Architecture Apr 2, 2015 Microsoft and Apple Have Everything to Lose if Chromebooks Succeed Mar 31, 2015 On apprenticeship Feb 13, 2015 Wall St. wakes up to underinvestment in OMS Aug 21, 2014 Cassandra: Lessons Learned Jun 6, 2014

TypeScript starts where JavaScript leaves off

August 2, 2017

As a software engineer, I learned that one measure of my success is whether or not the code I've written is in production and maintainable by others years after I moved on to other things. Self-documentation features of the programming language play a crucial role.

The rapid adoption of JavaScript and Node.js in the enterprise revealed some flaws in the platform. While it is possible for apps to be rapidly built and put in production, the long term maintainability becomes almost impossible. One of the problems with JavaScript is that the code is not self-documenting.

Consider object-orientation as an example: class keyword was only introduced in 2015. Until then the mechanism to accomplish this was via prototype functions. Class keyword is a syntactic sugar over prototypes, but it sure is far more readable in the longer term than a prototype function.

Another example of poor self-documentation is lack of strong typing. Strong typing is a programming language concept that guarantees consistency of the code at compile-time. It is possible in JavaScript to do the following:


var amount = 10.52;
amount = amount + 1.57;
amount = "$" + amount;


TypeScript addresses these and many other flaws of JavaScript that prevent it from becoming a real enterprise application platform. Syntactically TypeScript is a superset of JavaScript. Since TypeScript cannot be natively executed by Node.js or by browsers, it needs to be compiled into JavaScript – the process sometimes is also called transpiling.

When computers made their way into the enterprise in the 1960s and 1970s, the coders had to write programs in assembler – a low-level mnemonic language that is translated directly into machine code. Believe it or not, many of these programs are still around in banks, government, and other big enterprises.

As you can imagine, assembler programs are difficult to maintain at scale. This is where languages like C, PL/I, Pascal, COBOL, and later C++, Objective-C, and Java come in. Programs written in these higher level languages are first translated into assembler as part of compilation. During the compilation stage, the compiler can identify silly programming mistakes and prevent difficult to solve problems later on.

In a way, JavaScript is the assembler and TypeScript is the higher-level language on top of it. TypeScript offers strong typing and syntactic mechanisms for object-orientation and name spacing similar to languages like Pascal, Delphi, Java, and C#. In fact, Anders Hejlsberg, the lead architect of TypeScript, also worked on both Delphi and C#.

Over time, it is possible that the features of TypeScript may find their way to JavaScript. That would be nice. Until then, TypeScript helps us keep our sanity when using Node.js in the enterprise.