Wait, Angular 1 is dead? That's news to me.
The other kind of JavaScript fatigue
11–20 of 99 posts
Re: The other kind of JavaScript fatigue
#12I think the convenience of GitHub and NPM are good features, and it's easy to blame ease-of-use as a culprit. I have often pondered about how remarkably poor these tools are at representing repo quality. I think there are some basic questions to ask before accepting any unknown source in as a module. What is the core problem and requirements the source addresses? Does it verify the solution and how? What is the reputation of the core contributors? Is it used by any serious institutions? (Aside: download count and star count are a measure of herd mentality) What are the open issues? What are the closed "won't fix" issues? How often are issues regressed? What is a safe version? How is the versioning managed and how should I pin it? How many dependencies do I assume from this library? How severable are the dependencies?
It would be useful if package management tools facilitated the process of understanding the liability imposed by a package, but the opposite is encouraged. Authors too often put up shiny marketing materials and make bold statements about the utility and vision of their software. It would be refreshing if authors were as open about the flaws, trade-offs, alternatives, etc. but few are.
Perhaps some kind of rating or feedback system that is qualitative in nature would help mitigate the salesmanship? I'd love to know who has been burned by a project and anecdotes about how packages are used by others. Ratings around issue resolutions would also be helpful, how often have we all had major bugs dismissively closed by maintainers?
TL;DR there are ways to develop a comprehensive assessment of a repo, but our tools are lacking and need much improvement in this regard.
Re: The other kind of JavaScript fatigue
#13I think the convenience of GitHub and NPM are good features, and it's easy to blame ease-of-use as a culprit. I have often pondered about how remarkably poor these tools are at representing repo quality. I think there are some basic questions to ask before accepting any unknown source in as a module. What is the core problem and requirements the source addresses? Does it verify the solution and how? What is the reputation of the core contributors? Is it used by any serious institutions? (Aside: download count and star count are a measure of herd mentality) What are the open issues? What are the closed "won't fix" issues? How often are issues regressed? What is a safe version? How is the versioning managed and how should I pen it? How many dependencies do I assume from this library? How severable are the dependencies?
It would be useful if package management tools facilitated the process of understanding the liability imposed by a package, but the opposite is encouraged. Authors too often put up shiny market materials and make bold statements about utility and vision of their software. Perhaps some kind of rating or feedback system that is qualitative in nature would help mitigate the salesmanship? I'd love to know who has been burned by a project and anecdotes about how packages are used by others.
Re: The other kind of JavaScript fatigue
#14This is nothing new, JS just evolved the problem to the next level. Perl and CPAN had notoriously bad modules and each subsequent language has made packaging easier. And now JS is available with easy packaging or just by including a URL to the package. This problem is inevitable. JS just is the current most widely distributed and used language.
I think we have to learn live with crap code and find ways to surface the diamonds. A rating system for packages would be great. Maybe based on developer ratings, amount of contributors/community interaction, and number of unresolved issues?
Re: The other kind of JavaScript fatigue
#15> Remember Google’s Polymer? Angular 1? Express? Perhaps the organizations and individuals which cause these abrupt termination events should carry a stigma. Why is Polymer on this list?
Same question. As far as I know, it's a pretty active project. Did the author mean the jump from v. 0.5 to v. 1.0? That had some breaking changes, but that was expected.
Re: The other kind of JavaScript fatigue
#16"JavaScript programmer" term is similar to "vegan" - nobody cares if they only use one programming language for all tasks, but they constantly tell others about that.
What this article is about? Snippets from SO answers are not as good as battle-tested code? It's obvious and it's same in all languages. You can't find library for any task in tracker you have? Same thing.
Re: The other kind of JavaScript fatigue
#17This is nothing new, JS just evolved the problem to the next level. Perl and CPAN had notoriously bad modules and each subsequent language has made packaging easier. And now JS is available with easy packaging or just by including a URL to the package. This problem is inevitable. JS just is the current most widely distributed and used language. I think we have to learn live with crap code and find ways to surface the…
I guess my experience with CPAN has been different. Probably the most frustrating thing is the paucity of documentation from certain perl modules. But the modules I've found and used have been pretty good quality and pretty stable.
Then again, I've never built anything "enterprisey" in Perl (just little tools and scripts here and there), so that could it be it.
Re: The other kind of JavaScript fatigue
#18I blame Github, in particular its "stars" feature. It makes putting out code a popularity contest.
"Why should I make someone else's project more popular? I'd rather spend my free time making myself popular."
Re: The other kind of JavaScript fatigue
#19I see his point and I think another dimension of the tooling is a root cause too...
> Recently I needed a library to build query strings, just a small one so that I wouldn’t have to include jQuery just for that. After a couple of hours of research...
jQuery clearly is the best library to look to for a mature implementation. So why not just use it? Hours looking for alternatives is actually really expensive.
The justification is that jQuery is too big.
First It's probably not too big. CDNs and browser caching exist to optimize the problem upstream.
Next, the dynamic nature of JavaScript is to blame. You can't easily extract and compile just the functions you need.
Ideally we could all leverage bits of jQuery instead of poorly rewriting parts of it in the name of minimalism.
Re: The other kind of JavaScript fatigue
#20The basis of the complaints raised in this article, is that they didn't want to include jQuery just for the query string parser. I think rollup and ES2015 modules is taking us in the right direction which allows large projects like jQuery and lodash to be kitchen sinks, but to be used piecemeal. I think that will get us a long way toward the less-sensitive-to-filesize ecosystems that were compared in this article.