This comment in the Jest repository, https://github.com/facebook/jest/pull/7554#issuecomment-454358729, has been floating around on the Twitterverse the past few days and seems to be garnering a lot of attention.
The fact that a Facebook project is migrating to TypeScript (TS) is kind of big deal considering they're also behind Flow, a direct competitor of TS.
Other prominent JS devs have been chiming in as well. Some with a little more cursing, so apologies in advance. 😉
Is this the final nail in the coffin for Flow? Is it another year where TypeScript adoption continues to rise and it becomes the Year of TypeScript?
There's even a horse_ts Twitter account now. It's not too hard to guess who it is, but I still find it pretty funny.
"So if you’ve been a holdout (like me, to be honest), 2019 is definitely the year to learn TypeScript.", @kball quote from https://zendev.com/2019/01/15/frontend-development-topics-to-learn-in-2019.html
Share your thoughts in the comments below and feel free to shamelessly plug your TS posts, if you've written any on dev.to. I'll shamelessly plug first.
Photo by NordWood Themes on Unsplash
Latest comments (61)
Oh yes i write about my subjective ideas' and i hope to get other ideas back.
I would love to hear yours, but it seems you are all out.
I will call it a day, because we can agree on one thing at least.
This is boring and uninformative.
Nah, people just need to start making it a factor. ;)
I am sorry, but i don't see how adding complexity to a situation resolves things, and i think that is perfectly valid reasoning.
For now TS is just yet another tool in a long line of stuff i need to setup before i can press the go' button.
For the record, strongly typed OOP languages like C#, Java, and C++ are the exact reasons i do not like TS/js-class to begin with.
My code has always done' stuff, it never is' stuff on it's own.
So why bother with that?
You write very subjectively, throw some ideas at me.
Otherwise i wont have much of a take-away from this. :)
It is entirely possible to avoid most common down the line problems by keeping your codebase mutable, contrary to popular belief.
TS takes that mutability away by tying you to a language subset that requires extra tooling.
You can use all of those, what I am trying to say is don’t build your entire application around them.
You might want to change it later.
JavaScript is supported with no setup for almost all libraries, and run native in the browser.
Anything that adds complexity to that situation i would deem as a bad solution.
With TS, we are just shifting the work to someplace else and adding new problems for people to learn rather than solving the original issues.
Just published a TypeScript tutorial for beginners. Enjoy!
I think one of the wonderful things about Typescript is that it's an opt-in type system.
You can take the following JavaScript file (
app.js):And copy it into a Typescript file (
app.ts):And then compiled it with the Typescript compiler:
tsc app.tsNo changes were need to my JavaScript!
If I wanted to I could add just 1 type:
And everything still works!
Sure, Typescript code that you might see in an Angular application can have types everywhere and a bunch of strict compiler flags - but this is one side of the spectrum.
Typescript is happy and helpful anywhere along that spectrum.
Use
:any(or don't add an annotation at all - it's the same thing), leave the compiler options loose, and ease yourself into it.Then as the project grows in complexity, start flipping on compiler flags, add more types and see where your expectations of your code don't match reality.
If you just prefer no type information in your code, cool! Don't use Typescript :)
(JavaScript still has types, it's just weakly typed and doesn't require you to specify them)
But it's not an all or nothing thing - approach Typescript on your own terms and I think you'll find it enjoyable and interesting.
From Pete Hunt
This is like a TV advertisement, not a tech article.
I really hope not..
Typescript, has its usecases, but without native support it is almost pointless to me.
Too much setup.
The easier debugging is nice however.
My main gripe is problably that it tends to promote large corp style OOP with bajillions of pointless interfaces and classes.
Which in my experience leads to state soup and lack of code-mutability.
I tend to agree. I have to use it at work and I understand the arguments in favour; but to me it still feels like a ball-and-chain compared to vanilla JS. I do understand some of the benefits; but there are also some downsides:
privatereally means privateBut yes - mainly my problem is that it can encourage a classic OOP approach to coding when IMO one of the big strengths of JS is that it facilitates some really effective functional approaches.
For sure it can promote large corp style OOP. Perhaps, and I have no data for this, just my musings, is that Angular promoted this once they adopted TypeScript. DI, classes, decorators etc...
I've been using TypeScript in React and browser extensions and almost never use OOP. The only time I've really used classes in React was for components that required state. Aside from that rarely, and now that hooks are stable and able, function components would be the way to go for new work.
Having said that, OOP is not a bad thing. Just like anything, people can do bad things 😉
I am mostly against OOP, for a number of reasons that would longwinded and off topic. :)
I my world, the TS gains do not outweigh the layers of complexity added to all parts of the developing process from developer skills to the libraries and build systems we use today.
It is unnecessary for most things, so why bother with it?
I don't think Typescript does anything more OOP than JavaScript (ES2015+) does, besides Interfaces (which also appear in functional languages).
Typescript supports all the same functional concepts that JavaScript does, including being able to type higher-order functions. It also includes other functional concepts that aren't in JavaScript, like union types, or even better, discriminated unions.
I am talking about complexity, and the way I see the language generally used in practice.
TS has more features, that is the entire point of the language.
Exampletime,
Just yesterday I was debugging a TS npm library, all I wanted was add to poke the source with a few console logs.
But because it was a TS library it came in 5 different ES versions, had a slew of typings I had to see through, and the actual source was not included because npm is for JS.
This would have forced me to get the source code, hook it up to my npm dependencies and then build it with my few debug changes.
Is there a better way to debug, problably yes, I could have explored the map in the browser and addd breakpoints, or use some other tool.
Had this been a JS library I would have spend a few minutes looking over the source.
Now, imagine a junior wanting to do this.
Complexity comes at cost, it is the entire point of functional programming, but centered around the problem of state management.
Toting TS as a good tool for functional programming is like saying eating children is a good way to prevent hunger.
It overlooks the actual problem.
Yeah, that all makes sense. It's definitely a different workflow.
I'm used to other languages that don't ship source code in packages, so this is nothing new to me.
Npm package authors could include source if they wanted - so the lack of it seems more like a personal choice on the part of the author.
Also, the issues you noted about all the transpiled variations of JavaScript for that Typescript authored lib ... those appear with JavaScript libraries too!
If a js lib author uses Babel to support older versions of Node or browsers, they will include transpiled versions of their js code.
This seems to be more an issue of the JavaScript tooling ecosystem still needing to mature.
In .NET/C# I can make a package that has compiled code only, but includes a hash to a git commit. When I'm debugging, my IDE pulls the repo code down to my machine and lets me debug into it live. It's a great developer experience.
I think the JavaScript community will come up with similar creative solutions.
Lack of tools is not really the problem, quite the opposite the way I see it.
Tools should make us more productive, not be a nessesary thing to be productive at all.
The fact that we are even talking about solving the problem with more IDE tools suggests a flaw in the system.
We need something that will reduce complexity at this point. Otherwise the frontend community will end up fragmenting into completely unessesary domains of knowledge based on frameworks and what kind of transpilation we do.
More so than it already has.
Came across this today. I rarely use classes myself, but I thought this was pertinent to the convo.
And I love the new VueJs 3 functional component API RFC.
Functional + Types = 💗.
It looks like even yarn is migrating to TypeScript.
If only TypeScript finally had newtypes.
At least in the form of
flow's Opaque type aliases.TypeScript is the one reason that made me start writing Frontend code as a Backend developer.
2019 is going to be a year of typescript for me for sure. It was a growing interest throughout 2018 (along with testing) and I finally might get a proper project in TS. My hopes are for higher code quality and predictability, and for the benefits of code editor suggestions :)
@swyx 😉