6 ms·

It's really telling that, for every big project that does not support TypeScript, the number 1 feature request is TypeScript support. (And consequently, that th

by Vinnl 6y ago

It's really telling that, for every big project that does not support TypeScript, the number 1 feature request is TypeScript support. (And consequently, that there are fewer and fewer such projects.)

swyx 6y ago
indeed we are in a new age of javascript now. one where TS support is (in practice) not optional. https://www.swyx.io/writing/js-third-age/ https://www.swyx.io/writing/js-third-age/
- novok 6y ago
  Might as well make it part of the language officially and get rid of the need for transcompliers.
  - kylemh 6y ago
    laughs in browser compat
  - mekster 6y ago
    Not going to happen anytime soon as people will take forever to upgrade to browsers that may support TS natively. Stick with transpilers and you're good to go from today. There's also deno for node.js alternative that supports TS natively but not sure of its future.
- hajile 6y ago
  We really need a "use types" mode. Instead of trying to support all the super-dynamic parts of JS, those parts should just go away in typed mode. Unlike TS, the type system should be sound. Hindley-Milner with immutable by default and options instead of null with structural typing everywhere and typeclass module definitions. I guess that's just StandardML with JS syntax, but that would be an amazing language to work with -- far better than either TS or ReasonML.
  - still_grokking 6y ago
    ReasonML is ML (OCaml) with JS syntax. OCaml has more features than SML. So I'm not sure what you're after. And regarding "the dynamic parts should just go away": No, please! And I'm saying this as a full time Scala dev doing "pure FP" in my day job who loves static types. But I also really like the "super-dynamic" parts of JS. I think such features should get integrated into some static lang. This would need some thinking though. The "old" static languages can't do that easily. To bring an example of what I mean: One can see JS objects as "extensible records". Adding and removing props on a prototype looks for example like "a super-dynamic" feature. But "extensible records" are also doable in static langs. I think more of those "super-dynamic" features are actually doable in a static context. Extending current FP languages with all kind of such features would be quite desirable, imho. "Why not have both?" :-)
moltar 6y ago
I basically haven’t written any JS code in over two years at this point. Everything I do is TypeScript. When I pick libraries I make sure they have TypeScript support. Preference goes to TypeScript-written packages.
- koolba 6y ago
  > Preference goes to TypeScript-written packages. Indeed, the only thing worse than no typings is wrong typings.
  - joshstrange 6y ago
    Those 2-4 seconds when you type `npm i @types/packageName` and hope you don't get a 404 or worse it comes down but hasn't been updated in forever.
tester756 6y ago
I think that's just proof that "the next future" of web development is going to be owned by languages like C# (that __already__ allow you to write decent client side web apps) and other already popular not dynamic languages After C# of course yet another DSLs.
- cageface 6y ago
  Typescript can seamlessly interop with existing JS libraries. This is a huge advantage over any non-JS language.
  - tester756 6y ago
    Ain't everything going to be WASM anyway?
- rubber_duck 6y ago
  I came to TS after years of C#, all the way back to .NET 2.0 and WinForms. TBH TypeScript is just better than C# for the job it does - DOM control and gluing data - structural typing that's backed by a dynamic runtime is a much better fit for those kinds of tasks than a nominal type system backed by IL level type checking - AutoMapper is nonsense created by this design decision and C# is particularly verbose (almost Java level). C# allows you to get much lower level than TS can, you can control memory layout, allocation patterns, you have proper threading model, etc. etc. But for dealing with single threaded DOM event loop, stitching data from all kinds of sources, simple transformations and sending it around - IMO TS is a better fit.
- k__ 6y ago
  I hope not. C# is too bloated for my taste and I have to admit, TS is too close to C# for my taste.
  - tester756 6y ago
    I do agree that it's becoming lately
  - 6y ago
