Out of the loop

One hundred percent this. It reeks of the kind of ego you get from devs that think their code is so perfect it's inherently easily maintainable.

I know junior devs that don't struggle with types and unit testing—any dev that thinks they're too good for either is immediately sub-junior in my assessment, because they're clearly unable to write code intended to be maintained by a team.

Lmao I’ve literally had conversations with people who have asked me to not be as rigorous with unit tests because you have to change some tests when you make a modification to the business logic.

Bro: that’s the fucking point.

Can't be a 10x developer if you keep spending your time writing unit tests.

I hate it's syntax. I have no problem with typed languaged like java and c#

People use rockstar in production?

https://codewithrockstar.com/

I love unit tests but I hate the eternal struggle behind them.

We should make unit tests so we can tell when the build runs that the app is going to be consistent

Everyone cheers

We lose a sprint setting up unit tests

Oh this one test just went yellow, somebody spends a few hours figuring it out and finds that it's a bug in the unit test. No no we're good That's just a bug in the unit test we'll plan to fix that in the next Sprint.

Oh look now this unit test is going red we're blocked. 2 hours later they find out that it's a real problem but it's not so bad that it overrides current feature work. Well we're going to need to override that and we'll have to fix it in the next sprint.

Unit test failures slowly degrade in priority to try to get feature work done. You end up with a backlog full of yellow and red known problems and no one pays any attention to you that tests anymore.

I think it’s more of a JSDoc > TS thing. I need to check the drama, but I don’t believe anyone would want to write vanilla JS without some type declarations..

Honestly I'm surprised Microsoft isn't pushing for that already. They already have a decently popular browser (Edge), they own TS, and they have a history with not giving a shit about standards (IE and ActiveX).

I don't know, those language are more difficult than Javascript. What makes FE difficult are the libraries and frameworks, and the artistic aspect of the whole thing.

For your Go code to be useful, you've got to set up the Go compiler right?

As much as I wouldn't recommend it, you can even install the typescript compiler via an OS package manager (at least in most Debian distributions)

At that point (and once you've added it to your makefile, or however else you're triggering your go build), surely then there's zero additional moving parts needed to compile your front end vs your backend?

Not least of all, I'd argue having a compiler tell me I messed up immediately is a bonus too vs poking around for some time until I get an error in the JS console

You are making a lot of false assumptions about typescript and bringing in a lot of outside problems that don't have anything to do with the language. Try working with typescript. It is a strict super set of javascript. So if you like vanilla JS, you can just keep writing it, then slowly introduce the syntactic sugar that typescript provides. I did the javascript and coffee script thing for a long while, and typescript is just the better way for most use cases at this point.

To be fair, I've never written frontend. No doubt the problems there are a bit different.

I usually write Typescript with Vue and SSR so my server and client are using the same tooling. If I was writing a basic frontend with minimal JavaScript I would just (and have) use jsdoc for typing.

But let's be fair, what you mentioned as dependencies are development dependencies and don't impact the end user (outside of poorly optimized build systems causing issues). Build systems can have some great benefits. Such as reducing file size by utilizing methods such as tree shaking to prune out the unused classes in a CSS library.

It just comes down to choosing the tools to suit the job. Sure, you can use a table saw to cut a stick but it's probably easier just to use a handsaw. Whereas if you're cutting a large plywood board you could make do with a handsaw but it'll take longer and the result might not be pretty.

I haven’t need any

need any

any

How even dare you. PR denied.

Same, but I come from a C++ background so strong typing is in my blood. This sounds like people who write bad code complaining because the language/transpiler won’t let them write bad code.

I don't do java- or typescript but that guy's comment definitely translates as "I want to keep on writing messy code and you can't force me to learn to clean my shit up".

I've heard it's more of a problem on the library side. But I've personally had pains with ts when working with quirky features such as enums or discriminating unions. Part of the problem in my opinion is that the types all disappear at runtime, so you lose a lot of the joy of a statically typed language. For example, an API can pass you unexpected garbage and all your ts type wrangling helps not at all.

They just say the typing is too much and JSDoc is good enough for them as they get intellisense from it.

Svelte, Turbo and a few others I think.

It's more for library devs when writing their libraries. Using TS means you're writing in one language and then distributing the compiled version for users.

As users can use things in a lot of different ways you have to do a lot of type "gymnastics" to make your library API as useful as possible.

That means spending a lot of time setting up types when a jsdoc and .d.ts file will do the same thing for library consumers.

It's really a non issue. If some library devs think they can ship code which is easier for them to maintain correctly, and end users have the same developer experience, then it's totally cool.

Of course people with no nuance are using this as an argument for why no one should write in typescript (because they don't like it for some reason). This thread has a bunch of people doing this. That creates drama, but there really shouldn't be any. TS is bae for me, but I totally get why library devs might want to not use it.

I understand why some hobbyist individuals with small-ish scripts might not see the value, even though I even still disagree there.

The more code and people touching the code, the more value you'll see.

Thanks :) I didn't see anyone mention the points made by the svelte guys https://news.ycombinator.com/item?id=35892250 which is a shame since I thought they made better points than the dramatic "type gymnastics" argument haha (i am biased toward type-safety, as long as there is idiomatic, algebraic data types w/ pattern matching)

Overall it sounds like a major change with a few minor/moderate benefits, but it's their choice and time will tell if it was worth it :P