Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
I don't think Typescript does anything more OOP than JavaScript (ES2015+) does, besides Interfaces (which also appear in functional languages).
Typescript supports all the same functional concepts that JavaScript does, including being able to type higher-order functions. It also includes other functional concepts that aren't in JavaScript, like union types, or even better, discriminated unions.
I am talking about complexity, and the way I see the language generally used in practice.
TS has more features, that is the entire point of the language.
Exampletime,
Just yesterday I was debugging a TS npm library, all I wanted was add to poke the source with a few console logs.
But because it was a TS library it came in 5 different ES versions, had a slew of typings I had to see through, and the actual source was not included because npm is for JS.
This would have forced me to get the source code, hook it up to my npm dependencies and then build it with my few debug changes.
Is there a better way to debug, problably yes, I could have explored the map in the browser and addd breakpoints, or use some other tool.
Had this been a JS library I would have spend a few minutes looking over the source.
Now, imagine a junior wanting to do this.
Complexity comes at cost, it is the entire point of functional programming, but centered around the problem of state management.
Toting TS as a good tool for functional programming is like saying eating children is a good way to prevent hunger.
Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
Yeah, that all makes sense. It's definitely a different workflow.
I'm used to other languages that don't ship source code in packages, so this is nothing new to me.
Npm package authors could include source if they wanted - so the lack of it seems more like a personal choice on the part of the author.
Also, the issues you noted about all the transpiled variations of JavaScript for that Typescript authored lib ... those appear with JavaScript libraries too!
If a js lib author uses Babel to support older versions of Node or browsers, they will include transpiled versions of their js code.
This seems to be more an issue of the JavaScript tooling ecosystem still needing to mature.
In .NET/C# I can make a package that has compiled code only, but includes a hash to a git commit. When I'm debugging, my IDE pulls the repo code down to my machine and lets me debug into it live. It's a great developer experience.
I think the JavaScript community will come up with similar creative solutions.
Lack of tools is not really the problem, quite the opposite the way I see it.
Tools should make us more productive, not be a nessesary thing to be productive at all.
The fact that we are even talking about solving the problem with more IDE tools suggests a flaw in the system.
We need something that will reduce complexity at this point. Otherwise the frontend community will end up fragmenting into completely unessesary domains of knowledge based on frameworks and what kind of transpilation we do.
I'm a fan of Open Source and have a growing interest in serverless and edge computing. I'm not a big fan of spiders, but they're doing good work eating bugs. I also stream on Twitch.
Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
I don't think Typescript does anything more OOP than JavaScript (ES2015+) does, besides Interfaces (which also appear in functional languages).
Typescript supports all the same functional concepts that JavaScript does, including being able to type higher-order functions. It also includes other functional concepts that aren't in JavaScript, like union types, or even better, discriminated unions.
I am talking about complexity, and the way I see the language generally used in practice.
TS has more features, that is the entire point of the language.
Exampletime,
Just yesterday I was debugging a TS npm library, all I wanted was add to poke the source with a few console logs.
But because it was a TS library it came in 5 different ES versions, had a slew of typings I had to see through, and the actual source was not included because npm is for JS.
This would have forced me to get the source code, hook it up to my npm dependencies and then build it with my few debug changes.
Is there a better way to debug, problably yes, I could have explored the map in the browser and addd breakpoints, or use some other tool.
Had this been a JS library I would have spend a few minutes looking over the source.
Now, imagine a junior wanting to do this.
Complexity comes at cost, it is the entire point of functional programming, but centered around the problem of state management.
Toting TS as a good tool for functional programming is like saying eating children is a good way to prevent hunger.
It overlooks the actual problem.
Yeah, that all makes sense. It's definitely a different workflow.
I'm used to other languages that don't ship source code in packages, so this is nothing new to me.
Npm package authors could include source if they wanted - so the lack of it seems more like a personal choice on the part of the author.
Also, the issues you noted about all the transpiled variations of JavaScript for that Typescript authored lib ... those appear with JavaScript libraries too!
If a js lib author uses Babel to support older versions of Node or browsers, they will include transpiled versions of their js code.
This seems to be more an issue of the JavaScript tooling ecosystem still needing to mature.
In .NET/C# I can make a package that has compiled code only, but includes a hash to a git commit. When I'm debugging, my IDE pulls the repo code down to my machine and lets me debug into it live. It's a great developer experience.
I think the JavaScript community will come up with similar creative solutions.
Lack of tools is not really the problem, quite the opposite the way I see it.
Tools should make us more productive, not be a nessesary thing to be productive at all.
The fact that we are even talking about solving the problem with more IDE tools suggests a flaw in the system.
We need something that will reduce complexity at this point. Otherwise the frontend community will end up fragmenting into completely unessesary domains of knowledge based on frameworks and what kind of transpilation we do.
More so than it already has.
Came across this today. I rarely use classes myself, but I thought this was pertinent to the convo.
And I love the new VueJs 3 functional component API RFC.
Functional + Types = 💗.