Although I definitely agree that Deno is simply a "reboot of Node.js" (so to speak), I feel as though your "general spectrum of TS users" underrepresents those who truly value from the tooling TS provides.
For me, my main use case for TypeScript is the tooling for IDEs. Debugging JS-powered web applications is much easier with type-checking because of some "contractual guarantees". I must concede that it doesn't solve all bugs, but the contracts do provide some helpful autocompletion suggestions during development.
In response to your suggestion of using JSDoc instead, I would agree to this to some extent because it is indeed a nice substitute for the "JS purists" out there who also want a piece of the TS tooling's cake.
I tried JSDoc myself before migrating my side projects to TypeScript, but I found the comments to be a bit too verbose and cumbersome for my liking. Furthermore, the JSDoc tooling for IDEs (such as in VS Code) is vastly inferior to actual TypeScript. Basic support for types are included, which is good for small projects, but I would imagine that larger projects would simply be better off using TS altogether instead of JSDoc.
And just to add a few more bits of information here, TypeScript also powers the JavaScript "language servers" for many IDEs. At least in VS Code, TypeScript powers the autocompletion for JavaScript and JSDoc. To say that TypeScript is just a fad misrepresents the value of JS tooling we have nowadays.
Sure, one can opt to write pure JS, but at the end of the day, many of our tools (for JS) depends on TypeScript to provide rich developer experiences.
In defense of Deno, Deno simply supports this kind of tooling "out-of-the-box" without the hassle of installing a plethora of NPM packages. That, to me, is the main selling point of Deno. Perhaps not the runtime itself, but the native support for the incredible tooling of the TS ecosystem.
"the converted" (these are the developers who've accepted the benefits of autocompletions brought by TS and really enjoy writing code this style.),
i genuinely didn't mean it in derogatory sense, i do appreciate the value TS provides for many people. sorry for any harsh feelings i do see that on the background of other points it might have looked negatively
yeah thanks for your comments they're really useful. as i said there are (and many) people who find salvation in ts and for the right reasons, like contractual obligations.
ah it's true ts provides jsdoc support for us so sure it deserves 👍 on that but it might have been just anything else. it's just because MS give vs code for free nobody wants to or needs to do that job because they won't be able to compete with the IDE. I don't know what webstorm uses for example, it might be TS it might not be, but sure it's possible to perform static analysis without TS isn't, so the implementation can be anything.
it's true jsdoc is pain for larger projects and your comment about it is very much appreciated. i don't use blank jsdoc i use a type manager that generates jsdoc on top of types, so that the types model is actually decoupled from implementation. that also hides away all those bulky /** */ comments in the implementation source code. It's true there's a lot of junk, and Go uses a different format and /// natural language to describe [attributes], but once you put it away, it doesn't get in a way and one can focus on writing code. Finally, personally I'm doc maniac and want every public API param to be documented. I know in TS, you can type params to functions(s: string), but if you want to describe it, you still need to write jsdoc.
For me, the "bulkiness" of JSDoc comments is what threw me off the first time. The two code blocks below are semantically equivalent, but TypeScript frankly does it more elegantly.
But relating back to Deno, the whole point of my comment earlier was to shed some light on the perspective that Deno's goal as a runtime is to provide native support for what used to be a cumbersome process of installing and configuring various NPM packages. It's basically the best of JS, but in one neat executable.
As a disclaimer, though, I am certainly not advocating for it's production use yet, but it really is an interesting "toy" to look out for.
how do you mean various npm packages? what would you need apart from actual typescript? aren't packages compiled into js with types.d.ts provided so that you don't really need anything.
this i get 100% it's more natural to flow types like that (for PRIVATE code). Yet I still don't mind to write the first kind if it spares me installing 50mb binary :P
yet when you come writing APIs, in both cases you need
/**
* Returns an example.
* @param {string} s The first part of the string.
* @param {string} t The second part of the string.
*/exportdefaultfunctionexample(s,t){return`${s}.${t}`}
But then you're not generating full doc. Maybe it's not needed to have full docs with description of params, but I like it. In any way, I believe that documentation CAN be decoupled from code altogether so that you have your types defined completely independently of implementation, and can convert them into an interface in any language, be it js, ts, dart, go... the design stage i mentioned in the post involves object modelling, which can be split into Conceptual (business stakeholders), logical (db entities) and physical (data types). So that types are not even part of implementation. By taking a step back, we can take those out of the actual source code, and design "abstract" types. This means that we can then distribute those designs between members of the team, and they can communicate and work on them in their own time, such that the front-ender will do his job in JS/TS, and back-ender can work with the same data types in say Go or anything else and they'll be consistent with each other. there are many times web development is a one-man job, but for larger, and truly scalable projects we need a better approach :)
I can't really argue against your separation of concerns (as in documentation and implementation). I actually agree with it. Unfortunately, it's really just a matter of taste when it comes to the discussion of syntax.
In regard to the "NPM packages" I mentioned, I will particularly note Webpack and Babel for more advanced TypeScript projects. Testing TypeScript is a whole other beast in and of itself, too. That's what I mean by TypeScript being a hassle in the default Node environment (compared to Deno).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Although I definitely agree that Deno is simply a "reboot of Node.js" (so to speak), I feel as though your "general spectrum of TS users" underrepresents those who truly value from the tooling TS provides.
For me, my main use case for TypeScript is the tooling for IDEs. Debugging JS-powered web applications is much easier with type-checking because of some "contractual guarantees". I must concede that it doesn't solve all bugs, but the contracts do provide some helpful autocompletion suggestions during development.
In response to your suggestion of using JSDoc instead, I would agree to this to some extent because it is indeed a nice substitute for the "JS purists" out there who also want a piece of the TS tooling's cake.
I tried JSDoc myself before migrating my side projects to TypeScript, but I found the comments to be a bit too verbose and cumbersome for my liking. Furthermore, the JSDoc tooling for IDEs (such as in VS Code) is vastly inferior to actual TypeScript. Basic support for types are included, which is good for small projects, but I would imagine that larger projects would simply be better off using TS altogether instead of JSDoc.
And just to add a few more bits of information here, TypeScript also powers the JavaScript "language servers" for many IDEs. At least in VS Code, TypeScript powers the autocompletion for JavaScript and JSDoc. To say that TypeScript is just a fad misrepresents the value of JS tooling we have nowadays.
Sure, one can opt to write pure JS, but at the end of the day, many of our tools (for JS) depends on TypeScript to provide rich developer experiences.
In defense of Deno, Deno simply supports this kind of tooling "out-of-the-box" without the hassle of installing a plethora of NPM packages. That, to me, is the main selling point of Deno. Perhaps not the runtime itself, but the native support for the incredible tooling of the TS ecosystem.
you're
i genuinely didn't mean it in derogatory sense, i do appreciate the value TS provides for many people. sorry for any harsh feelings i do see that on the background of other points it might have looked negatively
No offense taken at all! 😉
This is a great discussion about what Deno really provides to the community. I just plopped in my two cents to the table.
yeah thanks for your comments they're really useful. as i said there are (and many) people who find salvation in ts and for the right reasons, like contractual obligations.
ah it's true ts provides jsdoc support for us so sure it deserves 👍 on that but it might have been just anything else. it's just because MS give vs code for free nobody wants to or needs to do that job because they won't be able to compete with the IDE. I don't know what webstorm uses for example, it might be TS it might not be, but sure it's possible to perform static analysis without TS isn't, so the implementation can be anything.
it's true jsdoc is pain for larger projects and your comment about it is very much appreciated. i don't use blank jsdoc i use a type manager that generates jsdoc on top of types, so that the types model is actually decoupled from implementation. that also hides away all those bulky /** */ comments in the implementation source code. It's true there's a lot of junk, and Go uses a different format and
/// natural language to describe [attributes], but once you put it away, it doesn't get in a way and one can focus on writing code. Finally, personally I'm doc maniac and want every public API param to be documented. I know in TS, you can type params to functions(s: string), but if you want to describe it, you still need to write jsdoc.I totally agree, man. I see what you mean. 👍
For me, the "bulkiness" of JSDoc comments is what threw me off the first time. The two code blocks below are semantically equivalent, but TypeScript frankly does it more elegantly.
But relating back to Deno, the whole point of my comment earlier was to shed some light on the perspective that Deno's goal as a runtime is to provide native support for what used to be a cumbersome process of installing and configuring various NPM packages. It's basically the best of JS, but in one neat executable.
As a disclaimer, though, I am certainly not advocating for it's production use yet, but it really is an interesting "toy" to look out for.
how do you mean various npm packages? what would you need apart from actual
typescript? aren't packages compiled into js with types.d.ts provided so that you don't really need anything.this i get 100% it's more natural to flow types like that (for PRIVATE code). Yet I still don't mind to write the first kind if it spares me installing 50mb binary :P
yet when you come writing APIs, in both cases you need
I mean you could've do
But then you're not generating full doc. Maybe it's not needed to have full docs with description of params, but I like it. In any way, I believe that documentation CAN be decoupled from code altogether so that you have your types defined completely independently of implementation, and can convert them into an interface in any language, be it js, ts, dart, go... the design stage i mentioned in the post involves object modelling, which can be split into Conceptual (business stakeholders), logical (db entities) and physical (data types). So that types are not even part of implementation. By taking a step back, we can take those out of the actual source code, and design "abstract" types. This means that we can then distribute those designs between members of the team, and they can communicate and work on them in their own time, such that the front-ender will do his job in JS/TS, and back-ender can work with the same data types in say Go or anything else and they'll be consistent with each other. there are many times web development is a one-man job, but for larger, and truly scalable projects we need a better approach :)
I can't really argue against your separation of concerns (as in documentation and implementation). I actually agree with it. Unfortunately, it's really just a matter of taste when it comes to the discussion of syntax.
In regard to the "NPM packages" I mentioned, I will particularly note Webpack and Babel for more advanced TypeScript projects. Testing TypeScript is a whole other beast in and of itself, too. That's what I mean by TypeScript being a hassle in the default Node environment (compared to Deno).