joshstrange 6y ago
I won't pretend tsconfig/webpack or any other bundler out there is "fun" to work with but once I get my TS support working in a project it is a joy to write in TS. I already liked JS (if that didn't make you hate me I like PHP too and have gotten paid to write it for a decade now) but TS really pushed me over the top. I avoided TS like the plague because I didn't want another layer added in and I thought it was just coffeescript++ but after taking the plunge on 6to5 (renamed to babel) because "well these features are coming to JS soon anyway or have already landed in stable browsers" it was just a hop, skip, and a jump over into TS (in for a penny...). Modern JS is actually really fun to work in and TS takes to the next level with peace of mind I never had with just JS.
- ewired 6y ago
  > I won't pretend tsconfig/webpack or any other bundler out there is "fun" to work with For me, Parcel is fun to work with. Rollup is my favorite for more advanced or customized pipelines, but Parcel has a silky smooth workflow for the typical bundling tasks in most projects. I've started using it for Node.js as well (since I want to avoid ts-node) but it seems best for frontend-only projects and components. Speaking as someone who has managed to avoid Webpack thus far despite its status as the "industry standard".
  - sunsetSamurai 6y ago
    do you have any guide on how to setup,TS, linters etc with Parcel?
    - ewired 6y ago
      From what I can tell, Parcel v1 does not have linting, but I rely on linting and typechecking in my editor anyway, so I didn't notice. It's actually pretty handy to bypass typechecking and write untyped JS to quickly check if something will work then add types to it gradually. VS Code yells at me until I fix it, so it doesn't go unfixed. https://parceljs.org/ https://parceljs.org/ is the homepage. Run the command (or put the command in an npm script) like `parcel whatever.ts` and it will output your bundle with all dependencies transpiled to JS and CSS. The simplicity does come at a cost; it's not as readily customizable as something like Rollup. I've been eagerly tracking v2 and it appears they are adding linting and much more into Parcel.
pjmlp 6y ago
Because it comes down to what I advocate, guest languages only look nicer on the surface, they add up more layers to debug, extra tooling to integrate, FFI to platform and library wrappers for idiomatic code. Since the Web platform isn't going away from JavaScript anytime soon, and WebAssembly is relatively constrained beyond WebGL, that leaves UI frameworks as the possible "platform". What I am looking for is that the adoption will keep carrying on, to the point that browser natively understand Typescript, or WebIDL for that matter.
- Vinnl 6y ago
  Browsers don't need to understand TypeScript, but just be able to ignore TS-specific syntax like Babel does. Then it's really possible to use TypeScript like a linter without requiring a bundler. But of course, that'll add quite a drag on TypeScript development. With Babel, they can just maintain the plugin themselves; with browsers, they'll have to go through the standardisation track for every syntax change they want to make.
  - pjmlp 6y ago
    Strong typing is not only about linting, JSLint already does that. TypeScript also has to go through the same process, after all they need to grow alongside JavaScript and besides typing, there is nothing that gets introduced that isn't JavaScript at its core.
    - Vinnl 6y ago
      Sure, but the value of TypeScript is that it warns you about bugs in your editor or at compile time. The value of browsers supporting TypeScript would be that you can serve it up to users without a build step.
      - pjmlp 6y ago
        My IDE already does that for JavaScript as well, the benefit of strong typing on the browser, besides removing the build step, is that JIT would be able to actually take advantage of the type system instead of guessing and hoping for the best.

by Vinnl 6y ago

It's really telling that, for every big project that does not support TypeScript, the number 1 feature request is TypeScript support. (And consequently, that there are fewer and fewer such projects.)

swyx 6y ago

indeed we are in a new age of javascript now. one where TS support is (in practice) not optional. https://www.swyx.io/writing/js-third-age/ https://www.swyx.io/writing/js-third-age/

novok 6y ago
Might as well make it part of the language officially and get rid of the need for transcompliers.
- kylemh 6y ago
  laughs in browser compat
- mekster 6y ago
  Not going to happen anytime soon as people will take forever to upgrade to browsers that may support TS natively. Stick with transpilers and you're good to go from today. There's also deno for node.js alternative that supports TS natively but not sure of its future.
hajile 6y ago
We really need a "use types" mode. Instead of trying to support all the super-dynamic parts of JS, those parts should just go away in typed mode. Unlike TS, the type system should be sound. Hindley-Milner with immutable by default and options instead of null with structural typing everywhere and typeclass module definitions. I guess that's just StandardML with JS syntax, but that would be an amazing language to work with -- far better than either TS or ReasonML.
- still_grokking 6y ago
  ReasonML is ML (OCaml) with JS syntax. OCaml has more features than SML. So I'm not sure what you're after. And regarding "the dynamic parts should just go away": No, please! And I'm saying this as a full time Scala dev doing "pure FP" in my day job who loves static types. But I also really like the "super-dynamic" parts of JS. I think such features should get integrated into some static lang. This would need some thinking though. The "old" static languages can't do that easily. To bring an example of what I mean: One can see JS objects as "extensible records". Adding and removing props on a prototype looks for example like "a super-dynamic" feature. But "extensible records" are also doable in static langs. I think more of those "super-dynamic" features are actually doable in a static context. Extending current FP languages with all kind of such features would be quite desirable, imho. "Why not have both?" :-)

moltar 6y ago

I basically haven’t written any JS code in over two years at this point. Everything I do is TypeScript. When I pick libraries I make sure they have TypeScript support. Preference goes to TypeScript-written packages.

koolba 6y ago
> Preference goes to TypeScript-written packages. Indeed, the only thing worse than no typings is wrong typings.
- joshstrange 6y ago
  Those 2-4 seconds when you type `npm i @types/packageName` and hope you don't get a 404 or worse it comes down but hasn't been updated in forever.

