Комментарии:
in terms of types, you can be 1 of two people, who uses it or does not... if you DO NOT use types, then make sure you have TDD. However, if you use types, TS is THE-BEST-OPTION! The train of thought suggesting "TS forces you to code types and then the actual code" is not unique to TS, in fact take any strongly typed programming language, you still need to change types for the purpose of type manipulation.. Where TS shines is, it lets you be more specific and expressive in terms of types. Now, tell me TS is inefficient compared to RUST and Go, A.B.S.O.L.U.T.E.L.Y true! However, I find it shocking to find someone like @ThePrimeTime who likes vim because it lets you code at the speed of thought (in my opinion because it lets you express exactly what you want) but hates TS because it lets you express exactly what you want as a type? Think about it, you could make it as generic as any strongly typed language or make it specific so that your imports accurately translate what to expect.
You say you are fine with JSDoc but that is in a way a type def as well, what is the purpose of a type? 1. To describe what is stored, 2. Guide consumers, TS types are just more specific than JSDoc 🤷♂
It is true that maintaining a library or framework that heavily relies on TypeScript typings can sometimes introduce additional complexity and challenges. TypeScript's strong typing system can indeed lead to a more involved and sometimes confusing process when it comes to maintaining and updating typings. There are a few reasons why maintaining typings can become complex:
1. Versioning and Compatibility: Type definitions may need to be updated and tested with each new release or version of the library or framework. Ensuring compatibility and consistent typings across different versions can be challenging, especially as the library evolves and introduces breaking changes.
2. Community Contributions: Open-source libraries often rely on community contributions for maintaining and updating their typings. It can be difficult to manage and merge community PRs related to typings, especially if they introduce conflicting changes or do not align with the project's goals and conventions.
3. Different Use-Cases: Libraries and frameworks may be used in various scenarios and configurations, which can lead to complex typing requirements. Supporting different module systems, bundlers, and runtime environments adds an extra layer of complexity to the typing maintenance process.
That being said, TypeScript still has significant benefits, especially for large-scale projects and teams. It provides static type checking, improved developer tooling, and better documentation for codebases. TypeScript can help catch errors during development, improve code quality, enhance code navigation, autocompletion, and refactoring capabilities. The decision to drop or limit TypeScript usage in a library or framework depends on various factors, including the nature of the project, the size of the codebase, the development team's familiarity with TypeScript, and the overall goals and requirements of the project. It's essential to weigh the trade-offs carefully and consider the benefits and drawbacks in the context of your specific use-case.
I love JavaScript but for a completely different reason to DHH, I.e without the classes, just keep it all functional.
Functional code scales to infinite complexity, but you do need to know what you are doing. A couple of seniors to steer things in the right direction.
Who is this shithead that dares to talk about DHH?
ОтветитьPersonally I've tried JSDoc and it is no replacement for Typescript. I was using it because I was making a template for a coding workshop that I was sending out to kids and I didn't want them to have to install Node and a bunch of stuff to get Typescript working, so I switched back to vanilla JS and just used JSDoc for typing. I instantly started making clumsy mistakes again because JSDoc doesn't highlight errors when the types don't match anymore. And also when I closed the project and came back to it in my IDE, it didn't load up all of the types for files I hadn't opened and I had to open each individual file for Vscode to index the types, so doing that on a huge project with hundreds of files would be a bigger pain in the * than just using Typescript in the first place. I respect some people not wanting to use it, but I think the tradeoffs of not using Typescript aren't worth it.
ОтветитьHey @ThePrimeTime, did you find that the girl was not your... TYPE? 😜
ОтветитьI thought the Microsoft hate bandwagon was so 2000, don’t think that will help your completely backwards and incorrect decision nowadays
ОтветитьTurbo is awesome. It's what you should be using instead of HTMX.
Ответитьi mean yeah do what ever you do man im sticking with typescript i dont want to deal with undefined function
ОтветитьJust stay away from Web Development if you want to maintain your sanity as a developer
Ответитьwow man, Prime really hates ruby. Every time he mentioned it there was a cut and edit lmao
Ответитьwhat about scala 3?
ОтветитьGreat things are are hard to attain, JS-TS
ОтветитьIt’s weird to me that ECMA haven’t put typescript-style hints into JS syntax. They could still be completely ignored at runtime, but your editor or source control integration step could validate types for you.
And heck, JS already has “strict” mode. JS engines could add “strict type” mode where it does runtime type checking and throws type error exceptions.
That and it would be funny to see a Microsoft product get embraced, turned into an extension to JS, and then extinguished.
This stuff is insane
ОтветитьSomeone has to present type inference to this kid. Maybe he’ll stop hating on strongly typed languages a bit
ОтветитьOh I love hating Typescript (MS in General) . The type defining should have been a part of originally javascript becuase of only that single limitation many devs were forced to use typescript.
ОтветитьTypescript is great for people who aren't smart enough to know how to work with dynamically typed languages.
ОтветитьFor me, people who like dynamic typing, are people who may put a pizza in a washing machine and will still expect the clothes to be washed correctly. And the pizza will fail being washed silently.
ОтветитьThis is my channel; "m"; [Grey Background]. It was stolen by Tom Conroy. HELP.
ОтветитьHmm, yes there is the occasional typing gymnastics, but one of the things I like about TypeScript is when trying to using a library I know what props are the the thing is that I'm importing.
ОтветитьTypescript was created for mediocre developers who are unable to write proper JS code. There is no way on Earth someone can like Typescript's horrendous syntax.
ОтветитьLove your videos 😍
Question:
Have you blocked @t3dotgg from the comments section? 🤣
DHH apparently doesn't know that strong typing and static typing are not the same thing, it always irks me when people misuse those terms like they're interchangeable.
ОтветитьThis is way it’s better to only use JavaScript/TypeScript on both front-/backend. Instead of using another language so you become better coder for JS/TS.
ОтветитьImagine being mad about a free product. "Buh I use it!", okay, did you sign some contract or something that will force the owner of the repo to not make stupid decisions?
The entitlement is bewildering to me
Not just Turbo 8, Typescript is removed from Svelte as well.
ОтветитьGoing full midwid? What does he mean? Not a native speaker ..
ОтветитьI love prototyping in a dynamic language, but if you're maintaining anything that changes, types please.
ОтветитьIn my experience dynamic languages are fast to build things with, but are awful to maintain at any reasonable scale. Types document code, enable much nicer refactoring and IDE tooling. I’ve used JS, TS, Ruby, Java, Groovy and Scala in big production apps and would always go for types over dynamic. But, whatever works, if it’s your project. Type compilation just saves so many bugs from making it into production code.
ОтветитьJSDoc feels way better than TS without worrying about adding type checks everywhere. Also it is a big headache to do typechecks for a very large codebase. I like the freedom to first code in your style and worry about types later on. If devs worry about types first, then the creativity and the joy of coding will take a backseat.
ОтветитьRemember: Always do the opposite of what DHH does
ОтветитьI don't have a bet on this match but I don't enjoy javascript as much when I have to constantly refer to original source to get what arguments and return values do. TypeError cannot undefined/undefined reading undefined/undefined is just undefined aka Null hell. Solve it however you like: FP, OO, code-time docs, but it beats having to hunt down the code taking the args I didn't provide or buried type property that was null and then used for a bunch of function calls. TDD is dying deservedly and while it might be ok for lone rangers, it sucks for a community to have to change horses. I have long hoped that undefined and null will disappear as error causes. I really think we can do better than this.
ОтветитьLet us live in peace in Ruby land without our types.
ОтветитьI mean, the whole point of Turbo is to achieve React-like interactivity without writing JS... No idea why anyone would want to combine that philosophy with TS. If you want to use TS with Rails, it makes more sense to use a React front-end or something, not Turbo.
ОтветитьTypeScript is garbage and in the near future, we will look back and laugh at how we used TypeScript.
Ответитьusing typescript for library dev is a pain but a direct win for the end developer
using vanila for library dev is just transfering that pain to each end dev
Making that choice as a library dev is profoundly stupid
I love dynamic typing however the more expetience I have with working with strict tyoes the less I feel that type overhead. Now I've really gotten into meta programming and code generation I feel like strict typing is the way to go. However I wish it was possible to disable types on parts of the code momentarily while prototyping. This can't be done in Kotlin but in a roundabout way can be done in typescript, hence why I am a fan of typescript.
ОтветитьIf typing is the only thing one has understood of the benefits of Typescript, I'm tempted to believe one is a noob at TS and perhaps programming in general.
ОтветитьFuck TypeScript
ОтветитьI prefer Tuurbo 11, it's 3 better...
ОтветитьBro your Microsoft hate is so 2006 🤡
ОтветитьImplicit typing (eg in (C#) is the sweet spot IMHO.
ОтветитьYou can have too many abstractions
ОтветитьHow have I only found your content today 😂
ОтветитьAll you really need to do is type a functions input and output. That's it. Inside the function, `any` away, nobody cares.
ОтветитьJavascript a joy to write? DONT ever let this guy cook again
ОтветитьYeah, right, and if you move to JSDoc, you do your type gymnastics in a poorly defined comment format instead.
Because JSDoc only appears to be a well-defined standard, and is really more accurately defined by how that standard is interpreted by the only implementation that actually matters to anyone, which is the one in TypeScript's transpiler and LSP. Since it's just comments, there's an extremely low barrier to interpreting its standard differently than the TypeScript implementation does (*cough* web-component-analyzer *cough*), or just outright extending it. And suddenly, you're back to running type-related build tooling to turn that alternative JSDoc interpretation into .d.ts files that TypeScript actually understands…
TypeScript is for those clowns who like to do circus with code. If you wanted types so badly you would stick with Java instead instead of twisting up and mangling JS so badly. There is a reason why c, c++ ( ... ), js and perl exist and that is to solve every day real problems. Typescript code looks like somebody let a monkey have a go at the keyboard. And also I suspect that MicroSoft secretly hates Javascript and its success. I am sure there is some interesting bit of history in there somewhere ...
Ответить