Except I fucking hate using Typescript, and totally wasn't expecting to see you mention you like it, given all the other stuff.
IME all the same people that overengineer everything with god awful dependencies are the same ones pushing super hard for typescript on every project I'm on. When they get their way (as always, since everything is decided democratically and everyone is dragged down to the level of the worst dev on the team), they write the worst typescript ever. On my last project, one of the people championing typescript defined some constant strings containing css breakpoints as the type 'string | int'. Rather than getting knocked back as one of the dumbest lines of code in the history of front-end, this somehow generated 3 pages of discussion in code review then got left in. I'd give the person a pass, assuming they'd never used a typed language before, except (a) they were senior and (b) they're the one that wanted types. These "seniors" lack even the most basic understanding of the shit they're using, but feel the need to impose their opinions about libraries, tooling and languages constantly.
I don't feel like I'd mind using TS at all on my personal projects, but on work projects with average devs it just adds another entire layer of complexity that they spend hours and days and weeks and months wrangling with instead of writing any code that might be remotely useful, by say, maybe implementing a business requirement, or doing anything that makes the company money instead of pissing away millions in salaries playing npm lego.
Plus, although I'm not familiar with any of it since I'm never the one pushing for TS, and so never the one setting it up, I've seen people spend absolutely ludicrous amounts of time tinkering with webpack and fussing over TS integration with 3rd party libraries and whatnot.
I'm surprised you haven't run into more of these people that just seem to use TS as a complexity multiplier for every bad engineering decision they make. Like spending 6 months setting up Gatsby or Next isn't costly enough for them, so they decide to tack on 3 months of TS integration and 'upskilling' for 3000 combo points, when they already (more or less, usually less) know how to write Javascript.
yeah this really is the fundamental problem with TypeScript advocates. They seem to come in two different breeds: A) people that would rather be doing Haskell but are forced to use JavaScript because that's where the jobs are and see nothing at all wrong with type inference and error messages that are 10 lines long and completely indecipherable by actual humans, and B) people that have never used a language that isn't JavaScript and have no clue how to structure type interfaces within an actual system (you end up with partial/omit and optional fields every-fucking-where and no rhyme or reason behind anything).
For some stupid reason this entire industry seems to suddenly believe that a 40+ year old debate of static vs. dynamic typing was settled because Microsoft came out with TypeScript.
I also used Haxe, which was a similar typed language, that compiles down to Javascript, and writing typed language for an untyped environment was an exercise in frustration.
It's almost like the React trend to write CSS in javascript. It separates the end result from the code even more, and doesn't really get you anything other than the typescript tax.
Maybe one day I will have that aha moment and get it, but the only real reason I see to learn Typescript is if the industry deems it essential to learn.
One of my favourite things about Javascript is how expressive you can be in it. Some of the new ES6 stuff helps with this too, but at the point when you write Typescript, you might as well be writing in a whole different language.
But naturally every typescript fan has a few stories about 'type-safety' saved their bacon, and no stories about how they struggled with defining types for callback functions or getting everything scaffolded for hours.
* structural instead of nominal types (i.e. if it walks like a duck and talks like a duck, it is a duck)
* mapped types let you transform object types into other object types: https://www.typescriptlang.org/docs/handbook/2/mapped-types....
* conditional types let you apply conditional type transformations, and combine with mapped types to provide the equivalent of for comprehensions https://www.typescriptlang.org/docs/handbook/2/conditional-t...
* template literal types let you generate dynamic string types on the fly, which you can use in various places including property names: https://www.typescriptlang.org/docs/handbook/2/template-lite...
and so on.
It does have a learning curve, and the tooling is annoying to set up.
I expect Template TypeScript and Liquid TypeScript are not far off.
My enthusiasm for it has died, and I enjoy just doing a plain old <script src="myfile.mjs"/> on my own projects.
> I'm surprised you haven't run into more of these people that just seem to use TS as a complexity multiplier for every bad engineering decision they make.
AngularJS claims to be TypeScript but most instances of Angular code rarely make use of type definitions, which then defeats the whole point of TypeScript and then only contributes to spaghetti and tech debt.
Configuring the compiler is now as complicated as selecting the right set of GHC compiler pragmas to successfully compile the code, and they are anyway type annotations that have zero impact in code performance, just a friendly than using JsDoc.
I look forward to when browsers just adopt WebIDL and be done with it.
Oh yeah, I feel this. The problem is many "seniors" went from junior->senior by being the big fish in a small pond (small startup + golfing buddies with the CTO) so they never had to question their own assumptions. Then they just glide from job to job at the senior level. It makes for monsters who can't differentiate their own personal preferences from industry best practices, and will attack your PRs if you go against either.
When I finished uni I had a few interviews for large enterprise-y companies to get into their graduate programs. None of those panned out. Then while I was looking for more things like that, one of my classmates asked if I wanted to interview to be employee #1 at the startup him and a non-technical friend had created.
They didn't have much funding, so it was ~45k (minimum wage or close to it in Australia) to start, as opposed to the grad programs that I think would have been around 55k-60k. But the job was basically building an entire fairly large and complex web app (as well as a bit of desktop and hardware related stuff) between the two of us, who had close to zero real world experience, my friend on the back-end and me on the front-end. So we basically just had all the responsibility, with no experience, and nobody to guide us.
From there I just hopped around a few jobs, looking for small places where I was the senior or second most senior person on the team. I learnt from the first job that the easiest way to learn is to be in a position where you have as much responsibility as possible so failure isn't really an option.
Things have improved a lot since 2009 however, IMO. There was barely a concept of modularity at that time, the tools (e.g. AMD / requirejs / r.js) were way worse and managing the state of the DOM was a pain, jQuery or otherwise.