The other kind of JavaScript fatigue
chrismm.com
The other kind of JavaScript fatigue
1–10 of 99 posts
Re: The other kind of JavaScript fatigue
#2This 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.
Re: The other kind of JavaScript fatigue
#3Realized this sometime ago, when I was wondering why the Java ecosystem doesn't have this problem. It boils down to the barrier of entry. On JS it's so low as to be almost nonexistent, which is why you end up with junk like isPositiveInteger. Slap some shit together and ship it.
You can't do that easily in Java. You need to spend some time understanding the language, the ecosystem, how to bundle your code into an artifact, and then how to release and publish it; the barrier of entry is much higher because there is a lot more to learn and understand.
The article mentions Android - I haven't worked much with Android and so I'm not familiar with the libraries there. Is there the same sort of problem in the Android ecosystem that you see in Node? I wonder if he is talking about the fragmentation of Android implementations (flavors from different providers), which is a different thing entirely. Seeing as Android uses Java, I'm thinking the ecosystem is not like Node.
Re: The other kind of JavaScript fatigue
#4> 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?
Re: The other kind of JavaScript fatigue
#5This 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.
But his bigger point is that we need better tooling for improving existing code. Which is more achievable than "write better code".
Re: The other kind of JavaScript fatigue
#6Maybe 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?
Re: The other kind of JavaScript fatigue
#7This 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.
But his bigger point is that we need better tooling for improving existing code. Which is more achievable than "write better code".
you can't be serious...
Re: The other kind of JavaScript fatigue
#8This 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 happier and happier with react over the last two years. Redux is also consistently making me smile.
Re: The other kind of JavaScript fatigue
#9Realized this sometime ago, when I was wondering why the Java ecosystem doesn't have this problem. It boils down to the barrier of entry. On JS it's so low as to be almost nonexistent, which is why you end up with junk like isPositiveInteger. Slap some shit together and ship it. You can't do that easily in Java. You need to spend some time understanding the language, the ecosystem, how to bundle your code into an art…
That's why there's JSweet, the Java to Javascript transpiler.
Re: The other kind of JavaScript fatigue
#10> The fragmented nature of large open source ecosystems has become evident since the advent of Android.
Is the author talking about the fragmentation of libraries and tools for Android, or the general "Android fragmentation"? If it's the former then I haven't experienced it, certainly not to the extent of the Node ecosystem. Yet...
> [...] because languages with smaller communities such as Go [...] don’t yet suffer from it
... I disagree, take for example the tons of different projects trying to "solve" the web framework problem, or the dependency problem, etc.