Typescript projects definitely give me the most pain. You regularly end up to the point you have to resort to 'any' after hours of looking for a stupid type definition. IMAO it's just one big waste of time, just landed a job with a good old JS codebase, what a relief. TS might help for junior and medior developers so they make less mistakes. But I'm pretty sure if you can code Javascript well Typescript only stands in your way when you want to create something. Imagine you give a painter a brush that doesn't allow to be used freely, that's what TS does to a good JS developer.
But TS is at this moment really eating JS jobs, and that kinda hurts. I just don't understand the proponents, besides the job opportunity, give me one single reason to write in TS? If you want to go for a strictly typed language TS is definitely the worse choice. TS simply doesn't fit in the JS ecosystem. Look at (a part of) the dependency part of this package.json, from the beginning of a large project. Don't you agree something is going very wrong in the JS world?
> But I'm pretty sure if you can code Javascript well Typescript only stands in your way when you want to create something.
You and the author are both overly concerned about writing code and completely ignoring maintainability. If you write your code once and never touch it again, sure, use plain JS. If you're going to come back in six months month and refactor it or hand it off to a co-worker and expect him to write some code TypeScript is a godsend.
you mean Python and Ruby like languages are unmaintainable and therefore deprecated? I rarely have a problem with maintainability in JS because of types, but I do have problems with poor constructs, poor readability, dependency issues and so on. It's a typical illusion of TS proponents that code becomes magically maintainable.
JS developers moving to TS should at least do a few weeks of Assembly and C programming to first understand the origin of types. I've spoken too many front-end devs who don't have a clue what a type actually is and at the same time promote TS. It's a godsend we don't need them in scripting languages. Use tooling to catch issues, that's the future, TS is just a whim.
It's like using a bandage to prevent an injury. Yes it's good to have, but it doesn't prevent anyone from writing unmanageable code. Contrary it can make it even easier to write unmaintainable code.
You can say that about literally any technology. Nobody's claiming TypeScript will fix all your problems and discover all the secrets of the universe: it's just a useful tool that well outweighs the overhead it adds.
I just don't like having to look things up, or remember them, or tell someone else about them, or make sure the things I told them or that they told me are still true six months later, or check manually that I haven't typo'd a variable name, and so on and so on, when a machine can do those things for me.
The absolute worst case with TS is that I'm as bad off as I would be in JS (use "any", or "as", or provide a dummy anything-goes d.ts for a lib, or whatever). I haven't found that I actually need to do those things very often, even being fairly lazy and having a very low tolerance for time lost to managing my tools.
When dealing with binary packages I have to do stuff like iterating over an object to see what it exposes. I guess typings (if one exist) help a lot there. But for open source code you can just look in the source. Looking at other peoples source code is the best way to learn, so don't let TypeScript take that away for you. The projects with non-existing documentation is often the ones most easy to use. Maybe because the source code is so easy to understand that no documentation is needed :P
Most developers coming new to JS are Java and C# developers. They want to keep their old tools, and methods. And Microsoft want to keep selling it to them. Which is my main concern, once you're in you are locked in.
Why? I've worked on large codebases in Coffeescript, ES6 and Typescript. Whatever this whole community sings and believes, but Coffeescript still wins for me. ES6 is still trying to catch up but will probably never reach the beauty and ease of Coffeescript. Both are transpilers, only ES6 with Babel is a total horror to manage (just upgraded a large codebase to Babel 7..).
Typescript takes about 2x the time to write if you want to create all your typings properly. I hear you say; only in the beginning, later it will speed up the development process. I've never seen that in reality! I've actually never seen a proper codebase in Typescript. Show me a Typescript codebase not using the type 'any'! In a decent system language you can't get away with that, it's just a fake sense of security.
A good codebase should not be dependant at all by Typescript or whatever hype comes next. Writing a good codebase is IMHO a craft and should not depend on the language or a bunch of tooling. If Typescript is way to go, what about Python, Ruby, abandon it, deprecated? Are those inferior languages compared to Typescript? Typescript is just another hype, very smart play by Microsoft btw.
> Typescript takes about 2x the time to write if you want to create all your typings properly.
Not true at all. You balance all of this stuff inside your head anyways: this object has this shape, this function takes these arguments, etc. The only overhead is actually writing them down -- which in itself arguably speeds up development because then your IDE knows about them too.
I pushed back migrating from Coffeescript to TypeScript and I consider it one of the only times I was really wrong about a front-end technology.
> I've actually never seen a proper codebase in Typescript.
That's the problem then. I have, and have clearly seen in the real world why it's superior. ES6/Coffeescript can obviously be done correctly, but chaos tends to ensue as the flexibility is abused. Over time it makes debugging/understanding difficult. TypeScript makes changing/navigating large codebases a breeze. In other words, it's much easier to do correctly than ES6/Coffeescript.
There are multiple benefits from having TypeScript a clear winner.
1. One standard typed version of JS (As appose to flow and TypeScript) is a better use of open-source developer time. It also reduces decision fatigue when architecturing new JS projects.
2. TypeScript tooling is fantastic. Using VSCode or Webstorm spoils you.
3. TypeScript is a testing ground for experimental language features. It can shape the direction of future versions of JS.
4. Finally, the language is clearly well liked, in addition to being popular. We can debate the pros and cons of its quirks, but overall, the stats say developer satisfaction is high. https://hub.packtpub.com/4-key-findings-from-the-state-of-ja...
> ES6 is still trying to catch up but will probably never reach the beauty and ease of Coffeescript. Both are transpilers, only ES6 with Babel is a total horror to manage (just upgraded a large codebase to Babel 7..).
...
> Both are transpilers
You don't have to transpile es6 if you don't want older browser support.
> Show me a Typescript codebase not using the type 'any'! In a decent system language you can't get away with that, it's just a fake sense of security.
I don't know the comparison to system languages is fair though, because the use-case for JS is quite different from system languages.
Javascript (and by extension, Typescript) is commonly used to interface between the user and the network, both of which often are outside the bounds of the type system. Add to that any code that interfaces with plain JS, such as external libraries or legacy code. When dealing with those, it's natural to use statically untyped values and type ascriptions based on reasonable assumptions.
Taking that into account, I actually think Typescript's type system is fairly well-designed for the use-case. The problem isn't really with Typescript, it's just intrinsic to the use-case of JS.
Exactly. Even strongly-typed languages have this problem. In C, it looks like `void *`, while in Java, it's `Object`. The `any` keyword is just the latest in a long line of escape hatches. Pretty much every language has one.
> Show me a Typescript codebase not using the type 'any'!
Show me a Java project without an unchecked cast... I’m not a CS person but my impression is that sometimes you need these types and they exist in the type system for a reason. No type system is conceptually “perfect” as in there are soundness/expressively tradeoffs. I don’t think using ‘any’ is always bad. Sometimes it’s even right?
Haskell's type system still isn't sound. It just elimates that particular class of errors.
A lack of soundness is closely related to the Turing completeness, especially in languages based on HM. In an ideal world you would want a sound type system and not want Turing completeness, but the tooling doesn't exist to make those choices the most pragmatic right now.
Well, I mean, you can write perfectly sound programs in Java as well, or in TS. It's rather a question of how hard/easy it is to do so. Technically, any language that has either direct memory manipulation or FFI has the potential to do unsound things about types, but it takes a lot more effort.
> Writing a good codebase is IMHO a craft and should not depend on the language or a bunch of tooling.
Of course, relative to other code in that language you can write good code in any language and that is a useful and important skill. If you invest enough energy and craft, you can even write code that compares favorably to good code in any language - the Linux code base is a testament to that. Still, it is a fallacy to assume that all languages are created equal. Nowadays, next to nobody would argue that writing code in Assembler is a good idea. And even though it is now possible to write web apps with C (via webassembly) there is no movement by seasoned C programmers to conquer the web.
> If Typescript is way to go, what about Python, Ruby, abandon it, deprecated? Are those inferior languages compared to Typescript? Typescript is just another hype, very smart play by Microsoft btw.
While the truism "use the right tool for the job" is overrated, it applies here. Untyped, quick to write languages are excellent for small projects. When I'm writing Python as glue code, designing nicely typed interfaces is a distraction. Also, Python, Ruby and Javascript have base types with excellent usability. E.g. when you parse time sheet data, it is pleasant to return [(time.parse('9:00'), 'document project X'), (time.parse('10:15'), 'implement feature Y')]. But when projects grow every structure enforced by the language is a guarantee I cherish. You know, there is this special case in your time sheet parser where you return a (time.parse('23:59'), Null) element, instead of using the empty string, which made the code much more elegant. But months later, when you are refactoring the code calling the parser, you have totally forgotten this behavior and introduce a subtle bug. That's the time where I wish I had a robust type system.
TypeScript is great in this regard, as you can ignore all types if you wish and gradually add them later, when the complexity of the code base calls for it. Or you start with complete type coverage from the start if that floats your boat. Or you never introduce types and just consume JavaScript. Because of that, TypeScript is especially valuable for libraries: It gives the consumers of the libraries all choices. And it's also the reason the success of TypeScript is celebrated that much: Each new TypeScript enhanced library increases the effectiveness of the tool (and reduces the amount of `any` crutches).
Admittedly Flow, not TypeScript -- but 99% the same thing syntax-wise. And yes -- it was difficult to set up and get working comprehensively, but now it's there, it's fairly easy to maintain, and it's invaluable when refactoring, accepting PRs, or adding new features.
Most people using `any` should really be using `mixed` (flow) or `unknown` (ts) which at least force you to check before you use some property of those types.
Do you have any experience with static typed languages? All the benefits brought by static typing become obvious & make sense when you actually get to use it.
Also, I'm sorry but you make some weird comparisons. ES6, Coffeescript, TypeScript and Python/Ruby are 4 completely different things. Not sure why you are trying to compare them and choose a winner.
I'm reading this because I'm about to move back to systems programming after a 6 year journey into Javascript Nodejs full-stack developement.
Don't underestimate the pile of garbage JS indeed is! Yes, you can install a package with ease, you'll have to do that with about 100 packages that keep changing all the time with all kinds of breaking changes (not talking about their 1000's of dependencies). I'm also sick and tired of the hipster JS community where every piece of shit can become a hype. With JS you'll be forced to work with things you hate. Almost all codebases I have to work with are horrendous piles of rubbish that often need to be completely rewritten from scratch. Almost everything you write doesn't last. You've spent a year learning Backbone? Just throw it away, now it's Angular you can start all over again. One year later? Stop doing Angular, it's React now, just start all over again! Hey, now we have some hipsters promoting Vue, they say it's the holy grail, just start all over again, it's fun! Flux stores? Fluxxor, Alt, Redux, Redux with Saga's, or just go with Thunk? It doesn't matter that much, it only lasts for 1 or 2 years! I'm completely sick and tired of it, including the fact that I'm only working on stupid e-commerce websites..
Talking about make files, a magnitude easier than trying to setup babel and webpack for a medium sized SSR SPA. I recently had to upgrade from babel 6 to 7, what a fuckin pain that was, so many changes, the deployment server refused to boot etc, etc..
I'm not too worried about the constant "framework hype". Although there are many frameworks, React is a solid option that remains relatively dominant. Yes, others exist like Vue and Angular--but I can be pretty confident that React isn't leaving anytime soon.
Similarly, with C++ there are also many packages to do the same thing. This summer I was using TLS and I found a variety of options, OpenSSL, mbedTLS, wolfSSL, etc. etc.
I do agree that it is tiring to learn some of React's accessories. I have never used Redux and when I do need some form of global state management, I think I will use MobX.
The complaints about code base quality and "stupid e-commerce websites" don't seem to be problems inherent to Javascript, although I suspect the problems Javascript solves are less interesting than the ones C++ solves.
All in all, I feel like C++ (for me) has been more difficult than Javascript due to a lack of standardization and the community being less beginner friendly.
That being said, I was trying to use a relative obscure feature (SGX) in C++, whereas with Javascript I stick to relatively mainstream applications.
Unfortunately in the JS community you cannot say these things without being punished. If you do anything else than strict eslint with "airbnb settings", or default prettier settings, your head goes off! Don't ever say this to your JS team mate. It's a very rigid community if it comes to these futilities.
This is... puzzling. Where do you see these attitudes? Both ways are perfectly cromulent and it's fine for people to have opinions.
In my years of JS dev the main thing I've seen from the community is "pick a style and stick to it. Be consistent." And that's pretty typical and sage advice of all programming.
The reason to downvote parent is that it's bringing up a tired debate. We may as well discuss tabs vs. spaces while we're at it.
If I remember correctly it used to be the case that every JavaScript repo came with it's own eccentric style. I'm certainly guilty of that. Now -- when we have these style "standard" style guides -- we've sort of settled on 3 or 4 competing standards. None of them look particularly bad (or at least not worse then my personal style cerca 2012).
Don't get me wrong. We still engage in stupid bikeshedding about semi vs. no semi, tabs vs. spaces etc. but I feel overall we've embiggened our spirit when it comes to code style debates.
No, you’re free to talk about whatever you want. But don’t expect pointless bikeshedding to be well-received.
First, it’s not a real problem. The JS community is pretty much equivalent to any other of this matter.
Second, it’s not a big issue. Use a code formatter to make sure shared code is in the agreed style for whatever project you are contributing to.
Third, this does not affect your own code. You are free and encouraged to use whatever formatting convention works for your own teams. Just make sure it’s consistent and enforced.
Keeping consistent style is anything but a “silly rule” and it’s essentially no effort.
It is a real problem, I've seen heated discussions in a few companies, and it can take out a big part of the fun you have in your work.
We really need to write an editor plugin/solution for this. Your editor should show the code in your preferred style, but saving it in the team's agreed style. And then a local-style.js for your own settings, and a team-style.js for the team settings. local-style.js in the .gitignore. Should be possible though?
It'd be possible but it's a non-trivial amount of work: think about things like linting or debuggers where line numbers might vary substantially, sequencing things in tools around merges and code review, etc.
The option you can do right now is to use something like Prettier where everyone's experience is entirely consistent and you have no cognitive load switching styles or dealing with inconsistency. This is basically free and means that there's a whole slew of high-emotion discussions which you can stop having for the rest of your career, in favor of working on things which actually matter. The older I get, the more that looks like pure win.
But TS is at this moment really eating JS jobs, and that kinda hurts. I just don't understand the proponents, besides the job opportunity, give me one single reason to write in TS? If you want to go for a strictly typed language TS is definitely the worse choice. TS simply doesn't fit in the JS ecosystem. Look at (a part of) the dependency part of this package.json, from the beginning of a large project. Don't you agree something is going very wrong in the JS world?