An Overview of Microsoft Typescript

Total Page:16

File Type:pdf, Size:1020Kb

An Overview of Microsoft Typescript An overview of Microsoft TypeScript Hilde Verbeek January 27, 2020 1 Introduction TypeScript is a language developed by Microsoft and first released in 2012, that is meant as an improved version of JavaScript. TypeScript is a superset of JavaScript, meaning ev- ery JavaScript program is also a valid TypeScript program. TypeScript programs compile to JavaScript, so can be run in web browsers making them useful for the same purposes as JavaScript, with web development at its core.[1] TypeScript was created with several similar languages for the same purposes existing, such as CoffeeScript and Google's Dart. However, TypeScript has become one of the most popular languages for web development over the years, ranking as the tenth most used language in Stack Overflow's 2019 survey.[2] The language was developed after Microsoft developers felt the need for a better alternative to JavaScript. The language aims to mitigate the shortcomings of JavaScript, mainly with regards to its type system (which is where the languages gets its name). The main feature to achieve this, is the addition of a static type checker, but besides this, TypeScript adds many other features to improve the quality when one would normally use JavaScript. This report will look at some of the features of TypeScript, and analyze and evaluate the usefulness of the type system. It will end with some of the advantages and drawbacks to using TypeScript over pure JavaScript or other alternatives. The entire language specification of TypeScript is available online. This report royally refers to it for certain details, whereas some others are the result of experimenting with the TypeScript compiler.[3] 2 Language Features Because TypeScript is a syntactic superset of JavaScript, its possibilities and purposes are much the same. TypeScript-specific features are mostly meant to improve the development process of writing a typical JavaScript application, with a focus on adding a static type checker, as well as generally extending and improving JavaScript's type system. Other features include syntactic sugar to improve existing language concepts. 2.1 Programming paradigm TypeScript is classified as a multi-paradigm language. Like JavaScript, it is at its core an imperative language, that contains features that allow for different paradigms. The inclusion of classes and objects allows for an object-oriented approach. TypeScript's static type checker, as well as some other features enhance this. Furthermore, there are multiple features that allow functional programming approaches, such as functions as first-class citizens. TypeScript's type system also allows ways to easily define algebraic data types.[4] 1 2.2 Type system TypeScript's essential addition to JavaScript, and its namesake, is the static type checker intro- duced by the compiler. JavaScript's own type system is a loosely-, dynamically-typed system that is often at the core of criticism directed at the language. TypeScript seeks to eliminate these problems, by introducing a compile-time static type checker, using a system commonly known as gradual typing. The programmer is allowed to add (optional) type annotations to variables, constants, parameters and return values; if no type annotation is given, the compiler attempts to infer the type from context. Using the provided or inferred types, the compiler statically checks the usage of values, and raises errors upon misuse. The enforced type system is more strict and safe than JavaScript's dynamic typing system: for example, it is strongly typed, and as such does not allow for every value to be used in every context. The type system is further detailed in the next section. 2.3 Scalability One goal of TypeScript and specifically its static type checker, is to improve the scalability of applications. There are multiple ways this is helped: for one, static type checking prevents the misuse of functions with regards to parameter and return types, which becomes more and more likely in large applications, especially in teams. In pure JavaScript, this kind of type errors can often goes uncaught. Furthermore, TypeScript's compiler allows for the creation of declaration files (similar to C/C++'s header files) that only describe the types of functions and values exported by a module. These declaration files allow for efficient module or library development, as the applications using these modules can refer to the declaration files during type checking. 3 Type System 3.1 The JavaScript type system To understand TypeScript's static typing, it is first important to understand how JavaScript itself handles types. Remember that a TypeScript program compiles to JavaScript, so Type- Script is actually (sort of) subjected to these rules as well; however, it adds guards at compile time to ensure types are not used in \unsafe" ways that will cause weird or unexpected results when run by a JavaScript interpreter. 3.1.1 Primitive and object types JavaScript has a limited amount of types. Some are straight-forward primitive types such as number, string and boolean. The types null and undefined correspond to their equally- named values. The type object is applied to any JavaScript object, including arrays and user- defined types constructed with new. This means that there is no way to distinguish between object types at runtime; the reasons and implications of this become clear later on.[5] 3.1.2 Weak typing and type coercion A typing feature of JavaScript, that is commonly referred to as \weak typing", is one of the problematic features that TypeScript attempts to mitigate. Weak typing means that in any application of a value, the interpreter will attempt to find a way to use it, and produce a value. This process is called type coercion. An example is the expression "3" * "4": there is no way to multiply strings, so the interpreter casts the values to numbers, and the result is 12 (a number). 2 This is likely not the intention of the programmer, as they would probably actually provide values of type number if it was. In case one of the operands cannot be properly parsed as a number, such as in "3" * "foo", it will become NaN, and so will the outcome of the expression. This could cause serious problems in a program. While the result of this expression should still be clear, there are much worse examples where type coercion produces extremely unexpected and arbitrary-seeming results. [6] 3.1.3 Duck typing A typing pattern that is certainly not unique to JavaScript, is called \duck typing". After the poet James Whitcomb Riley, who wrote \When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.", duck typing means that any object can be treated as a desired type, as long as it more or less exhibits the behavior of said type. To call a function, or access a property of an object, the object's type or structure does not matter as long as it contains the requested property.[7] Consider the following example: function Person(name) { this.name = name; } Person.prototype.greet = function() { console.log("Hello, " + this.name); } var people = []; people.push(new Person("Amy")); people.push(new Person("Josh")) people.push({greet: function() {console.log("I'm a duck!");}}); for(var person of people) person.greet(); This code will run fine, even though the third object is not defined as a Person and has its own greet method instead. For each of the objects, JavaScript will simply check if it has a greet method and run it, regardless of how it was defined. In certain other languages, especially statically-typed ones, such an approach would not work, as it would require a shared definition of the method, for instance in a superclass. The behavior can be used for good and bad: one one hand, it allows for a very simple definition of interfaces (without explicitly defining the interface beforehand) to use a strategy pattern. However, the lack of static type checking makes it much more prone to runtime errors (eg. when some of the methods are not defined by an implementation) and occasionally harder to understand as programmer.[8] On top of that, the lack of static definitions and protections (eg. non-public interfaces and unoverridable methods) make it more prone to malicious usage. 3.2 Overview of TypeScript types TypeScript introduces a system of static type checking, that is performed as the code is compiled to JavaScript, in order to make it more \developer-proof". The static checker is subject to much stricter rules than pure JavaScript: the previous example of the expression "3" * "4" will produce a compiler error: The right-hand side of an arithmetic operation must be of type `any', `number', `bigint' or an enum type. However, it should be noted that despite the compiler error it still produces output, as it is still valid JavaScript code that will have no trouble running. 3 We will look at a subset of typing features and concepts to better understand how TypeScript handles it. 3.2.1 Type annotations and type inference TypeScript checks type correctness from the bottom up. On the lowest level, the type of simple values is often obvious: "foo" is obviously a string, and 42 is obviously a number. From here on out, the types of more complex expressions can be inferred: for instance, the result of a number added to a number, is obviously itself a number. This process is called type inference. When declaring functions, variables and constants, the programmer can choose to supply a type annotation, to declare the type of said value. If the type annotation is omitted, in many cases it can and will still be inferred by the compiler, from its initial value.
Recommended publications
  • Coffeescript Accelerated Javascript Development.Pdf
    Download from Wow! eBook <www.wowebook.com> What readers are saying about CoffeeScript: Accelerated JavaScript Development It’s hard to imagine a new web application today that doesn’t make heavy use of JavaScript, but if you’re used to something like Ruby, it feels like a significant step down to deal with JavaScript, more of a chore than a joy. Enter CoffeeScript: a pre-compiler that removes all the unnecessary verbosity of JavaScript and simply makes it a pleasure to write and read. Go, go, Coffee! This book is a great introduction to the world of CoffeeScript. ➤ David Heinemeier Hansson Creator, Rails Just like CoffeeScript itself, Trevor gets straight to the point and shows you the benefits of CoffeeScript and how to write concise, clear CoffeeScript code. ➤ Scott Leberknight Chief Architect, Near Infinity Though CoffeeScript is a new language, you can already find it almost everywhere. This book will show you just how powerful and fun CoffeeScript can be. ➤ Stan Angeloff Managing Director, PSP WebTech Bulgaria Download from Wow! eBook <www.wowebook.com> This book helps readers become better JavaScripters in the process of learning CoffeeScript. What’s more, it’s a blast to read, especially if you are new to Coffee- Script and ready to learn. ➤ Brendan Eich Creator, JavaScript CoffeeScript may turn out to be one of the great innovations in web application development; since I first discovered it, I’ve never had to write a line of pure JavaScript. I hope the readers of this wonderful book will be able to say the same. ➤ Dr. Nic Williams CEO/Founder, Mocra CoffeeScript: Accelerated JavaScript Development is an excellent guide to Coffee- Script from one of the community’s most esteemed members.
    [Show full text]
  • Chapter 1: Introduction to the Pencil Code Environment
    Chapter 1: Introduction to the Pencil Code Environment In this manual we will show how to use Pencil Code to explore programming. Pencil Code is a free programming tool available at pencilcode.net. Pencil Code was developed by Google engineer David Bau together with his son Anthony Bau, with open-source contributions from many others. Two Ways of Looking at a Program There are two ways of viewing a program. A computer user sees a program by looking at its output. A programmer works with a program’s source code. In Pencil Code, the screen is split into two halves, with the source code on the left and the output on the right. You run programs by by pressing the “play” button in the middle. The Pencil Code interface splits the screen, showing source code on the left and output on the right. The play button in the center runs the code and produces output. Languages and Libraries in Pencil Code Pencil Code supports code in both blocks and text using mainstream web programming languages and useful libraries including: • HTML, the standard HyperText Markup Language for the web. • JavaScript, the standard programming language of web browsers. • CSS, the standard Cascading Style Sheet language for visual styles on the web. • jQuery, a popular library that simplifies programming interactive websites. • CoffeeScript, a language that lets you do more with less typing than JavaScript. • jQuery-turtle, which extends jQuery to simplify graphics and animation for novices. With Pencil Code, students can use these technologies to create web applications with global visibility and impact while exploring fundamental concepts in computational thinking.
    [Show full text]
  • Coffeescript Accelerated Javascript Development, Second Edition
    Extracted from: CoffeeScript Accelerated JavaScript Development, Second Edition This PDF file contains pages extracted from CoffeeScript, published by the Prag- matic Bookshelf. For more information or to purchase a paperback or PDF copy, please visit http://www.pragprog.com. Note: This extract contains some colored text (particularly in code listing). This is available only in online versions of the books. The printed versions are black and white. Pagination might vary between the online and printed versions; the content is otherwise identical. Copyright © 2015 The Pragmatic Programmers, LLC. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. The Pragmatic Bookshelf Dallas, Texas • Raleigh, North Carolina CoffeeScript Accelerated JavaScript Development, Second Edition Trevor Burnham The Pragmatic Bookshelf Dallas, Texas • Raleigh, North Carolina Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf, PragProg and the linking g device are trade- marks of The Pragmatic Programmers, LLC. Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein. Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun.
    [Show full text]
  • Safe, Fast and Easy: Towards Scalable Scripting Languages
    Safe, Fast and Easy: Towards Scalable Scripting Languages by Pottayil Harisanker Menon A dissertation submitted to The Johns Hopkins University in conformity with the requirements for the degree of Doctor of Philosophy. Baltimore, Maryland Feb, 2017 ⃝c Pottayil Harisanker Menon 2017 All rights reserved Abstract Scripting languages are immensely popular in many domains. They are char- acterized by a number of features that make it easy to develop small applications quickly - flexible data structures, simple syntax and intuitive semantics. However they are less attractive at scale: scripting languages are harder to debug, difficult to refactor and suffers performance penalties. Many research projects have tackled the issue of safety and performance for existing scripting languages with mixed results: the considerable flexibility offered by their semantics also makes them significantly harder to analyze and optimize. Previous research from our lab has led to the design of a typed scripting language built specifically to be flexible without losing static analyzability. Inthis dissertation, we present a framework to exploit this analyzability, with the aim of producing a more efficient implementation Our approach centers around the concept of adaptive tags: specialized tags attached to values that represent how it is used in the current program. Our frame- work abstractly tracks the flow of deep structural types in the program, and thuscan ii ABSTRACT efficiently tag them at runtime. Adaptive tags allow us to tackle key issuesatthe heart of performance problems of scripting languages: the framework is capable of performing efficient dispatch in the presence of flexible structures. iii Acknowledgments At the very outset, I would like to express my gratitude and appreciation to my advisor Prof.
    [Show full text]
  • Comparative Studies of Programming Languages; Course Lecture Notes
    Comparative Studies of Programming Languages, COMP6411 Lecture Notes, Revision 1.9 Joey Paquet Serguei A. Mokhov (Eds.) August 5, 2010 arXiv:1007.2123v6 [cs.PL] 4 Aug 2010 2 Preface Lecture notes for the Comparative Studies of Programming Languages course, COMP6411, taught at the Department of Computer Science and Software Engineering, Faculty of Engineering and Computer Science, Concordia University, Montreal, QC, Canada. These notes include a compiled book of primarily related articles from the Wikipedia, the Free Encyclopedia [24], as well as Comparative Programming Languages book [7] and other resources, including our own. The original notes were compiled by Dr. Paquet [14] 3 4 Contents 1 Brief History and Genealogy of Programming Languages 7 1.1 Introduction . 7 1.1.1 Subreferences . 7 1.2 History . 7 1.2.1 Pre-computer era . 7 1.2.2 Subreferences . 8 1.2.3 Early computer era . 8 1.2.4 Subreferences . 8 1.2.5 Modern/Structured programming languages . 9 1.3 References . 19 2 Programming Paradigms 21 2.1 Introduction . 21 2.2 History . 21 2.2.1 Low-level: binary, assembly . 21 2.2.2 Procedural programming . 22 2.2.3 Object-oriented programming . 23 2.2.4 Declarative programming . 27 3 Program Evaluation 33 3.1 Program analysis and translation phases . 33 3.1.1 Front end . 33 3.1.2 Back end . 34 3.2 Compilation vs. interpretation . 34 3.2.1 Compilation . 34 3.2.2 Interpretation . 36 3.2.3 Subreferences . 37 3.3 Type System . 38 3.3.1 Type checking . 38 3.4 Memory management .
    [Show full text]
  • Learning HTML5 Game Programming Addison-Wesley Learning Series
    Learning HTML5 Game Programming Addison-Wesley Learning Series Visit informit.com/learningseries for a complete list of available publications. The Addison-Wesley Learning Series is a collection of hands-on programming guides that help you quickly learn a new technology or language so you can apply what you’ve learned right away. Each title comes with sample code for the application or applications built in the text. This code is fully annotated and can be reused in your own projects with no strings attached. Many chapters end with a series of exercises to encourage you to reexamine what you have just learned, and to tweak or adjust the code as a way of learning. Titles in this series take a simple approach: they get you going right away and leave you with the ability to walk off and build your own application and apply the language or technology to whatever you are working on. Learning HTML5 Game Programming A Hands-on Guide to Building Online Games Using Canvas, SVG, and WebGL James L. Williams Upper Saddle River, NJ • Boston • Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Cape Town • Sydney • Tokyo • Singapore • Mexico City Many of the designations used by manufacturers and sellers to distinguish their products Associate are claimed as trademarks. Where those designations appear in this book, and the publish- Publisher er was aware of a trademark claim, the designations have been printed with initial capital Mark Taub letters or in all capitals. Senior Acquisitions The author and publisher have taken care in the preparation of this book, but make no Editor expressed or implied warranty of any kind and assume no responsibility for errors or omis- Trina MacDonald sions.
    [Show full text]
  • Open Source on IBM I Webinar Series Day 2 ERWIN EARLEY ([email protected]), SR
    Open Source on IBM i Webinar Series Day 2 ERWIN EARLEY ([email protected]), SR. SOLUTIONS CONSULTANT, PERFORCE, NOVEMBER 2019 2 | COMMON Webinar Series: Open Source on IBM i | November 2019 zend.com Day 1 Review • Introduction to Open Source on IBM i • Why is Open Source on IBM i Important • Understanding the PASE environment as the enabler of Open Source on IBM i • Getting Familiar with the PASE environment 2 | Zend by Perforce © 2019 Perforce Software, Inc. zend.com 3 | COMMON Webinar Series: Open Source on IBM i | November 2019 zend.com Day 2 Agenda • Setting up OSS EcoSystem on IBM i – ACS version • Exploring Containers on IBM i • Managing Open Source on IBM i • Exploring Open Source Programming Languages ▪ Integration with Db2 and ILE • After-Hours Lab: Containers & Setting up Development Environment • After-Hours Lab: Open Source Programming Languages 3 | Zend by Perforce © 2019 Perforce Software, Inc. zend.com IBM Systems Technical University © 3 4 | COMMON Webinar Series: Open Source on IBM i | November 2019 zend.com Setting up OSS Ecosystem on IBM i – ACS Version 4 | Zend by Perforce © 2019 Perforce Software, Inc. zend.com 5 | COMMON Webinar Series: Open Source on IBM i | November 2019 zend.com The directory structure Before installing the Open Source ecosystem / dev home lib sbin tmp usr var Directory Contents bin Commands dev Device Files etc Configuration files home User Home Directories lib Libraries pkgs Package files / commands sbin Privileged commands tmp Temporary files usr Utilities & Applications var Variable files
    [Show full text]
  • Static Analyses for Stratego Programs
    Static analyses for Stratego programs BSc project report June 30, 2011 Author name Vlad A. Vergu Author student number 1195549 Faculty Technical Informatics - ST track Company Delft Technical University Department Software Engineering Commission Ir. Bernard Sodoyer Dr. Eelco Visser 2 I Preface For the successful completion of their Bachelor of Science, students at the faculty of Computer Science of the Technical University of Delft are required to carry out a software engineering project. The present report is the conclusion of this Bachelor of Science project for the student Vlad A. Vergu. The project has been carried out within the Software Language Design and Engineering Group of the Computer Science faculty, under the direct supervision of Dr. Eelco Visser of the aforementioned department and Ir. Bernard Sodoyer. I would like to thank Dr. Eelco Visser for his past and ongoing involvment and support in my educational process and in particular for the many opportunities for interesting and challenging projects. I further want to thank Ir. Bernard Sodoyer for his support with this project and his patience with my sometimes unconvential way of working. Vlad Vergu Delft; June 30, 2011 II Summary Model driven software development is gaining momentum in the software engi- neering world. One approach to model driven software development is the design and development of domain-specific languages allowing programmers and users to spend more time on their core business and less on addressing non problem- specific issues. Language workbenches and support languages and compilers are necessary for supporting development of these domain-specific languages. One such workbench is the Spoofax Language Workbench.
    [Show full text]
  • Blossom: a Language Built to Grow
    Macalester College DigitalCommons@Macalester College Mathematics, Statistics, and Computer Science Honors Projects Mathematics, Statistics, and Computer Science 4-26-2016 Blossom: A Language Built to Grow Jeffrey Lyman Macalester College Follow this and additional works at: https://digitalcommons.macalester.edu/mathcs_honors Part of the Computer Sciences Commons, Mathematics Commons, and the Statistics and Probability Commons Recommended Citation Lyman, Jeffrey, "Blossom: A Language Built to Grow" (2016). Mathematics, Statistics, and Computer Science Honors Projects. 45. https://digitalcommons.macalester.edu/mathcs_honors/45 This Honors Project - Open Access is brought to you for free and open access by the Mathematics, Statistics, and Computer Science at DigitalCommons@Macalester College. It has been accepted for inclusion in Mathematics, Statistics, and Computer Science Honors Projects by an authorized administrator of DigitalCommons@Macalester College. For more information, please contact [email protected]. In Memory of Daniel Schanus Macalester College Department of Mathematics, Statistics, and Computer Science Blossom A Language Built to Grow Jeffrey Lyman April 26, 2016 Advisor Libby Shoop Readers Paul Cantrell, Brett Jackson, Libby Shoop Contents 1 Introduction 4 1.1 Blossom . .4 2 Theoretic Basis 6 2.1 The Potential of Types . .6 2.2 Type basics . .6 2.3 Subtyping . .7 2.4 Duck Typing . .8 2.5 Hindley Milner Typing . .9 2.6 Typeclasses . 10 2.7 Type Level Operators . 11 2.8 Dependent types . 11 2.9 Hoare Types . 12 2.10 Success Types . 13 2.11 Gradual Typing . 14 2.12 Synthesis . 14 3 Language Description 16 3.1 Design goals . 16 3.2 Type System . 17 3.3 Hello World .
    [Show full text]
  • Webassembly: High Speed at Low Cost for Everyone
    WebAssembly: high speed at low cost for everyone Andreas Rossberg Google [email protected] Abstract instructions that are widely available on modern CPUs. They map WebAssembly is a new language- and platform-independent bi- to machine code in a predictable manner and with predictable nary code format bringing native-code performance to the web. We performance on all relevant platforms. present its design and report our experience with specifying its se- High-level Data Flow. WebAssembly is an expression language: mantics via a reference interpreter written in OCaml, that currently it is defined as an AST in which machine operators return values serves as a proxy for a future formal specification. and can be used as operands to other operators. The binary format is a post-order serialisation of this AST. This design provides for 1. Introduction more compact binaries than 3-address code or SSA form would. Like it or not, the Web has become one of the most important Low-level Control Flow. Control flow is available mainly in the platforms for application development. Yet there is only one pro- form of sequential blocks and branch instructions, plus a structured gramming language that the Web understands: JavaScript. Liter- conditional. However, branches are still structured: they can only ally hundreds of compilers have been written that translate almost break out of an expression, not jump into one. This prevents ir- every imaginable language into JavaScript in order to run on the reducible control flow and associated complications (it’s the pro- Web [1]. Unfortunately, JavaScript is not the most delightful com- ducers’ responsibility to transform irreducible control flow into pilation target: it’s brittle and often slow in unpredictable ways, all structured form [6]).
    [Show full text]
  • Archive and Compressed [Edit]
    Archive and compressed [edit] Main article: List of archive formats • .?Q? – files compressed by the SQ program • 7z – 7-Zip compressed file • AAC – Advanced Audio Coding • ace – ACE compressed file • ALZ – ALZip compressed file • APK – Applications installable on Android • AT3 – Sony's UMD Data compression • .bke – BackupEarth.com Data compression • ARC • ARJ – ARJ compressed file • BA – Scifer Archive (.ba), Scifer External Archive Type • big – Special file compression format used by Electronic Arts for compressing the data for many of EA's games • BIK (.bik) – Bink Video file. A video compression system developed by RAD Game Tools • BKF (.bkf) – Microsoft backup created by NTBACKUP.EXE • bzip2 – (.bz2) • bld - Skyscraper Simulator Building • c4 – JEDMICS image files, a DOD system • cab – Microsoft Cabinet • cals – JEDMICS image files, a DOD system • cpt/sea – Compact Pro (Macintosh) • DAA – Closed-format, Windows-only compressed disk image • deb – Debian Linux install package • DMG – an Apple compressed/encrypted format • DDZ – a file which can only be used by the "daydreamer engine" created by "fever-dreamer", a program similar to RAGS, it's mainly used to make somewhat short games. • DPE – Package of AVE documents made with Aquafadas digital publishing tools. • EEA – An encrypted CAB, ostensibly for protecting email attachments • .egg – Alzip Egg Edition compressed file • EGT (.egt) – EGT Universal Document also used to create compressed cabinet files replaces .ecab • ECAB (.ECAB, .ezip) – EGT Compressed Folder used in advanced systems to compress entire system folders, replaced by EGT Universal Document • ESS (.ess) – EGT SmartSense File, detects files compressed using the EGT compression system. • GHO (.gho, .ghs) – Norton Ghost • gzip (.gz) – Compressed file • IPG (.ipg) – Format in which Apple Inc.
    [Show full text]
  • Why I Was Wrong About Typescript TJ Vantoll
    Why I Was Wrong About TypeScript TJ VanToll TypeScript TypeScript TypeScript Why I Was Wrong About TypeScript Whether TypeScript is a good fit for your next project Why I Was Wrong About TypeScript “A typed superset of JavaScript that compiles to plain JavaScript” “A typed superset of JavaScript that compiles to plain JavaScript” !" # $ Compile to JavaScript tools • There are a lot. • 345 • Source: https://github.com/jashkenas/coffeescript/wiki/List-of- languages-that-compile-to-JS • Ruby, Python, Erlang, Java, Scala, C#, F#, Lisp, Scheme, Haskell, Smalltalk, C, C++, Basic, Go, PHP, and way more. Fun names of compile-to-JS tools • treehugger • jangaroo • Waterbear http://waterbearlang.com/ Compile to JavaScript tools • There are a lot. • 345 • Source: https://github.com/jashkenas/coffeescript/wiki/List-of- languages-that-compile-to-JS • Ruby, Python, Erlang, Java, Scala, C#, F#, Lisp, Scheme, Haskell, Smalltalk, C, C++, Basic, Go, PHP, and way more. Why I Was Wrong About TypeScript % “We risk a lot by building our core on top of TypeScript.” “I don’t hear anyone talking about TypeScript.” “I like to keep my JavaScript pure, as God intended.” Why I Was Wrong About TypeScript Why? 3 reasons 1) Commitment to the ECMAScript standard “Some examples [of compile-to-JavaScript frameworks], like Dart, portend that JavaScript has fundamental flaws and to support these scenarios requires a “clean break” from JavaScript in both syntax and runtime. We disagree with this point of view. We believe that with committee participant focus, the standards runtime can be expanded and the syntactic features necessary to support JavaScript at scale can be built upon the existing JavaScript standard.” 2) Types are opt-in 3) Tooling So should you use TypeScript? • Are your apps big? • Do you work on a team? • Unfamiliar codebases? • Non JS developers that need to write JS code? Thanks! @tjvantoll http://bit.ly/DR2017-vantoll.
    [Show full text]