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.
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).