Hey, it's 2023.

If your component isn't written in TypeScript, I'm not using it :)

"TypeScript is overly complicated!!!" why, because it pointed out everything wrong in your JS code?

"TypeScript is not flexible!!!" why, because it makes you not rely on fragile "only possible in javascript" patterns?

"TypeScript isn't needed!!!" why, because you've never worked on a project with more than 100 lines of code where dependency management and clean code policies were implemented?

god just stop with the JavaScript purist BS, you aren't going to win this battle, and it's even worse because not only are you injuring everyone in the software community, you're injuring your own productivity and skillset

actually, you know what, fine. just use pure JS and HTML implementations. see you in 10 years when i'm retired and you are still running around in circles wondering why the world has left you behind

I made it a new years resolution that every future javascript project (or javascript component) is written in typescript and fully modular using webpack.

Reminded me of this:
https://devrant.com/rants/4141724/...

Nahh, I avoid web development altogether.

@nikolatesla we have at least static typed backend with Golang, Java and C# :)

yes, it's 2023

WASM exists.

Fuck ECMAScript and TypeScript altogether.

I know a effing 10/10 developer who just didn't bother with typescript. Put him in a team, he probably won't work well. But solo'ing he produced a work of art, that would take years for someone else for what took him 2 months.. I guess that's called mastering your craft.

@thebiochemic good luck making WASM-rendered canvas UI accessible to screen readers bro

sorry bro, but JavaScript is forever, and in 10 years you tell me to wait it will replace whatever native BS you're using now. M1 already has dedicated JS hardware. AMD and Intel will follow the trend.

This thread right now is giving me....feelings.

I hope it doesn't awaken anything inside me!

Lemme get this straight...

...we were given a super-flexible language... but now you're saying it's TOO flexible for our own good..

...and because we have a bunch of shit-ass developers with no attention-to-detail and self-discipline, the only choice is to make the language LESS flexible to cover for their inability to do their job right? Instead of fixing the flaws in ourselves, we gotta foist additional build steps, config files and needless complexity onto EVERYONE, slow everything down, and make it so that the code we write is no longer the code that actually executes in the runtime? ('cause what could possibly go wrong with that?!)

I'm not saying TS doesn't have benefits and you shouldn't ever use it, but let's not fool ourselves: it doesn't exist because JS sucks, it exists because DEVELOPERS suck and can't be trusted to do things right on their own. We're covering for peoples' shortcomings - shortcomings WHICH STILL EXIST with TS in the picture.

JavaScript seems to work just fine for my uses. I've never felt the need for a type enforcement system. I've also almost never been bitten by unexpected type bugs - and the few times I have, the answer was soon found.

I'm using it mostly for in-house web utilities, command line tools, servers and automation related stuff though.

I suppose if TS was somehow natively supported by the browser and/or nodejs, I'd have more interest. I just don't like that I can't have a spur-of-the-moment idea and test it in F12.

From what I've seen, it works better for really large scale projects being worked on by many people.

Trying to use it for small projects feels like drinking water out of a coffee mug.

*creator of JavaScript sees Java*

"I like that, but what if it didn't have types?"

*creator of TypeScript sees JavaScript*

"I like that, but what if it had types?"

We've come full circle 😂

@fullstackclown, you can have both: write your code in JS and provide an index.d.ts :)

@kiki Yew and Blazor both render HTML without any JavaScript user code.

@kiki I don't actually mind JS being some kind of interop standard, a lot of situations work well with its dynamic approach to data and interfaces. I just wish it supported type annotations so that engines could start optimizing code based on them. So many existing optimizations could become way more powerful if they verified provided types rather than trying to infer implied ones. It would make JS a decent compile target.

I can't remember the last time I wrote plain typeless JS. Even my ad-hoc scripts run on ts-node. My demonstrative HTML scratchpads reference the adapter script.

Occasionally I find a task where I can't imagine how setting up Typescript could pay off, then I work on it for 15 minutes and realize that this would've taken 5 if I had intellisense.

@lorentz you’re right. You’re right.

@webketje That's the worst way, nobody maintains that. Its kinda like tech documentation nobody wants to bother.

@lorentz typescript seems quite capable in handling data like heterogeneous arrays, unions, template literals, conditional types, so on. I'd say it's even more flexible that most languages type system.

See rollup: it can generate an index.d.ts for you. Though I'm still not sure why you would want to produce one if the project itself is written in pure JS 🥴

@jassole don't overgeneralize. All the NPM packages under the @types org are maintained this way and it works.

As a maintainer who recognizes the popularity and importance of TS without necessarily preferring it I find this an excellent compromise. Should there be an overlooked TS bug, I can always produce a quick patch release

If the equivalent amount of effort that was put in TS was put into JSdoc (including editor intellisense & validation), I would honestly not even bother with TS

@webketje Yet, they break quite often due to impedance mismatch and you're looking into 2 places why your code doesn't work or compile.

Sure JSDoc is better that declaration files, but why not use javascript-compatible typescript....?

@JS-Guy - Trying to use it for small projects feels like drinking water out of a coffee mug.

- it does taste different from the mug, but in the end it is the same thing! Great analogy!

@BixelPitch - I am genuinely curious - where do you deploy deno (when not using docker)?

@BixelPitch - thanks for the answer. I agree that docker is easiest way to ship it!