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