7 ms·

1 - it is not just server software, but general purpose usage. 2 - personally I don't see why you'd want to use anything other than Typescript right now. It c

1 - it is not just server software, but general purpose usage. 2 - personally I don't see why you'd want to use anything other than Typescript right now. It certainly feels like TypeScript has "won" and is now the defacto standard for anyone doing any kind of work in the JS-ecosystem. That of course may change in the future of course, but today it feels like TS is where its at. 3 - I've experienced a lot of annoyance shipping around huge node_modules/ directories, just to get a CLI app working. Sure these are not "problems", but it is a pain to have to compress up hundreds of thousands of files and then decompress again rather than just moving around one executable. 4 - deno is the "package manager", if you can call it that. You explicitly state the imports & versions you need in your code as import statements, and the deno runtiem handles sourcing the files for you transparently. So either from a cache, or at first run it will try and go out onto the network (internet or proxied IIRC) to get them for you.

franciscop 5y ago
[deleted comment]
- andrew_ 5y ago
  This is something often overlooked by fans of typing. On the surface it may appear to some as being strongly typed, but it's a mirage [1] and frequently requires a lot more lifting, e.g. writing specific typings to work around shortcomings, just to make the types play nice together. That's not a feature of a strongly typed language, it's a feature of statically type-checked languages or schemas. I still use TypeScript, and I understand the benefits, but I'm not always a fan and will write plain JS when it fits better than TS. [1] https://news.ycombinator.com/item?id=15090561 https://news.ycombinator.com/item?id=15090561
  - k__ 5y ago
    I didn't like TypeScript when writing frontend only code, because the the iteration speed is just so fast in the browser. But when I started using it for backend and infra, the iteration speed is much slower, so even TS only saves a few % of deploys, it's still a noticeable amount of absolute time.
    - handrous 5y ago
      Typescript is miraculously productive on the front-end as soon as you've got people writing at different "layers"—someone writing a frontend library, someone else handling state and actions, someone writing components for re-use, someone making it look pretty and using those components. You can be sitting right next to someone using code you wrote but rarely need to discuss it because the types communicate everything so damn well.
  - twooster 5y ago
    I've seen this take so many times an I simply don't get it. The notion that TypeScript can't be (some form of) strongly-typed because Javascript is (some form of) weakly-typed is just silly. CPUs are entirely weakly typed in this sense and this doesn't impact the typings of languages built on top. JavaScript is strongly typed in the sense that every value has a well-defined type. It's weak in the sense that it has implicit conversion between types in a lot of cases, but it's not as though those conversions don't follow particular rules if you know the types. TypeScript gives you accurate static typing on top of that, so long as you don't use `any` as an escape. Arguably, `JSON.parse` returning `any` is the 1-million dollar mistake of TypeScript, because it leads a lot of people to think that they get automatic runtime typechecking for free, which they obviously don't, which leads to comments about how bad/slippery TypeScript is stemming from their misunderstanding. In my experience, you only need to work around typings in TypeScript when you're dealing with some absurdly designed API that only made sense in the super-flexible world of olden-days JavaScript, or perhaps if you're doing some meta-programming, generating class definitions on the fly or such.
    - andrew_ 5y ago
      > I've seen this take so many times an I simply don't get it. That may sincerely be, because how it feels as you're using it doesn't align with the objective truths of how it behaves. The definition of a strongly typed language has been well-cemented for some time. TypeScript does not completely align with that definition, thus it cannot be considered truly strongly typed.
      - twooster 5y ago
        https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing Wikipedia disagrees with you in the opening paragraph about strong and weak typing: it's contentious. For all practical purposes that I can think of, TypeScript creates a strongly typed environment. The problem comes when you're interacting with non-typed (or, worse, incorrectly-manually-typed) libraries, or misuse `any`. Honestly, I'd be interested to see a pure TypeScript program and where weak typing comes in. There are definitely a couple of language escapes (again, `JSON.parse`, previously `fn.bind`), but these are going away as TS gains better inference and type-propagation logic.
  - manigandham 5y ago
    All typing is a mirage, enforced at various levels by various tools, whether that's a compiler during the build or a VM during runtime. Everything gets compiled down to the same machine code in the end.
