Removing TypeScript - DHH | Prime Reacts 

lsp is very important tool

Turbo has a tiny public API. It won't make much difference.

Even auto import stops working without it. It’s insanity.

@@WilsonSilva90 The sad reality is some hardworking soul is going to write the d.ts and add a @types repo instead of just letting it die with this decision.

@@danielsharp2402 which is fine I guess.. But the base code is now still more readable.

Dynamic programming is crap but I've always hated Typescript syntax. The ugly code you have to write just to get fake types!

​​@@jel1951if you're writing ugly TS in apps, you're usually writing wrong. And yeah, you can write TS wrong, because of his due to its incremental nature.

​@@jel1951static types you meab

@@oscarljimenez5717 no, it's still ugly and never been amongst "good looking" ones

​@@jel1951i don't care if it's ugly or mot atleast I'm not spending 5-6 hours to debug code for some silly mistakes

if you go to the main page of their website, it tells you at the top of the page: > Turbo is an incremental bundler and build system optimized for JavaScript and TypeScript, written in Rust. ... though I had to click around for like 5 minutes to figure this out from the npm page.

@@homelessrobot I know. But don't think you think it would be better if it was first chapter in npm package so that I can quickly decide weather or not I am interested and weagher or not spend more time to look for more information on the homepage ?

@@sk-sm9sh yes, i do.

Hmmm guys, I think you're looking for the wrong turbo. That's vercel's turbo (which is ok I guess). This whole drama is about @hotwired/turbo

​@@homelessrobotwrong turbo. the topic of the video is hotwired turbo

DHH will be too busy solving errors in all of his wonderful, complex, and geniusly well put together apps. If only there's an easier way for him to find all these bugs faster, so we can have a Prime vs DHH fight...

DHH will be too busy meeting women. He wouldn't expect us to understand.

DHH will be too busy racing

Racing to solve those undefined bugs XD

Turbo 8 doomed to fail now. I didn't even know it existed before this discussion.

Then you have to define "dynamic typing". Do you mean runtime type inference?

​@@ElPikacupacabra Yes, probably, unless there's some gotcha you want to pull from some obscure 1974 paper or something...

This is the first time I have heard anyone describe C as loose typing. What do you mean? Every variable has to have a type with a fixed size. Are you referring to the C compiler automatically/user manually converting types in expressions?

@@coolcax99 Every variable is fixed at compile time, so it is static. However, things like type punning means that it's not really enforced. This makes sense for C, of course, but it's an example of something that has a static system that is not particularly strict.

I usually see it written as "strong" vs "weak" rather than "strict" and "loose". Strong, in this case, meaning resistant to coercion. Python is dynamic and strongly typed. Type checking happens at runtime, but you still can't use an int as a string; it'll raise an exception. JS is dynamic and weakly typed. Type checking also happen at runtime, but you can use an object as a string and it'll implicitly coerce the type for you. Not sure how C fits into this model. It's somewhere in the middle - it does implicitly coerce some things for you, but not as much as JS

People get rightly punished for relying too much on bad third party tools

​@@lungfishpeople get rightly punished for relying too much on DHH's code

@@igorordecha go back to your python and javascript piles and stay away from rails.

@@lungfish lil triggered arent you

super position of the worst

Typescript is statically typed end of. No quotes needed.

JS and TS aren't examples of worst anything. There are bullshit languages being used in the wild by companies that will make you beg for a language with a functioning debugger.

Yeah people tend to forget that Javascript (especially the browser one) is crappy because it was born out of free-for-all fight between vendors with all dirty tricks in the world possible and has to accommodate all the legacy code written in those times. That's like python 3 having to be fully backwards compatible with python 2 and python 1 (even pre-GPL license) code.

Regarding some latest changes in the ES, I’d prefer not having types in js, just do ts. No more messing up with ts please.

I didn’t know that Microsoft was the company that rejected ES4! 😡. ES4 did happen but not in the browser, was used in the glory days of Adobe Flash (when it introduced bitmap manipulations, 3D and video, before html supoorted those things) under the name ActionScript 3 and was great and very sophisticated (even compared to today’s JS). I’m sure that the strict data typing was the thing that allowed it to optimize the instruction to do heavy graphics inside web pages with the hardware we had had in those days.

My first time coming into contact with Python, I had to look up the source code of a function, then the source code of functions that it called, and then the documentation of functions that those functions called, just to find out the return type of the first function. It turned out to be something like list of lists of pairs of strings.

