Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities [email protected]
The title makes it seem like it's a wide spread thing in the industry but according to the video it's 3 frameworks.
Yeah, it's additional work but I've found that really convoluted or complex type definitions usually mean you should consider refactoring. Of course this is a bit different when it comes to developing frameworks where you might want to support a bunch of different use cases.
Maybe I'm biased because I've been using TS ever since it first came out.
And Rich Harris (Svelte) said, it's an issue for people in his position, aka, people making tools for developers - he fully expects and respects that the end users (developers using those tools) don't really experience the downsides.
That said, I feel like we're seeing a lot of versions of complaints about how big the stacks are getting, how big the foundation is that we "need" just to get started. That desire for minimalism is core to the developer mentality imo, it makes us good at our jobs. I think we're going to see more paring down and culling in the coming months/years.
And once again, clickbait YouTuber spreading bullshit appears
Tl;dw: it's too much "type-gymnastics" when developing a library.
I clicked, sorta interested in the topic because as it happens I just abandoned Typescript in favor of learning Go for a little nascent project I'm working on. (We do these things not because they are easy, but because they eventually will be good which Typescript+Node apparently never will for my particular project.) Then I saw it was Fireship and clicked back away.
Now it sounds like you're saying that what they're claiming is the issue is the one good thing that happened with Javascript in the last however-many years. Yes, it's a little tedious to have to straighten out all your types. You know what's more tedious than that? Having to straighten out all your types, but not getting any feedback about it at compile time and having to figure it out based on mysterious failures, or if you're lucky explicit exceptions, at runtime.
Having worked for a while in Javascript, and now for a pretty short time in Typescript, I cannot imagine trying to make a decent-complexity project in pure Javascript. That I believe is why they tend to not really be all that object-oriented and pass strings around for lots of things and be sorta flaky.
Yeah, dropping typescript and then codifying type information in jsdoc is comical.
The only thing I would say about your experience is that “dropping TS for go” is a little bit misleading, and it doesn’t really sound like it bears on the general debate of “TS vs. JS” - go and other static languages generally fit a different niche in my opinion, and can be a better option for certain kinds of systems.
If you’re building anything of even moderate complexity, or with more than one person, you really need the types and modularity that TS provides.
I guess it’s also worth noting that JS has actually been influenced/adopted some key features from TS over the years, so it’s possible to do a few things with it to make stuff that’s a bit more maintainable.
Yah, 100% agree. So in my case, Typescript is actually a better fit niche-wise... but I finally reached the point where I didn't want to cope anymore with flawed things it was inheriting from Javascript, so it was especially ironic to me when I saw this and thought maybe I'm not the only one, only to discover that the message was "SIIIKE we love the flawed things! It's the improvements we're getting rid of."
I mean every project is different and they've got a right to do what they want. It was just a hilarious surprise for me.
Too be frank, it is pretty short but your summary is on-point. I would only add, that Svelte also dropped it due to the additional compile step.
However TS can still be used in most of the frameworks including Svelte.
I wonder how Svelte's code is built to make this tradeoff worth it. I've been using TS for a long time and in every project the compilation part was the shortest task in the whole build process, especially when you compare it with bundling or running unit tests.
If that's what this video is about then it's a lie (I'm not going to watch that bait). Svelte did not move away from Typescript. Svelte just moved from TSs custom syntax to TS-in-JSDoc. They are still using the same types and TS compiler to fully enforce type checking their code.
Their reason isn't that TS is bad, just that the IDE experience is bad redirecting you to .d.ts instead of source files for libraries.
Afaik it had more to do with another layer of abstraction then with compike time.
Here is an alternative Piped link(s): https://piped.video/watch?v=5ChkQKUzDCs
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I'm open-source, check me out at GitHub.
Nah. Waste of time imo
I haven't dealt with a larger JS/Node Project in a while, but I like this approach to using TS features in JS.
so he does all of this because he dislikes transpiling because supposedly it makes debugging etc harder? does he know about sourcemaps?
he also says he doesnt like type information in his code, so he adda them as comments. the type information is still there, how is this an improvement?
The issue with transpiling is that the code that's running in production is not necessarily the one that's been tested. A source map doesn't fix that.
I loathe this line of reasoning. It's like saying "unless you wrote assembly, compiling your code could change what it does."
Guess what, the CPU reorders/ellides assembly, too! You can't trust anything!
Haha, what is this, the 90s?
Assembled instructions aren't even the lowest non-hardware stage in instruction execution. There's proprietary microcode sitting a level below your typical x86 ISA.
And even then, what if—God forbid—the hardware has errata. A line has to be drawn somewhere between trusting that what you write is logically correct at all stages below it. If someone is unable to trust that the environment they wrote code for works, they better start learning how to create PCBs and writing for FPGAs.
🙈🙉🙊
I know, but I didn’t want to scare the children.
I also chose to pretend it’s just little gnomes moving the bytes around. Less magic.
What are electrons, but a miserable pile of little magic gnomes? But enough talk... have a upvote!
Unless someone is using some language extensions, transpiling from TS to an ECMAScript module using the ESNext target merely drops the type annotations.
If not running the exact same code being developed is an issue, it's an easy fix.
Ugh? Why shouldn't it be the same code?
Because Browsers can't run Typescript, they run JavaScript. That's why the intermediate conversion step isneededd.
But your tests are running on the compiled code too. Nothing can be tested but handwritten assembly, with such approach
I do this daily and believe me when I say that I'd trade my kidney for the ability to use TS natively. This looks good on paper but jsdoc notation has lots of flaws and you literally can't do some things with it. Also, it doesn't check if the function actually does the thing you described so it needs manual review every time it's changed.
That approach was mentioned in the video.
good. typescript has always caused us more headache than it worth in all my projects. I bill my clients extra for it if they make me work on it.