- Otek 5y ago
  It's no more, or less future-proof. And as much as counting productivity of a programmer in LOC doesn't make any sense, your take on typescript does not either. It's extra security that matters. Typescript just prevents you from shooting your foot off (btw. show me, even small program, where Typescipt added 50% LOC)
  - deleted 5y ago
    [deleted]
Otek 5y ago
1. yeah but mostly node is used as a server software. Python is much better as 'general purpose' right now 3. ????? Why would you ship with node_modules? ALWAYS use npm install. If you don't trust npm, the use something like CodeArtifact, but oh my, don't compress dependencies.
- throwaway894345 5y ago
  > Python is much better as 'general purpose' right now Python has lots of its own problems. Specifically, its type system, performance, and package management are all awful. > Why would you ship with node_modules? ALWAYS use npm install. If you don't trust npm, the use something like CodeArtifact, but oh my, don't compress dependencies. You've certainly convinced me that Deno's single binary deployment is a useful feature.
- IggleSniggle 5y ago
  1. I don't buy that python is necessarily much better as general purpose. It has a lot of great libraries for some specific things, but its performance is worse and its type story isn't nearly as good as TypeScript's. 3. I have a few internal CLIs for use in scenarios that don't have npm available by default. It's very nice to be able to ship a single runtime and not have the folks downstream from me need to worry about node version + npm version + package installs from untrusty sources, etc. I can do that work so they don't need to, and give them a single runtime. I happen to not use Deno at the moment, but it's an appealing feature. Python has a comparable problem: I run into issues with some frequency around python versions and python environments. There are solutions, yes, but there are also scenarios where you want to bring your own dependencies. I haven't used CodeArtifact, but is it something you can deploy on-premise?
