371–380 of 400 posts
If anything, Typescript is the best of both typed and dynamic languages because you have the option to use types only in places where you really want to enforce them, it's not all or nothing.
Earlier quoted context omitted.
JS the language isn't great but it's JS the culture that is the real problem. There is a subset of JS codebases that are good, well engineered and written by people that understand the languages faults and limitations but the list is incredibly small and even smaller still now Joyent isn't really around anymore. If there was one ecosystem I wish I never needed to touch again it would be JS but unfortunately it's beco…
> JS the language isn't great but it's JS the culture that is the real problem. This is the money quote of the thread for me. From the perspective of someone whose main language has been JS or TS for about 8 years, it's getting worse since some of the biggest names in the discipline just seem to be people with large social followings giving terrible advice. This advice is then eaten up by hoardes of bootcamp alumni w…
I have a theory that TypeScript was not actually invented for frontend developers, it was created for non-frontend developers who were forced to deal with the frontend, and hated JavaScript. That's also why I think it's very funny that JavaScript developers are starting to use TypeScript on be backend, i.e. Deno. You are using the patch to JavaScript that backend devs needed to make JavaScript more like backend langu…
I don't understand any arguments of this variety because TS just compiles to JS TS hasn't changed the way I write applications too much, besides giving me a bit of safety/enforcement of good practices and productivity boost
With Deno, you're using a classic OOP inspired superset of JavaScript, transpiling it to JavaScript, and running it in a JavaScript engine on a server. That's only necessary in a browser.
On a server, if you don't want to use JavaScript, you can just directly use a classic OOP language, and dispense with the whole extra frontend transpilation abstraction.
Unless you're a frontend-only webdev, and, understandably enough, you don't want to learn a classic OOP language, which I believe is the real reason.
Or, at least I hope so, because the only other possible reason is mass obliviousness, and that's horrific.
Earlier quoted context omitted.
I miss the elegance of Haml. Moving from an indented syntax for DOM literals to the likes of JSX felt like a step backwards.
Maybe for you, but that is not a popular opinion. JSX's rigor is a breath of fresh air in a world that constantly generates low quality html due to loose constraints. HAML had those same problems. JSX is kind of xml done "right". Differences between children and attributes in xml is very hard to grasp, but JSX has a much better defined structure to it and is super well suited to generate html because of that.
Earlier quoted context omitted.
Maybe for you, but that is not a popular opinion. JSX's rigor is a breath of fresh air in a world that constantly generates low quality html due to loose constraints. HAML had those same problems. JSX is kind of xml done "right". Differences between children and attributes in xml is very hard to grasp, but JSX has a much better defined structure to it and is super well suited to generate html because of that.
This sounds like an orthogonal point. (I agree with it, so it feels odd to see it presented as a rebuttal.) Surely an indented syntax could have rigor if we wanted it to?
Earlier quoted context omitted.
>The author isn't claiming to have had an informed opinion of types. They're saying that they found learning about types to be difficult and stressful. That's a real problem that I think people who understand types forget. Respectfully, its really hard for me to wrap my head around this mindset. When I wrote my first line of code, almost 10 years ago, one of the very first concepts I learned was types. You know the b…
The opposite for me. Typing makes zero sense. I know what I'm doing with my variables so why do I need to specify a type? Why can't the computer figure this out? Isn't that what computers are good at?
For everything else, there's type inference.
> I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits. I honestly find this attitude horrifying. I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry. As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can t…
Oh come on, this is a discussion probably older than both of us put together. And we probably both know that the discussion devolves into where/what kind of tests are written. I'm on your side in the static type system debate, but you must realize that the responsible part of the other side delegates the responsibility to exhaustive testing.
I certainly realize it, and I've seen it once in ten years and it'd have been dealt with automatically by a compiler because they were writing tests for autogenerated code. (Why not test the generator, you may ask - and that's a story for another day.)
Earlier quoted context omitted.
If you're not using a bunch of generics, check out typescript-is [1]. It takes little work to get it setup, but it generates run time type checks for you. I understand why typescript decided to not add this functionality to the core of the language, but it's starting to feel like the largest missing piece of typescript is a built-in way to generate run-time type-checks for user-defined types from just the type defini…
Doing runtime-typechecks really is a blessing, and it would be great if typescript would provide this as a language-feature. There are two more libraries I know which are great for that: * Zod: https://github.com/colinhacks/zod * io-ts: https://github.com/gcanti/io-ts (for the more functional-programming-oriented)
I forget why Zod didn't pass muster for me now, but I've looked at it before and didn't find a compelling reason to jump to it. Thought it seemed good, though.
I really wish at least one of these let you emit JSON schema back out, though. That'd be way easier for dealing with stuff like OpenAPI.
I was hesitantly open to TS when the hype was first ramping up. The team I was on (and I've seen this in lots of code elsewhere too) was doing stuff like this: declare let myColor: Color | undefined; Suddenly everything turned into Java with signatures cascading endlessly. I'm not blaming TS, it's more of a.. lack of faith to make the full jump? Or limitation of the underlying Javascript? This problem should be solve…
assuming you meant let myColor: Color | undefined; I don't understand what the problem is. Native JS would require you to define the starting scope of the variable (unless you're relying on global scope!). Then you declare what the type is: Color or undefined. The state of the variable can be one of two things. Perhaps I've been writing TS for too long but I think I'm missing the problem here.
At that point, TS is just a burden.