I get the question, “Karl, why do you use ES2015 (ES6)?”
The answer I give depends on the context of the question, in other words what is the scenario we are asking about.
I will answer the question for each of these scenarios:
- Authoring Large Line of Business Application with more than a few developers
- Authoring a small application with one or a few developers
Why, because I can transpile to ES2015 or ES5, so I can deliver my framework in Typescript, ES2015, or ES5.
Several years from now, I’ll be able to transpile my framework to ES vNext (as long as Typescript is still around and maintained properly), effectively future proofing my code.
I don’t have the hassle of 3rd party .d.ts files that are old or incomplete because my framework probably does not have many 3rd party dependencies.
If my framework does have them, I have the resources to create the required .d.ts files. I’ll pay this tax because the benefits outweigh the .d.ts file hassles.
Authoring Large Line of Business Application with More Than a Few Developers
Without equivocation I would use Typescript for building a large line of business application with more than a few developers.
Why, because I can leverage the compile time checking, strong typing, and interfaces that Typescript offers; additionally I would use a linter with very strict rules.
Second, because Typescript does perform strong type checking at compile time.
Back all this up with unit and integration tests, and you have the basis for a very successful large line of business application.
Authoring a Small Application with One or a Few Developers
Here is where my answer to the original question changes from Typescript to ES2015.
For all of my personnel projects and blog post projects, I’ll use ES2015 (ES6).
For small team projects, I would still like to use ES2015.
- Because I write very clean ES2015 that is very easy to read
- Because I use a ES6 linter with very strict rules, helps keep my ES6 clean and I’ve learned a lot from the linter rules I violated
- Because I don’t want to pay the 15% tax for authoring Typescript (adding the type definitions to the code, getting the .d.ts files downloaded, and imported in the code. This 15% does not count towards missing or incorrect .d.ts files.)
- Because I don’t want to deal with 3rd party .d.ts files that are either out of date or missing – this can be a real bummer
- Because for a long time, basically a single developer was managing the Definitely Typed github repro. I look at it yesterday and it seems to have gotten a face lift and many new developers helping out.
- Because the tool Microsoft ships for creating .d.ts files does not render a .d.ts file that can be used, I always found myself having to add more code to them to get them to work.
- Just because you’re using a framework that was authored in Typescript, it does not mean you have to use Typescript.
Obviously, these are my opinions, and I know that others can easily come back with solutions or comments, but after many projects using Typescript this what I’ve decided to do.
All developers need to evaluate languages, tools, frameworks, and 3rd party dependencies for all of their projects, and pick the ones that meet the needs of that specific project.
Select the best tool for the job, not because the framework was written in, or because it’s new and shiny, or because other developers use it, select a tool because it is the best fit for the given requirements.
So if you ask me if I use Typescript or ES2015, my first question will be, what is the scenario or use case, then I can answer based on the above criteria.
Hope this helps someone and have a great day.
Just a grain of sand on the worlds beaches.