- schwartzworld 5y ago
  > yeah but mostly node is used as a server software. As a frontend dev, I use node tooling every day that has nothing to do with server code. > Python is much better as 'general purpose' Node is just fine for general purpose. I use it for shell scripting without any difficulty. Working with async in JS is a dream compared to most languages, and although I rarely use dependencies, when you need `em, node has a great ecosystem. That said, I am 100% sold on Deno. Secure by default might not matter for server code that is going to have a couple of instances of it running, but the need to enable explicit flags for insecure APIs means that people who don't know how (or care) to read the code can use your program knowing that it literally can't access their filesystem or whatever. Beyond that, Deno uses Promises for async. Node was built before promises and many APIs rely on callbacks vs promises. It also has the ability to compile to an executable. But the number one for me is that the APIs mirror the browser APIs. This makes it much easier to extend frontend knowledge to building my own tooling.
thatwasunusual 5y ago
> personally I don't see why you'd want to use anything other than Typescript right now. Ditto. It's also important to remember that TS transpiles to JS, so you're not locked in in that sense. (I've actually seens TS-to-JS-transpiled code that is much better than code that was written in/as JS in the first place.)
fulafel 5y ago
> personally I don't see why you'd want to use anything other than Typescript right now. It certainly feels like TypeScript has "won" and is now the defacto standard for anyone doing any kind of work in the JS-ecosystem. There are a bunch of nice languages featuring good FP support that compile to JS that are have viable sized developer communities and longer histories than TS. For example ReasonML, ClojureScript, Flow and Elm. Then you have the bunch of languages that compile to asm.js or WebAssembly. Not to mention the majority of Node and FE developers who continue to use JS.
- llimos 5y ago
  > Not to mention the majority of Node and FE developers who continue to use JS. I don't think this is true any more. According to https://2020.stateofjs.com/en-US/technologies/javascript-flavors/ https://2020.stateofjs.com/en-US/technologies/javascript-fla... 78% of JS devs actively use TypeScript
  - nightpool 5y ago
    I've never used TypeScript. I've also never heard of this survey before, and I certainly didn't fill it out. I don't think these two facts are unrelated—according to their data, the vast plurality (48%, almost a majority) of the people who filled out that survey did so because they were on the mailing list for it. It's by no means a random or representative sample of the community. People who are more interested in surveys & new technology and are more likely to sign up to answer future surveys. Meanwhile, the StackOverflow 2020 survey, which reached twice as many JS developers (54k vs 23k), saw that only half of JS developers reported using TypeScript. (not counting any developers that reported using TS but not JS, which would drive the percentage further down). Again though—people who are more likely to fill out random surveys are going to be more plugged in to new technologies and more likely to adopt them. I've never used Typescript, and I don't plan to. I don't care about static typing. It's nice occasionally, but I don't find that the structural problems I need to solve day to day when working on large codebases are the sorts best solved by static typing. When working on hobby projects, I don't use JS compilers at all, the set of JS supported by modern browsers is already very expressive and iterating very quickly.
vagrantJin 5y ago
> feels like TS is where its at. Yes. It seems the majority of engineering decisions are tighly coupled to this expression right there. Future be damned because a Medium.com ex-FAANG said TS is where it's at Bless them and the hype train, woe to developers 5 years from now.
rglover 5y ago
> personally I don't see why you'd want to use anything other than Typescript right now A desire to not have IP coupled to Microsoft and a desire to put the burden/discipline on the self to ensure clean API design versus using TypeScript as a crutch to do it for you. In my experience, writing JavaScript code that's conscious of types/inputs/etc. is far easier (and more productive) than maintaining a TS codebase and all the trimmings that come with it (i.e., dependency on build tools, frameworks, etc). A lot of hidden costs.
- jolux 5y ago
  How is TypeScript a crutch for API design?
  - rglover 5y ago
    API meaning data API/structure, not a public/restful API.
- manigandham 5y ago
  How are you conscious of types without any tooling? And if you use tooling, then what's the difference?
  - rglover 5y ago
    When you design your API/write functions, you just ask "what is the type in play here (e.g., a string, int, etc)?" and then consider what—if any—issues that may cause and write code against it. For example, JavaScript default args are really helpful for avoiding type errors: const nameString = (name = {}) => { return `${name.first} ${name.last}`; }; Here, because I set a default expected type (technically speaking), I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case, or, write a test to call my attention to the problem (often unnecessary because the "bug" is a design issue).
    - imbnwa 5y ago

franciscop 5y ago

[deleted comment]

andrew_ 5y ago
This is something often overlooked by fans of typing. On the surface it may appear to some as being strongly typed, but it's a mirage [1] and frequently requires a lot more lifting, e.g. writing specific typings to work around shortcomings, just to make the types play nice together. That's not a feature of a strongly typed language, it's a feature of statically type-checked languages or schemas. I still use TypeScript, and I understand the benefits, but I'm not always a fan and will write plain JS when it fits better than TS. [1] https://news.ycombinator.com/item?id=15090561 https://news.ycombinator.com/item?id=15090561
- k__ 5y ago
  I didn't like TypeScript when writing frontend only code, because the the iteration speed is just so fast in the browser. But when I started using it for backend and infra, the iteration speed is much slower, so even TS only saves a few % of deploys, it's still a noticeable amount of absolute time.
  - handrous 5y ago
    Typescript is miraculously productive on the front-end as soon as you've got people writing at different "layers"—someone writing a frontend library, someone else handling state and actions, someone writing components for re-use, someone making it look pretty and using those components. You can be sitting right next to someone using code you wrote but rarely need to discuss it because the types communicate everything so damn well.
- twooster 5y ago
  I've seen this take so many times an I simply don't get it. The notion that TypeScript can't be (some form of) strongly-typed because Javascript is (some form of) weakly-typed is just silly. CPUs are entirely weakly typed in this sense and this doesn't impact the typings of languages built on top. JavaScript is strongly typed in the sense that every value has a well-defined type. It's weak in the sense that it has implicit conversion between types in a lot of cases, but it's not as though those conversions don't follow particular rules if you know the types. TypeScript gives you accurate static typing on top of that, so long as you don't use `any` as an escape. Arguably, `JSON.parse` returning `any` is the 1-million dollar mistake of TypeScript, because it leads a lot of people to think that they get automatic runtime typechecking for free, which they obviously don't, which leads to comments about how bad/slippery TypeScript is stemming from their misunderstanding. In my experience, you only need to work around typings in TypeScript when you're dealing with some absurdly designed API that only made sense in the super-flexible world of olden-days JavaScript, or perhaps if you're doing some meta-programming, generating class definitions on the fly or such.
  - andrew_ 5y ago
    > I've seen this take so many times an I simply don't get it. That may sincerely be, because how it feels as you're using it doesn't align with the objective truths of how it behaves. The definition of a strongly typed language has been well-cemented for some time. TypeScript does not completely align with that definition, thus it cannot be considered truly strongly typed.
    - twooster 5y ago
      https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing Wikipedia disagrees with you in the opening paragraph about strong and weak typing: it's contentious. For all practical purposes that I can think of, TypeScript creates a strongly typed environment. The problem comes when you're interacting with non-typed (or, worse, incorrectly-manually-typed) libraries, or misuse `any`. Honestly, I'd be interested to see a pure TypeScript program and where weak typing comes in. There are definitely a couple of language escapes (again, `JSON.parse`, previously `fn.bind`), but these are going away as TS gains better inference and type-propagation logic.
- manigandham 5y ago
  All typing is a mirage, enforced at various levels by various tools, whether that's a compiler during the build or a VM during runtime. Everything gets compiled down to the same machine code in the end.
Otek 5y ago
It's no more, or less future-proof. And as much as counting productivity of a programmer in LOC doesn't make any sense, your take on typescript does not either. It's extra security that matters. Typescript just prevents you from shooting your foot off (btw. show me, even small program, where Typescipt added 50% LOC)
- deleted 5y ago
  [deleted]

Otek 5y ago

1. yeah but mostly node is used as a server software. Python is much better as 'general purpose' right now 3. ????? Why would you ship with node_modules? ALWAYS use npm install. If you don't trust npm, the use something like CodeArtifact, but oh my, don't compress dependencies.

throwaway894345 5y ago
> Python is much better as 'general purpose' right now Python has lots of its own problems. Specifically, its type system, performance, and package management are all awful. > Why would you ship with node_modules? ALWAYS use npm install. If you don't trust npm, the use something like CodeArtifact, but oh my, don't compress dependencies. You've certainly convinced me that Deno's single binary deployment is a useful feature.
IggleSniggle 5y ago
1. I don't buy that python is necessarily much better as general purpose. It has a lot of great libraries for some specific things, but its performance is worse and its type story isn't nearly as good as TypeScript's. 3. I have a few internal CLIs for use in scenarios that don't have npm available by default. It's very nice to be able to ship a single runtime and not have the folks downstream from me need to worry about node version + npm version + package installs from untrusty sources, etc. I can do that work so they don't need to, and give them a single runtime. I happen to not use Deno at the moment, but it's an appealing feature. Python has a comparable problem: I run into issues with some frequency around python versions and python environments. There are solutions, yes, but there are also scenarios where you want to bring your own dependencies. I haven't used CodeArtifact, but is it something you can deploy on-premise?
schwartzworld 5y ago
> yeah but mostly node is used as a server software. As a frontend dev, I use node tooling every day that has nothing to do with server code. > Python is much better as 'general purpose' Node is just fine for general purpose. I use it for shell scripting without any difficulty. Working with async in JS is a dream compared to most languages, and although I rarely use dependencies, when you need `em, node has a great ecosystem. That said, I am 100% sold on Deno. Secure by default might not matter for server code that is going to have a couple of instances of it running, but the need to enable explicit flags for insecure APIs means that people who don't know how (or care) to read the code can use your program knowing that it literally can't access their filesystem or whatever. Beyond that, Deno uses Promises for async. Node was built before promises and many APIs rely on callbacks vs promises. It also has the ability to compile to an executable. But the number one for me is that the APIs mirror the browser APIs. This makes it much easier to extend frontend knowledge to building my own tooling.