tester756 6y ago

I think that's just proof that "the next future" of web development is going to be owned by languages like C# (that __already__ allow you to write decent client side web apps) and other already popular not dynamic languages After C# of course yet another DSLs.

cageface 6y ago
Typescript can seamlessly interop with existing JS libraries. This is a huge advantage over any non-JS language.
- tester756 6y ago
  Ain't everything going to be WASM anyway?
rubber_duck 6y ago
I came to TS after years of C#, all the way back to .NET 2.0 and WinForms. TBH TypeScript is just better than C# for the job it does - DOM control and gluing data - structural typing that's backed by a dynamic runtime is a much better fit for those kinds of tasks than a nominal type system backed by IL level type checking - AutoMapper is nonsense created by this design decision and C# is particularly verbose (almost Java level). C# allows you to get much lower level than TS can, you can control memory layout, allocation patterns, you have proper threading model, etc. etc. But for dealing with single threaded DOM event loop, stitching data from all kinds of sources, simple transformations and sending it around - IMO TS is a better fit.
k__ 6y ago
I hope not. C# is too bloated for my taste and I have to admit, TS is too close to C# for my taste.
- tester756 6y ago
  I do agree that it's becoming lately
- 6y ago

joshstrange 6y ago

I won't pretend tsconfig/webpack or any other bundler out there is "fun" to work with but once I get my TS support working in a project it is a joy to write in TS. I already liked JS (if that didn't make you hate me I like PHP too and have gotten paid to write it for a decade now) but TS really pushed me over the top. I avoided TS like the plague because I didn't want another layer added in and I thought it was just coffeescript++ but after taking the plunge on 6to5 (renamed to babel) because "well these features are coming to JS soon anyway or have already landed in stable browsers" it was just a hop, skip, and a jump over into TS (in for a penny...). Modern JS is actually really fun to work in and TS takes to the next level with peace of mind I never had with just JS.

ewired 6y ago
> I won't pretend tsconfig/webpack or any other bundler out there is "fun" to work with For me, Parcel is fun to work with. Rollup is my favorite for more advanced or customized pipelines, but Parcel has a silky smooth workflow for the typical bundling tasks in most projects. I've started using it for Node.js as well (since I want to avoid ts-node) but it seems best for frontend-only projects and components. Speaking as someone who has managed to avoid Webpack thus far despite its status as the "industry standard".
- sunsetSamurai 6y ago
  do you have any guide on how to setup,TS, linters etc with Parcel?
  - ewired 6y ago
    From what I can tell, Parcel v1 does not have linting, but I rely on linting and typechecking in my editor anyway, so I didn't notice. It's actually pretty handy to bypass typechecking and write untyped JS to quickly check if something will work then add types to it gradually. VS Code yells at me until I fix it, so it doesn't go unfixed. https://parceljs.org/ https://parceljs.org/ is the homepage. Run the command (or put the command in an npm script) like `parcel whatever.ts` and it will output your bundle with all dependencies transpiled to JS and CSS. The simplicity does come at a cost; it's not as readily customizable as something like Rollup. I've been eagerly tracking v2 and it appears they are adding linting and much more into Parcel.

pjmlp 6y ago

Because it comes down to what I advocate, guest languages only look nicer on the surface, they add up more layers to debug, extra tooling to integrate, FFI to platform and library wrappers for idiomatic code. Since the Web platform isn't going away from JavaScript anytime soon, and WebAssembly is relatively constrained beyond WebGL, that leaves UI frameworks as the possible "platform". What I am looking for is that the adoption will keep carrying on, to the point that browser natively understand Typescript, or WebIDL for that matter.

Vinnl 6y ago
Browsers don't need to understand TypeScript, but just be able to ignore TS-specific syntax like Babel does. Then it's really possible to use TypeScript like a linter without requiring a bundler. But of course, that'll add quite a drag on TypeScript development. With Babel, they can just maintain the plugin themselves; with browsers, they'll have to go through the standardisation track for every syntax change they want to make.
- pjmlp 6y ago
  Strong typing is not only about linting, JSLint already does that. TypeScript also has to go through the same process, after all they need to grow alongside JavaScript and besides typing, there is nothing that gets introduced that isn't JavaScript at its core.
  - Vinnl 6y ago
    Sure, but the value of TypeScript is that it warns you about bugs in your editor or at compile time. The value of browsers supporting TypeScript would be that you can serve it up to users without a build step.
    - pjmlp 6y ago
      My IDE already does that for JavaScript as well, the benefit of strong typing on the browser, besides removing the build step, is that JIT would be able to actually take advantage of the type system instead of guessing and hoping for the best.