5 ms·
(not a frontend dev, so excuse any ignorance) I agree CoffeeScript usage has gone down dramatically, but has Typescript not usurped it? It doesn't seem like ev
by cs-szazz 5y ago
(not a frontend dev, so excuse any ignorance)
I agree CoffeeScript usage has gone down dramatically, but has Typescript not usurped it? It doesn't seem like everyone just went back to using JS, so maybe Scala was CoffeeScript, and Kotlin is closer to Typescript?
- afavour 5y agoI don't want to stretch metaphors too far here but there's some truth in what you're saying. TypeScript usage is a tiny minority of JavaScript usage but it's climbing and I'm sure it's much higher than CoffeeScript ever was. But I see TypeScript as a different beast altogether because of its aims. CoffeeScript and Kotlin were both created to make a complicated messy language more straightforward and powerful. TypeScript aims to make JavaScript safer by introducing types. If anything it slows development down, not makes it faster (and before someone jumps on me for saying that: yes, I think it's worth the price). IMO that makes comparisons difficult.
- cs-szazz 5y agoThat's fair, though I will say Kotlin's type system having nullability built-in is something I doubt Java will ever fully add (instead of the annotations it currently uses). So in that respect, it's making it more type safe, but the delta between Kt and Java isn't near as big as TS and JS.
- imoverclocked 5y agoIt can’t have it built-in without breaking backwards compatibility. NullAway adds this feature by enforcing sane use of @Nullable annotations.
- apatheticonion 5y ago> TypeScript usage is a tiny minority of JavaScript usage shudders at the thought After using TypeScript for almost 5 years now, I can not imagine a scenario where I would write JavaScript without type safety - other than a 5 minute POC to test something out. I look forward to the day when TypeScript can be compiled to wasm binaries and it can be a language all on it's own rather than a superset/wrapper of JavaScript.
- acdha 5y agoI like TypeScript but I think there's a complexity threshold — if you have a massive collection of other people's code, types are essential. If you're building a basic web app which is using the built-in behaviour and have a reasonably modern editor + linter + test setup, type safety is still good but it buys you less than it does when your baseline complexity level is higher. Since modern browsers and JavaScript give you a lot of functionality out of the box which people used to use libraries for, there are quite a few projects which are under that threshold.
- eropple 5y agoFor smaller projects, I find that the value is less the type safety (still valuable) and more the much stronger control of intellisense. Yeah, if you have a language server that's able to deal with typings your JS code will still be a lot better than without it, but starting with TypeScript just makes that way more fluid. I find that I write TypeScript much more quickly, and more correctly, than I do JavaScript, both for small and large projects.
- cardanome 5y agoI agree that TS is a good pragmatic choice for any non trivial amount of code but I am still surprised how bad it is. Error messages in TypeScript are quite cryptic for a modern language. Compiling it is super slow. Type safety, well they are doing their best considering the very dynamic nature of JavaScript but now if we compare it to other languages that compile to JS like Elm, it is just not that huge of a step. With Elm you get a guarantee of no runtime exceptions at all in productions plus the most helpful compiler ever written. Even compilation time feels much faster. Similiar for competitors like ReScript, Purescript and the like. Of course TypeScript is the easiest to learn for established JS Developers. And I am quite grateful that the option exists but I just wish it would be better considering how much money is put into it.
- addicted 5y agoTypescript is completely different from Elm. Elm is an entirely different language. Typescript is little more than a typing layer on top of JavaScript. As such, your typescript should look almost exactly like your JS would, with the only difference being that all your variables are now typed.
- deleted 5y ago[deleted]
- root_axis 5y ago> If anything it slows development down, not makes it faster It doesn't really "slow development down", it just forces you to explicitly specify the data structures that exist whether you decide to acknowledge them or not. Eschewing types is just a form of technical debt that every developer has to repay as they deduce the application data structures through trial and error, often times in production.
- stickfigure 5y agoMy guess is that people who feel that types "slow development down" just haven't become sufficiently familiar with the type system. In languages I am familiar with, types are just muscle memory. If anything, development is faster because of code completion. In languages I am learning, yes there tends to be some fumbling with the type system. But that fades with experience.
- Quekid5 5y agoIndeed, and Type-Driven Development is also a thing. Given a great type system and editor/IDE types can even be used to derive implementations.
- michaelmior 5y agoScala still has a reasonably strong following :) I think largely as a result of Spark.
- rgblambda 5y agoThat strong following might not last. My company made the decision to have PySpark be the default for training and future greenfield Spark projects, and they're only really making official what's been the reality for the past few years. A shame, as Scala seems like a nice language but I've never really gotten into it as Python is always the preferred option.
- michaelmior 5y agoIt's true that PySpark probably is overtaking (or already has overtaken) Spark with Scala. I still personally like Scala over Java in general for non-Spark projects as it's much less verbose which is my main problem with Java. However, I also haven't used all the new Java features to see how that would adjust the comparison for me.
- klodolph 5y agoTypeScript is in a unique position. It's basically a set of extensions to JavaScript, and with a very short list of exceptions, those extensions only affect the type system. You can mostly just convert TypeScript to JavaScript by going through your source files, selecting various ranges of text, and pressing "delete" on your keyboard. This is more or less how the TypeScript compiler compiles your code anyway. The exception I can think of is enum types. These always result in some amount of generated code. TypeScript can also apply some other transformations to your code during compilation, but as far as I know that's just so you can use newer JavaScript language features and target older JavaScript runtimes.