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 🍺
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 = 💗.