<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>kowdermeister</author><text>First the term. By fragmentation I mean two things: 1) we have many libraries doing the same thing. 2) the implementation is JS is not the same in every environment.&lt;p&gt;If you are spending most of your time writing other languages which have a standard library, I can understand your opinion.&lt;p&gt;However, I see fragmentation as:&lt;p&gt;1) It introduces the opportunity everyone on the planet to give a shot at implementing something that may or may not be better than we consider today the best. For example I used a datepicker in my latest project but in the current it failed and I could replace it in 15 minutes rather than spending hours finding the issue with the &amp;quot;standard one&amp;quot;. I&amp;#x27;m not really experienced in the C++ world, but I guess people would call me crazy if I proposed a new stdio lib. Maybe there could be better libraries, who knows. It&amp;#x27;s a settled game there. See jQuery in JS land, it was for many years, &amp;quot;the golden tool&amp;quot;. Now we have alternatives for more specialized workflows. Not everybody wears the same hat all the time.&lt;p&gt;2) EcmaScript is constantly evolving, that causes another fragmentation, but this also allows the dev community to propose changes, implement new features and create a really vibrant feedback loop. If you stick to the latest stable (currently ES5) you are safe to build whatever you like with great stability.</text><parent_chain><item><author>omegote</author><text>How can you find the js fragmentation a feature and not a stinking pile of shit? Seriously.</text></item><item><author>kowdermeister</author><text>I don&amp;#x27;t see the need for this to cherry pick a few project and push them with the Linux brand. The JS landscape is fragmented for a good reason and I don&amp;#x27;t see that as problem in fact, rather as a feature. With NPM and YARN we already have a good enough package management system and their platform can help me evaluate if a package is community supported enough. I&amp;#x27;m talking about the stats that I can just check: number of stars, contributors and open&amp;#x2F;closed issue ratios.&lt;p&gt;If someone understood it better than me please add your thoughts.&lt;p&gt;I also don&amp;#x27;t see faces here: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;js.foundation&amp;#x2F;members&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;js.foundation&amp;#x2F;members&amp;#x2F;&lt;/a&gt; Who runs the show?</text></item></parent_chain></comment><story><title>The Linux Foundation Unites the JavaScript Community for Open Web Development</title><url>https://js.foundation/announcements/2016/10/17/Linux-Foundation-Unites-JavaScript-Community-Open-Web-Development/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>onion2k</author><text>There are two schools of thought. The first is that you should optimise for the platform you&amp;#x27;re targeting, so a fragmented JS world is a good thing because you optimise for different things depending on where your code is going to run. The second school of thought is that you should optimise for development, and you should have the same language everywhere even if that means slightly less efficient code.&lt;p&gt;For example, if you write long running services in node then optimising for memory allocation in order to avoid leaks is a good idea. It&amp;#x27;s less useful for clientside things that &lt;i&gt;generally&lt;/i&gt; don&amp;#x27;t run for nearly as long. Conversely, if you write isomorphic JS that can run in the browser but also needs to run on the server for that first-load advantage, then you&amp;#x27;d prefer if things work the same everywhere.&lt;p&gt;Neither school is &amp;#x27;&lt;i&gt;right&lt;/i&gt;&amp;#x27; per se. How a language ought to evolve is incredibly subjective.</text><parent_chain><item><author>omegote</author><text>How can you find the js fragmentation a feature and not a stinking pile of shit? Seriously.</text></item><item><author>kowdermeister</author><text>I don&amp;#x27;t see the need for this to cherry pick a few project and push them with the Linux brand. The JS landscape is fragmented for a good reason and I don&amp;#x27;t see that as problem in fact, rather as a feature. With NPM and YARN we already have a good enough package management system and their platform can help me evaluate if a package is community supported enough. I&amp;#x27;m talking about the stats that I can just check: number of stars, contributors and open&amp;#x2F;closed issue ratios.&lt;p&gt;If someone understood it better than me please add your thoughts.&lt;p&gt;I also don&amp;#x27;t see faces here: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;js.foundation&amp;#x2F;members&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;js.foundation&amp;#x2F;members&amp;#x2F;&lt;/a&gt; Who runs the show?</text></item></parent_chain></comment><story><title>The Linux Foundation Unites the JavaScript Community for Open Web Development</title><url>https://js.foundation/announcements/2016/10/17/Linux-Foundation-Unites-JavaScript-Community-Open-Web-Development/</url></story>