1. 40
  1.  

  2. 38

    Appreciate the honesty here. My take: GitHub stars aren’t real. Twitter followers aren’t real. Likes aren’t real. It’s all a video game. If you want to assess the quality of the code, you have to read it. You can’t rely on metrics except as a weak indicator. I predict there will be services to let you buy Github stars if the current trend of overvaluing them continues.

    The endless self-promotion and programmers-masquerarding-as-brands on Twitter and Medium generates a huge amount of noise for an even larger amount of BS. The only winning move is to not engage.

    1. 9

      This is more true than one might think. There are a couple of projects on GitHub with thousands of stars, some more than all the BSDs source codes combined, with the promise to bring something amazing, while not even having a working proof of concept, and being completely abandoned.

      However, since it is true (to some degree) that having a larger user base in programming historically means that you won’t have to maintain a project on your own in the end it’s easy to be fooled by anything that appears to indicate a large userbase, like GitHub stars.

      Many people use GitHub more like a “might be interesting, let’s bookmark it” or “Wow, so many buzzwords”, etc.

      On the other hand there is quite a few projects that do one thing and do it well. Programmed to solve a problem, with 0-10 stars.

      One might think that are extreme cases, they are only in the sense that 0 stars is the extreme of not being able to have fewer. They are not rare cases.

      Another thing to consider is that GitHub is built a lot like a social network, so you have network effects, where people follow other people and one person liking something results in timelines, causing others to like it to remember to look at it, or “in case I need this some day”, and so one ends up having these explosions. Hackernews, Lobsters, reddit, etc. and in general having someone mention it to a bigger audience can help a lot too - and be it just “I have heard about this, but not looked at it yet”. It appears to be similar to the same story having zero upvotes on one day, and hundreds or thousands on another.

      The rest is probably rooted in human psychology.

      1. 3

        This is what I do. I use stars on Github pretty much only as a bookmarking tool.

      2. 4

        Spot on. On top of the detrimental “programmers-masquerarding-as-brands”, many GH repos are heavily marketed by the companies behind the projects. Covert marketing might be more popular than what people think.

        1. 7

          Corporate OSS is winning the mindshare war. Plenty of devs would rather use a massive framework by $MEGACORP instead of something simple that doesn’t box them in. Pragmatism, they say.

          (Of course, they don’t think twice about pulling in a community-sourced standard library (JS).)

          Favorite example of this was a CTO talking about how they used Sinatra instead of Rails for their API endpoint and the flood of surprised replies, “but what if you need to change feature X?”, to which he said, “well, we understand all of the code, so it’s no big deal. Can you say the same about Rails?”

      3. 11

        Because everyone is looking for a silver bullet and thinks the proper framework should make everything easy. If things are still difficult to implement in a framework, the framework is blamed. Not the intrinsic complexity of the problem, the inconsistent requirements of the customer, the shortcomings of the emergent design (because design was skipped and just appeared) or the implementation that wasn’t refactored nearly often enough. So a new framework is created, this one focused on the problem that was perceived as not easily solvable in the previous framework. And the cycle continues.

        1. 5

          Fun part about a framework: if you’re working in an area it is good at, it often feels like coloring by number. This is either comforting or incredibly boring, depending on your personality.

          There are definite psychological effects on the programmer of using large amounts of automation on a daily basis.

          1. 3

            As a rails dev it often feels like just plugging gems together because everything has been done before. I get very excited at work when there is no gem that exists to do what I need.

            1. 1

              I was thinking of Rails when I made that comment. I don’t expect work to be exciting or fulfilling but somehow I don’t mesh with Rails at all. Feels like I’m playing in DHH’s conceptual sandbox.

        2. 11

          I think that Javascript is part of the problem. It lacks a large standard library so people are out there reinventing the wheel. It would be nice if browsers created a better base for people to work with.

          1. 2

            Isn’t that basically what JQuery is?

            1. 2

              Exactly. If a library became so universal as to nearly be default, why not elevate the most imporant parts of it into a standard library that is preloaded on all browsers?

              Since JavaScript is sent over the wire with each invocation it cares more about “binary” size than the average language.

              1. 2

                FWIW this seems to have happened with some ideas from jQuery. See e.g. document.querySelectorAll.

                1. 1

                  What I think JS and the HTTP in general needs is fetching content from hashes instead of URLs. That way if everyone uses the same library it may as well be preloaded because the browser will be able to identify that it already has the same resource without having to centralize files on a CDN

                  1. 3

                    Cue IPFS

                    1. 1

                      I’ve had the same thought - turns out this is non-trivial to tack on to HTTP after the fact. See w3c/webappsec-subresource-integrity#22 and https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html (I haven’t read either of them in a while, but there you go).

                2. 1

                  I do think that there’s space for a JS standard library

                  The big difficulty is that front-end development is still looking for what “the wheel” is. And there are different paradigms depending on what kind of system you’re building and the resource constraints.

                  To be honest I think a lot of the glibness for web UIs ignores that many web UIs are miles more complex than what most native GUIs accomplish. Very few native apps have the variety involved in a facebook-style “stream of events” UI. And a lot of web UIs are these kinds of streams of events.

                  1. 2

                    There is a lot of room at the framework level for various different solutions. I was thinking of really basic utilities. Solutions to the “left-pad” problem. I think JavaScript didn’t have a function for properly checking if an object was an array until ECMAScript 5.1. It’s hard to build on top of shaky fundamentals.

                    A lack of history with modules and some notion of compilation (bundling) also hurts JavaScript. The tool chain exists now, but it has felt a bit uninviting in my limited experience.

                    So we’ve ended up with a small standard library and primitive ways of combining scripts. It’s no wonder that things are so chaotic.

                    1. 1

                      FWIW, left-pad-like functionality has been in the standard library since ES2017: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/padStart

                      Tiny stuff like that isn’t too hard to put in the standard library. But the stuff that frameworks do is too high-level, abstract, and opinionated.

                3. 3

                  It reminds me how Perl used to be: Catalyst had hundreds of prereqs(like Moose and Dbic), each being a constantly moving target, framework being just the glue holding loose parts together. Mojolicious by @kraih was an effort to create more consistent solution by creating in-house modules. It was successful in reducing the fadtigue and flattening the learning curve. What was different is that Perl5 was a mature and stable language back then with the Camel Book and excellent documentation.

                  1. 1

                    But why everyone blame npm and “micro-libraries” as the main problem in js? Aren’t all other languages (except C/C++) has the same way of dealing with dependencies? Even in conservative Java installing hundreds of packages from Maven is norm.

                    1. 10

                      Something to consider is that JavaScript has an extreme audience. People who barely consider themselves programmers, because they mostly do design use it, or people just doing tiny modifications. Nearly everyone building a web application in any kind of language, framework, etc. uses it.

                      I think the reason there is so much bad stuff in JavaScript is not only something rooted in language design. JavaScript isn’t so much worse than other popular bad languages, it just has a larger base having even more horrible programmers and a lot of them also build some form of frameworks.

                      Don’t get me wrong, JavaScript is not a great language by any stretch, but blaming the ecosystem of a language who certainly has at least a few of the bright minds designing and implementing (working at/with Google, Mozilla and Joyent for example) it should not result in something so much more unstable.

                      Of course this doesn’t mean that it’s not about the language at all either. It’s just that I have yet to see a language where there isn’t a group writing micro-libraries, doing bad infrastructure, doing mostly worst-practice, finding ways, to work around protections to not shoot yourself in the foot, etc. Yes, even in Python, Rust, Go, Haskell and LISP that exists.

                      Maybe it’s just that JavaScript has been around for ages, many learned it do so some animated text, they wrote how they did it, there is a ton of bad resources and people that didn’t really learn the language and there is a lot of users/developers that also don’t care enough, after all it’s just front-end. Validation happens on the server and one wants to do the same sending off some form and loading something with a button, updating some semi-global state anyway.

                      JavaScript is used from people programming services and systems with it (Joyent, et al.) to a hobby web designer. I think that different approaches also lead to very different views on what is right and what isn’t. Looking at how it started and how the standards-committee has to react to it going into backend, application and even systems programming direction probably is a hard task and it’s probably a great example of how things get (even) worse when trying to be the perfect thing for everything, resulting in the worst.

                      On a related note: I think the issue the community, if you even can call it like that (there are more communities around frameworks rather than the language itself, which is different from many other scripting languages) doesn’t seem to look at their own history too much, resulting in mistakes to be repeated, often “fixing” a thing by destroying another, sometimes even in different framework-layers. For example some things that people learned to be bad in plain JavaScript and HTML get repeated and later learned to be bad using some framework. So one starts over and builds a new framework working around exactly that problem, overlooking other - or intentionally leaving them out, because it wasn’t part of the use case.

                      1. 2

                        there are more communities around frameworks rather than the language itself, which is different from many other scripting languages

                        In general I tend to agree, but at least at some time ago I am pretty sure the Rails community was larger than the Ruby community. The Django community in Python also seems to be quite big vocal, but probably not larger than its language community given that the Python community is overall way more diversified and less focused on one particular use of the language.

                      2. 9

                        A lot of Java frameworks predate maven - e.g. Spring was distributed as a single enormous jar up until version 3 or so, partly because they didn’t expect everyone to be using maven. I think there’s still a cultural hangover from that today, with Java libraries ending up much bigger than those in newer languages that have had good package management from early on (e.g. Rust).

                        1. 5

                          Even including all transitive libraries, my (quite large) Android app Quasseldroid has 21 real dependencies. That’s for a ~65kLOC project.

                          In JS land, even my smallest projects have over 300 transitive dependencies.

                          It’s absolutely not the same.

                          1. 3

                            In technical terms, npm does not differ much from how python does package management. Culturally, however, there are a big difference in how package development is approached. Javascript has the famous left-pad package (story). It provided a single function to left-pad a string with spaces or zeroes. Lots of javascript libraries are like it, providing a single use case.

                            Python packages on the other hand usually handle a series of cases or technical area - HTTP requests, cryptography or, in the case of left-pad, string manipulation in general. Python also has PEP8 and other community standards that mean code is (likely to be) more homogeneous. I am using python here as that is what I know best.

                            1. 1

                              Because npn micro-libraries tends to be much worse than most other languages.

                              1. 1

                                It’s a problem there too.