The other kind of JavaScript fatigue • Hacker News Board

Re: The other kind of JavaScript fatigue

#21

Post by sebcat » Sat, Jul 16, 2016, 2:33 PM UTC

rosalinekarr wrote: post #6

Maybe what we need is a better system for assessing and comparing javascript projects. In the Ruby world, RubyToolbox has a great system that tells you about gem's popularity, update frequency, age and a ton of other stuff. Is there a similar project for the javascript world?

Or just review the code. It's not hard, and if you add a dependency to your code base you should review it. If you lack the ability, time or then you should not add it as a dependency.

DRY only goes so far. If you can do the same thing with a couple of hours of work, it's probably not worth adding an external dependency that you need to track over time.

Re: The other kind of JavaScript fatigue

#22

Post by scotttrinh » Sat, Jul 16, 2016, 2:34 PM UTC

nzoschke wrote: post #19

I 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 justi…

> Next, the dynamic nature of JavaScript is to blame. You can't easily extract and compile just the functions you need.

Definitely check out rollup, if you haven't heard of it. We (the JavaScript community) are working towards solving this!

Re: The other kind of JavaScript fatigue

#23

Post by cyberpanther » Sat, Jul 16, 2016, 2:34 PM UTC

vivin wrote: post #17

cyberpanther wrote: post #14

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

I think you might have hit something here. Because Perl is definitely hard to read and with bare documentation, the module might have been fine but we just never knew how to use it.

Re: The other kind of JavaScript fatigue

#24

Post by vivin » Sat, Jul 16, 2016, 2:35 PM UTC

EugeneOZ wrote: post #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.

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

It's much harder to ship SO copypasta in say, Java or C#, than in Node. JavaScript is a much easier language to grasp and it is also a lot more forgiving and loose. Combine that with NPM and can suddenly be immensely "productive". But the ability to write and push a lot of code very fast also means that it makes it very easy to write and push a lot of bad code very fast.

Re: The other kind of JavaScript fatigue

#25

Post by n0us » Sat, Jul 16, 2016, 2:38 PM UTC

One factor that leads to fragmentation is this "theme" that I seem to see over and over that when a project is popular the creator gets to be the github maintainer and take credit for it's success as a large and popular project, which by itself is a good thing.

The bad part is that when the maintainers make unpopular decisions like disabling all functionality by default and relying on submodules, or not wanting to fix some obviously horrible bug because it's a 'feature', or abandoning the project for months at a time, often there is a cop out mentality that goes along the lines of "well it's my project and I didn't guarantee anything when you decided to use it so why don't you go make your own." There by taking credit for the project's successes but not responsibility for it's failures. So then people do go and write their own implementations and we end up with half a dozen half baked libraries.

An Example: Underscore and lodash are both very good, so are not examples of half-baked, but do we really need both of them? People will just say "well you only have to use one in your app... yada yada yada" but the problem is that if I want to rely on any other npm packages in my app, are they using lodash or underscore? I'll probably just end up with both of them shipping in the bundle because for whatever reason there couldn't just be one popular utility library, there had to be two that do basically the same thing. People will respond to this and say "well why don't you fork those modules that rely on underscore and make them use lodash?" My answer is no. I don't want to fork stuff. I just want to be able to find modules that I can rely on with a reasonable expectation of quality and maintenance. I'll even help maintain if it doesn't seem completely futile.

There may be some advantages of lodash over underscore in comparison to one another but those advantages are minor in comparison to what would be gained by having a single utility library that everyone is on board with.

Don't even get me started with routing libraries for React.

Re: The other kind of JavaScript fatigue

#26

Post by thesmart » Sat, Jul 16, 2016, 2:45 PM UTC

nzoschke wrote: post #19

I 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 justi…

jQuery, while mature and great, is fairly unnecessary considering all that HTML5 and ECMA maintainers have accomplished since jQuery matured.

Re: The other kind of JavaScript fatigue

#27

Post by zzzcpan » Sat, Jul 16, 2016, 2:46 PM UTC

endergen wrote: post #8

woah wrote: post #2

This doesn't really add much to the discussion. Sure, write better code. We all want to do that. To the author: I believe that the node standard library has the query string tools you are looking for.

My take away was that we need to work towards converging efforts rather than diverging and causing constant fragmentation and lost effort. It being easy to deploy is a good thing, but people need to try to reduce noise and fix existing good enough projects to make them great and robust. Contrary to my above points, I'm super in redux and react and feel they were large leaps in design over previous ones. I've been hap…

> My take away was that we need to work towards converging efforts rather than diverging and causing constant fragmentation and lost effort.

Fragmentation and lost effort are essential for progress. Things that you use today were created because someone decided not to work towards converging efforts.

Re: The other kind of JavaScript fatigue

#28

Post by krapp » Sat, Jul 16, 2016, 2:47 PM UTC

john2x wrote: post #18

I 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."

Github seems to want to be a social media site first and a git host second. Which is why I exclusively use Bitbucket now.

Re: The other kind of JavaScript fatigue

#29

Post by thesmart » Sat, Jul 16, 2016, 2:49 PM UTC

john2x wrote: post #18

I 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."

And the lack of repo ratings or author reputation. How is it that I can see 2,000 reviews about a taco stand down the street but I can't easily assess deps quality in a source base I depend on for my livelihood?

Re: The other kind of JavaScript fatigue

#30

Post by EugeneOZ » Sat, Jul 16, 2016, 2:52 PM UTC

vivin wrote: post #24

EugeneOZ wrote: post #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.

> 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. It's much harder to ship SO copypasta in say, Java or C#, than in Node. JavaScript is a much easier language to grasp and it is also a lot more forgiving and loose. Combine that with NPM and can suddenly be immensely "productive". But the ability to write and push a lot of code ve…

It only depends on programmer. Somebody copy-paste from SO to production, somebody write tests and run them before deployment. There is a lot of dynamic ("forgiving") languages, so JS is not unique here.