thatwasunusual 5y ago

> personally I don't see why you'd want to use anything other than Typescript right now. Ditto. It's also important to remember that TS transpiles to JS, so you're not locked in in that sense. (I've actually seens TS-to-JS-transpiled code that is much better than code that was written in/as JS in the first place.)

fulafel 5y ago

> personally I don't see why you'd want to use anything other than Typescript right now. It certainly feels like TypeScript has "won" and is now the defacto standard for anyone doing any kind of work in the JS-ecosystem. There are a bunch of nice languages featuring good FP support that compile to JS that are have viable sized developer communities and longer histories than TS. For example ReasonML, ClojureScript, Flow and Elm. Then you have the bunch of languages that compile to asm.js or WebAssembly. Not to mention the majority of Node and FE developers who continue to use JS.

llimos 5y ago
> Not to mention the majority of Node and FE developers who continue to use JS. I don't think this is true any more. According to https://2020.stateofjs.com/en-US/technologies/javascript-flavors/ https://2020.stateofjs.com/en-US/technologies/javascript-fla... 78% of JS devs actively use TypeScript
- nightpool 5y ago
  I've never used TypeScript. I've also never heard of this survey before, and I certainly didn't fill it out. I don't think these two facts are unrelated—according to their data, the vast plurality (48%, almost a majority) of the people who filled out that survey did so because they were on the mailing list for it. It's by no means a random or representative sample of the community. People who are more interested in surveys & new technology and are more likely to sign up to answer future surveys. Meanwhile, the StackOverflow 2020 survey, which reached twice as many JS developers (54k vs 23k), saw that only half of JS developers reported using TypeScript. (not counting any developers that reported using TS but not JS, which would drive the percentage further down). Again though—people who are more likely to fill out random surveys are going to be more plugged in to new technologies and more likely to adopt them. I've never used Typescript, and I don't plan to. I don't care about static typing. It's nice occasionally, but I don't find that the structural problems I need to solve day to day when working on large codebases are the sorts best solved by static typing. When working on hobby projects, I don't use JS compilers at all, the set of JS supported by modern browsers is already very expressive and iterating very quickly.

vagrantJin 5y ago

> feels like TS is where its at. Yes. It seems the majority of engineering decisions are tighly coupled to this expression right there. Future be damned because a Medium.com ex-FAANG said TS is where it's at Bless them and the hype train, woe to developers 5 years from now.

rglover 5y ago

> personally I don't see why you'd want to use anything other than Typescript right now A desire to not have IP coupled to Microsoft and a desire to put the burden/discipline on the self to ensure clean API design versus using TypeScript as a crutch to do it for you. In my experience, writing JavaScript code that's conscious of types/inputs/etc. is far easier (and more productive) than maintaining a TS codebase and all the trimmings that come with it (i.e., dependency on build tools, frameworks, etc). A lot of hidden costs.

jolux 5y ago
How is TypeScript a crutch for API design?
- rglover 5y ago
  API meaning data API/structure, not a public/restful API.
manigandham 5y ago
How are you conscious of types without any tooling? And if you use tooling, then what's the difference?
- rglover 5y ago
  When you design your API/write functions, you just ask "what is the type in play here (e.g., a string, int, etc)?" and then consider what—if any—issues that may cause and write code against it. For example, JavaScript default args are really helpful for avoiding type errors: const nameString = (name = {}) => { return `${name.first} ${name.last}`; }; Here, because I set a default expected type (technically speaking), I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case, or, write a test to call my attention to the problem (often unnecessary because the "bug" is a design issue).
  - imbnwa 5y ago