And this is why every library and every large app written in Python must use mypy.

@@ruanpingshan also same thing for passed arguments, and then some functions in some conditions would return entirely different structures.

Oh god, using godot engine and having to look at documentation every time I want to get collision data because it's returned as a dictionary with string keys instead of a struct.

Because size:number is so much clearer?

I see things a little different. Well actually, almost 180 degrees opposite of how you have described things. I think dynamically typed languages are more appropriate when the path is well trodden. Specifically, when the largest sub-components of your thing already exist as stable external components, and the work you are doing is gluing things together or probing an interface boundary. So mainly things that don't actually have all that much nuance to their internal structure. If the structure is obvious, the structure is obvious.

@@homelessrobot "I don't know what the word interface means therefore I don't need it"

@@user-fr2fm3ri3w whether you need it or not though, its there, and you are going to interact with it unless your programs don't interact with other code or the user interface or the internet or anything. It's the I in API (also i didn't see the quotes, lol)

@@homelessrobot saying strong types are bad for big projects is like saying being an alcoholic makes you a good dad. At some points you stop saying your subjective opinion and you start sounding silly.

In a way, you're both right and both wrong. Dynamic typing is best when (1) you know what you're trying to do, and (2) you don't yet know what you're trying to do. So you know, almost all of the time. Static typing is definitely the best though when you need the code to go really fast and you need strong guarantees about its behavior. So basically, static typing is only good when you're using Rust. Otherwise it sucks. I mean think about it -- when you're using Rust, you get (1) fast code, (2) guarantees about memory safety (3) guarantees you won't fall into weird concurrency traps and (4) strong functional bounds on program behavior like you get from Haskell or OCaml. Every other statically typed language gives you 0-1 of those benefits. You guys realize there was a head-to-head study done recently and they found that javascript projects had a significantly lower defect rate than typescript projects? They were trying to prove the opposite, that it protects you from bugs, and literally got a 0.99 p value on the hypothesis test. That's pretty much the same as finding out you can be 99% confident that using TypeScript instead of JavaScript will produce more defects. 😂 DHH is definitely a silly man-child though, I can't argue with that.

.. i use elm, btw

The Proneagen

Proneagen Toagen Mistakesagen

based take

Yeah, besides it's libraries not products

Like “I’m doing what I want, fuck all people who relates to my thing” 😂

I still write js for some simple scripts, but even that I need to use jsdoc, without type hint and autocompletion, I don't know what I can do.

^^ above comment is exemplar Stockholm syndrome cause by TS.

Agreee typescript is really nice to be honest

@@loshan1212 Typescript feels incomplete at times, and at worst, needs some typing gymnastics. Take for example, if you do Object.keys(obj), it'll just return string[], instead of the array of the keys. There are probably other outliers but these kind of cases makes me think that just using JSDoc to document the major expectations, and then just get used to the codebase, rather than spending half your time trying to type correctly, only to throw them out once specs change

@@GameFuMaster i think the original comment i replied to was deleted. my reply seems to make no sense.

It is BETTER than static typing because you can write with static types most of the time and then at 1 or 2 places use dynamic typing for great effect. It's more powerful. But if you actually do that, you are wrong, and an idiot. Don't do that. Anyways, not sure why you and the youtuber have more trust in a compiler than in a type checker. Doesn't make sense to me, maybe I am missing something.

Exactly what i was just thinking... Js can use something like that

@@nandoflorestan ahh yes lets check types at runtime as if python isn't barely faster than doing the math with pen and paper. What's next make every variable a global?

@@nandoflorestan by what measure is it better than static typing? the fact that it's optional? you get none of the actual good things you get from a compiler enforcing types and you dirty up some simple python code with a bunch of verbose type hints, to get little more than spell checking out of a linter. you're better off without the type hints. python never would have blown up in popularity like it did if there were brainless type hints littered out everywhere in its early days like there are now.

I tried to learn Ruby when it was hot. It felt like Perl. Lots and lots of syntax and punctuation. Lots of "end". I was super glad to abandon the idea and go back to the legibility of Python. I'll never understand DHH's love for the Ruby language.

@@nandoflorestan "Legibility of python" dude each one of your comments gets worse I swear python devs come out of some cult or something.

He just says he likes developing in it lol, It can be a pretty soothing experience after working on a project that heavily uses OOP / strict typing. Until its not... The paycheck it gives you is pretty soothing too

I freaking lost my marbles there 😂. Absolute Grade-A trolling. Imma go upvote that

I started doing this when I joined a React project with plain JS. The tech lead can't organize code for squat and it is a pain having to debug all his spaghetti code, so I started implementing types using JSDoc and definition files. Works like a charm!

Yea unless you and everyone on your team are 200 IQ there's just no reason not to put at least some basic jsdocs with how functions are intended to be used. Just laziness honestly. Vanilla js gets a bad name because people are lazy

Name shame it…also, why are you using it??

Ain't nobody got time for that! 😂

No you are not weird that's me too. I really like the type system of Go and Rust

The weirdly high overlap of Haskell and C developers would disagree

Yes

No, I'm on a similar boat. I love Angular because it enforces a rigid but clean app architecture on you using proper OOP patterns. Meanwhile I love Svelte because it's extremely flexible by allowing you to write JS in its simplest form, which is easy to read and understand. React in the middle is just a mess.

@@Dan_1348 Thanks Dan. Good to see I'm not too normal.

Well, his first is Ruby so there's that (although personally I quite like it).

How's that? Do you mean instead of Typescript? If you're only dealing with web stack, it's useful to keep certain things the same (like, say, using the same typedefs files referenced in both the server and client rather than duplicate them). Besides C# and PHP I have not really worked with any other languages for server-side. Open to suggestions.

JavaScript and Ruby lovers are not people to be taken seriously - on any subject matter

​@@modicooldude if ruby and js are your fav langs you are insane, they're both just spaghetti langs not suitable for serious stuff, obviously you can code serious stuff in it but it's not suitable (there's a big difference)

@@masterflitzer I don't use Ruby. I don't like Vanilla JS, I like Typescript.

If TypeScript is too hard for somebody, they probably shouldn't be a developer.

There are good developers and bad developers, some people just don’t care about code qualities, just keep away from them, and use generics.

It is only hard to define everything, if you are working with very crap 3rd party code / libs or if you simply don't know what you're doing.

I'm doubtful this will ever happen, because type annotations will further bloat the bundle sizes and site load times.

@@kon.simeonov true, but if you’re concerned about file size you’ll pass your production JS through a minifier and that can strip off type annotations.

@@Dave01Rhodes What you're describing is the way the typescript toolchain works rn.

@@kon.simeonov the point is that it wouldn’t have to work that way.

Ya all examples show simple function parameters and not object style that are just as much work

You are not.

Honestly sounds like you either need to learn to respect your team or hire some new people. You really don't need to be all that smart to be good at most programming jobs

*just not dumb

that's how humanity will end

Supposedly py3.12 will use annotations for jitting, which should speed up a lot of things if you're anal about putting in annotations in your code so that autocomplete doesn't shit itself. But I find it sometimes pylance still shits itself even if you explicitly define the type annotations.

python's type system is actually flawed and type checkers fail to properly know what type something has even when you annotate it urself. the official type checker (mypy) is actually worse than pyright (and even pyright being better is still not perfect or near it) but the good thing python has type wise is that it's strongly typed, it won't let u mix and match types and play a guessing game with u, it just throws an error and makes u explicitly do the type conversions (this is one of the biggest reasons for why javascript is a mess, implicit type conversions in it are hell)

I have to read a lot of third-party Python code in my job. Usually my go-to approach to understanding a code repo is to add type hints to my local copy as I read through it. But it's really frustrating, so many people use functions with different return types depending on the argument values. And some libraries released by big companies even have inaccurate type hints that result in pyright mistakenly flagging correct code.

@@ruanpingshan I've given up on understanding python just by reading it. to me python is hard to read once the logic becomes complex using a debugger or printing as u go seems to be the best u can do I also type stuff when it makes sense, but yeah... python type hints aren't reliable and I personally would avoid python on anything reasonably big but there's people that like that workflow of debugging ur way thru the code and guessing types, to each their own ig

@@FlanPoirot There are two options here. Either your brain is broken or you're reading sh-t codebases. When I learned Python, I did it by reading Twisted, which was one of the largest and most complex Python codebases at the time (and used zope-like interfaces on top of that). I literally went from knowing 0 Python to understanding Twisted and having a first draft of an async i/o distributed monitoring system built on top of it in less than 2 days. The readability and maintainability of Python are pretty much its standout feature (everything else is meh).